Distributed futures transaction service system of stateless micro-service architecture based on RestfulApi

Abstract

The invention provides a distributed futures transaction service system of a stateless micro-service architecture based on RestfulApi. The system comprises a front routing service, a relay transaction service, a market information acquisition service, a market information service, a tidb distributed database and a codis memory distributed database. The front routing service provides a stateless interface based on Restful Api, and supports multi-node parallel expansion and dynamic load adjustment; the relay transaction service is integrated with mainstream futures sdk and interacts with the counter system through an asynchronous communication mechanism; the market information acquisition service acquires dynamic market information data and writes the dynamic market information data into the codis memory distributed database; the market information service reads the dynamic market information data and externally provides an api interface; the tidb distributed database is used for storing user account information, and the codis memory distributed database is used for storing entrustment return, transaction return and dynamic market data. All the modules cooperate to realize high-concurrency, low-delay, high-availability and multi-mode futures transaction request processing and return information management.

Description

Technical Field

[0001] This invention relates to the field of financial transaction technology, and more specifically, to a distributed futures trading service system based on a stateless microservice architecture using RestfulAPI. Background Technology

[0002] In the fintech sector, futures trading service systems serve as the core hub connecting investors and futures trading desks, and their stability, efficiency, and scalability directly impact trading efficiency and user experience. With the continuous growth of futures market trading volume, the increasing variety of trading instruments, and investors' rising demands for trading latency and system availability, traditional futures trading service systems are struggling to meet current market needs.

[0003] Traditional futures trading service systems often employ a single-point-of-failure architecture. If a deployed machine fails, the entire system is paralyzed, unable to process trading requests, resulting in investors' trading orders being unable to execute, and exhibiting poor disaster recovery capabilities. Furthermore, traditional system interfaces are stateful, heavily reliant on session management, and cannot achieve equal collaboration between service nodes. This makes it difficult to handle high-concurrency scenarios by adding nodes, and single-point failures directly impact overall service operation.

[0004] In terms of module interaction and interface adaptation, when traditional systems connect to different futures trading platforms, they need to redevelop integration functions separately for the exclusive SDKs provided by each platform, which is time-consuming and costly. Moreover, the exposed interfaces lack a unified standard, and adaptation code needs to be repeatedly developed for different connection scenarios. In addition, the relay service and front-end service in traditional systems are highly coupled, the interface design is restricted by external access, and the flexibility is insufficient. Furthermore, the forwarding of user requests lacks efficient algorithm support, which can easily lead to problems such as uneven load and repeated connection establishment, resulting in resource waste and low data processing efficiency.

[0005] Regarding multi-account login and resource utilization, traditional systems only support one set of appid and authorization code for logging into the futures trading platform. If multiple sets of appid and authorization codes are required, additional machines must be applied for to redeploy the relay service system, resulting in a serious waste of server resources. At the same time, traditional systems have a single request method, relying mostly on single HTTP requests, and cannot achieve persistent bidirectional communication. This makes it difficult to proactively push real-time information streams such as transaction reports and order reports to users, affecting users' real-time control over the progress of their transactions.

[0006] At the data storage level, traditional systems mostly use single-machine databases or simple cluster storage solutions. Capacity expansion depends on upgrading single-machine hardware, which is costly and makes it difficult to achieve smooth expansion of large-scale data. At the same time, the number of data replicas is limited, and data loss or unavailability is likely to occur when a single point of failure occurs.

[0007] A patent search revealed an invention patent with publication number CN113065953A, which discloses a distributed futures relay trading system. This system is deployed entirely within the futures company, with all user data stored in the company's data center. It also ensures that cloud conditional orders are triggered based on the trading status of the trading floor, eliminating the need for server time calibration and guaranteeing normal order triggering. The technical solution consists of three parts: a front-end module, a trading system, and a data storage module. The trading system includes a message middleware unit and a cloud conditional order processing cluster unit. The message middleware unit handles communication between the trading cluster unit and the order placement cluster unit, and also supports expansion of both units. The cloud conditional order processing cluster unit handles the creation, deletion, modification, querying, and triggering of cloud conditional orders. While this patent employs a distributed architecture, improving system availability to some extent, it fails to provide effective solutions to problems such as stateful interface design, session dependency, repetitive development for different trading floors, and inconsistent interfaces. Furthermore, it does not address resource utilization for multi-account logins or the diversification of request methods.

