Middleware migration test method and device, equipment, medium and program product

Abstract

The invention provides a middleware migration test method which can be applied to the technical field of big data. The method comprises the following steps: receiving online transactions from a plurality of channels, and storing transaction data of the online transactions to a buffer pool; in response to the transaction data received by the buffer pool, obtaining the state of a back-switching identifier deployed on the original middleware; under the condition that the state of the cut-back identifier indicates that transaction data distribution is allowed, obtaining a distribution strategy from a rule database, and distributing the transaction data in the buffer pool to an original server and a test server according to the distribution strategy; a plurality of distribution strategies are stored in the rule database; the plurality of distribution strategies are combinations of a plurality of distribution rules with different priorities; analyzing the performance data of the transaction data processed by the original server and the test server, and taking the analysis result as the test result of the middleware migration test. The invention further provides a middleware migration test device, electronic equipment, a storage medium and a program product.

Description

Methods, apparatus, equipment, media, and procedures for middleware migration testing Technical Field

[0001] This disclosure relates to the field of big data, and more specifically to a method, apparatus, equipment, medium, and program product for middleware migration testing. Background Technology

[0002] Based on actual production needs, a large number of open platform applications need to be migrated from the original middleware to the new middleware. The evaluation of the hardware and software standards of the new middleware includes memory capacity, number of processors, cache size, etc. Online performance data such as business transaction response time, transaction throughput, server availability, transaction latency, number of concurrent transaction connections, and database query speed of the original middleware and the new middleware servers are collected, compared and analyzed.

[0003] Currently, performing separate functional and performance tests on application systems based on the original middleware and the new middleware results in low testing efficiency. Summary of the Invention

[0004] In view of the above problems, this disclosure provides methods, apparatus, equipment, media and program products for middleware migration testing to improve testing efficiency and convenience.

[0005] According to a first aspect of this disclosure, a method for middleware migration testing is provided. The middleware includes a source middleware and a test middleware configured as a distributed system. The source middleware runs on a source server, and the test middleware runs on a test server. The method includes: receiving online transactions from multiple channels and storing the transaction data of the online transactions in a buffer pool; in response to the buffer pool receiving the transaction data, obtaining the status of a switchback flag deployed on the source middleware; if the status of the switchback flag indicates that transaction data allocation is permitted, obtaining an allocation strategy from a rule database, and allocating the transaction data in the buffer pool to the source server and the test server according to the allocation strategy; the rule database stores multiple allocation strategies; the multiple allocation strategies are combinations of multiple allocation rules with different priorities; analyzing the performance data of the source server and the test server in processing the transaction data, and using the analysis results as the test results of the middleware migration test.

[0006] According to embodiments of this disclosure, the aforementioned multiple allocation rules include: application distribution rules, group distribution rules, and service distribution rules; wherein, the application distribution rules have a higher priority than the group distribution rules; and the group distribution rules have a higher priority than the service distribution rules.

[0007] According to embodiments of this disclosure, the aforementioned multiple allocation strategies include a first allocation strategy, a second allocation strategy, and a third allocation strategy; the first allocation strategy is a strategy that includes application distribution rules; the second allocation strategy is a strategy that includes group distribution rules but does not include application distribution rules; and the third allocation strategy is a strategy that only includes service distribution rules.

[0008] According to embodiments of this disclosure, the above-mentioned allocation of transaction data in the buffer pool to the original server and the test server according to the above-mentioned allocation strategy includes: when the above-mentioned allocation strategy is the first allocation strategy, adding a tag of the server where the target application is located to the transaction data of the target application indicated in the online transaction application distribution rule; when the above-mentioned allocation strategy is the second allocation strategy, adding a tag of the server where the target group is located to the transaction data of the target group indicated in the online transaction group distribution rule; when the above-mentioned allocation strategy is the third allocation strategy, adding a tag of the server where the target service is located to the transaction data of the target service indicated in the online transaction service distribution rule; and uploading the tagged transaction data to the server indicated by the tag.

[0009] According to embodiments of this disclosure, the method further includes: uploading the transaction data in the buffer pool to the original server when the status of the back-off flag indicates that transaction data allocation is prohibited.

[0010] According to embodiments of this disclosure, the method further includes: controlling the processing of transaction data received by the original middleware from the original server and the processing of transaction data received by the test middleware from the test server to be performed simultaneously.

[0011] According to embodiments of this disclosure, the above allocation strategy is adjusted based on the analysis results described above.

[0012] According to embodiments of this disclosure, the aforementioned performance data includes at least one of the following: online transaction response time, transaction throughput, server availability, transaction latency, number of concurrent transaction connections, and database query speed.

