Distributed futures trading service system based on stateless micro-service architecture of restful api

Abstract

The application provides a distributed futures transaction service system based on a stateless micro-service architecture of RestfulApi, which comprises a front routing service, a relay transaction service, a market data collection service, a market data service, a tidb distributed database and a codis in-memory distributed database. The front routing service provides a stateless interface based on RestfulApi, supports multi-node parallel expansion and dynamic load adjustment; the relay transaction service integrates mainstream futures SDK and interacts with the counter system through an asynchronous communication mechanism; the market data collection service collects dynamic market data and writes the dynamic market data into the codis in-memory distributed database; the market data service reads the dynamic market data and provides an api interface to the outside; the tidb distributed database stores user account information, and the codis in-memory distributed database stores commission returns, transaction returns and dynamic market data. Each module cooperates to realize high-concurrency, low-latency, high-availability and multi-modal futures transaction request processing and return information management.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of financial transactions, in particular to a distributed futures transaction service system based on a stateless micro-service architecture of RestfulApi. BACKGROUND

[0002] In the field of financial technology, the futures transaction service system, as the core hub connecting investors and futures desks, its stability, efficiency and scalability directly affect the transaction efficiency and user experience. With the continuous growth of futures market trading volume, the continuous enrichment of trading varieties, and the improvement of investors' requirements for transaction delay and system availability, the traditional futures transaction service system has been difficult to meet the current market demand.

[0003] The traditional futures transaction service system mostly adopts a single-point running architecture. Once the deployment machine is down, the entire system is paralyzed and cannot handle transaction requests, resulting in the failure of investor transaction instructions and poor system disaster recovery capability. At the same time, the interface design of the traditional system has a state feature and is highly dependent on session management. The service nodes cannot achieve equal cooperation, and it is difficult to cope with high concurrency scenarios by increasing nodes, and single-point failure will directly affect the overall service operation.

[0004] In terms of module interaction and interface adaptation, when the traditional system interfaces different futures desks, it needs to separately develop integrated functions for the exclusive sdk provided by each desk, which has a long development cycle and high cost. The exposed interface lacks a unified standard, and repeated development and adaptation codes are needed in different interfacing scenarios. In addition, the relay service and pre-service in the traditional system have high coupling degree, the interface design is limited by external access, and the flexibility is insufficient. Moreover, the user request forwarding lacks efficient algorithm support, which is prone to problems such as uneven load and repeated connection establishment, resulting in resource waste and low data processing efficiency.

[0005] In terms of multi-account login and resource utilization, the traditional system only supports one set of appid and authorization code to log in to the futures desk. If multiple sets of appid and authorization code are needed, additional machines must be applied to redeploy the relay service system, causing serious waste of server resources. At the same time, the traditional system has a single request mode, relying mainly on single http requests, which cannot achieve persistent two-way communication and cannot actively push real-time information flow data such as transaction returns and commission returns to users, affecting users' real-time control over transaction progress.

[0006] In terms of data storage, the traditional system mostly uses single-machine databases or simple cluster storage solutions, and capacity expansion relies on upgrading single-machine hardware, which is costly and difficult to achieve large-scale data smooth expansion. At the same time, the number of data replicas is limited, and single-point failure may cause data loss or unavailability.

[0007] Through the retrieval of patent documents, it is found that the patent for an invention with publication number CN113065953A discloses a futures relay transaction system based on distribution, which realizes full deployment in futures companies, all user data are stored in the futures company computer room, and the triggering of cloud conditional orders is based on the transaction state of the counter, without the need for server time calibration to ensure the normal triggering of conditional orders. The technical solution is that the system is composed of a pre-module, a transaction system and a data storage module, the transaction system includes a message middleware unit and a cloud conditional order processing cluster unit, the message middleware unit is configured to process the communication between the transaction cluster unit and the bid cluster unit, and to provide support for the expansion of the transaction cluster unit and the bid cluster unit, and the cloud conditional order processing cluster unit is configured to process the operations of adding, deleting, modifying, inquiring and triggering of cloud conditional orders. Although the patent uses a distributed architecture to improve the availability of the system to some extent, it does not give effective solutions to the problems of stateful interface design, dependence on session session, repeated development for different counters, non-uniform interface, etc., and it does not involve multi-account login resource utilization and diversified request methods.