[0008] In summary, given the problems of the existing technologies, researching a stateless microservice architecture based on RestfulAPI for a distributed futures trading service system has become a critical task that urgently needs to be addressed. Summary of the Invention

[0009] To address the shortcomings of existing technologies, the purpose of this invention is to provide a distributed futures trading service system based on a stateless microservice architecture using RestfulAPI.

[0010] The present invention provides a stateless microservice architecture distributed futures trading service system based on Restful API, comprising a market data module, a trading module, and a shared storage database; The transaction module includes a front-end routing service and a relay transaction service. The front-end routing service receives API call requests from clients and forwards them to the relay transaction service. The relay transaction service receives API call requests, interacts with the counter system to generate transaction processing results, and feeds back the transaction processing results to the front-end routing service. The front-end routing service also returns the transaction processing results from the relay transaction service to the client. The market data module includes a market data acquisition service and a market data service. The market data acquisition service is used to collect dynamic market data from the counter system and write it to the shared storage database; the market data service is used to read dynamic market data from the shared storage database and provide market data API interfaces to the outside world. Shared storage databases include tidb distributed database and codis in-memory distributed database.

[0011] Preferably, the front-end routing service includes multiple routing service nodes deployed in parallel. The routing service nodes are used to provide a stateless interface based on the Restful API to receive API call requests from clients.

[0012] Preferably, the relay transaction service includes multiple relay transaction service nodes deployed in parallel. The routing service node determines the target relay transaction service node to process the interface call request from among the multiple relay transaction service nodes based on the type of the interface call request, using a consistent hashing algorithm or a matching pattern algorithm, and forwards the interface call request to the target relay transaction service node.

[0013] Preferably, the types of interface call requests include user login requests and non-login requests. For received user login requests, the front-end routing service uses a consistent hashing algorithm to perform hash calculation on the user account ID in the interface call request to determine the relay transaction service to process the request. For received non-login requests, the front-end routing service uses a matching pattern algorithm to query the pre-stored routing mapping table between the user account ID and the relay transaction service based on the user account ID in the non-login request to determine the relay transaction service to process the non-login request.

[0014] Preferably, the process of using a consistent hashing algorithm to complete request forwarding includes the following steps: Step a1: The front-end routing service receives the user login request and obtains the user ID data from the user login request; Step a2: The front-end routing service calculates the hash value by performing a hash function on the user ID data; Step a3: The front-end routing service determines the target relay transaction service node based on the mapping relationship between the hash value and the hash value range of each relay transaction service node; Step a4: The front-end routing service forwards the user login request to the target relay transaction service node; Step a5: After the target relay transaction service node completes login, it writes the user ID, seat, and target relay transaction service node name information as a routing mapping relationship into the Codis in-memory distributed database storage.

[0015] Preferably, the process of using a matching pattern algorithm to complete request forwarding includes the following steps: Step b1: The front-end routing service receives non-login requests and obtains the user ID and seat information from the non-login requests; Step b2: The front-end routing service uses the combination of user ID and seat information as the key to query the routing mapping relationship stored in the Codis in-memory distributed database to obtain the name of the relay transaction service node for the corresponding user login. Step b3: The front-end 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.

[0016] Preferably, the relay trading service node integrates a futures SDK. After receiving an interface call request, the relay trading service node interacts with the counter system through an asynchronous communication mechanism to generate a transaction processing result, and feeds back the transaction processing result to the routing service node that sent the interface call request. The transaction processing result includes user account information, order confirmation data, and transaction confirmation data. The relay trading service node writes the user account information into the TiDB distributed database and writes the order confirmation data and transaction confirmation data into the Codis in-memory distributed database.

[0017] Preferably, 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. The process of implementing the interface path includes the following steps: Step c1: Set the seat environment variables in the runtime environment of the relay trading service node; Step c2: When the relay trading service node starts, it reads the value of the seat environment variable; 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; Step c4: The relay trading service node registers the service path of the provided futures interface to the system.