[0013] A second aspect of this disclosure provides an apparatus for middleware migration testing. The middleware includes a source middleware and a test middleware configured as a distributed system. The source middleware runs on a source server, and the test middleware runs on a test server. The apparatus includes: a data receiving module for receiving online transactions from multiple channels and storing the transaction data of the online transactions in a buffer pool; a status acquisition module for acquiring the status of a switchback flag deployed on the source middleware in response to the buffer pool receiving the transaction data; a data allocation module for acquiring an allocation strategy from a rule database when the status of the switchback flag indicates that transaction data allocation is permitted, and allocating the transaction data in the buffer pool to the source server and the test server according to the allocation strategy; the rule database stores multiple allocation strategies; the multiple allocation strategies are combinations of multiple allocation rules with different priorities; and a performance analysis module for analyzing the performance data of the source server and the test server respectively in processing the transaction data, and using the analysis results as the test results of the middleware migration test.

[0014] A third aspect of this disclosure provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0015] A fourth aspect of this disclosure also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0016] The fifth aspect of this disclosure also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.

[0017] According to embodiments of this disclosure, by constructing a distributed system including a source server and a test server, simultaneous testing of the source middleware and the test middleware is achieved, improving the testing efficiency of the source middleware and the test middleware in middleware migration testing scenarios. Furthermore, by configuring allocation strategies with different priorities, the flexibility of transaction data allocation is improved, thereby enhancing the convenience of middleware migration testing. In addition, when testing the source middleware and the test middleware, the same online transaction data is used, reducing the error in test results between the source server and the test server due to differences in online transactions, and improving the accuracy of the middleware migration test results. Attached Figure Description

[0018] The foregoing contents, as well as other objects, features, and advantages of this disclosure, will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0019] Figure 1 schematically illustrates an application scenario of the middleware migration testing method, apparatus, device, medium, and program product according to embodiments of the present disclosure;

[0020] Figure 2 schematically illustrates a flowchart of a middleware migration test method according to an embodiment of the present disclosure;

[0021] Figure 3 schematically illustrates an application scenario of a middleware migration testing method according to another embodiment of the present disclosure;

[0022] Figure 4 schematically illustrates a flowchart of a middleware migration test method according to another embodiment of the present disclosure;

[0023] Figure 5 schematically illustrates a structural block diagram of an apparatus for middleware migration testing according to an embodiment of the present disclosure; and

[0024] Figure 6 schematically illustrates a block diagram of an electronic device suitable for implementing a method for middleware migration testing according to an embodiment of the present disclosure. Detailed Implementation

[0025] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0026] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0027] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0028] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0029] In the technical solution disclosed herein, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse.

[0030] In scenarios involving automated decision-making using personal information, the methods, devices, and systems provided in this disclosure all offer users corresponding entry points for choosing to agree to or reject the automated decision-making results. If the user chooses to reject, the process proceeds to the expert decision-making stage. Here, "automated decision-making" refers to the activity of automatically analyzing and evaluating an individual's behavioral habits, interests, or economic, health, and credit status through computer programs, and then making a decision. Here, "expert decision-making" refers to the activity of making decisions by personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0031] Based on actual production needs, a large number of open platform applications need to be migrated from the original middleware to the new middleware. This necessitates an evaluation of the new middleware's hardware and software standards, including memory capacity, number of processors, cache size, etc. It also requires collecting and analyzing online performance data from both the original and new middleware servers, such as transaction response time, transaction throughput, server availability, transaction latency, number of concurrent transaction connections, and database query speed. This comparison and analysis plays a crucial role in the application migration process. The new middleware will be referred to as the test middleware below.

[0032] Traditional performance evaluation methods involve conducting separate functional and performance tests on application systems based on the original middleware and the test middleware, and then evaluating the metrics of the new test middleware server by comparing the test data of the original middleware and the test middleware servers.

[0033] The original method of testing the middleware and test middleware servers separately has several shortcomings. First, the traffic brought into the middleware and test middleware servers differs, affecting the accuracy of the output results. Second, testing the middleware and test middleware servers separately requires building different test time windows due to different business scenarios, resulting in low system migration efficiency. Business scenarios can include the head office and branch operations of a banking system, different functional pages of a shopping system, etc. For example, a banking system may have a scenario where the head office and branches participate in business verification. Third, in terms of monitoring, the test output results of traditional methods are static data. Usually, the input strategy is adjusted by reverse analysis of the output results, and the output results after the adjustment strategy are analyzed to see if they meet expectations. This requires redeploying the environment, initiating transactions, and adjusting parameters, resulting in high labor and time costs.