[0008] In view of the above problems of the prior art, it is a key task to study a distributed futures transaction service system based on a stateless micro-service architecture of RestfulApi. SUMMARY

[0009] In view of the defects in the prior art, the purpose of the present application is to provide a distributed futures transaction service system based on a stateless micro-service architecture of RestfulApi.

[0010] According to the distributed futures transaction service system based on the stateless micro-service architecture of RestfulApi, the system includes a market module, a transaction module and a shared storage database.

[0011] The transaction module includes a pre-routing service and a relay transaction service, the pre-routing service is used to receive interface call requests from the client and forward the interface call requests to the relay transaction service, the relay transaction service is used to receive the interface call requests, interact with the counter system to generate transaction processing results, and feed back the transaction processing results to the pre-routing service, and the pre-routing service is also used to return the transaction processing results from the relay transaction service to the client.

[0012] The market module includes a market collection service and a market service, the market collection service is used to collect dynamic market data from the counter system and write it into the shared storage database, and the market service is used to read the dynamic market data from the shared storage database and provide a market api interface to the outside.

[0013] The shared storage database includes a tidb distributed database and a codis memory distributed database.

[0014] Preferably, the front-end routing service includes a plurality of parallel deployed routing service nodes, which provide a stateless interface based on a Restful API to receive interface call requests from clients.

[0015] Preferably, the relay transaction service includes a plurality of parallel deployed relay transaction service nodes, and the routing service nodes determine a target relay transaction service node for processing the interface call request from the plurality of relay transaction service nodes according to the type of the interface call request by using a consistent hashing algorithm or a matching pattern algorithm, and forward the interface call request to the target relay transaction service node.

[0016] Preferably, the type of the interface call request includes a user login request and a non-login request, for the received user login request, the front-end routing service performs a hash calculation on a user account ID in the interface call request by using a consistent hashing algorithm to determine a relay transaction service for processing the request, and for the received non-login request, the front-end routing service performs a matching pattern algorithm to query a pre-stored user account ID and relay transaction service routing mapping table according to a user account ID in the non-login request to determine a relay transaction service for processing the non-login request.

[0017] Preferably, the process of forwarding the request by using the consistent hashing algorithm includes the following steps:

[0018] Step a1, the front-end routing service receives a user login request and obtains user ID data in the user login request;

[0019] Step a2, the front-end routing service performs a hash function calculation on the user ID data to obtain a hash value;

[0020] Step a3, the front-end routing service determines a target relay transaction service node according to a mapping relationship between the hash value and a hash value range of each relay transaction service node;

[0021] Step a4, the front-end routing service forwards the user login request to the target relay transaction service node;

[0022] Step a5, after the target relay transaction service node completes the login, the user ID, seat, and target relay transaction service node name information are written into a Codis memory distributed database as a routing mapping relationship.

[0023] Preferably, the process of forwarding the request by using the matching pattern algorithm includes the following steps:

[0024] Step b1, the pre-routing service receives the non-login request and obtains the user ID and seat information in the non-login request;

[0025] Step b2, the pre-routing service queries the routing mapping relationship stored in the Codis in-memory distributed database with the user ID-seat information combination as the key to obtain the relay transaction service node name corresponding to the user login;

[0026] Step b3, the pre-routing service adds the user ID, seat information and relay transaction service node name to the non-login request and forwards the non-login request to the relay transaction service node.

[0027] Preferably, the relay transaction service node integrates a futures SDK, after receiving the interface call request, the relay transaction service node interacts with the counter system through an asynchronous communication mechanism, generates a transaction processing result, and feeds back the transaction processing result to the routing service node sending the interface call request, the transaction processing result includes user account information, commission return data and transaction return data; the relay transaction service node writes the user account information into the tidb distributed database and writes the commission return data and transaction return data into the codis in-memory distributed database.