[0018] Preferably, the relay transaction service node supports logging into the counter system using multiple sets of appids and authorization codes on the same service node or different service nodes, including the following steps: Step d1: Configure multiple sets of appid and authorization codes in the configuration information of the relay transaction service node; Step d2: When the relay transaction service node starts, it loads multiple sets of appid and authorization code information into the service program; Step d3: When a request is made 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 uses the appid parameter and the authorization code to initiate login to the counter system.

[0019] Preferably, the market data collection service interacts with the trading platform system through the integration of the futures SDK to collect dynamic market data and writes the dynamic market data into the Codis in-memory distributed database. The market data service includes multiple market data service nodes deployed in parallel. The market data service nodes read dynamic market data from the Codis in-memory distributed database and provide dynamic market data to the outside world through the dynamic market data API interface. The dynamic market data API interface supports single requests based on the HTTP protocol and subscription push based on the WebSocket protocol.

[0020] Compared with the prior art, the present invention has the following beneficial effects: 1. Addressing the issues of statefulness, session dependency, and single point of failure in traditional futures trading service interfaces, this invention proposes a stateless front-end routing service based on the RESTful API. This eliminates the need for session management and results in concise code. The front-end routing service supports parallel scaling across multiple nodes, allowing for handling high-concurrency scenarios by adding server nodes. In the event of a single node failure, requests are automatically routed to other healthy nodes, preventing single-point failures from impacting overall service operation. Furthermore, the RESTful API is naturally compatible with the HTTP protocol, supporting cross-platform and cross-device access without restricting the developer's language, thus reducing development costs.

[0021] 2. The front-end routing service of this invention is responsible for providing interface services to external clients. It utilizes consistent hashing and matching pattern algorithms to forward requests, achieving a stateless interface design. Specifically, the login interface uses consistent hashing to hash the user account ID, distributing user login requests across different relay transaction service nodes. In case of node failure, requests are transferred to a working relay transaction service node, ensuring that the same user logs in only on one relay transaction service node, avoiding resource waste. Other interfaces besides login use the matching pattern algorithm, which queries the routing mapping table to accurately forward non-login requests to the node where the user is already logged in, reusing existing SDK connections, avoiding duplicate connection establishment, saving resource overhead, reducing network interactions, and improving data processing efficiency.

[0022] 3. The relay trading service of this invention integrates multiple SDKs and provides a unified trading interface for the front-end routing service to call internally. Because it is not exposed externally, the interface design is more flexible. The relay trading service controls the interface path prefix by reading the environment variable seat. The seat variable is used as a request parameter and must be reported when calling all interfaces. The relay trading service is responsible for forwarding user query, order placement and other requests to the counter, thereby decoupling the business functions from the front-end routing service, improving the overall system performance and reducing code maintenance costs.

[0023] 4. To address the issues of single-point operation and poor disaster recovery capabilities in traditional futures trading services, this invention is based on a microservice distributed architecture. The front-end routing service, relay trading service, and market data service all support horizontal scaling: 3 servers are the minimum unit for system operation, allowing the system to continue operating even if 1 server fails, 5 servers allow 2 servers to fail, and so on. When server resources are sufficient, it can be expanded to thousands of nodes, with a transaction request processing latency of ≤50ms, improving system availability and processing capacity.

[0024] 5. To address the issues of repetitive development and inconsistent interfaces required for traditional systems to connect to different counters, this invention implements standardized external interfaces through Restful API. With unified interfaces, new counter SDKs or business modules can be quickly integrated, eliminating the need for developers to redevelop, thus saving development time and costs.

[0025] 6. To address the issue of traditional systems requiring additional machine deployment and wasting resources when logging in with multiple appids and authorization codes, this invention supports the use of multiple appids and authorization codes in the same machine environment, i.e., with the number of service nodes remaining unchanged, thus saving machine resource overhead; at the same time, it supports adding relay transaction service nodes to achieve login with multiple appids and authorization codes, realizing physical isolation of services corresponding to different appids and authorization codes.

[0026] 7. This invention supports two request methods: HTTP single request and WebSocket long connection. WebSocket is based on the TCP protocol, provides reliable transmission, and has the characteristics of persistence, bidirectional communication and low latency. It can proactively push information stream data such as transaction reports and order reports to users.

[0027] 8. This invention adopts a distributed database solution, which expands capacity by adding nodes and supports smooth expansion of data from TB level to PB level; data is automatically replicated to multiple node replicas, and automatically switches to available nodes in case of single point of failure, ensuring data availability to the greatest extent. Attached Figure Description