[0034] Embodiments of this disclosure provide a method for middleware migration testing, comprising: receiving online transactions from multiple channels and storing the transaction data of the online transactions in a buffer pool; in response to the buffer pool receiving transaction data, obtaining the status of a switchback flag deployed on the original middleware; if the status of the switchback flag indicates that transaction data allocation is permitted, obtaining an allocation strategy from a rule database, and allocating the transaction data in the buffer pool to the original server and the test server according to the allocation strategy; the rule database stores multiple allocation strategies; the multiple allocation strategies are combinations of multiple allocation rules with different priorities; analyzing the performance data of the original server and the test server in processing transaction data, and using the analysis results as the test results of the middleware migration test.

[0035] According to embodiments of this disclosure, by constructing a distributed system including a source server and a test server, simultaneous testing of the source middleware and the test middleware is achieved, improving the testing efficiency of the source middleware and the test middleware in middleware migration testing scenarios. Furthermore, by configuring allocation strategies with different priorities, the flexibility of transaction data allocation is improved, thereby enhancing the convenience of middleware migration testing. In addition, when testing the source middleware and the test middleware, the same online transaction data is used, reducing the error in test results between the source server and the test server due to differences in online transactions, and improving the accuracy of the middleware migration test results.

[0036] Figure 1 schematically illustrates an application scenario of a method, apparatus, device, medium, and program product for middleware migration testing according to embodiments of the present disclosure.

[0037] As shown in Figure 1, the application scenario according to this embodiment may include a source server 101, a test server 102, and a terminal device 103. The source server 101 and the test server 102 are connected to the terminal device 103 via a network; the network serves as a medium to provide communication links between the terminal device 103 and the source server 101, and between the terminal device 103 and the test server 102. The network may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0038] The test server 102 is treated as an extension node of the original server 101, thus integrating the two independent servers, the original server 101 and the test server 102, into a single independent distributed system. The test server 102 is equipped with the test middleware, and the original server 101 is equipped with the original middleware. The original middleware runs on the original server, while the test middleware runs on the test server.

[0039] Users can use terminal device 103 to interact with the original server 101 and test server 102 via the network to receive performance data from the original server 101 and test server 102 or send transaction data for online transactions.

[0040] Terminal device 103 can be various electronic devices with a display screen and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0041] It should be noted that the middleware migration testing method provided in this disclosure embodiment can generally be executed by the terminal device 103. Correspondingly, the middleware migration testing apparatus provided in this disclosure embodiment can generally be located in the terminal device 103. The middleware migration testing method provided in this disclosure embodiment can also be executed by a server or server cluster that is different from the terminal device 103 and capable of communicating with the original server 101 and the test server 102 and / or the terminal device 103. Correspondingly, the middleware migration testing apparatus provided in this disclosure embodiment can also be located in a server or server cluster that is different from the terminal device 103 and capable of communicating with the original server 101 and the test server 102 and / or the terminal device 103.

[0042] The following will describe in detail the middleware migration test method of the disclosed embodiment based on the scenario described in Figure 1, using Figures 2 to 4.

[0043] Figure 2 schematically illustrates a flowchart of a middleware migration test method according to an embodiment of the present disclosure.

[0044] As shown in Figure 2, the middleware migration test method of this embodiment includes operations S210 to S240.

[0045] In operation S210, online transactions from multiple channels are received, and the transaction data of the online transactions is stored in a buffer pool.

[0046] In the embodiments of this disclosure, during operation S210, online transactions from various channels are received through the traffic persistence unit, including online transactions initiated by testers, automated batch scripts, and business online transaction traffic initiated by clients, or high-concurrency scripts initiated by testing tools. A buffer pool is formed by first persisting the transaction information and then asynchronously fetching and uploading it. This facilitates subsequent querying and management of transaction execution and reduces system complexity.

[0047] In operation S220, in response to the buffer pool receiving transaction data, the status of the switchback flag deployed on the original middleware is obtained.

[0048] In embodiments of this disclosure, the state of the cutback flag includes allowing transaction data allocation and disallowing transaction data allocation. When the cutback flag indicates that transaction data allocation is prohibited, the transaction data in the buffer pool is uploaded to the original server.

[0049] According to embodiments of this disclosure, in some cases, when it is necessary for all transaction data to be processed by the original middleware, this can be achieved by setting a flag to prohibit transaction data allocation on the switchback flag. This facilitates the rapid execution of having all transaction data processed by the original middleware, saves resources, and improves the reliability and ease of operation of the testing method. When it is not necessary for all transaction data to be processed by the original middleware, transaction data is allocated according to the allocation rules.