[0028] Preferably, the relay transaction service node reads the seat parameters in the preset environment variables of itself, and uses the seat parameters to control the interface path for interacting with different counter systems, the process of realizing the interface path includes the following steps:

[0029] Step c1, setting the seat environment variable in the running environment of the relay transaction service node;

[0030] Step c2, the relay transaction service node reads the value of the seat environment variable when starting;

[0031] Step c3, the value of the seat environment variable is spliced as a prefix to the head of each interface path to realize dynamic adjustment of the interface path;

[0032] Step c4, the relay transaction service node registers the service path of the provided futures interface to the system.

[0033] Preferably, the relay transaction service node supports using multiple sets of appid and authorization codes to log in to the counter system on the same service node or different service nodes, including the following steps:

[0034] Step d1, configuring multiple sets of appid and authorization codes in the configuration information of the relay transaction service node;

[0035] Step d2, the relay transaction service node loads multiple sets of appid and authorization code information into the service program when starting;

[0036] Step d3, when requesting to call the login interface, the appid parameter is reported, the relay transaction service node queries the authorization code corresponding to the appid parameter, and initiates login to the counter system using the appid parameter and the authorization code.

[0037] Preferably, the market collection service interacts with the counter system through integrated futures sdk to collect dynamic market data, and writes the dynamic market data into the codis memory distributed data; the market service includes a plurality of parallel deployed market service nodes, the market service node reads the dynamic market data from the codis memory distributed database, and provides the dynamic market data to the outside through a dynamic market api interface, and the dynamic market api interface supports single request based on the Http protocol and subscription push based on the WebSocket protocol.

[0038] Compared with the prior art, the application has the following beneficial effects:

[0039] 1. In view of the problems of stateful, session-dependent and single-point operation of the traditional futures transaction service interface, the pre-routing service in the application is designed as a stateless interface based on Restful Api, without session management, and the logic code is simple; the pre-routing service supports multi-node parallel expansion, can cope with high-concurrency scenarios by increasing server nodes, automatically routes requests to other healthy nodes when a single node fails, avoids the influence of single-point failure on the overall service operation. At the same time, the Restful Api interface is naturally compatible with the http protocol, supports cross-platform and cross-device access, does not limit the development language of the connected party, and reduces the development cost of connection.

[0040] 2. The pre-routing service of the application is responsible for providing interface services to external customers, uses a consistent hashing algorithm and a matching mode algorithm to complete request forwarding, and realizes stateless design of the interface. Among them, the login interface performs hash operation on the user account ID through the consistent hashing algorithm, disperses the user login request to different relay transaction service nodes, and realizes request transfer to the normal relay transaction service node when the node fails, ensures that the same user is only logged in to one relay transaction service node, and avoids resource waste. Except for the login, other interfaces use the matching mode algorithm, accurately forward non-login requests to the node where the user has logged in through the query routing mapping table, reuse the existing SDK connection, avoid repeated connection, save resource overhead, reduce network interaction, and improve data processing efficiency.

[0041] 3、The relay transaction service integrates multiple SDKs in the application, provides a unified transaction interface for the front routing service to call, and is more flexible in interface design because it is not exposed externally; the relay transaction service controls the interface path prefix by reading the environment variable seat, and the seat variable needs to be reported as a request parameter when calling all interfaces; the relay transaction service is responsible for forwarding user queries, order placement and other requests to the counter, decouples the business functions of the front routing service, improves the overall system performance, and reduces the code maintenance cost.

[0042] 4、In view of the problems of single-point operation and poor disaster recovery capability of the traditional futures transaction service, the application is based on a micro-service distributed architecture, and the front routing service, the relay transaction service and the market service all support parallel horizontal expansion: three servers are the minimum unit for system operation, allowing the system to operate normally when one server is down, five servers allowing two servers to be down, and so on; when the server resources are sufficient, it can be expanded to thousands of nodes, the transaction request processing delay is ≤50ms, and the system availability and processing capacity are improved.

[0043] 5、In view of the problem that the traditional system needs to be repeatedly developed and the interface is not unified when connecting different counters, the application realizes a standardized external interface through a Restful Api, the interface is unified, and new counter SDK or business module can be quickly accessed, and the developer does not need to redevelop, saving development time and cost.

