The evolution of the application server on NodeJS
In our system 2 servers peacefully coexist. The main server (core), written in JAVA and the application server - NodeJS, this article is dedicated to him.
Initially, the application server had 2 fundamental tasks:
1) proxying requests to the main server in order to reduce non-specific workload and save resources for more important tasks;
2) implementation of client-specific functionality so that you do not have to make changes to the kernel code when client-side applications appear.
Strictly speaking, the presence of an application server is not at all necessary for the functioning of the system, since The kernel has a full-fledged REST API that implements all the main functionality of the system. A few words about the protocol. RTLSCP (real track location system communication protocol) is a protocol that works over HTTP and allows you to receive data and perform basic operations with the RealTrac system using requests and responses in JSON / KML / PNG format.
The basic part of the RTLSCP is divided into 3 subsets:
')
● RTLSCP REST API (synchronous resources)
● RTLSCP WebSocket API (streaming data)
● RTLSCP Asynchronous API (asynchronous commands)
Thus, anyone can download their application server or connect to the kernel directly and use the basic features of the system. But there were few such enthusiasts. Therefore, the fourth subset is RTLSCP Ext, a protocol extension implemented by an application server with client-specific functionality.
Most of the clients were interested not only in the information coming in real time, because for use in business processes quite often an array of data is used for a certain period of time, or more simply, history. In this regard, a significant part of the RTLSCP Ext functional was made up of work with saving and pre / post-processing of data for the needs of a specific customer. The need to keep history led to the appearance of the database on the application server side. Time passed, internal data structures changed, new ones appeared. The format of data storage changed, customer needs grew. After all, everyone wants reports to be collected faster and at the same time take up less space. All this led to the complication of the database structure, server architecture and the complication of its support. The increase in the volume of data processed led to an increase in the load on the server, and the single-threading of NodeJS led to a slower operation of the server, and there was no longer any asynchrony.
At first, performance problems were solved by running additional workers for specific tasks. For this, the standard cluster module was used. At first, it helped and for a while everyone was happy.
Later, an understanding came that this was not enough for us and there was a desire to parallelize the execution of a number of tasks. But the existing architecture did not allow to make such a freebie. Also, situations often arose in which one had to take care of data synchronization between runners being started, and the exchange of large amounts of data was not very smooth ... It was very lazy to support all this heterogeneous and very cumbersome “good”.
In connection with these and some other fundamental problems, it was recently decided to change the architecture of the system as a whole and the application server in particular.
Based on the current situation, the following requirements were made for the new architecture:
1. simplicity of parallelization of tasks performed,
2. modular system architecture.
After extensive deliberation, it was decided to use an event-oriented architecture. In particular, use the model of actors that communicate with each other through a common global bus. This approach allows you to distribute the load and at the same time to obtain an easily scalable solution.
In classical theory, an actor is an entity with the following properties:
● Actors can create a finite number of messages
● Actors can create a finite number of other actors,
● Actors can perform some manipulations with the data that comes to them at the input.
The philosophy or model of actors assumes that everything around is an actor, which is partially similar in the PLO model, but it is assumed that the sequence of creating actors or exchanging messages between them is not defined.
In the course of its livelihoods, the actor, on the basis of the incoming data, performs some calculations and produces a new piece of data, in which they are more like “pure functions” than objects. The main advantage of the actors is the finiteness of actions and parallelism. Ideally, an actor is an entity that does not depend on anything and does not know anything about the environment in which it operates.
Data exchange between actors occurs through the exchange of messages through a common bus. Messages can be addressed, for this the actor must know the details of the addressee, or broadcast.
The event-driven architecture is extremely loosely coupled and well distributed. It has an asynchronous nature, since the order of processing or delivery of messages is not regulated in any way.
Findings.
What are the advantages and disadvantages in combat, we will not get this from yet, since the new architecture has not yet been fully implemented, but it is already clear that the code has become cleaner, more transparent and simpler. Adding new functionality came down to adding a couple of new events and their handlers. The server has become truly modular. The first load tests are also encouraging.
PS: As for me, micromodular architecture is a promising approach for implementing projects on Node.js and not only. This approach allows you to write more simple and transparent code. Do not forget that the use of small modules allows you to simplify the procedure for writing tests and speed up the localization of errors.
Initially, the application server had 2 fundamental tasks:
1) proxying requests to the main server in order to reduce non-specific workload and save resources for more important tasks;
2) implementation of client-specific functionality so that you do not have to make changes to the kernel code when client-side applications appear.
Strictly speaking, the presence of an application server is not at all necessary for the functioning of the system, since The kernel has a full-fledged REST API that implements all the main functionality of the system. A few words about the protocol. RTLSCP (real track location system communication protocol) is a protocol that works over HTTP and allows you to receive data and perform basic operations with the RealTrac system using requests and responses in JSON / KML / PNG format.
The basic part of the RTLSCP is divided into 3 subsets:
')
● RTLSCP REST API (synchronous resources)
● RTLSCP WebSocket API (streaming data)
● RTLSCP Asynchronous API (asynchronous commands)
Thus, anyone can download their application server or connect to the kernel directly and use the basic features of the system. But there were few such enthusiasts. Therefore, the fourth subset is RTLSCP Ext, a protocol extension implemented by an application server with client-specific functionality.
Most of the clients were interested not only in the information coming in real time, because for use in business processes quite often an array of data is used for a certain period of time, or more simply, history. In this regard, a significant part of the RTLSCP Ext functional was made up of work with saving and pre / post-processing of data for the needs of a specific customer. The need to keep history led to the appearance of the database on the application server side. Time passed, internal data structures changed, new ones appeared. The format of data storage changed, customer needs grew. After all, everyone wants reports to be collected faster and at the same time take up less space. All this led to the complication of the database structure, server architecture and the complication of its support. The increase in the volume of data processed led to an increase in the load on the server, and the single-threading of NodeJS led to a slower operation of the server, and there was no longer any asynchrony.
At first, performance problems were solved by running additional workers for specific tasks. For this, the standard cluster module was used. At first, it helped and for a while everyone was happy.
Later, an understanding came that this was not enough for us and there was a desire to parallelize the execution of a number of tasks. But the existing architecture did not allow to make such a freebie. Also, situations often arose in which one had to take care of data synchronization between runners being started, and the exchange of large amounts of data was not very smooth ... It was very lazy to support all this heterogeneous and very cumbersome “good”.
In connection with these and some other fundamental problems, it was recently decided to change the architecture of the system as a whole and the application server in particular.
Based on the current situation, the following requirements were made for the new architecture:
1. simplicity of parallelization of tasks performed,
2. modular system architecture.
After extensive deliberation, it was decided to use an event-oriented architecture. In particular, use the model of actors that communicate with each other through a common global bus. This approach allows you to distribute the load and at the same time to obtain an easily scalable solution.
In classical theory, an actor is an entity with the following properties:
● Actors can create a finite number of messages
● Actors can create a finite number of other actors,
● Actors can perform some manipulations with the data that comes to them at the input.
The philosophy or model of actors assumes that everything around is an actor, which is partially similar in the PLO model, but it is assumed that the sequence of creating actors or exchanging messages between them is not defined.
In the course of its livelihoods, the actor, on the basis of the incoming data, performs some calculations and produces a new piece of data, in which they are more like “pure functions” than objects. The main advantage of the actors is the finiteness of actions and parallelism. Ideally, an actor is an entity that does not depend on anything and does not know anything about the environment in which it operates.
Data exchange between actors occurs through the exchange of messages through a common bus. Messages can be addressed, for this the actor must know the details of the addressee, or broadcast.
The event-driven architecture is extremely loosely coupled and well distributed. It has an asynchronous nature, since the order of processing or delivery of messages is not regulated in any way.
Findings.
What are the advantages and disadvantages in combat, we will not get this from yet, since the new architecture has not yet been fully implemented, but it is already clear that the code has become cleaner, more transparent and simpler. Adding new functionality came down to adding a couple of new events and their handlers. The server has become truly modular. The first load tests are also encouraging.
PS: As for me, micromodular architecture is a promising approach for implementing projects on Node.js and not only. This approach allows you to write more simple and transparent code. Do not forget that the use of small modules allows you to simplify the procedure for writing tests and speed up the localization of errors.
Source: https://habr.com/ru/post/283390/
All Articles