There is a central server that will receive requests from users and exchange with servers, depending on the need to contact a particular server.

It would be good to know what is best to use and how. That is, sockets or http requests, TCP etc., etc. Links to resources where you can read about a particular implementation. Well, and of course an invaluable experience.

On servers node will turn, from DB on central mysql , and on minor mongodb .

    1 answer 1

    Use the technology that you know well , and of course it should be popular enough so that you can easily find a developer.

    I will describe a fairly typical situation:

    usually the server system consists of a fairly large number of interconnected components, these are:

    • Database,
    • the queues
    • web servers
    • proxy servers
    • balancers,
    • monitoring systems
    • reservations

    All this needs to be deployed, configured, filled with test data. And then periodically update and rebuild, since many components are in active development. By the way, the complexity and heterogeneity of the server system implies the need to somehow manage this complexity. These are various systems of deployment, management, configuration, monitoring, diagnostics, collection, analysis and storage of logs. Sometimes, the development of these infrastructural components has to spend the lion's share of time and effort.

    Do not forget about scalability. When there is a serious influx of users. The load on the server system increases. One of the subsystems (usually the database) is slightly degraded due to the increased load, starts to respond more slowly or ceases to fit in at a reasonable response time. As a result, the total processing time of a single request on the business logic server increases, which, in turn, leads to an increase in the number of simultaneously working workflows. The server is running out of free memory, the operating system, trying to serve an increased number of processes, is now mainly engaged in context switching and shuffling pages in memory. This worsens the situation even more. Here the balancer is involved in the business, throwing the dull server out of the load and thereby increasing the load on the servers remaining in the line. Congratulations, our site is laid down, and raising it without removing the load will be very problematic.

    It is clear that such situations usually arise only at the very beginning of the development of a new service. In the future, either the developers correct the lack of the system, or the service is gradually bent.

    In order to successfully experience such excesses, the server software must be sufficiently "elastic" and scalable. Then the growth of the load will not lead to the failure of the service entirely, but, for example, only to a slight degradation in the speed of processing requests. In this case, the temporary increase in load can simply wait, and if the load has increased forever (that is, the service has become more popular), it is enough to compensate for it by delivering the required number of servers. Sometimes for this it is necessary to seriously rework the architecture of the entire application, purposefully looking for and eliminating the bottlenecks of the system.