[0028] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a schematic diagram of a distributed futures trading service system based on a stateless microservice architecture using RestfulAPI, as described in an embodiment of the present invention. Figure 2 This is a flowchart of the consistent hashing algorithm for user login requests in an embodiment of the present invention; Figure 3 This is a flowchart of the pre-routing service matching mode algorithm in an embodiment of the present invention; Figure 4This is a flowchart of the matching pattern request forwarding process in an embodiment of the present invention; Figure 5 This is a design diagram of the prefix of the interface path for the relay transaction service in this embodiment of the invention, which dynamically adjusts the interface path based on environmental variable seats. Figure 6 This is a schematic diagram of the relay transaction service cluster configuration scheme 1 in this embodiment of the invention; Figure 7 This is a schematic diagram of the relay transaction service cluster configuration scheme 2 in this embodiment of the invention. Detailed Implementation

[0029] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0030] This invention discloses a distributed futures trading service system based on a stateless microservice architecture using RESTful API. The system includes a front-end routing service, a relay trading service, a market data acquisition service, a market data service, a TiDB distributed database, and a Codis in-memory distributed database. The front-end routing service provides a stateless interface based on RESTful API, supporting multi-node parallel scaling and dynamic load balancing. The relay trading service integrates mainstream futures SDKs and interacts with the trading platform system via asynchronous communication mechanisms. The market data acquisition service collects dynamic market data and writes it to the Codis in-memory distributed database. The market data service reads dynamic market data and provides API interfaces. The TiDB distributed database stores user account information, and the Codis in-memory distributed database stores order confirmations, trade confirmations, and dynamic market data. These modules work together to achieve high concurrency, low latency, high availability, and multimodal futures trading request processing and confirmation information management.

[0031] Example 1: Figure 1 This is a schematic diagram of a distributed futures trading service system based on a stateless microservice architecture using RestfulAPI, as described in an embodiment of the present invention.

[0032] like Figure 1 As shown, this embodiment provides a stateless microservice architecture distributed futures trading service system based on RESTful API, including a market data module, a trading module, and a shared storage database. The trading module includes a front-end routing service and a relay trading service.

[0033] The front-end routing service is used to receive API call requests from clients and forward them to the relay transaction service.

[0034] Specifically, the front-end routing service includes multiple routing service nodes deployed in parallel. These routing service nodes provide a stateless interface based on the Restful API to receive API call requests from clients.

[0035] Since all routing service nodes are equal, all stateless interfaces are provided by the routing service nodes, enabling multi-path active-active operation; the front-end routing service module dynamically adjusts the number of nodes according to the load, improving the system's disaster recovery capability.

[0036] The relay transaction service is used to receive API call requests, interact with the counter system to generate transaction processing results, and feed back the transaction processing results to the front-end routing service.

[0037] Specifically, the relay transaction service includes multiple relay transaction service nodes deployed in parallel. The routing service node determines the target relay transaction service node to process the interface call request from among the multiple relay transaction service nodes based on the type of the interface call request, using a consistent hashing algorithm or a matching pattern algorithm, and forwards the interface call request to the target relay transaction service node.

[0038] In this embodiment, the types of interface call requests include user login requests and non-login requests.

[0039] For a received user login request, the front-end routing service uses a consistent hashing algorithm to hash the user account ID in the interface call request to determine the relay transaction service to handle the request. For a received non-login request, the front-end routing service uses a matching pattern algorithm to query the pre-stored routing mapping table between the user account ID and the relay transaction service based on the user account ID in the non-login request to determine the relay transaction service to handle the non-login request.

[0040] Shared storage databases include tidb distributed database and codis in-memory distributed database. Figure 2 Flowchart of the consistent hashing algorithm for user login requests Figure 3 Flowchart of the matching pattern algorithm for the front-end routing service. Figure 4 Flowchart for forwarding a matching pattern request.