[0050] In operation S230, if the status of the back-off flag indicates that transaction data allocation is allowed, the allocation strategy is obtained from the rule database, and the transaction data in the buffer pool is allocated to the original server and the test server according to the allocation strategy. The rule database stores multiple allocation strategies. Multiple allocation strategies are combinations of multiple allocation rules with different priorities.

[0051] In the embodiments of this disclosure, the multiple allocation rules include: application distribution rules, group distribution rules, and service distribution rules; wherein, the application distribution rules have a higher priority than the group distribution rules; and the group distribution rules have a higher priority than the service distribution rules.

[0052] In the embodiments of this disclosure, the multiple allocation rules may also include user requests, random allocation, the importance of online transaction data, time-based distribution rules, etc., and the priority of different allocation rules can be set according to the actual application needs.

[0053] For example, user-requested transaction data can be processed using the original middleware or the test middleware. Alternatively, to achieve the general performance of the current test middleware, a random distribution rule can be applied. Or, transaction data at different time points can be set to be processed by the corresponding original middleware or test middleware. In addition, online transaction data with high importance can be distributed to the original middleware for processing, while online transaction data with low importance can be distributed to the test middleware for processing.

[0054] In the embodiments of this disclosure, multiple allocation rules can be combined to obtain multiple allocation strategies, and multiple allocation strategies can realize various data distribution methods, improving the flexibility of transaction data allocation and thus improving the convenience of middleware migration testing.

[0055] In embodiments of this disclosure, the multiple allocation strategies include a first allocation strategy, a second allocation strategy, and a third allocation strategy; the first allocation strategy is a strategy that includes application distribution rules; the second allocation strategy is a strategy that includes group distribution rules but does not include application distribution rules; and the third allocation strategy is a strategy that only includes service distribution rules.

[0056] In the embodiments of this disclosure, since the allocation rules have different priorities, the multiple allocation strategies also differ. For example, when an allocation strategy restricts application distribution rules, group distribution rules, and service distribution rules, only the restriction on application distribution rules is executed. When an allocation strategy restricts only group distribution rules and service distribution rules, only the restriction on group distribution rules is executed. When an allocation strategy restricts only service distribution rules, only the restriction on service distribution rules is executed. Because the allocation strategy is dynamically adjusted, different combinations can be set according to the actual needs of the test.

[0057] According to embodiments of this disclosure, by configuring allocation strategies with different priorities, the flexibility of transaction data allocation is improved, thereby enhancing the convenience of middleware migration testing.

[0058] In embodiments of this disclosure, transaction data in the buffer pool is allocated to the original server and the test server according to an allocation strategy, including: when the allocation strategy is a first allocation strategy, adding a tag to the server where the target application is located to the transaction data of the target application indicated in the online transaction application distribution rule; when the allocation strategy is a second allocation strategy, adding a tag to the server where the target group is located to the transaction data of the target group indicated in the online transaction group distribution rule; when the allocation strategy is a third allocation strategy, adding a tag to the server where the target service is located to the transaction data of the target service indicated in the online transaction service distribution rule; and uploading the tagged transaction data to the server indicated by the tag.

[0059] According to embodiments of this disclosure, each change to the dynamic routing of the allocation policy triggers an automatic push mechanism. The dynamic routing policy format is: Y = APP_NAME + GROUP_NAME + SERVICE_NAME. Where Y is the dynamic routing policy, APP_NAME is the application name, indicating filtering and distribution at the application level; if the application level is ineffective, then APP_NAME = F - NULL; GROUP_NAME is the group level, indicating filtering and distribution at the group level; if the group level is ineffective, then GROUP_NAME = G - NULL; SERVICE_NAME is the service name, indicating distribution at the service level; if the service level is ineffective, then SERVICE_NAME = S - NULL. The permissions for the three levels to take effect are: APP_NAME > GROUP_NAME > SERVICE_NAME.

[0060] According to embodiments of this disclosure, by configuring allocation strategies with different priorities, the flexibility of transaction data allocation is improved, thereby enhancing the convenience of middleware migration testing. When testing the original middleware and the test middleware, the same online transaction data is used, reducing the error in test results between the original server and the test server due to differences in online transactions, and improving the accuracy of middleware migration test results.

[0061] When operating S240, the performance data of the original server and the test server in processing transaction data are analyzed, and the analysis results are used as the test results of the middleware migration test.

