CN110740184A - Transaction strategy testing system based on micro-service architecture - Google Patents
Transaction strategy testing system based on micro-service architecture Download PDFInfo
- Publication number
- CN110740184A CN110740184A CN201911010054.5A CN201911010054A CN110740184A CN 110740184 A CN110740184 A CN 110740184A CN 201911010054 A CN201911010054 A CN 201911010054A CN 110740184 A CN110740184 A CN 110740184A
- Authority
- CN
- China
- Prior art keywords
- test
- service module
- transaction
- strategy
- testing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Technology Law (AREA)
- Strategic Management (AREA)
- Marketing (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention discloses an transaction strategy testing system based on a micro-service architecture, which comprises a front-end service module, a testing service module and a database service module, wherein the testing service module comprises a testing task scheduler and a plurality of testing task executors deployed in a cluster, the front-end service module is used for receiving a plurality of strategy testing requests initiated by a user terminal and sending the strategy testing requests to the testing service module, the testing service module is used for sending each strategy testing request transmitted by the front-end service module to testing task executors through the testing task scheduler, each testing task executor executes testing on a transaction strategy to be tested according to testing parameter information of the transaction strategy to be tested, the database service module is used for storing strategy information of the transaction strategy to be tested, market quotation data and testing results of each testing task executor, and the front-end service module is also used for outputting the testing results.
Description
Technical Field
The invention relates to the field of Internet, in particular to an transaction strategy testing system based on a micro-service architecture.
Background
This section is intended to provide a background or context to the embodiments of the invention that are recited in the claims. The description herein is not admitted to be prior art by inclusion in this section.
As is known, in the quantitative transaction of financial products, an investment user needs to create transaction strategies to execute the quantitative transaction, after transaction strategies are created, historical retest or simulated transaction test needs to be executed on the transaction strategies, and only under the condition that the test result meets the condition of , the transaction strategies can be put on a real disk to perform real transaction.
At present, an existing transaction strategy testing system is based on a B/S architecture system, and cannot respond to high-concurrency strategy testing requests, so that the strategy testing efficiency is low.
Disclosure of Invention
The embodiment of the invention provides transaction strategy test systems based on a micro-service architecture, which are used for solving the technical problem that the existing transaction strategy test system cannot cope with high-concurrency strategy test requests and causes low strategy test efficiency because of being based on a B/S architecture system, and comprise a front-end service module, a test service module and a database service module, wherein the test service module comprises a test task scheduler and a plurality of test task executors deployed in a cluster;
the system comprises a front-end service module, a test service module and a data processing module, wherein the front-end service module is connected with a user terminal and is used for receiving a plurality of strategy test requests initiated by the user terminal and sending the strategy test requests to the test service module, wherein each strategy test request comprises strategy information of a transaction strategy to be tested and test parameter information for executing a test on the transaction strategy to be tested;
the test service module is connected with the front-end service module and used for sending each strategy test request transmitted by the front-end service module to test task executors through the test task scheduler, wherein each test task executor executes a test on a transaction strategy to be tested according to test parameter information of the transaction strategy to be tested;
the database service module is respectively connected with the front-end service module and the testing service module and is used for storing strategy information of the transaction strategy to be tested, market quotation data required by each testing task executor for testing the transaction strategy to be tested and a testing result obtained by each testing task executor for testing the transaction strategy to be tested;
the front-end service module is also used for outputting a test result of the transaction strategy to be tested.
In the embodiment of the invention, based on a micro-service architecture, a front-end service function, a test service function and a database service function of a transaction strategy test system are decomposed and respectively realized by an independent front-end service module, a test service module and a database service module, after a plurality of strategy test requests initiated by a user terminal are received by the front-end service module, a plurality of test task executors are established by the test service module connected with the front-end service module, each strategy test request is sent to test task executors to execute the test function, because the database service module is respectively connected with the front-end service module and the test service module, the front-end service module can store strategy information of a transaction strategy to be tested in the database service module, and each test task executor in the test service module can acquire the strategy information of the transaction strategy to be tested from the database module and execute a test on the transaction strategy to be tested according to market quotation data stored in the database service module, and after the test on the transaction strategy to be tested, the test result is stored in the database service module so that the front-end service module can acquire the test result of the transaction to be tested transaction strategy to be tested.
According to the embodiment of the invention, based on the micro-service architecture, each sub-service function of the transaction strategy test system is decomposed and realized by each independent module, so that the coupling of the system can be reduced, and more flexible service support is provided. In addition, the test service module in the embodiment of the invention adopts a plurality of test task executors deployed in a cluster to test a plurality of strategy test requests, so that the requirement of high concurrent strategy test can be met, and the transaction strategy test system has strong scalability.
Drawings
In order to more clearly illustrate embodiments of the present invention or prior art solutions, reference will now be made briefly to the attached drawings which are used in the description of embodiments or prior art, it being understood that the drawings in the following description are only embodiments of the present invention, and that other drawings may be obtained by those skilled in the art without inventive effort, in which:
FIG. 1 is a schematic diagram of transaction policy testing systems based on microservice architecture according to an embodiment of the present invention;
FIG. 2 is an interaction diagram of transaction policy testing systems based on micro service architecture according to an embodiment of the present invention;
fig. 3 is a schematic diagram of message queues based on Redis lists according to an embodiment of the present invention;
FIG. 4 is a flow chart of a method for performing historical backtesting and simulated transaction testing on transaction policies, according to an embodiment of the present invention;
FIG. 5 is a schematic diagram of alternative transaction policy testing systems based on microservice architecture provided in an embodiment of the present invention;
FIG. 6 is a schematic diagram of alternative transaction policy return systems based on microservice architecture according to an embodiment of the present invention;
FIG. 7 is a flow chart of specific implementation of history echoes provided in an embodiment of the invention;
fig. 8 is a flow chart of a specific implementation of real-time simulated transaction tests provided in an embodiment of the present invention.
Detailed Description
To make the objects, technical solutions and advantages of the embodiments of the present invention more apparent, the embodiments of the present invention are described in further with reference to the accompanying drawings.
Reference throughout this specification to the use of the terms " embodiments," " embodiments," " embodiments," "for example," and the like, means that a particular feature, structure, or characteristic described in connection with the embodiments or examples is included in at least embodiments or examples of the present application.
The embodiment of the invention provides transaction strategy test systems based on a micro-service architecture, which are used for solving the technical problem that the existing transaction strategy test system based on a B/S architecture system cannot cope with highly concurrent strategy test requests, so that the strategy test efficiency is very low.
Fig. 1 is a schematic diagram of transaction policy testing systems based on micro-service architecture provided in an embodiment of the present invention, as shown in fig. 1, the system may include a front-end service module 10, a testing service module 20, and a database service module 30, where the testing service module 20 includes a testing task scheduler 201 and a plurality of testing task executors 202 deployed in a cluster;
the front-end service module 10 is connected to a user terminal (omitted in fig. 1), and configured to receive multiple policy test requests initiated by the user terminal and send the policy test requests to the test service module 20, where each policy test request includes policy information of a transaction policy to be tested and test parameter information for performing a test on the transaction policy to be tested;
the test service module 20 is connected to the front-end service module 10, and configured to send each policy test request transmitted by the front-end service module 10 to test task executors 202 through the test task scheduler 201, where each test task executor 202 executes a test on a transaction policy to be tested according to test parameter information of the transaction policy to be tested;
the database service module 30 is connected to the front-end service module 10 and the test service module 20, and is configured to store policy information of the transaction policy to be tested, market quotation data required by each test task executor 202 to execute a test on the transaction policy to be tested, and a test result obtained by each test task executor 202 to execute a test on the transaction policy to be tested;
the front-end service module 10 is further configured to output a test result of the transaction policy to be tested.
It should be noted that, in the embodiment of the present invention, the transaction policy to be tested may be a transaction policy created by a user locally in a user terminal through a code writing manner or a visual configuration manner. Preferably, the transaction strategy to be tested in the embodiment of the present invention may be a quantitative strategy for trading financial products (e.g., products such as stocks, funds, futures, foreign exchange, precious metals, options, etc.).
In the embodiment of the present invention, the function of the test task executor 202 for performing the test on the transaction policy is virtualized into a Docker container, so that the test services among the test task executors 202 are isolated from each other and do not affect each other, and since the Docker container can be newly added with processing nodes by copying, the cluster deployment of each test task executor 202 has good expandability, and the computing nodes in the cluster can be rapidly increased by copying the mirror image file.
It should be further noted that, in the embodiment of the present invention, the front-end service module, the test service module, and the database service module refer to modules that independently run each sub-service, and may be on devices, or may be broadcast on different devices, and no matter on devices or on different devices, compatibility and low coupling connection are ensured among the modules, so as to ensure a stable and efficient operation mechanism of the entire system.
Fig. 2 is an interaction schematic diagram of transaction policy testing systems based on micro-service architecture provided in the embodiment of the present invention, and as shown in fig. 2, a user can submit a transaction policy to be tested (i.e., send a policy test request) to a front-end server through an application based on a client on a user terminal or an application based on a browser access, the front-end server stores policy information of the transaction policy to be tested in a text database of the database server, the user calls a cluster testing service system (including a testing task scheduler and a plurality of testing task executors deployed in a cluster) through the front-end server, and both the cluster testing service system and the front-end server follow a RESTful architecture design, thereby ensuring the interconnection between the front-end server and the cluster testing service system.
The front-end server sends the received strategy test request from the user terminal to a test task scheduler on the cluster test service system, the strategy test request is distributed to each test task executor through the test task scheduler, and after each test task executor executes test on the distributed transaction strategy to be tested, the test result is stored in a database server; and the database server returns the test result to the front-end server based on the query request of the front-end server.
As can be seen from the above, the transaction policy testing system based on micro-service architecture provided in the embodiments of the present invention is implemented by the front-end service module, the test service module, and the database service module, which are independent from each other, and after receiving a plurality of policy test requests initiated by the user terminal through the front-end service module, a plurality of test task executors are created through the test service module connected to the front-end service module, and each policy test request is sent to test task executors to execute the test function.
According to the transaction strategy testing system based on the micro-service architecture, provided by the embodiment of the invention, based on the micro-service architecture, each sub-service function of the transaction strategy testing system is decomposed and realized by each independent module, so that the coupling of the system can be reduced, and more flexible service support is provided. In addition, the test service module in the embodiment of the invention adopts a plurality of test task executors deployed in a cluster to test a plurality of strategy test requests, so that the requirement of high concurrent strategy test can be met, and the transaction strategy test system has strong scalability.
Although the test service module in the embodiment of the present invention tests multiple policy test requests through multiple test task executors deployed in a cluster, in a scenario of a high concurrent policy test request, or in a situation that the number of policy test requests received by a front-end server module exceeds the number of test task executors deployed by a test service module cluster, such a high concurrent situation may cause a crash or restart of the test service module, therefore, as optional implementation manners, in the transaction policy test system based on a micro-service architecture provided in the embodiment of the present invention, the front-end service module 10 may further send each policy test request to the test service module 20 through a Redis message queue, as shown in fig. 3, a schematic diagram of message queues based on a Redis list provided in the embodiment of the present invention is shown in fig. 3, the embodiment of the present invention uses the Redis list to implement the message queue, and the Redis list is implemented by using a bidirectional linked list, and stores head and tail nodes, so that insertion elements at the head and tail of the list are very fast.
It should be noted that, each test task executor deployed by the cluster in the test service module 20 may occupy many physical resources, and the more the number of the test task executors deployed by the cluster is, the more the resources are occupied, so that when the test execution of the transaction policy to be tested by each test task executor 202 in the test service module 20 is finished, as optional implementations, in the transaction policy test system based on the micro service architecture provided in the embodiment of the present invention, the test task scheduler 201 is further configured to release the physical resources occupied by each test task executor 202 when each test task executor 202 stores the test result of the transaction policy in the database service module 30.
Through the above embodiment, after each test task executor executes a test on a transaction policy to be tested, the test result is stored in the database server module 30, so that the front-end service module 10 directly queries the test result from the database server module 30, and therefore, the test task scheduler 201 timely releases the physical resources occupied by each test task executor 202 under the condition that each test task executor 202 stores the test result of the transaction policy in the database server module 30, so as to process other policy test requests.
Preferably, each test task executor 202 may store the test results of the transaction policy in the database service module 30 through a Kafka message queue. The embodiment of the invention writes the strategy test result into the text database by adding the message queue Kafka, thereby maintaining the long-term stable performance of the system.
When each test task executor 202 executes a test on a transaction policy to be tested, the transaction policy to be tested generates test results (i.e., policy transaction results) due to market data of each tick, and thus tests on the transaction policy generally involve transmitting millions or even tens of millions of data between the test task executor 202 and the database service module 30, the embodiment of the present invention not only supports high throughput by setting a Kafka message queue between the test task executor 202 and the database service module 30, but also makes the test service module 20 and the database service module 30 independent from each other, wherein the test task executor 202 only needs to be responsible for transmitting the test results of the transaction policy to the Kafka message queue, and the database service module 30 only needs to service to read the test results of each transaction policy from the Kafka message queue.
Optionally, in this embodiment of the present invention, the database service module 30 may further be configured to store the test result of the transaction policy in a text database, so that the storage of the test result data is completed in an intuitive document manner. Preferably, the text database employed may be a database based on distributed file storage, mongoDB database.
As optional embodiments, in the transaction policy testing system based on the micro-service architecture provided in the embodiment of the present invention, the policy test request may be a history retest request or a simulated transaction test request, where the history retest request is used to request to perform history retest on the transaction policy to be tested based on history market quotation data, and the simulated transaction test request is used to request to perform simulated transaction test on the transaction policy to be tested based on real-time market quotation data, where a trigger manner of the test task executor 202 is event trigger when the policy test request is the history retest request, and a trigger manner of the test task executor 202 is event trigger when the policy test request is the simulated transaction test request.
It should be noted that, when the test task executor performs the history retest on the transaction policy to be tested, the data used for performing the history retest on the transaction policy to be tested is the historical market quotation data in a certain retest time period selected by the user, so the start of the test task executor is triggered by operation events (for example, the user selects the retest time period and triggers the test of the test task executor through a control such as a click-back test button), which is called event trigger, and when the test task executor performs the simulated transaction test on the transaction policy to be tested, the data used for performing the simulated transaction test on the transaction policy to be tested is the real-time market quotation data, so the start of the test task executor is the simulated transaction test of the test task executor triggered by time, which is called time trigger.
In alternative embodiments, in the transaction policy testing system based on microservice architecture provided by the present invention, the database service module 30 may be further configured to store the real-time market quotation data in a Redis database, and store the historical market quotation data in a time-series database, or in a relational database in a partition manner.
It should be noted that, since the policy return test is performed on the historical market quotation data in the accessed data return time period, the policy return test is automatically stopped when return time periods are completed, the real-time market quotation data of the simulated transaction access is automatically stopped, and if the real-time market quotation data of the simulated transaction access is not stopped, the simulated transaction test is executed . in order to realize the automatic interruption of the simulated transaction test, in each policy test request received by the front-end service module 10 in the embodiment of the present invention, if the policy test request is the historical return test request, the test parameter information may at least include the return time period for executing the historical return test on the transaction policy to be tested, and if the policy test request is the simulated transaction test request, the test parameter information may at least include the simulation running time period for executing the simulated transaction test on the transaction policy to be tested, so that the return test task executor 202 may stop the simulated transaction test according to the return time periods or according to the simulation running time period.
in an alternative embodiment, when the policy test request is a simulated transaction test request, the test task executor 202 in the test service module 20, which executes the simulated transaction test on the transaction policy to be tested, reads the real-time market quotation data directly from the Redis database.
In another optional embodiments, when the policy test request is a history retest request, the test task scheduler 201 reads the history market quotation data from the time-series database or the relational database according to the test parameter information of the transaction policy to be tested, and caches the history market quotation data to the test service module 20, wherein the test task executor 202 in the test service module 20 performs history retest on the transaction policy to be tested according to the history market quotation data cached in the test service module 20.
Regardless of the embodiments described above, each test task executor 202 may read market data needed to perform tests on trading strategies through a RabbitMQ message queue.
, each test task executor 202 returns confirmation messages to the RabbitMQ message queue after reading the market quotation data of each tick, and the RabbitMQ message queue clears the market quotation data of the corresponding tick according to the received confirmation messages returned by each test task executor 202.
Fig. 4 is a flowchart of methods for performing history backtesting and simulated transaction testing on a transaction policy according to an embodiment of the present invention, as shown in fig. 4, which mainly includes the following parts:
() market penetration:
the data engine of the policy testing system receives all real-time market data distributed by the production system data engine module. Optionally, market quotation data can be transmitted between the production system data engine and the data engine of the strategy test system through a RabbitMQ message queue.
(II) market quotation storage:
after the data engine of the policy testing system obtains the market quotation data, the real-time market quotation data (for example, the latest tick market quotation data) are stored in a Redis database, and the historical market quotation data are stored in the following two ways:
(1) stored to a time series database (e.g., dopinndb).
(2) The data is stored in a non-time-series database, for example, in a manner of a relational database (Mysql) + partition. The partitioning principle includes two dimensions: partitioned by product ID or by time.
And (III) strategy testing:
(1) the user selects real-time simulation through a front-end interface, and simultaneously selects a strategy to be tested:
a strategy simulation transaction system (test task executor) initiates market data subscription to a data engine of the strategy test system according to a strategy to be tested selected by a front end, and the data engine of the strategy test system reads the latest data of a requested product from a Redis database after receiving a subscription request and sends the latest data to a RabbitMQ queue connected with the strategy simulation transaction system (test task executor);
(2) the user selects the historical retest through the front-end interface, and simultaneously selects the strategy and the retest date range (calendar form):
the strategy simulation transaction system (test task executor) initiates subscription of historical market data to a backtesting engine of the strategy test system according to the strategy to be tested selected by the front end and the backtesting time period of the historical backtesting, and after receiving a subscription request, the backtesting engine reads corresponding historical data from a time sequence database or a relational database, sends the historical data to a RabbitMQ queue communicated with the strategy simulation transaction system (test task executor), and temporarily caches the market data at the moment;
fourthly, the strategy simulation trading system (test task executor) reads market quotation data in the RabbitMQ queue and outputs strategy test results (for example, strategy income information);
and (V) the user checks the strategy test result through the front-end interface.
The system can be used for historical return test of strategies and simulated transaction test of the strategies, market quotation data is accessed into a Redis database of a database service module, and the historical market quotation data is stored in a time sequence database or a relational database in a partitioning mode.
Optionally, in order to reduce the read-write operation on the database, when the policy test request is a history retest request, the test task scheduler reads the history market quotation data from the time series database or the relational database according to the test parameter information of the transaction policy to be tested, and caches the history market quotation data to the test service module, so that the test task executor performing history retest on the transaction policy to be tested in the test service module performs history retest on the transaction policy to be tested according to the history market quotation data cached in the test service module.
Fig. 6 is a schematic diagram of optional transaction policy return test systems based on a micro-service architecture according to an embodiment of the present invention, where as shown in fig. 6, a user accesses a front-end service module through a user terminal to submit a policy and click to start return test, the front-end service module sends each policy test request to a return test scheduler through a distributed cache Redis queue, if the operation is overtime or the return test scheduler returns error reporting information, the front-end service module sends a prompt message indicating that test start fails to the user terminal, and if the return test scheduler returns a prompt message indicating that test start succeeds, the front-end service module receives the message and starts polling a database to obtain a return test result.
The backtesting scheduler creates a backtesting example according to the strategy text identification, the backtesting time interval, the transaction target equal-backtesting related parameters transmitted from the front end; and the retest scheduler reads market quotation data from the quotation database and caches the market quotation data to the retest service module according to marks such as product labels, market and date, so that the database reading operation in the retest process is reduced, and the retest efficiency is improved. The backtest scheduler creates a backtest on a backtest cluster (Docker cluster), which reads the backtest instance context data and reads market quotation data from a cache or database service module of the backtest service module.
The retest cluster executes a retest instance through a driving type batch processing engine to complete a retest process; and stores the retest results or the retest reports to a text database in the database service module via Kafka.
The front-end service module scans and reads the text database at regular time and inquires the execution result of the retest instance; and performing visual rendering according to the retest result, and displaying the result to a user through a user terminal to finish the retest.
Fig. 7 is a flow chart of specific implementation of types of history retrieval provided in the embodiment of the present invention, as shown in fig. 7, including the following steps:
(1) and starting a retest engine, starting a thrift service, and waiting for a data subscription request of the transaction strategy to be tested.
(2) Starting a test task executor, initiating a login request, and defining a queue after receiving the login request by a retest engine as follows:
md_(senderCompID):(senderSubID)。
(3) and starting a test task executor and sending a data subscription request to the retest engine.
(4) After the backtesting engine receives the subscription request, taking the mdStreamID in the request parameters as a key binding queue:
md_(senderCompID):(senderSubID)。
(5) and the backtesting engine circularly reads the market data publish from the time sequence database to the corresponding exchange according to the time and the subscription parameters specified in the parameter configuration interface. Here we need to consider the per-packet acknowledgement mechanism of MQ.
(6) The test task executor tests the strategy, outputs a test result strategy receiving message for processing, and sends the quotation information to the simulated transaction system through the TD.
(7) And after the backtesting engine confirms that the data is sent, unbinding the key and then deleting the queue.
(8) And the test task executor tests the strategy and stores the test result into the database.
Fig. 8 is a flowchart of a specific implementation of real-time simulated transaction tests provided in an embodiment of the present invention, as shown in fig. 8, including the following steps:
(1) the data engine starts a thrift service and waits for a data subscription request of a transaction policy to be tested.
(2) Starting a test task executor, initiating a login request to a data engine, and defining a queue md (sendCompID): sendSubID after the policy end receives the login request.
(3) The transaction to be tested sends a data subscription request to the data engine.
(4) After receiving the data subscription request, the data engine takes the mdstreamID in the request parameters as a key binding queue: md _ (sendCompID): sendSubID.
(5) The in the data engine publishes the time and the subscription parameters specified in the parameter configuration interface into the corresponding exchange.
(6) The test task executor listens for mq, , receives and executes the simulated transaction test on the transaction strategy to be tested once there is a new message.
(7) And the test task executor performs simulation transaction test on the strategy and stores the test result into the database.
(8) And if the test task executor cancels the subscription of certain data, the data engine unbinds the key, logs out and outputs a simulation transaction test result.
To sum up, the embodiment of the present invention provides transaction policy test systems based on micro-service architecture, which are implemented by each independent module based on micro-service architecture, and the functions of each sub-service of the transaction policy test system are decomposed, so that the coupling of the system can be reduced, and more flexible service support can be provided.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on a variety of computer-usable storage media including, but not limited to, disk storage, CD-ROM, optical storage, and the like, having computer-usable program code embodied therein.
It is to be understood that each flow and/or block in the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions which can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flow diagram flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
The above embodiments, objects, technical solutions and advantages of the present invention have been described in , it should be understood that the above embodiments are only examples of the present invention and are not intended to limit the scope of the present invention, and any modifications, equivalents, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.
Claims (13)
- The transaction strategy test system based on micro-service architecture is characterized by comprising a front-end service module, a test service module and a database service module, wherein the test service module comprises a test task scheduler and a plurality of test task executors deployed in a cluster;the front-end service module is connected with the user terminal, and is used for receiving a plurality of strategy test requests initiated by the user terminal and sending the strategy test requests to the test service module, wherein each strategy test request comprises strategy information of a transaction strategy to be tested and test parameter information for executing a test on the transaction strategy to be tested;the test service module is connected with the front-end service module and used for sending each strategy test request transmitted by the front-end service module to test task executors through a test task scheduler, wherein each test task executor executes a test on a transaction strategy to be tested according to test parameter information of the transaction strategy to be tested;the database service module is respectively connected with the front-end service module and the testing service module and is used for storing strategy information of the transaction strategy to be tested, market quotation data required by each testing task executor for testing the transaction strategy to be tested and a testing result obtained by each testing task executor for testing the transaction strategy to be tested;the front-end service module is also used for outputting a test result of the transaction strategy to be tested.
- 2. The system of claim 1, wherein the front end service module sends respective policy test requests to the test service module through a Redis message queue.
- 3. The system of claim 1, wherein the test task scheduler is further configured to release physical resources occupied by each test task executor if each test task executor stores a test result of a transaction policy in the database service module.
- 4. The system of claim 3, wherein each test task executor stores test results of a transaction policy in the database service module via a Kafka message queue.
- 5. The system of claim 4, wherein the database service module is further configured to store the test results of the transaction policy in a text database.
- 6. The system of any one of claims 1 to 5 and , wherein the policy test request is a history return test request or a simulation transaction test request, the history return test request is used for requesting to perform history return test on the transaction policy to be tested based on history market data, and the simulation transaction test request is used for requesting to perform simulation transaction test on the transaction policy to be tested based on real-time market data, wherein the trigger mode of the test task executor is event trigger in case of the policy test request being the history return test request, and the trigger mode of the test task executor is event trigger in case of the policy test request being the simulation transaction test request.
- 7. The system of claim 6, wherein the database service module is further configured to store real-time market quotation data in a Redis database, and to store historical market quotation data in a time series database, or in a relational database in a partitioned manner.
- 8. The system of claim 7, wherein when the policy test request is a simulated transaction test request, a test task executor of the test service module that performs simulated transaction testing on the transaction policy to be tested reads real-time market quotation data directly from the Redis database.
- 9. The system of claim 7, wherein, when the policy test request is a historical return test request, the test task scheduler reads historical market quotation data from the time-series database or the relational database according to the test parameter information of the transaction policy to be tested, and caches the historical market quotation data to the test service module; the test service module is used for executing the historical retest to the transaction strategy to be tested, and the test service module is used for executing the historical retest to the transaction strategy to be tested according to the historical market quotation data cached in the test service module.
- 10. The system of claim 8 or 9, wherein each test task executor reads market quotation data required to perform testing on trading strategies through a RabbitMQ message queue.
- 11. The system of claim 10, wherein each test task executor returns acknowledgement messages to the RabbitMQ message queue after reading the market quotation data for each tick, and the RabbitMQ message queue clears the market quotation data for the corresponding tick based on the received acknowledgement messages returned by each test task executor.
- 12. The system of claim 1, wherein the transaction policy under test is a transaction policy created locally at the user terminal by code writing or visual configuration.
- 13. The system of claim 1, wherein the test service module employs Docker to build test task executors of a cluster deployment, each test task executor monopolizing Docker containers.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911010054.5A CN110740184B (en) | 2019-10-23 | 2019-10-23 | Transaction strategy testing system based on micro-service architecture |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911010054.5A CN110740184B (en) | 2019-10-23 | 2019-10-23 | Transaction strategy testing system based on micro-service architecture |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110740184A true CN110740184A (en) | 2020-01-31 |
| CN110740184B CN110740184B (en) | 2022-09-20 |
Family
ID=69270980
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911010054.5A Active CN110740184B (en) | 2019-10-23 | 2019-10-23 | Transaction strategy testing system based on micro-service architecture |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110740184B (en) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111737125A (en) * | 2020-06-19 | 2020-10-02 | 中国工商银行股份有限公司 | Method and device for generating market data of quantitative transaction and server |
| CN112596885A (en) * | 2020-12-25 | 2021-04-02 | 网易（杭州）网络有限公司 | Task scheduling method, device, equipment and storage medium |
| CN112866256A (en) * | 2021-01-22 | 2021-05-28 | 中信银行股份有限公司 | Data processing method, device and storage medium |
| CN112905486A (en) * | 2021-03-26 | 2021-06-04 | 建信金融科技有限责任公司 | Service integration test method, device and system |
| CN113300900A (en) * | 2020-06-28 | 2021-08-24 | 阿里巴巴集团控股有限公司 | Method, device and system for testing service on cloud and method and device for testing container |
| CN114723566A (en) * | 2022-06-10 | 2022-07-08 | 高盈国际创新科技(深圳)有限公司 | Financial transaction data processing method and system |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150205709A1 (en) * | 2008-09-30 | 2015-07-23 | Interactive TKO, Inc. | Modeling and Testing Interactions Between Components Of A Software System |
| CN107578334A (en) * | 2017-09-07 | 2018-01-12 | 张毅 | The execution method and distributed transaction system of a kind of electronic transaction strategy |
| CN207490985U (en) * | 2017-09-07 | 2018-06-12 | 厦门宽投信息科技有限公司 | A kind of electronic transaction strategy test equipment |
| CN108765149A (en) * | 2018-05-11 | 2018-11-06 | 南京工程学院 | A kind of quantization strategy based on cluster returns examining system and its returns survey method |
| CN110349022A (en) * | 2019-06-28 | 2019-10-18 | 北京奇才天下科技有限公司 | A kind of automated testing method, device and the electronic equipment of the virtual credit card transaction scene based on micro services |
-
2019
- 2019-10-23 CN CN201911010054.5A patent/CN110740184B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150205709A1 (en) * | 2008-09-30 | 2015-07-23 | Interactive TKO, Inc. | Modeling and Testing Interactions Between Components Of A Software System |
| CN107578334A (en) * | 2017-09-07 | 2018-01-12 | 张毅 | The execution method and distributed transaction system of a kind of electronic transaction strategy |
| CN207490985U (en) * | 2017-09-07 | 2018-06-12 | 厦门宽投信息科技有限公司 | A kind of electronic transaction strategy test equipment |
| CN108765149A (en) * | 2018-05-11 | 2018-11-06 | 南京工程学院 | A kind of quantization strategy based on cluster returns examining system and its returns survey method |
| CN110349022A (en) * | 2019-06-28 | 2019-10-18 | 北京奇才天下科技有限公司 | A kind of automated testing method, device and the electronic equipment of the virtual credit card transaction scene based on micro services |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111737125A (en) * | 2020-06-19 | 2020-10-02 | 中国工商银行股份有限公司 | Method and device for generating market data of quantitative transaction and server |
| CN111737125B (en) * | 2020-06-19 | 2024-01-30 | 中国工商银行股份有限公司 | Method, device and server for generating quotation data of quantized transaction |
| CN113300900A (en) * | 2020-06-28 | 2021-08-24 | 阿里巴巴集团控股有限公司 | Method, device and system for testing service on cloud and method and device for testing container |
| CN112596885A (en) * | 2020-12-25 | 2021-04-02 | 网易（杭州）网络有限公司 | Task scheduling method, device, equipment and storage medium |
| CN112866256A (en) * | 2021-01-22 | 2021-05-28 | 中信银行股份有限公司 | Data processing method, device and storage medium |
| CN112905486A (en) * | 2021-03-26 | 2021-06-04 | 建信金融科技有限责任公司 | Service integration test method, device and system |
| CN114723566A (en) * | 2022-06-10 | 2022-07-08 | 高盈国际创新科技(深圳)有限公司 | Financial transaction data processing method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110740184B (en) | 2022-09-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110740184B (en) | Transaction strategy testing system based on micro-service architecture | |
| US10013278B2 (en) | Methods and systems for batch processing in an on-demand service environment | |
| CN108536532B (en) | Batch task processing method and system | |
| US8306996B2 (en) | Processing model-based commands for distributed applications | |
| US7769821B2 (en) | Systems and methods for enhanced meassage support using a generic client proxy | |
| CN105718244B (en) | A kind of streamlined data are shuffled Spark task schedulings and the execution method of transmission | |
| CN110806933B (en) | Batch task processing method, device, equipment and storage medium | |
| US10467576B2 (en) | Distributed software process tracking | |
| CN111414389B (en) | Data processing method and device, electronic equipment and storage medium | |
| US9529651B2 (en) | Apparatus and method for executing agent | |
| AU2018309008B2 (en) | Writing composite objects to a data store | |
| CN110012062B (en) | Multi-computer-room task scheduling method and device and storage medium | |
| CN109426550A (en) | The dispatching method and equipment of resource | |
| JP4536833B2 (en) | Financial information processing system | |
| CN111367792A (en) | Test method, test device, storage medium and electronic equipment | |
| CN111813868B (en) | Data synchronization method and device | |
| US9886473B2 (en) | Managing job status | |
| CN115984022B (en) | Unified account checking method and device for distributed payment system | |
| CN114153427A (en) | Optimization method and system of continuous integration assembly line | |
| US20120296951A1 (en) | System and method to execute steps of an application function asynchronously | |
| TWI287725B (en) | Specifying parameters for selective return to an invoker | |
| US20080163225A1 (en) | Method and/or system for task scheduling | |
| CN110209940A (en) | Display methods, server and the computer storage medium of alternative loose-leaf | |
| CN114510337B (en) | Task execution method, system and computer readable storage medium | |
| CN114546629B (en) | Task execution system, method, server, and computer-readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |