Structure and background:
There is currently a system. Its structure is different from the general B/S. That is, there is a layer at the bottom (it is said to be a layer, but it is actually a separate program). This layer is winform. Program, let's use "exchange" to represent it. It is mainly used to communicate with "external", send, receive and process some information. No details will be given.
Then the current structure of the system is:
client--web server (presentation layer--logic layer--data access layer)--database--exchange--externally
some "real-time" communication is required at some point (of course It is real-time. In fact, it is impossible to do like CS, which is just a timer on the "client"), and the data sent by the "external" can be displayed in a timely manner to the "client" or the data sent by the "client" can be sent to the "client" in a timely manner. external". We call this "real-time communication". Most of the time, "external" data is directly stored in the database by "exchange" for later use. We call it "regular communication".
There are currently two options:
First, whether it is "real-time communication" or "regular communication", "exchange" all data received from the outside to the database, the client regularly goes to the web server, and the web server goes to the database to get the data, and then returns. The client's data is also sent directly to the database, and then "exchanged" to read the data and forwarded to the "external". Specifically, it is the line picture above.
This has higher requirements on the database, because all data passes through the database, involving a large amount of data exchange and table operations. I don’t know if SQL2005 can withstand it.
2. For "real-time communication", the "switching" layer is used as the remoting server, and the web server is used as the remoting client. That is to say, the web server communicates directly with the "exchange" program. At this time, the data is stored in the memory of the computer where the "exchange" program is located, and the client still looks for the web server regularly. "Regular communication" is still handled according to the first method. The specific structure is to add a branch to the above line for the Web server to directly communicate with the "exchange". When needed (that is, during "real-time communication") the data will go through this branch.
Are there any problems with this approach? I'm not familiar with remoting, and I have no idea what the performance of such a structure can be.
Difference:
Between these two methods, there is nothing wrong with the structure of the "regular communication" part. The key is the "real-time communication" part. Simply put, it means whether the data comes from the database or the web server communicates directly with the "exchange".
Now we need to consider what kind of structure to adopt. The requirements are:
One server cannot be under too much pressure, otherwise the system cannot bear it. (The amount of "external" concurrency is very large)
The performance requirements for the "real-time communication" part are very high.
Note:
The BS structure has been determined and cannot be changed. (The company's previous projects were C/S, and now it wants to transition to B/S)
There is no problem with the second hardware, and each piece is a separate high-configuration server.
Third, everyone may not have a clear understanding of the "exchange" part. In fact, it is responsible for many functions and the pressure will be very high. Of course it is also a separate server.
Some configurations are basically as follows: Windows2003, MS-SQL2005, VS2005, etc., all are enterprise editions.
Question:
Which of the above methods 1 and 2 has better structural performance? (Mainly considering the performance of the "real-time" part, let's not talk about anything else for now)
2. Is there any other feasible structure? Or technology?
3. Some things may not be clear to me, please leave a message and I will reply as soon as possible.
4. Do you have any friends who do GPS positioning? Please leave your contact information and ask questions.