[0044] 6、In view of the problem that multiple sets of appid and authorization code login in the traditional system need to be deployed on additional machines, wasting resources, the application supports multiple sets of appid and authorization code login in the same set of machine environment, i.e. the number of service nodes remains unchanged, saving machine resource overhead; at the same time, it supports increasing relay transaction service nodes to realize multiple sets of appid and authorization code login, and realizes physical isolation of services corresponding to different appid and authorization code.

[0045] 7、The application supports two request modes of http single request and websocket long connection, websocket is based on TCP protocol, provides reliable transmission, has the characteristics of persistence, bidirectional communication and low delay, and can actively push information flow data such as transaction return and order return to the user.

[0046] 8、The application adopts a distributed database scheme, realizes capacity expansion by increasing nodes, supports smooth expansion from TB level to PB level data; data is automatically replicated to multiple node copies, and when a single point fails, it is automatically switched to an available node, maximizing data availability. BRIEF DESCRIPTION OF DRAWINGS

[0047] Other features, objects and advantages of the application will become more apparent through reading the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0048] Other features, objects and advantages of the application will become more apparent through reading the following detailed description of non-limiting embodiments with reference to the accompanying drawings:Figure 1 A distributed futures transaction service system based on a stateless micro-service architecture of RestfulApi for an embodiment of the present application is shown in the schematic diagram.

[0049] Figure 2 A user login request consistency hash algorithm flowchart for an embodiment of the present application is shown in the flowchart.

[0050] Figure 3 A pre-routing service matching mode algorithm flowchart for an embodiment of the present application is shown in the flowchart.

[0051] Figure 4 A matching mode request forwarding flowchart for an embodiment of the present application is shown in the flowchart.

[0052] Figure 5 A prefix design diagram for an embodiment of the present application in which a relay transaction service dynamically adjusts an interface path according to an environment variable seat is shown in the diagram.

[0053] Figure 6 A relay transaction service cluster configuration scheme 1 for an embodiment of the present application is shown in the schematic diagram.

[0054] Figure 7 A relay transaction service cluster configuration scheme 2 for an embodiment of the present application is shown in the schematic diagram. DETAILED DESCRIPTION

[0055] The present application will be described in detail below with specific embodiments. The following embodiments will help those skilled in the art to further understand the present application, but do not limit the present application in any form. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present application. These are within the scope of protection of the present application.

[0056] The present application discloses a distributed futures transaction service system based on a stateless micro-service architecture of RestfulApi, which comprises a pre-routing service, a relay transaction service, a market data collection service, a market data service, a tidb distributed database and a codis in-memory distributed database. The pre-routing service provides a stateless interface based on Restful Api, supports multi-node parallel expansion and dynamic load adjustment; the relay transaction service integrates mainstream futures sdk and interacts with the counter system through an asynchronous communication mechanism; the market data collection service collects dynamic market data and writes it into the codis in-memory distributed database; the market data service reads dynamic market data and provides an api interface to the outside; the tidb distributed database stores user account information, and the codis in-memory distributed database stores commission returns, transaction returns and dynamic market data. Each module cooperates to realize high-concurrency, low-latency, high-availability and multi-modal futures transaction request processing and return information management.

[0057] Embodiment 1:

[0058] Figure 1 A distributed futures trading service system based on a stateless micro-service architecture of Restful Api is provided in the embodiments of the present application.

[0059] As shown in Figure 1 , the distributed futures trading service system based on the stateless micro-service architecture of Restful Api includes a market module, a transaction module, and a shared storage database. The transaction module includes a front routing service and a relay transaction service.

[0060] The front routing service is configured to receive an interface call request from a client and forward the interface call request to the relay transaction service.

[0061] Specifically, the front routing service includes a plurality of routing service nodes deployed in parallel. The routing service nodes are configured to provide a stateless interface based on Restful Api to receive the interface call request from the client.

[0062] Since the routing service nodes are in an equal relationship, all stateless interfaces are provided by the routing service nodes, achieving multi-path multi-active. The front routing service module dynamically adjusts the number of nodes according to the load, improving the system disaster recovery capability.