[0041] like Figure 2 As shown, the process of request forwarding using the consistent hashing algorithm includes the following steps: Step a1: The front-end routing service receives the user login request and obtains data such as the user ID from the user login request; Step a2: The front-end routing service calculates the hash value by performing a hash function on the user ID data; Step a3: The front-end routing service determines the target relay transaction service node based on the mapping relationship between the hash value and the hash value range of each relay transaction service node; Step a4: The front-end routing service forwards the user login request to the target relay transaction service node; Step a5: After the target relay transaction service node completes login, it writes the user ID, seat, and target relay transaction service node name information as a routing mapping relationship into the Codis in-memory distributed database storage.

[0042] like Figure 3 , 4 As shown, the process of request forwarding using the matching pattern algorithm includes the following steps: Step b1: The front-end routing service receives non-login requests and obtains the user ID and seat information from the non-login requests; Step b2: The front-end routing service uses the combination of user ID and seat information as the key to query the routing mapping relationship stored in the Codis in-memory distributed database to obtain the name of the relay transaction service node for the corresponding user login. Step b3: The front-end 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.

[0043] Furthermore, the relay trading service node integrates the futures SDK. After receiving the interface call request, the relay trading service node interacts with the counter system through an asynchronous communication mechanism to generate the transaction processing result and feeds back the transaction processing result to the routing service node that sent the interface call request. The transaction processing result includes user account information, order return data, and transaction return data.

[0044] 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.

[0045] 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.

[0046] 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.

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

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

[0049] like Figure 5 As shown, the process of implementing the interface path includes the following steps: Step c1: Set the seat environment variables in the runtime environment of the relay trading service node; Step c2: When the relay trading service node starts, it reads the value of the seat environment variable; 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; Step c4: The relay trading service node registers the service path of the provided futures interface to the system.

[0050] 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.

[0051] 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.

[0052] 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: Step d1: Configure multiple sets of appid and authorization codes in the configuration information of the relay transaction service node; Step d2: When the relay transaction service node starts, it loads multiple sets of appid and authorization code information into the service program; Step d3: When a request is made 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 uses the appid parameter and the authorization code to initiate login to the counter system.

[0053] The market data module includes market data collection services and market data services.

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

[0055] Furthermore, the market data collection service interacts with the trading platform system through the integration of the futures SDK to collect dynamic market data, and writes the dynamic market data into the Codis in-memory distributed data.

[0056] In this embodiment, the futures SDK includes CTP, Hang Seng, Kingstar, or Feichuang SDK. Dynamic market data includes dynamic market data for futures or options.

[0057] The market data service is used to read dynamic market data from a shared storage database and provides a market data API interface to the outside world.

[0058] Specifically, the market data service includes multiple market data service nodes deployed in parallel. The market data service nodes read dynamic market data from the Codis in-memory distributed database and provide dynamic market data to the outside world through the dynamic market data API interface. The dynamic market data API interface supports single requests based on the HTTP protocol and subscription push based on the WebSocket protocol.

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

[0060] Those skilled in the art will understand that, besides implementing the system and its various devices, modules, and units provided by this invention in the form of purely computer-readable program code, the same functions can be achieved entirely through logical programming of the method steps, making the system and its various devices, modules, and units of this invention function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by this invention can be considered as a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices, modules, and units for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0061] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A stateless microservice architecture-based distributed futures trading service system based on RESTful API, characterized in that, Includes a market data module, a trading module, and a shared storage database; The transaction module includes front-end routing service and relay transaction service; The front-end routing service is used to receive the client's interface call request and forward the interface call request to the relay transaction service; the front-end routing service includes multiple routing service nodes deployed in parallel, and the routing service nodes are used to provide a stateless interface based on Restful API to receive the client's interface call request. The relay transaction service is used to receive the interface call request, interact with the counter system to generate a transaction processing result, and feed back the transaction processing result to the front-end routing service; the front-end routing service is also used to return the transaction processing result from the relay transaction service to the client; the relay transaction service includes multiple relay transaction service nodes deployed in parallel, and the routing service node determines the target relay transaction service node to process the interface call request from the multiple relay transaction service nodes according to the type of the interface call request, using a consistent hashing algorithm or a matching pattern algorithm, and forwards the interface call request to the target relay transaction service node; The market data module includes a market data acquisition service and a market data service. The market data acquisition service is used to collect dynamic market data from the counter system and write it into the shared storage database. The market data service is used to read dynamic market data from the shared storage database and provide a market data API interface to the outside world. The shared storage database includes the tidb distributed database and the codis in-memory distributed database.