[0062] According to embodiments of this disclosure, by constructing a distributed system including a source server and a test server, simultaneous testing of the source middleware and the test middleware is achieved, improving the testing efficiency of the source middleware and the test middleware in middleware migration testing scenarios. Furthermore, by configuring allocation strategies with different priorities, the flexibility of transaction data allocation is improved, thereby enhancing the convenience of middleware migration testing. In addition, when testing the source middleware and the test middleware, the same online transaction data is used, reducing the error in test results between the source server and the test server due to differences in online transactions, and improving the accuracy of the middleware migration test results.

[0063] Figure 3 schematically illustrates an application scenario of a middleware migration testing method according to another embodiment of the present disclosure.

[0064] As shown in Figure 3, the distributed system architecture of this embodiment includes: variable center 301, dynamic policy push unit 302, traffic persistence unit 303, routing rule calculation unit 304, traffic tagging unit 305, traffic distribution unit 306, test server unit 307, original server unit 308, back-switch unit 309, analysis result display unit 310, data analysis unit 311, and performance acquisition unit 312.

[0065] In the embodiments of this disclosure, the variable center 301 is responsible for managing all variables of the original middleware and the test middleware. The dynamic variable function manages variables that can be changed during application system operation. The dynamic policy push unit 302 is deployed in the variable center 301. The dynamic policy push unit 302 configures dynamic routing policies and can push these policies to routing users. The traffic persistence unit 303 is responsible for receiving business traffic, including online transaction traffic initiated by the client or high-concurrency scripts initiated by test tools.

[0066] In the embodiments of this disclosure, the routing rule calculation unit 304 is used to read and parse the dynamic routing policy, i.e., the allocation policy, pushed by the dynamic policy push unit 302. The routing parsing result includes three dimensions: application, group, and service. The traffic tagging unit 305 is used to add the tag ENV=NEW to the traffic URL of traffic that conforms to the test middleware, and add the tag ENV=OLD to the traffic URL of traffic that does not conform to the test middleware, based on the routing rule parsing result of the three dimensions of the routing rule calculation unit 304. The traffic distribution unit 306 routes the traffic with ENV=NEW to the test middleware unit and the traffic with ENV=OLD to the original middleware unit based on the traffic tags of the traffic tagging unit 305.

[0067] In the embodiments of this disclosure, the test server unit 307 uses the services provided by the test middleware as the target server for migration. The original server unit 308 uses the services provided by the original middleware. By controlling the timing of the processing of transaction data by the test server unit 307 and the original middleware / original server unit 308, the processing of transaction data received by the original server and the processing of transaction data received by the test server by the test middleware can be performed simultaneously.

[0068] According to embodiments of this disclosure, when controlling the original server and the test server to process the received transaction data simultaneously, a time synchronization mechanism and a unified trigger signal can be used to enable the original server and the test server to process their respective received transaction data at the same time.

[0069] For example, the system clocks of the origin server and the test server are calibrated using a time synchronization protocol. Based on clock synchronization, trigger signals are sent to both the origin server and the test server to execute tasks simultaneously. These trigger signals can be based on synchronization triggered by a central controller, sending synchronization instructions to both servers through an independent control node, such as a third server, script controller, or physical device. Alternatively, they can be based on hardware signals, such as transmitting trigger signals via physical hardware, using the same clock source to provide synchronization for both servers, sending hardware pulse signals via trigger lines, and having the servers capture these hardware pulse signals through interrupt routines and immediately execute the tasks.

[0070] According to the embodiments of this disclosure, by simultaneously applying the received transaction data to the original server and the test server for testing, the testing efficiency is improved, and the same online transaction data is used, reducing the error in the test results between the original server and the test server caused by different online transactions.

[0071] In the embodiments of this disclosure, the back-off switch unit 309 is deployed on the original server, and the routing calculation unit determines whether the switch is open. When the back-off switch's state value VALUE is Y, dynamic routing is enabled; when the back-off switch's state value VALUE is N, dynamic routing is disabled. All service traffic flows through the original server.

[0072] In the embodiments of this disclosure, the performance acquisition unit 312 acquires performance metrics of the origin server and the test server. The performance data includes at least one of the following: online transaction response time, transaction throughput, server availability, transaction latency, number of concurrent transaction connections, and database query speed. By acquiring values ​​from different aspects of the performance data, a more comprehensive test of the origin server and the test server can be achieved, leading to more accurate evaluation results and thus a precise assessment of the hardware and software configuration metrics and deployment effectiveness of the test middleware.