[0063] The relay transaction service is configured to receive the interface call request, interact with a counter system to generate a transaction processing result, and feed back the transaction processing result to the front routing service.

[0064] Specifically, the relay transaction service includes a plurality of relay transaction service nodes deployed in parallel. The routing service nodes determine a target relay transaction service node for processing the interface call request from the plurality of relay transaction service nodes according to the type of the interface call request by using a consistent hashing algorithm or a matching pattern algorithm, and forward the interface call request to the target relay transaction service node.

[0065] In the embodiments, the type of the interface call request includes a user login request and a non-login request.

[0066] For the received user login request, the front routing service performs a hash calculation on a user account ID in the interface call request by using a consistent hashing algorithm to determine the relay transaction service for processing the request. For the received non-login request, the front routing service uses a matching pattern algorithm to query a pre-stored user account ID and relay transaction service routing mapping table according to the user account ID in the non-login request to determine the relay transaction service for processing the non-login request.

[0067] The shared storage database includes a tidb distributed database and a codis in-memory distributed database. Figure 2A consistent hashing algorithm flowchart for user login request, Figure 3 A matching pattern algorithm flowchart for pre-routing service, Figure 4 A request forwarding flowchart for matching pattern.

[0068] As Figure 2 shown, the process of completing request forwarding by using consistent hashing algorithm includes the following steps:

[0069] Step a1, the pre-routing service receives the user login request and obtains the user ID and other data in the user login request;

[0070] Step a2, the pre-routing service calculates the hash value of the user ID data by using hash function;

[0071] Step a3, the pre-routing service determines the target relay transaction service node according to the mapping relationship between the hash value and the hash value range of each relay transaction service node;

[0072] Step a4, the pre-routing service forwards the user login request to the target relay transaction service node;

[0073] Step a5, after completing login, the target relay transaction service node writes the user ID, seat, and target relay transaction service node name information as routing mapping relationship into the Codis in-memory distributed database storage.

[0074] As Figure 3 , 4 shown, the process of completing request forwarding by using matching pattern algorithm includes the following steps:

[0075] Step b1, the pre-routing service receives the non-login request and obtains the user ID and seat information in the non-login request;

[0076] Step b2, the pre-routing service queries the routing mapping relationship stored in the Codis in-memory distributed database with the user ID-seat information combination as the key, and obtains the relay transaction service node name corresponding to the user login;

[0077] Step b3, the pre-routing service adds the user ID, seat information, and relay transaction service node name to the non-login request, and forwards the non-login request to the relay transaction service node.

[0078] Further, the relay transaction service node integrates futures sdk, after receiving the interface call request, the relay transaction service node interacts with the counter system through asynchronous communication mechanism, generates transaction processing result, and feeds back the transaction processing result to the routing service node sending the interface call request, the transaction processing result includes user account information, commission return data, and transaction return data.

[0079] Specifically, the relay transaction service node writes user account information into the tidb distributed database and writes order return data and transaction return data into the codis in-memory distributed database.

[0080] In this embodiment, the user's account information, order return data, and transaction return data are provided to the interface caller for further processing. The relay transaction service of this invention does not perform secondary processing.

[0081] Furthermore, the relay trading service node reads the seat parameters from its own preset environment variables and uses the seat parameters to control the interface path for interaction with different counter systems.

[0082] Seat parameters are required request parameters when calling all interfaces of the relay trading service.

[0083] Figure 5 Design diagram for dynamically adjusting the interface path prefix based on the environment variable "seat" for relay trading services.

[0084] like Figure 5 As shown, the process of implementing the interface path includes the following steps:

[0085] Step c1: Set the seat environment variables in the runtime environment of the relay trading service node;

[0086] Step c2: When the relay trading service node starts, it reads the value of the seat environment variable;

[0087] Step c3: The value of the seat environment variable is appended as a prefix to the header of each interface path to achieve dynamic adjustment of the interface path;

[0088] Step c4: The relay trading service node registers the service path of the provided futures interface to the system.