2. The distributed futures trading service system based on a stateless microservice architecture using RESTful API as described in claim 1, characterized in that, The types of interface call requests include user login requests and non-login requests. For a received user login request, the front-end routing service uses a consistent hashing algorithm to hash the user account ID in the interface call request to determine the relay transaction service to handle the request. For a received non-login request, the front-end routing service uses a matching pattern algorithm to query a pre-stored routing mapping table between the user account ID and the relay transaction service based on the user account ID in the non-login request to determine the relay transaction service to handle the non-login request.

3. The distributed futures trading service system based on a stateless microservice architecture using RESTful API as described in claim 2, characterized in that, The process of request forwarding using the consistent hashing algorithm includes the following steps: Step a1: The front-end routing service receives a user login request and obtains the user ID data from the user login request; Step a2: The front-end routing service performs a hash function on the user ID data to obtain a hash value; Step a3: The front-end routing service determines the target relay transaction service node based on the mapping relationship between the hash value and the hash value range of each relay transaction service node; Step a4: The front-end routing service forwards the user login request to the target relay transaction service node; Step a5: After the target relay transaction service node completes login, it writes the user ID, seat, and target relay transaction service node name information as a routing mapping relationship into the Codis in-memory distributed database storage.

4. The distributed futures trading service system based on a stateless microservice architecture using RESTful API as described in claim 3, characterized in that, The process of request forwarding using a matching pattern algorithm includes the following steps: Step b1: The front-end routing service receives a non-login request and obtains the user ID and seat information from the non-login request; Step b2: The front-end routing service uses the combination of user ID and seat information as the key to query the routing mapping relationship stored in the Codis in-memory distributed database to obtain the name of the relay transaction service node for the corresponding user login. Step b3: The front-end routing service adds the user ID, seat information and the name of the relay transaction service node to the non-login request, and forwards the non-login request to the relay transaction service node.

5. The distributed futures trading service system based on a stateless microservice architecture using RESTful API as described in claim 4, characterized in that, The relay trading service node integrates the futures SDK. After receiving the interface call request, the relay trading service node interacts with the counter system through an asynchronous communication mechanism to generate a transaction processing result and feeds back the transaction processing result to the routing service node that sent the interface call request. The transaction processing result includes user account information, order return data, and transaction return data.

6. The distributed futures trading service system based on a stateless microservice architecture using RESTful API as described in claim 5, characterized in that, The relay transaction service node writes the user account information into the tidb distributed database and writes the order return data and transaction return data into the codis in-memory distributed database.

7. The distributed futures trading service system based on a stateless microservice architecture using RESTful API as described in claim 6, characterized in that, The relay trading service node reads the seat parameters from its preset environment variables and uses these seat parameters to control the interface path for interaction with different counter systems. The process of implementing the interface path includes the following steps: Step c1: Set the seat environment variables in the operating environment of the relay transaction service node; Step c2: When the relay transaction service node starts, it reads the value of the seat environment variable; 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; Step c4: The relay trading service node registers the service path of the provided futures interface to the system.

8. The distributed futures trading service system based on a stateless microservice architecture using RESTful API as described in claim 7, characterized in that, 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, including the following steps: Step d1: Configure multiple sets of appid and authorization codes in the configuration information of the relay transaction service node; Step d2: When the relay transaction service node starts, it loads the multiple sets of appid and authorization code information into the service program; Step d3: When a login interface is requested, the appid parameter is reported. The relay transaction service node queries the authorization code corresponding to the appid parameter and uses the appid parameter and the authorization code to initiate login to the counter system.

9. The distributed futures trading service system based on a stateless microservice architecture using RESTful API as described in claim 1, characterized in that, The market data collection service integrates the futures SDK with the trading platform to collect dynamic market data, and then writes the dynamic market data into the Codis in-memory distributed database.

10. The distributed futures trading service system based on a stateless microservice architecture using RESTful API according to claim 9, characterized in that, The market data service includes multiple market data service nodes deployed in parallel. The market data service nodes read dynamic market data from the Codis in-memory distributed database and provide the dynamic market data to the outside world through a dynamic market data API interface. The dynamic market data API interface supports single requests based on the HTTP protocol and subscription push based on the WebSocket protocol.

Images