[0073] In the embodiments of this disclosure, the data analysis unit 311 compares and analyzes the performance acquisition data sent by the performance acquisition unit 312. The analysis result display unit 312 displays the analysis results of the data analysis unit 311 on the monitoring client. Users can intuitively view the performance differences between the old and new servers. Based on the analysis results, the allocation strategy is adjusted, thereby achieving a closed-loop adjustment of the allocation strategy.

[0074] According to embodiments of this disclosure, when adjusting the allocation strategy, the adjustment of the allocation strategy can be automatically triggered by a preset rule that matches the analysis results, or the allocation strategy can be adjusted by technicians based on the analysis results.

[0075] When adjusting the allocation strategy, if the analysis results show that the transaction throughput of the original server is high, the transaction data processed by the original server can be changed to be processed by the test server. For example, the target application indicated in the application distribution rule for online transactions can be modified. The target application of the original server indicated in the application distribution rule for online transactions can be changed to the name of the application on the test server that can process the transaction data, and the name of the application on the test server can be used as the target application indicated in the application distribution rule. Here, the transaction data refers to the transaction data processed by the target application of the original server in processing online transactions.

[0076] According to embodiments of this disclosure, by adjusting the allocation strategy online in a closed-loop manner, a closed-loop test management system can be achieved, enabling targeted testing of the performance of the test middleware and further improving the testing effect.

[0077] This disclosure treats the test middleware server as an extension node of the original middleware server, integrating the two independent servers into a single distributed system. Data from the original and test middleware servers is distinguished by tagging the business traffic of online transactions according to an allocation strategy. A traffic routing unit is set up at the input of the integrated distributed system. This unit is responsible for routing different traffic to the old and new server units, ultimately displaying online transaction metrics in a unified monitoring unit. Furthermore, online dynamic traffic adjustment can be performed during implementation. This enables parallel testing of the original and test middleware servers, significantly compressing the testing time window, dynamically adjusting the allocation strategies of the original and test middleware servers, intuitively displaying the test results of the original and test middleware servers, and accurately evaluating various hardware and software metrics of the migrated test middleware.

[0078] This disclosure overcomes the shortcomings of existing methods that require separate testing of the original server and test server during the migration of the original middleware to the test middleware. It treats the test middleware server as an expansion node of the original middleware server and integrates the original middleware and test middleware into a unified system for testing. This effectively compresses the testing time window, intuitively demonstrates the operating effects of the original server and test server, and dynamically adjusts the online transaction traffic of the original server and test server, thereby accurately evaluating the hardware and software configuration indicators and production effectiveness of the test middleware.

[0079] Figure 4 schematically illustrates a flowchart of a middleware migration test method according to another embodiment of the present disclosure.

[0080] As shown in Figure 4, the steps of the middleware migration test method in this embodiment include: operation S401 to operation S413.

[0081] In operation S401, online transaction data is persisted.

[0082] In the embodiments of this disclosure, online transactions from various channels are received through a traffic persistence unit, including online transactions initiated by testers from various branches and other institutions, as well as automated batch scripts. A buffer pool is formed by first persisting the transaction information and then asynchronously fetching and uploading it. This facilitates subsequent querying and management of transaction execution and reduces system complexity.

[0083] In operation S402, determine whether the status of the cutback flag indicates that transaction data allocation is permitted. If the status of the cutback flag indicates that transaction data allocation is permitted, execute operation S403; if the status of the cutback flag indicates that transaction data allocation is permitted, execute operation S407.

[0084] In the embodiments of this disclosure, after the online transaction data is sent to the distributed system, the routing rule calculation unit is triggered to pull the switchback flag SWICH_FLAG deployed on the original middleware service unit. When the switchback flag SWICH_FLAG is Y, it indicates that the online transaction data will be directly sent to the service unit where the original middleware is located, i.e., following the transaction path before migration; when the switchback flag SWICH_FLAG is N, it indicates that the online transaction data will be uploaded to the service unit servers where the original middleware is located and the test middleware is located according to the custom routing strategy.

[0085] In operation S403, routing rules are calculated and allocation strategies are determined.

[0086] In the embodiments of this disclosure, the obtained allocation strategy is parsed, and the parsing result is stored in the routing memory of the rule calculation unit. The storage format is a hash table.

[0087] When operating S404, the transaction data is tagged according to the allocation strategy.

[0088] In the embodiments of this disclosure, the allocation strategy of operation S403 is used to tag the transaction data traffic URL sent in operation S401. A prefix (PREFIX) identifier is added to the transaction data traffic URL, for example, the prefix identifier ENV=XXX; where ENV=NEW indicates that the transaction data is uploaded to the test middleware server; ENV=OLD indicates that the transaction data is uploaded to the original middleware server.