[0089] Furthermore, the relay transaction service node supports logging into the counter system using multiple sets of appids and authorization codes on the same or different service nodes.

[0090] Figure 6 A schematic diagram of configuration scheme 1 for the relay transaction service cluster. Figure 7 Schematic diagram of configuration scheme 2 for relay transaction service cluster.

[0091] like Figure 6 , 7 As shown, the process of logging into the counter system using multiple sets of appids and authorization codes on a relay transaction service node includes the following steps:

[0092] Step d1: Configure multiple sets of appid and authorization codes in the configuration information of the relay transaction service node;

[0093] Step d2, the relay transaction service node loads multiple sets of appid and authorization code information into the service program when starting;

[0094] Step d3, when the login interface is called, the appid parameter is reported, the relay transaction service node queries the authorization code corresponding to the appid parameter, and initiates login to the counter system using the appid parameter and the authorization code.

[0095] The market module includes a market collection service and a market service.

[0096] The market collection service is used to collect dynamic market data from the counter system and write it into the shared storage database.

[0097] Further, the market collection service interacts with the counter system by integrating futures sdk to collect dynamic market data, and writes the dynamic market data into the codis in-memory distributed data.

[0098] In this embodiment, the futures sdk includes ctp, Hengsheng, Jinshida or Feichuang sdk. The dynamic market data includes futures or options and other dynamic market data.

[0099] The market service is used to read dynamic market data from the shared storage database and provide market api interfaces to the outside.

[0100] Specifically, the market service includes multiple parallelly deployed market service nodes, which read dynamic market data from the codis in-memory distributed database and provide dynamic market data to the outside through dynamic market api interfaces. The dynamic market api interface supports single request based on Http protocol and subscription push based on WebSocket protocol.

[0101] The front-end routing service is also used to return the transaction processing result from the relay transaction service to the client.

[0102] Those skilled in the art know that, in addition to implementing the system provided by the present application and each device, module and unit thereof in a pure computer readable program code manner, the same functions can also be achieved by logically programming the method steps in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers and embedded microcontrollers. Therefore, the system provided by the present application and each device, module and unit thereof can be considered as a hardware component, and the devices, modules and units included therein for achieving various functions can also be considered as structures within the hardware component. The devices, modules and units for achieving various functions can also be considered as both software modules for implementing methods and structures within hardware components.

[0103] The specific embodiments of the present application are described above. It needs to be understood that the present application is not limited to the specific embodiments described above, and various changes or modifications can be made by those skilled in the art within the scope of the claims, which does not affect the essential content of the present application. The embodiments of the present application and the features in the embodiments can be combined with each other at will without conflict.

Claims

1. A Restful Api-based stateless microservice architecture distributed futures trading service system, characterized in that, The system comprises a market module, a transaction module and a shared storage database; The transaction module comprises a front routing service and a relay transaction service; The front routing service is configured to receive an interface call request from a client and forward the interface call request to the relay transaction service; the front routing service comprises a plurality of routing service nodes deployed in parallel, and the routing service nodes are configured to provide a stateless interface based on a Restful API to receive the interface call request from the client; The relay transaction service is configured to receive the interface call request, interact with a counter system to generate a transaction processing result and feed back the transaction processing result to the front routing service; the front routing service is further configured to return the transaction processing result from the relay transaction service to the client; the relay transaction service comprises a plurality of relay transaction service nodes deployed in parallel, and the routing service nodes are configured to determine a target relay transaction service node for processing the interface call request from the plurality of relay transaction service nodes according to a type of the interface call request by using a consistent hashing algorithm or a matching mode algorithm and forward the interface call request to the target relay transaction service node; The market module comprises a market collection service and a market service, the market collection service is configured to collect dynamic market data from the counter system and write the dynamic market data into the shared storage database; and the market service is configured to read the dynamic market data from the shared storage database and provide a market API interface to the outside; The shared storage database comprises a tidb distributed database and a codis in-memory distributed database.