[0089] In operation S405, transaction data is distributed according to the tag. If the tag indicates a test server, operation S406 is executed; if the tag indicates an origin server, operation S407 is executed.

[0090] When operating S406, transaction data is distributed to the test server.

[0091] When operating S407, transaction data is distributed to the original server.

[0092] When operating S408, performance data of the original server and the test server are collected.

[0093] In the embodiments of this disclosure, performance and capacity data are collected on the transaction data of the original middleware server and the test middleware server generated by operations S406 and S407. This includes: business online transaction response time, transaction throughput, server availability, transaction latency, number of concurrent transaction connections, and database query speed.

[0094] The S409 is used to analyze the collected new energy data.

[0095] In the embodiments of this disclosure, the performance metrics sent by the server where the original middleware resides and the server where the test middleware resides are compared.

[0096] The analysis results are obtained and displayed after operating S410.

[0097] In operation S411, determine whether the test has ended. If the test has ended, execute operation S413; if the test has not ended, execute operation S412.

[0098] When operating S412, the allocation strategy is dynamically adjusted based on the analysis results.

[0099] In the embodiments of this disclosure, the allocation strategy is adjusted online by operating the display results of S410, forming a closed loop for the full lifecycle test management of a two-node distributed system.

[0100] The test ended after operating S413.

[0101] Based on the middleware migration testing method described above, this disclosure also provides a middleware migration testing apparatus. The apparatus will be described in detail below with reference to Figure 5.

[0102] Figure 5 schematically illustrates a structural block diagram of an apparatus for middleware migration testing according to an embodiment of the present disclosure.

[0103] As shown in Figure 5, the middleware includes the original middleware and the test middleware, which are constructed as a distributed system. The original middleware runs on the original server, and the test middleware runs on the test server. The middleware migration test apparatus 500 in this embodiment includes a data receiving module 510, a status acquisition module 520, a data distribution module 530, and a performance analysis module 540.

[0104] The data receiving module 510 is used to receive online transactions from multiple channels and store the transaction data of the online transactions in a buffer pool. In one embodiment, the data receiving module 510 can be used to perform the operation S210 described above, which will not be repeated here.

[0105] The status acquisition module 520 is used to acquire the status of the switchback identifier deployed on the original middleware in response to the receipt of transaction data by the buffer pool. In one embodiment, the status acquisition module 520 can be used to perform the operation S220 described above, which will not be repeated here.

[0106] The data allocation module 530 is used to retrieve an allocation strategy from the rule database when the status of the rollback flag indicates that transaction data allocation is permitted, and allocate the transaction data in the buffer pool to the original server and the test server according to the allocation strategy. The rule database stores multiple allocation strategies; the multiple allocation strategies are combinations of multiple allocation rules with different priorities. In one embodiment, the data allocation module 530 can be used to perform the operation S230 described above, which will not be repeated here.

[0107] The performance analysis module 540 is used to analyze the performance data of the source server and the test server in processing transaction data, and uses the analysis results as the test results of the middleware migration test. In one embodiment, the performance analysis module 540 can be used to perform the operation S240 described above, which will not be repeated here.

[0108] According to embodiments of this disclosure, any plurality of modules among the data receiving module 510, status acquisition module 520, data allocation module 530, and performance analysis module 540 may be combined into one module, or any one of these modules may be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules may be combined with at least part of the functionality of other modules and implemented in one module. According to embodiments of this disclosure, at least one of the data receiving module 510, status acquisition module 520, data allocation module 530, and performance analysis module 540 may be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the data receiving module 510, status acquisition module 520, data allocation module 530, and performance analysis module 540 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0109] Figure 6 schematically illustrates a block diagram of an electronic device suitable for implementing a method for middleware migration testing according to an embodiment of the present disclosure.

[0110] As shown in FIG6, an electronic device 600 according to an embodiment of the present disclosure includes a processor 601, which can perform various appropriate actions and processes according to a program stored in ROM (Read-Only Memory) 602 or a program loaded from storage portion 608 into RAM (Random Access Memory) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0111] RAM 603 stores various programs and data required for the operation of electronic device 600. Processor 601, ROM 602, and RAM 603 are interconnected via bus 604. Processor 601 performs various operations of the method flow according to embodiments of the present disclosure by executing programs in ROM 602 and / or RAM 603. It should be noted that the programs may also be stored in one or more memories other than ROM 602 and RAM 603. Processor 601 may also perform various operations of the method flow according to embodiments of the present disclosure by executing programs stored in said one or more memories.

[0112] According to embodiments of this disclosure, the electronic device 600 may further include an I / O (Input / Output) interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0113] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs that, when executed, implement the method according to the embodiments of this disclosure.

[0114] According to embodiments of this disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this disclosure, the computer-readable storage medium may include ROM 602 and / or RAM 603 and / or one or more memories other than ROM 602 and RAM 603 described above.

[0115] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the middleware migration testing methods provided in embodiments of this disclosure.

[0116] When the computer program is executed by the processor 601, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0117] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0118] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from the removable medium 611. When the computer program is executed by the processor 601, it performs the functions defined in the system of this disclosure embodiment. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0119] According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can execute entirely on a user's computing device, partially on a user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0120] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0121] Those skilled in the art will understand that the features described in the various embodiments of this disclosure can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this disclosure. In particular, the features described in the various embodiments of this disclosure can be combined and / or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

[0122] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A method for middleware migration testing, characterized in that, The middleware includes a source middleware and a test middleware configured as a distributed system. The source middleware runs on the source server, and the test middleware runs on the test server. The method includes: receiving online transactions from multiple channels and storing the transaction data of the online transactions in a buffer pool; in response to the buffer pool receiving the transaction data, obtaining the status of a switchback flag deployed on the source middleware; if the status of the switchback flag indicates that transaction data allocation is allowed, obtaining an allocation strategy from a rule database, and allocating the transaction data in the buffer pool to the source server and the test server according to the allocation strategy; the rule database stores multiple allocation strategies; the multiple allocation strategies are combinations of multiple allocation rules with different priorities; analyzing the performance data of the source server and the test server in processing the transaction data, and using the analysis results as the test results of the middleware migration test.

2. The method according to claim 1, characterized in that, The multiple allocation rules include: application distribution rules, group distribution rules, and service distribution rules; wherein, the application distribution rules have a higher priority than the group distribution rules; and the group distribution rules have a higher priority than the service distribution rules.

3. The method according to claim 2, characterized in that, The multiple allocation strategies include a first allocation strategy, a second allocation strategy, and a third allocation strategy; the first allocation strategy is a strategy that includes application distribution rules; the second allocation strategy is a strategy that includes group distribution rules but does not include application distribution rules; and the third allocation strategy is a strategy that only includes service distribution rules.

4. The method according to claim 3, characterized in that, The step of allocating transaction data in the buffer pool to the origin server and the test server according to the allocation strategy includes: when the allocation strategy is the first allocation strategy, adding a tag to the server where the target application is located to the transaction data of the target application indicated in the online transaction application distribution rule; when the allocation strategy is the second allocation strategy, adding a tag to the server where the target group is located to the transaction data of the target group indicated in the online transaction group distribution rule; when the allocation strategy is the third allocation strategy, adding a tag to the server where the target service is located to the transaction data of the target service indicated in the online transaction service distribution rule; and uploading the tagged transaction data to the server indicated by the tag.

5. The method according to claim 1, characterized in that, The method further includes: when the status of the back-cut identifier indicates that transaction data allocation is prohibited, uploading the transaction data in the buffer pool to the original server.

6. The method according to claim 1, characterized in that, The method further includes: controlling the processing of transaction data received by the original middleware from the original server and the processing of transaction data received by the test middleware from the test server to be performed simultaneously.

7. The method according to claim 4, characterized in that, The method further includes adjusting the allocation strategy based on the analysis results.

8. The method according to claim 1, characterized in that, The performance data includes at least one of the following: online transaction response time, transaction throughput, server availability, transaction latency, number of concurrent transaction connections, and database query speed.

9. An apparatus for middleware migration testing, characterized in that, The middleware includes a source middleware and a test middleware configured as a distributed system. The source middleware runs on the source server, and the test middleware runs on the test server. The device includes: a data receiving module for receiving online transactions from multiple channels and storing the transaction data of the online transactions in a buffer pool; a status acquisition module for acquiring the status of a switchback flag deployed on the source middleware in response to the buffer pool receiving the transaction data; a data allocation module for acquiring an allocation strategy from a rule database when the status of the switchback flag indicates that transaction data allocation is allowed, and allocating the transaction data in the buffer pool to the source server and the test server according to the allocation strategy; the rule database stores multiple allocation strategies; the multiple allocation strategies are combinations of multiple allocation rules with different priorities; and a performance analysis module for analyzing the performance data of the source server and the test server in processing the transaction data, and using the analysis results as the test results of the middleware migration test.

10. An electronic device, comprising: One or more processors; A memory for storing one or more computer programs, characterized in that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

Images