2. The Restful Api based stateless microservice architecture distributed futures trading service system according to claim 1, characterized in that, The type of the interface call request comprises a user login request and a non-login request; for the received user login request, the front routing service is configured to perform a hash calculation on a user account ID in the interface call request by using a consistent hashing algorithm to determine a relay transaction service for processing the request; and for the received non-login request, the front routing service is configured to query a pre-stored user account ID and relay transaction service routing mapping table according to a user account ID in the non-login request by using a matching mode algorithm to determine a relay transaction service for processing the non-login request. 3.The Restful Api based stateless microservice architecture distributed futures trading service system of claim 2, wherein, The process of completing request forwarding by using the consistent hashing algorithm comprises the following steps: Step a1, the front routing service receives a user login request and obtains user ID data in the user login request; Step a2, the front routing service performs a hash function calculation on the user ID data to obtain a hash value; Step a3, the front routing service determines a target relay transaction service node according to a mapping relationship between the hash value and hash value ranges of each relay transaction service node; Step a4, the front routing service forwards the user login request to the target relay transaction service node; Step a5, the target relay transaction service node writes user ID, a seat and a target relay transaction service node name information as a routing mapping relationship into the codis in-memory distributed database after completing login.

4. The Restful Api based stateless microservice architecture distributed futures trading service system according to claim 3, characterized in that, The process of completing request forwarding by using the matching mode algorithm includes the following steps: Step b1, the front routing service receives a non-login request, and obtains user ID and seat information in the non-login request; Step b2, the front routing service queries the routing mapping relationship stored in the codis in-memory distributed database with the user ID-seat information combination as the key, and obtains the relay transaction service node name corresponding to the user login; Step b3, the front routing service adds the user ID, seat information and relay transaction service node name to the non-login request, and forwards the non-login request to the relay transaction service node.

5. The Restful Api based stateless microservice architecture distributed futures trading service system according to claim 4, characterized in that, The relay transaction service node integrates futures sdk, after receiving the interface call request, the relay transaction service node interacts with the counter system through an asynchronous communication mechanism, generates a transaction processing result, and feeds back the transaction processing result to the routing service node sending the interface call request, the transaction processing result includes user account information, commission return data and transaction return data.

6. The Restful Api based stateless microservice architecture distributed futures trading service system according to claim 5, wherein, The relay transaction service node writes the user account information into the tidb distributed database, and writes the commission return data and transaction return data into the codis in-memory distributed database.

7. The Restful Api based stateless microservice architecture distributed futures trading service system according to claim 6, characterized in that, The relay transaction service node reads the seat parameters in the preset environment variables of itself, and uses the seat parameters to control the interface path for interacting with different counter systems, and the process of realizing the interface path includes the following steps: Step c1, set the seat environment variable in the running environment of the relay transaction service node; Step c2, the relay transaction service node reads the value of the seat environment variable when starting; Step c3, the value of the seat environment variable is spliced as a prefix to the head of each interface path to realize dynamic adjustment of the interface path; Step c4, the relay transaction service node registers the service path of the provided futures interface to the system.

8. The Restful Api based stateless microservice architecture distributed futures trading service system according to claim 7, characterized in that, The relay transaction service node supports using multiple sets of appid and authorization code to log in to the counter system on the same service node or different service nodes, including the following steps: Step d1, configure multiple sets of appid and authorization code in the configuration information of the relay transaction service node; Step d2, the relay transaction service node loads the multiple sets of appid and authorization code information into the service program when starting; Step d3, when requesting to call the login interface, report the appid parameter, the relay transaction service node queries the authorization code corresponding to the appid parameter, and uses the appid parameter and authorization code to initiate login to the counter system. 9.The Restful Api based stateless micro service architecture distributed futures trading service system of claim 1, wherein, The market data collection service interacts with the counter system through integrated futures sdk to collect dynamic market data, and writes the dynamic market data into the codis in-memory distributed data. 10.The Restful Api based stateless microservice architecture distributed futures trading service system of claim 9, wherein, The market service includes a plurality of parallel deployed market service nodes, the market service nodes read dynamic market data from the codis in-memory distributed database, and provide the dynamic market data to the outside through a dynamic market API interface, the dynamic market API interface supports single request based on the Http protocol and subscription push based on the WebSocket protocol.

Images