Seamless interface switching method and system based on Calling technology

Abstract

The invention provides an interface seamless switching method and system based on the Callable technology, electronic equipment and a storage medium, and aims to solve the problem of security risk existing in interface switching The method comprises the following steps: carrying out Apoll configuration to obtain preset strategy group configuration information; when the application end interface is called, whether an old interface or a new interface is adopted is determined according to preset strategy group configuration information; if the interface is an old interface, a request for the old interface is initiated, a response message is obtained, if the interface is a new interface, calling of a callable method is triggered, and the response message returned by the new interface is converted into a data format conforming to the old interface; and sending the obtained response message to the MQ, so that an MQ consumer selects another interface opposite to the interface of the original request to initiate a request according to message information, obtains message contents, compares the two message contents, and judges whether the data has a difference or not. According to the invention, the safety and stability of interface switching can be ensured.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to a method for seamless interface switching based on Callable technology, a system for seamless interface switching based on Callable technology, an electronic device, and a computer-readable storage medium. Background Art

[0002] Seamless interface switching is a critical requirement during software development. As system functionality continues to expand and upgrade, the original interface implementation may no longer meet new needs or performance requirements. In these cases, a smooth transition to a new interface implementation is required without impacting system performance and user experience.

[0003] Currently, the industry relies on two main strategies to implement interface switching: physical connection conversion and software-level protocol adaptation. First, the physical connection conversion strategy focuses on the independent docking and deployment of new interfaces at the physical level. This strategy flexibly implements switching between interfaces through the routing conversion mechanism of the underlying network protocol, ensuring seamless data migration and processing continuity. On the other hand, software-level protocol adaptation takes a more integrated approach, allowing new and old interfaces to coexist on the same device or project. Under this strategy, adaptation and routing control between interfaces are directly implemented through software coding. This approach not only improves system flexibility but also simplifies maintenance and upgrade processes.

[0004] In order to more intuitively demonstrate the operating mechanism of these two strategies, the following diagrams are drawn: Figure 1 The flowchart shown describes in detail the entire process from interface docking and deployment to protocol adaptation and routing conversion. Figure 1 When the application triggers an interface call, its decision-making mechanism relies on software configuration or the underlying network routing policy to determine whether to access the existing old interface (Platform A) or directly enable the new interface (Interface B). However, this policy design contains several significant drawbacks, which are explained below:

[0005] First, the new interface (Interface B) was deployed directly into the production environment without undergoing a thorough phased testing, undoubtedly creating significant security risks for the system. The lack of phased testing means the new interface could harbor unknown vulnerabilities or instability factors, directly threatening the stable operation of the system. Second, potential data structure inconsistencies between the old and new interfaces pose a potential threat to business logic. These discrepancies could lead to data parsing errors, disrupting business logic and even security incidents, negatively impacting user experience and business continuity. Furthermore, this strategy relies on complex underlying physical connection conversion logic, which not only increases the complexity of the system architecture but also impairs maintainability and scalability. In the long term, this design will increase the difficulty of system maintenance and upgrades, hindering the continuous optimization and development of the system. Finally, the lack of an effective interface fallback mechanism is another significant issue. Since the new interface has not yet been tested in a production environment, its stability and reliability remain to be verified. If the new interface becomes unstable or even completely unavailable, and the system cannot quickly and seamlessly switch back to the old interface to ensure business continuity, it will cause business interruption and significant losses to the enterprise.

[0006] In summary, the current strategy brings security risks and maintenance challenges that cannot be ignored. Therefore, it is necessary to review and optimize the interface call strategy to ensure the safe, stable and efficient operation of the system. Summary of the Invention

[0007] In order to at least solve the security risks and maintenance challenges of existing interface switching, the present invention provides a method for seamless interface switching based on Callable technology, a system for seamless interface switching based on Callable technology, an electronic device, and a computer-readable storage medium. By adopting a dual-track parallel strategy for the old and new interfaces and introducing a method for real-time comparison and statistics of return messages, it is ensured that during the interface switching process, a seamless transition can be achieved while ensuring the safety and stability of the operation, thereby improving the reliability, stability, and overall performance of the system, and providing users with a smoother and more efficient user experience.

[0008] In a first aspect, the present disclosure provides a method for seamless interface switching based on Callable technology, the method comprising:

[0009] Perform Apollo configuration to configure different effective policy information for different interface codes, generate Java encapsulation class objects based on the configuration, and obtain the preset policy group configuration information;

[0010] When the application initiates an interface call, it determines whether to use the old interface or the new interface data to respond to the caller based on the preset policy group configuration information;

[0011] If the old interface is used, a request to the old interface is directly initiated to obtain a response message. If the new interface is used, a callable method is triggered to execute the calling logic of the new interface and convert the response message returned by the new interface into a data object format that conforms to the old interface.

[0012] The obtained response message is sent to MQ (Message Queue), so that the MQ consumer can determine whether the original request of the message is for the old interface or the new interface based on the message information, and select another interface corresponding to the interface of the original request to initiate a request, obtain the message content returned by the interface, and compare the message contents obtained from the two interfaces to determine whether there is any difference in the data.

[0013] Furthermore, the Apollo configuration includes:

[0014] Interface name and brief description of policy logic;

[0015] Policy effective time;

[0016] Interface coding;

[0017] The source of application request interface data in the production environment is the old interface or the new interface;

[0018] Whether to compare the contents of the messages returned by the new and old interfaces;

[0019] Policy expiration time.

[0020] Furthermore, when the application initiates an interface call, determining whether to use data from the old interface or the new interface to respond to the caller according to the preset policy group configuration information includes:

[0021] When the application initiates an interface call, the method code being called is captured and recorded, the method code is verified, and the method code is checked to see if it exists in the preset policy group configuration information;

[0022] If it exists, the selected policy group information is obtained according to the effective policy information corresponding to the interface to obtain the final effective routing policy;

[0023] The routing policy determines whether to use the old interface or the new interface data to respond to the caller.

[0024] Furthermore, the method further comprises:

[0025] Before determining whether to use the old interface or the new interface data to respond to the caller according to the preset policy group configuration information, determine whether the current operating environment is the production environment;

[0026] If so, executing the step of determining whether to use data from the old interface or the new interface to respond to the calling end according to the preset policy group configuration information;

[0027] If not, it will automatically redirect and directly call the old interface, and then return the result to the caller.

[0028] Furthermore, the method further comprises:

[0029] If the check method code does not exist in the preset policy group configuration information, a redirection mechanism will be automatically triggered to divert the call process to the execution path of the old interface, directly call the old interface, and make the old interface process the corresponding business logic and return the processing results to the calling end.

[0030] Furthermore, the step of obtaining the selected policy group information according to the effective policy information corresponding to the interface to obtain the final effective routing policy includes:

[0031] Evaluate the start and end time of each policy in the policy group configuration information corresponding to the method encoding, and determine whether the current time falls exactly within the start and end time range specified by a policy configuration;

[0032] If so, the policy is considered a candidate. If there is only one candidate, it is selected as the final routing policy. If there are multiple candidates, the policy with the highest ranking among them is selected as the final routing policy according to the priority principle.

[0033] If not, a preset redirection mechanism is activated to ensure that the calling process can be redirected to the execution path of the old interface.

[0034] Furthermore, the method further comprises:

[0035] After obtaining the final effective routing policy, check whether the current routing policy is applied for the first time that day;

[0036] If so, a policy implementation notification process is automatically triggered to notify relevant personnel of the policy changes in a timely manner.

[0037] Furthermore, the method further comprises:

[0038] Before formally executing the routing policy, perform request anti-duplicate filtering to identify and eliminate all duplicate requests.

[0039] Furthermore, comparing the contents of the messages obtained from the two interfaces to determine whether there is a difference in the data includes:

[0040] Select and call the corresponding message comparison module through the predefined interface code,

[0041] The message comparison module compares the message contents obtained from the new interface and the old interface respectively.

[0042] If the comparison confirms that the two data are completely consistent, the message comparison process is terminated;

[0043] If there is a discrepancy between the two data, the code is extracted from the data object returned by the old and new interface messages, and statistical analysis is performed on it to summarize the number of exception types that appear in the old and new messages corresponding to each interface code, as well as the specific information of these current exceptions;

[0044] Based on the statistical analysis results, determine whether the new interface is ready to smoothly replace the old interface.

[0045] In a second aspect, the present disclosure provides a system for seamless interface switching based on Callable technology, the system comprising:

[0046] The configuration module is set to perform Apollo configuration to configure different effective policy information for different interface codes, generate Java encapsulation class objects according to the configuration, and obtain the preset policy group configuration information;

[0047] A determination module is configured to determine whether to use the old interface or the new interface data to respond to the calling end according to the preset policy group configuration information when the application end initiates an interface call;

[0048] The request module is configured to directly initiate a request to the old interface to obtain a response message if the old interface is used; if the new interface is used, it triggers a callable method call, executes the call logic of the new interface, and converts the response message returned by the new interface into a data object format that conforms to the old interface;

[0049] The comparison module is configured to send the obtained response message to the message queue MQ, so that the MQ consumer can determine whether the original request of the message is for the old interface or the new interface based on the message information, and select another interface corresponding to the interface of the original request to initiate a request, obtain the message content returned by the interface, and compare the message contents obtained from the two interfaces to determine whether there is any difference in the data.

[0050] In a third aspect, the present disclosure provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program. When the processor runs the computer program stored in the memory, the processor executes the interface seamless switching method based on Callable technology as described in any one of the first aspects.

[0051] In a fourth aspect, the present disclosure provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the method for seamless interface switching based on Callable technology described in any one of the first aspects above is implemented.

[0052] Beneficial effects:

[0053] The present disclosure provides a method for seamless interface switching based on Callable technology, a system for seamless interface switching based on Callable technology, an electronic device, and a storage medium. The method adopts a strategy of running new and old interfaces in parallel. Over a period of time, the new and old interfaces simultaneously serve the system, and a real-time monitoring system rigorously compares the data returned by the two interfaces. This determines whether the new interface is fully capable of replacing the old interface, thereby ensuring a seamless transition and ensuring operational security and stability during the interface switching process. This allows for a safe and secure complete replacement of the interface, improving the reliability, stability, and overall performance of the system, and providing users with a smoother and more efficient user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 This is a schematic diagram of the interface switching process in the prior art;

[0055] Figure 2 A flowchart of a method for seamless interface switching based on Callable technology provided in the first embodiment of the present disclosure;

[0056] Figure 3 A schematic diagram of the overall process of seamless interface switching based on Callable technology provided in an embodiment of the present disclosure;

[0057] Figure 4 A schematic diagram of an Apollo configuration information Java encapsulation class object provided in an embodiment of the present disclosure;

[0058] Figure 5 A schematic diagram of a message comparison logic flow provided by an embodiment of the present disclosure;

[0059] Figure 6 A schematic diagram of a policy decision group logic flow provided by an embodiment of the present disclosure;

[0060] Figure 7 A screenshot of a new interface method code provided in Example 3 of the present disclosure;

[0061] Figure 8 A screenshot of an old interface method code provided in Example 3 of the present disclosure;

[0062] Figure 9 A screenshot of the code for adapting the old and new interface return objects provided in the third embodiment of the present disclosure;

[0063] Figure 10 A screenshot of a policy group routing logic code provided in Example 3 of the present disclosure;

[0064] Figure 11 A screenshot of the rewritten code of an old interface method provided in the third embodiment of the present disclosure;

[0065] Figure 12 A policy group routing policy diagram provided in the third embodiment of the present disclosure;

[0066] Figure 13 A schematic diagram of a policy group routing information encapsulation class provided in the third embodiment of the present disclosure;

[0067] Figure 14 A screenshot of a project startup command provided in Example 3 of the present disclosure;

[0068] Figure 15 A screenshot of an old interface request command and response provided in Example 3 of the present disclosure;

[0069] Figure 16 This is a screenshot of a policy taking effect provided in Example 3 of the present disclosure;

[0070] Figure 17 A screenshot of a message abnormality alarm provided in the third embodiment of the present disclosure;

[0071] Figure 18 This is an architectural diagram of a seamless interface switching system based on Callable technology provided in the fourth embodiment of the present disclosure;

[0072] Figure 19 This is an architectural diagram of an electronic device provided in Example 5 of the present disclosure. DETAILED DESCRIPTION

[0073] To enable those skilled in the art to better understand the technical solutions of the present disclosure, the present disclosure is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments and drawings described herein are only used to explain the present disclosure, rather than to limit the present disclosure.

[0074] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence; and, in the absence of conflict, the embodiments and features in the embodiments of the present disclosure can be arbitrarily combined with each other.

[0075] The terms used in the embodiments of the present disclosure are for the purpose of describing specific embodiments only and are not intended to limit the present disclosure. The singular forms "a," "an," "the," and "the" used in the embodiments of the present disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0076] In the subsequent description, suffixes such as "module," "component," or "unit" used to represent elements are used only to facilitate the description of the present disclosure and have no specific meaning. Therefore, "module," "component," or "unit" may be used interchangeably.

[0077] The following is a detailed description of the technical solutions of the present invention and how the technical solutions of the present invention solve the technical problems in the prior art with specific embodiments. It will be appreciated that, in the embodiments of the present application, the execution subject may perform some or all of the steps in the embodiments of the present application, and these steps or operations are merely examples. The embodiments of the present application may also perform other operations or variations of various operations. In addition, the various steps may be performed in different orders as presented in the embodiments of the present application, and it may not be necessary to perform all the operations in the embodiments of the present application. Furthermore, the following specific embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in certain embodiments.

[0078] Figure 2 A flowchart of a method for seamless interface switching based on Callable technology provided in the first embodiment of the present disclosure is shown as follows: Figure 2 As shown, the method includes:

[0079] Step S101: Perform Apollo configuration to configure different effective policy information for different interface codes, generate Java encapsulation class objects according to the configuration, and obtain preset policy group configuration information;

[0080] Step S102: When the application initiates an interface call, it determines whether to use the old interface or the new interface data to respond to the caller according to the preset policy group configuration information;

[0081] Step S103: If the old interface is used, a request to the old interface is directly initiated to obtain a response message. If the new interface is used, a callable method is triggered to execute the call logic of the new interface and convert the response message returned by the new interface into a data object format that conforms to the old interface.

[0082] Step S104: Send the obtained response message to the message queue MQ, so that the MQ consumer can determine whether the original request of the message is for the old interface or the new interface based on the message information, and select another interface corresponding to the interface of the original request to initiate a request, obtain the message content returned by the interface, and compare the message contents obtained from the two interfaces to determine whether there are any differences in the data.

[0083] In real-world business applications, given that the legacy platform hosts critical business logic development, ensuring full compatibility with the legacy platform's existing business logic becomes a crucial task when migrating to a new platform. This process isn't a simple "one-size-fits-all" switch. Even with thorough pre-migration testing, it's impossible to fully anticipate the myriad scenarios that might arise in a production environment, leading to limited test coverage.

[0084] In order to ensure a smooth transition and data consistency, the embodiment of the present disclosure adopts a strategy of running two interfaces in parallel. That is, over a period of time, the new and old interfaces will serve the system at the same time, and the data returned by the two will be strictly compared through a real-time monitoring system. Only when the data returned by the two interfaces are completely consistent during the continuous parallel process and no abnormalities occur, can the new interface be considered to have fully met the conditions to replace the old interface (or called the old interface), and then the comprehensive replacement of the interface can be completed safely and securely. This strategy effectively reduces the business risks that may be caused by improper switching, and ensures the continuity of system operation and the accuracy of data.

[0085] Specifically, the disclosed embodiments utilize dynamic Callable technology and Apollo configuration to achieve seamless interface switching. Callable technology offers dynamic features, enabling the selection of interface implementations based on configuration at runtime; seamless features, maintaining data continuity and consistency during switching; and scalability, enabling the rapid addition of new interfaces, which are enabled through configuration. Apollo configuration allows for the configuration of dynamic rules and determines the interface validation rules based on the configured policies, determining the actual interface to be called.

[0086] The overall process is as follows Figure 3 As shown, a software routing strategy is adopted, where the implementation and dotted lines represent two decision logics respectively:

[0087] Logic 1 (solid line part):

[0088] When the application triggers the decision-making process, the decision-making group immediately initiates a request to the old interface (Platform A) based on the Apollo configuration policy. After receiving the response message from the old interface, it is first pushed to the MQ (message queue) as a sample for comparison between the old and new interfaces. The decision-making group then returns the old interface's response message directly to the requesting application, ensuring that the application can continue its business process without interruption.

[0089] At the same time, the MQ consumer (processing module) listens for and receives the message comparison task, proactively initiating a request to the new interface (Platform B) to obtain the corresponding response message. The consumer then conducts a detailed comparison of the response messages from the new interface with those from the old interface. If any inconsistencies are found, the system automatically categorizes and counts these inconsistencies, including their occurrences, to provide an in-depth analysis of the differences between the new and old interfaces.

[0090] Ultimately, the system accurately notifies relevant technicians of all identified message inconsistencies, including their types and frequency, through an alert robot. This mechanism not only provides intuitive problem feedback but also greatly facilitates their assessment of whether the new interface can fully replace the old one, laying a solid foundation for subsequent interface migration or optimization.

[0091] It is worth noting that under the current strategy, the interface messages actually used by the application side still come from the old interface, ensuring business continuity and stability. The new platform (Platform B) is running in parallel, and its main function is to provide data support for message comparison between the old and new interfaces, rather than directly participating in business processing in the production environment. This design not only ensures a safe transition of business, but also promotes the process of technology iteration and optimization.

[0092] Logic 2 (dashed line part):

[0093] Compared with the situation in logic one, this scenario presents a completely opposite pattern: the new interface (Platform B) now takes on the responsibility of directly serving the production process, while at the same time, the old interface (Platform A) that originally ran in parallel has transformed into a key message comparison reference role, ensuring the smooth transition of the system and data accuracy.

[0094] By employing a message comparison mechanism based on Logic 2, technicians can quickly and accurately analyze the alerts issued by the alarm robot. Once the analysis is complete, the technician proactively stops requests to the old interface and terminates the message comparison process between the old and new interfaces, marking the successful completion of the interface switchover. Furthermore, all operations performed by technicians after analysis can be easily implemented by modifying Apollo configuration policy information, greatly improving operational efficiency and convenience.

[0095] To implement the above logic, the embodiment of the present disclosure first performs Apollo configuration. The configuration item information of Apollo configuration is an array object, which can configure different effective policy information for different interface codes.

[0096] After the configuration information is configured and published in the Apollo management backend, the system's automated process seamlessly parses and maps the Apollo configuration information into the defined Java object instance; that is, Java encapsulated class objects are generated according to the configuration. Once the system is successfully started, whenever the application initiates an interface call, the system will uniformly execute the actual interface call judgment.

[0097] Determine whether to use the old or new interface data to respond to the caller based on the preset policy group configuration information set during Apollo configuration;

[0098] If you choose to pass the data returned by the old interface as the response to the caller, the system will directly initiate a request to the old interface;

[0099] If the data returned by the new interface is chosen as the response to be passed to the caller, a callable method will be called. This method encapsulates the calling logic for the new interface and is responsible for converting the response message returned by the new interface into a data object format that conforms to the old interface.

[0100] When message comparison is required, the response message (object information) obtained through the new interface or the old interface is sent to the MQ (message queue) for asynchronous content comparison processing. The MQ consumer determines whether the original request of the message is for the old interface or the new interface based on the message information, and selects another interface corresponding to the interface of the original request to initiate the request. If the message comes from the old interface, the new interface should be called. If the message comes from the new interface, the old interface should be called to obtain the message content returned by the interface. The message content obtained from the two interfaces is compared to determine whether there is any difference in the data.

[0101] A variance analysis is then performed to determine whether the new interface is ready to replace the old one. Once the system determines that the new interface is ready to smoothly replace the old one, it replaces the old one with the new one, ensuring a smooth, orderly, and secure transition between the old and new interfaces.

[0102] In response to the problem that the existing interface switching lacks an effective interface fallback mechanism, the disclosed embodiment has built a complete interface fallback mechanism through the deep integration of dynamic Callable technology and Apollo configuration strategy. It has the following features: Zero downtime switching: By comparing the results, you can switch back to the old interface at any time without downtime or version rollback. Data security protection: Even if the new interface is abnormal, the business still relies on the data response of the old interface to avoid interruption. Parameter changes are pushed in real time through the Apollo configuration center, and the interface can be switched without restarting the service. For example, when an abnormality occurs in the new interface, by setting the corresponding Apollo configuration parameters (such as oldEffect is set to true below), all requests are immediately switched back to the old interface. Business continuity is guaranteed.

[0103] The disclosed embodiment adopts a strategy of running the old and new interfaces in parallel. For a period of time, the new and old interfaces simultaneously serve the system, and the real-time monitoring system rigorously compares the data returned by the two interfaces. This determines whether the new interface is fully qualified to replace the old interface. This ensures a seamless transition during the interface switching process while guaranteeing operational security and stability. This complete replacement of the interface is completed safely and securely, improving the reliability, stability, and overall performance of the system, and providing users with a smoother and more efficient user experience.

[0104] Furthermore, the Apollo configuration includes:

[0105] Interface name and brief description of policy logic;

[0106] Policy effective time;

[0107] Interface coding;

[0108] The source of application request interface data in the production environment is the old interface or the new interface;

[0109] Whether to compare the contents of the messages returned by the new and old interfaces;

[0110] Policy expiration time.

[0111] Apollo Configuration provides instructions for using and configuring the Apollo Config Center. Apollo is Ctrip's open-source distributed configuration center for centralized application configuration management. Apollo facilitates application configuration management, supports multi-environment and multi-cluster configuration isolation, and supports phased releases.

[0112] The abstract encapsulation of Apollo configuration items in this example includes:

[0113] First, take the following Apollo configuration as an example:

[0114]

[0115] This configuration item is an array object. You can configure different effective policy information for different interface codes. The fields and explanations of each policy are as follows:

[0116] buName: Used to clearly identify the interface name and policy logic outline involved in an alarm. This naming convention can quickly locate the problem, specifically the specific interface and its applied policy, greatly improving troubleshooting efficiency.

[0117] startTime: Specifies the starting date and time when the policy takes effect. The format is YYYY-MM-DD, such as 2024-06-07. This ensures that the policy starts executing at the scheduled time.

[0118] interfaceName: A unique code for an interface, used to distinguish and identify different interfaces for easier system management and maintenance.

[0119] oldEffect: Indicates the source of application request data in the production environment. If the data originates from the old interface, this field is true; if it originates from the new interface, it is false. This setting helps track data flow and ensure data consistency and accuracy.

[0120] pkgCmp: Controls whether to compare the contents of packets returned by the new and old interfaces. To verify consistency between the new and old interface data, set this field to true to enable the comparison mechanism; to disable the comparison, set it to false.

[0121] endTime: Specifies the date and time when the policy expires, in the format of YYYY-MM-DD, for example, 2024-06-11. This field ensures that the policy is valid for a specific period of time and automatically stops executing after the expiration date, allowing for flexible adjustment of the policy application period.

[0122] Second: According to the first step, configure the production java encapsulation class object such as Figure 4 The docking field information and meaning are as described above.

[0123] Third: After configuring and publishing the configuration information in the first step in the Apollo management backend, start the Java application. The system will automatically convert the Apollo configuration information into the Java object constructed in the second step above.

[0124] Furthermore, after receiving a response message through the new or old interface, the routing policy group determines whether to compare the contents of the response data objects from the new and old interfaces based on the value of pkgCmp. Specifically, when pkgCmp is true, the response objects from the new and old interfaces need to be compared; when pkgCmp is false, the comparison does not need to be performed.

[0125] If the routing policy group sets the pkgCmp parameter to true, the system will compare the old and new interface response objects. In this scenario, the system will send the object information obtained in the previous step to the MQ (message queue) for asynchronous content comparison.

[0126] If the routing policy sets the pkgCmp parameter to false, this means the system doesn't need to compare the old and new interface response objects. In this case, the decision group simply uses the object captured in the previous step and returns it to the application, completing the entire process.

[0127] Furthermore, when the application initiates an interface call, determining whether to use data from the old interface or the new interface to respond to the caller according to the preset policy group configuration information includes:

[0128] When the application initiates an interface call, the method code being called is captured and recorded, the method code is verified, and the method code is checked to see if it exists in the preset policy group configuration information;

[0129] If it exists, the selected policy group information is obtained according to the effective policy information corresponding to the interface to obtain the final effective routing policy;

[0130] The routing policy determines whether to use the old interface or the new interface data to respond to the caller.

[0131] When the application initiates an interface call, the called method code is captured and recorded. Next, the system will verify the code to check whether it exists in the preset policy group configuration information. If it exists, the policy effectiveness conditions are determined based on the effective policy information corresponding to the interface (such as whether it is within the set effective time). If it is satisfied, the selected policy group information is obtained to obtain the final effective routing policy; based on the routing policy, it is decided whether to use the data of the old interface or the new interface to respond to the calling end; for example, the routing policy group will determine the source of the interface response data based on the value of oldEffect in the Apollo configuration, that is, determine whether to use the data of the old interface or the new interface to respond to the calling end. Specifically, when oldEffect is true, the data returned by the old interface will be sent to the calling end as a response; if oldEffect is false, the data returned by the new interface will be selected as the response content.

[0132] Furthermore, the method further comprises:

[0133] Before determining whether to use the old interface or the new interface data to respond to the caller according to the preset policy group configuration information, determine whether the current operating environment is the production environment;

[0134] If so, executing the step of determining whether to use data from the old interface or the new interface to respond to the calling end according to the preset policy group configuration information;

[0135] If not, it will automatically redirect and directly call the old interface, and then return the result to the caller.

[0136] After the system is successfully started, whenever the application initiates an interface call, the system will uniformly execute the environment judgment logic to clarify whether the current operating environment is a production environment or a non-production environment, thereby ensuring high consistency and security between application behavior and environmental requirements.

[0137] If the current operating environment is not a production environment, the system will automatically redirect and directly call the old API, and then return the result to the caller. It is worth noting that the policy group logic is designed to work only in a production environment. In non-production environments (such as development and test environments), this logic will not be activated and executed.

[0138] When the current running environment is identified as the production environment, the system will perform the following process: First, capture and record the called method code.

[0139] Furthermore, the method further comprises:

[0140] If the check method code does not exist in the preset policy group configuration information, a redirection mechanism will be automatically triggered to divert the call process to the execution path of the old interface, directly call the old interface, and make the old interface process the corresponding business logic and return the processing results to the calling end.

[0141] If the verification result indicates that the method code is not included in the policy group configuration, a redirection mechanism is automatically triggered, seamlessly redirecting the call flow to the legacy interface execution path. The legacy interface is then directly called and the corresponding business logic is processed. Ultimately, the processing results are efficiently returned to the original caller, ensuring continuity and stability throughout the entire process.

[0142] Furthermore, the step of obtaining the selected policy group information according to the effective policy information corresponding to the interface to obtain the final effective routing policy includes:

[0143] Evaluate the start and end time of each policy in the policy group configuration information corresponding to the method encoding, and determine whether the current time falls exactly within the start and end time range specified by a policy configuration;

[0144] If so, the policy is considered a candidate. If there is only one candidate, it is selected as the final routing policy. If there are multiple candidates, the policy with the highest ranking among them is selected as the final routing policy according to the priority principle.

[0145] If not, a preset redirection mechanism is activated to ensure that the calling process can be redirected to the execution path of the old interface.

[0146] If the method code validation is present in the pre-configured policy group configuration, the system further evaluates the start and end times of each policy. A policy is considered a candidate only if the current time falls within the specified start and end time range. In this scenario, if multiple policies are valid for the same interface code, the system prioritizes the candidate policy (usually the first one in the list) and selects it as the final routing policy.

[0147] Before executing a policy, the system first checks whether the explicitly selected policy group already exists. If this check confirms that the information does not exist, the system automatically activates a pre-defined redirection mechanism to ensure that the call flow can be seamlessly and smoothly transferred to the old interface execution path. This redirection then directly triggers the call to the old interface, allowing the system to continue processing the corresponding business logic, thus maintaining the continuity and stability of business operations.

[0148] Another significant issue in existing interface switching strategies is the lack of an effective interface fallback mechanism. Since the new interface has not yet been tested in a production environment, its stability and reliability remain to be verified. If the new interface becomes unstable or even completely unavailable, and the system cannot quickly and seamlessly switch back to the old interface to ensure business continuity, this will lead to business interruption and significant losses to the enterprise.

[0149] This disclosed embodiment takes effect in real time through Apollo configuration, and dynamically schedules Callable tasks to address the lack of an effective fallback mechanism in traditional interface switching. It also allows requests to be redirected to the old interface through a pre-defined redirection mechanism, ensuring that the call process seamlessly and smoothly transitions to the execution path of the old interface. This redirection will then directly trigger the call to the old interface, allowing the system to continue processing the corresponding business logic, thereby maintaining the continuity and stability of business operations.

[0150] Furthermore, the method further comprises:

[0151] After obtaining the final effective routing policy, check whether the current routing policy is applied for the first time that day;

[0152] If so, a policy implementation notification process is automatically triggered to notify relevant personnel of the policy changes in a timely manner.

[0153] If the selected policy group information exists, the system will then check whether the currently active policy is being applied for the first time today. If so, the system will automatically trigger a policy change notification process. This notification will be sent directly to designated personnel via instant text message, ensuring they are informed of the policy change in a timely manner.

[0154] Furthermore, the method further comprises:

[0155] Before formally executing the routing policy, perform request anti-duplicate filtering to identify and eliminate all duplicate requests.

[0156] Before the policy group formally executes the routing policy, the system performs a critical pre-processing step on the obtained policy configuration information: request anti-duplicate filtering. This step aims to accurately identify and eliminate all duplicate requests, ensuring efficient routing policy execution without interference from redundant data, thereby improving overall processing performance and accuracy.

[0157] Furthermore, comparing the contents of the messages obtained from the two interfaces to determine whether there is a difference in the data includes:

[0158] Select and call the corresponding message comparison module through the predefined interface code,

[0159] The message comparison module compares the message contents obtained from the new interface and the old interface respectively.

[0160] If the comparison confirms that the two data are completely consistent, the message comparison process is terminated;

[0161] If there is a discrepancy between the two data, the code is extracted from the data object returned by the old and new interface messages, and statistical analysis is performed on it to summarize the number of exception types that appear in the old and new messages corresponding to each interface code, as well as the specific information of these current exceptions;

[0162] Based on the statistical analysis results, determine whether the new interface is ready to smoothly replace the old interface.

[0163] The message comparison logic process is as follows Figure 5 As shown, including:

[0164] First: When MQ consumers receive a message comparison request, they will intelligently select and call the corresponding message comparison module based on the predefined interface code.

[0165] Second, the MQ consumer first analyzes the received message to determine whether the original request is for the old or new interface. Next, it compares the message content to determine whether the current operation should call the new or old interface. If the message comes from the old interface, the new interface should be called; if the message comes from the new interface, the old interface should be called. Based on this determination, the MQ consumer initiates a request to the corresponding interface and then retrieves the data object returned by that interface. This process ensures the correct direction of the request and accurate data acquisition.

[0166] Third: After receiving the previous request message from MQ, the system carefully compares it with the current request message obtained in step 2. If the comparison confirms that the two data are completely consistent, the system immediately terminates the message comparison process and no further operations are performed. Conversely, if there are any discrepancies between the two data, the process automatically proceeds to the next step. This process is designed to efficiently and accurately determine message consistency, thereby optimizing the processing flow.

[0167] Fourth: If the message comparison results show discrepancies between the two data types, the system will remove the code portion of the returned data object from both the old and new messages. This step is intended to reduce data redundancy and ensure that the data can be processed or displayed more concisely.

[0168] Fifth: In step 4, the system extracts the code from the data objects returned by both new and old interface messages and performs a detailed statistical analysis. This process aims to summarize the number of exception types that appear in both new and old messages corresponding to each interface code, as well as the specific number of occurrences of these exceptions. This statistical data allows the system to be fully prepared for subsequent exception reporting and troubleshooting, enabling more efficient management and response to potential issues.

[0169] Sixth: Using text messaging, the system promptly broadcasts the statistical analysis information from step five to relevant personnel. Once a notification containing anomaly information is received, relevant personnel immediately initiate a detailed investigation and audit process to assess whether the issue indicated by the current anomaly report truly requires interface optimization or can be considered a non-critical anomaly and ignored. This ongoing process, based on repeated audits and long-term production data verification, ensures a comprehensive understanding of interface performance. Ultimately, based on these in-depth evaluations and verifications, the system will be able to make an informed decision on whether the new interface is ready to smoothly replace the old one, thereby ensuring a smooth, orderly, and secure transition between the old and new interfaces.

[0170] The disclosed embodiment implements dynamic interface calling and switching based on dynamic Callable technology, implements a dual-track parallel strategy for new and old interfaces, and introduces a method for real-time comparison and statistics of returned messages. This ensures a seamless transition during interface switching while guaranteeing operational security and stability. It also allows programs to dynamically select and call different interface implementations based on specific conditions or requirements at runtime, thereby achieving flexible configuration and expansion of functions. It has the following features:

[0171] Dynamicity: Allows interface calls to be dynamically determined at runtime rather than fixed at compile time; this means that the system can flexibly adjust the interface implementation based on actual conditions to adapt to different business scenarios and needs.

[0172] Seamlessness: The interface seamless switching method of the embodiment of the present disclosure ensures that the system's operating status and data flow can maintain continuity and consistency when switching interfaces, thereby achieving seamless switching through carefully designed architecture and algorithms.

[0173] Scalability: This technology provides a good extension mechanism, allowing developers to easily add new interface implementations and switch interfaces through simple configuration; this greatly reduces the difficulty and cost of system upgrades and maintenance.

[0174] High availability: Seamless interface switching achieved through dynamic callable technology ensures that the system can still run stably under extreme conditions such as high concurrency and high load, thereby improving the availability and reliability of the system.

[0175] In order to more clearly describe the technical solution of the present disclosure, the second embodiment of the present disclosure also provides an interface seamless switching method based on Callable technology; the policy group is obtained by abstracting and encapsulating the content of the Apollo configuration item, and the policy decision group logic flow chart is as follows: Figure 6 As shown, including:

[0176] First: Before the system is initialized, Apollo must follow the instructions in the first step above to accurately configure the policy group policy information and successfully start the project. Subsequently, the system automation process will seamlessly parse and map the Apollo configuration information into the Java object instance defined in the second step (such as Figure 4 Once the system is successfully started, each time the application initiates an interface call, the system will uniformly execute the environment judgment logic to clarify whether the current operating environment is a production environment or a non-production environment, thereby ensuring a high degree of consistency and security between application behavior and environmental requirements.

[0177] Second: If the current operating environment is not a production environment, the system will automatically redirect and directly call the old API, and then return the result to the caller. It is worth noting that the policy group logic is designed to work only in production environments. In non-production environments (such as development and test environments), this logic will not be activated and executed.

[0178] Third: When the current operating environment is identified as a production environment, the system will execute the following process: First, the called method code is captured and recorded. Next, the system verifies the code to see if it exists within the preset policy group configuration information. If the verification result shows that the method code is not included in the policy group configuration information, a redirection mechanism is automatically triggered, seamlessly redirecting the call process to the execution path of the legacy interface. The legacy interface is then directly called and the corresponding business logic is processed. Finally, the processing results are efficiently returned to the original caller, ensuring the continuity and stability of the entire process.

[0179] Fourth: If the method code verification is present in the pre-set policy group configuration, the system further evaluates the start and end times of each policy. A policy is considered a candidate only if the current time falls within the specified start and end time range. In this scenario, if multiple policies are valid for the same interface code, the system prioritizes them, selecting the policy with the highest ranking (usually the first one in the list) as the final routing policy.

[0180] Fifth: The system first checks whether the policy group information explicitly selected in step 4 already exists. If this check confirms that it does not, the system automatically activates a pre-defined redirection mechanism to ensure a seamless and smooth transition to the legacy interface execution path. This redirection then directly triggers a call to the legacy interface, allowing the system to continue processing the corresponding business logic, thus maintaining the continuity and stability of business operations.

[0181] Sixth: The system first checks whether the policy group selected in step 4 already exists. Once confirmed, it then checks whether the currently active policy is the first to be applied today. If so, the system automatically triggers a policy change notification process. This notification is sent directly to designated personnel via instant text message, ensuring they are promptly informed of the policy change.

[0182] Seventh: The system first checks whether the policy group information clearly selected in the fourth step already exists, and obtains the policy configuration information.

[0183] Before the policy group officially executes the routing policy, the system performs a critical pre-processing step: request anti-duplicate filtering. This step accurately identifies and eliminates all duplicate requests, ensuring efficient routing policy execution without interference from redundant data, thereby improving overall processing performance and accuracy.

[0184] Ninth: The routing policy group determines the source of the interface response data based on the value of oldEffect. Specifically, it determines whether to respond to the caller using data from the old or new interface. Specifically, when oldEffect is true, the data returned by the old interface is sent as the response to the caller; if oldEffect is false, the data returned by the new interface is selected as the response content.

[0185] 10. If you choose to pass the data returned by the old interface as a response to the caller, the system will directly initiate a request to the old interface, and then the process will seamlessly transition to step 12.

[0186] Eleventh: If the data returned by the new interface is chosen as the response to the caller, a callable method is invoked. This method encapsulates the logic for calling the new interface and then converts the response message returned by the new interface into a data object format that conforms to the old interface. Once this conversion is complete, the entire process seamlessly and smoothly transitions to the next step, Step 12.

[0187] 12. The routing policy group determines whether to compare the content of the new and old interface response data objects based on the value of pkgCmp. Specifically, when pkgCmp is true, the content of the new and old interface response objects must be compared; when pkgCmp is false, the content of the new and old message objects does not need to be compared.

[0188] Thirteenth: If the routing policy group sets the pkgCmp parameter to true, the system will compare the contents of the old and new interface response objects. In this scenario, the system will send the object information obtained in steps 12 or 13 to an MQ (message queue) for asynchronous content comparison. The specific logic and steps of this asynchronous comparison process are described in Example 1 above and will not be repeated here.

[0189] 14. If the routing policy sets the pkgCmp parameter to false, this means the system does not need to compare the old and new interface response objects. In this case, the decision group directly uses the object captured in the previous step (step 12 or 13) and returns it to the application, completing the entire process.

[0190] The interface switching management mechanism of the disclosed embodiment can dynamically create, schedule, and destroy Callable tasks, and during the execution of Callable tasks, implement seamless interface switching based on preset rules or conditions. These mechanisms will significantly improve the reliability, stability, and overall performance of the system, providing users with a smoother and more efficient user experience, including:

[0191] 1. Improve system flexibility

[0192] Rapidly respond to changing requirements: Business requirements and technical standards often change during software development and maintenance. This disclosure allows the system to dynamically select or switch interfaces based on business requirements during runtime, thereby rapidly responding to these changes and reducing the system reconstruction costs caused by interface changes.

[0193] Support for multiple versions in parallel: Through this mechanism, the system can simultaneously support multiple versions of the interface and seamlessly switch based on actual conditions. This helps maintain business continuity during the upgrade process and reduces the risk of service interruption due to upgrade failure.

[0194] 2. Enhance system stability

[0195] Fault isolation and recovery: When an interface fails, this disclosure can quickly redirect requests to other available interfaces, thereby achieving fault isolation and rapid recovery. This helps reduce the overall system failure rate and improve service reliability and stability.

[0196] Load balancing: This mechanism can also intelligently distribute requests to different interface instances based on the interface's performance indicators and load, achieving load balancing. This helps avoid performance bottlenecks and crash risks caused by overloading a single interface.

[0197] 3. Improve system availability

[0198] Seamless switching capability: This disclosure enables the system to seamlessly switch interfaces, meaning that users can continue to use services almost without noticing during interface upgrades, maintenance, or troubleshooting. This significantly improves system availability and user experience.

[0199] Reduced downtime: Seamless interface switching minimizes system downtime caused by interface changes or failures. This is particularly important for business scenarios that require high availability.

[0200] 4. Simplify system maintenance

[0201] Centralized management: This disclosure uses dynamic callable technology to centralize the management of multiple interfaces, allowing configuration, monitoring, and troubleshooting through a unified interface management platform. This helps reduce the complexity and cost of system maintenance.

[0202] Simplified upgrade process: This device can simplify the interface upgrade process, making the upgrade process smoother and more controllable. At the same time, through automated interface testing and verification mechanisms, it can ensure that the upgraded interface still meets business requirements and technical standards.

[0203] The third embodiment of the present disclosure further provides a method for seamless interface switching based on Callable technology, including:

[0204] First: Connect to the new platform interface and encapsulate the data returned by the new interface into the data object returned by the old interface;

[0205] For example, there is an interface called Real-Name Authentication, whose interface code is com.aop.method.realname4g. The data type returned by the old interface is KCardRealName4GRes, while the new interface, before data conversion, originally returns the data type RealnamecheckRsp. To ensure data compatibility with the new interface, we need to convert the RealnamecheckRsp data type returned by the new interface to KCardRealName4GRes; the new interface method code screenshot is as follows: Figure 7 As shown, the old interface method code screenshot is as follows Figure 8 As shown, the screenshots of the object adaptation code returned by the new and old interfaces are as follows Figure 9 shown.

[0206] Second: rewrite the old interface calling method and embed the decision group routing strategy;

[0207] In order to ensure that the interface caller does not need to make any adaptation adjustments, it is necessary to integrate the decision group routing strategy into the caller of the old interface method. In this way, when the application initiates a call to the old interface, the decision group can intelligently choose to call the old interface or the new interface based on the logic of the routing strategy. The screenshot of the strategy group routing logic code is as follows Figure 10 shown.

[0208] Third: Rewrite the old interface call logic. This step only changes the internal logic of the old interface call, and does not change the external parameters and request information;

[0209] Use Callable driver technology to reconstruct the method body of the old interface. In this process, the object type returned by the new interface needs to be converted to the return object type expected by the old interface. In order to achieve this conversion, the specific implementation method is passed as a parameter of the Callable driver. The specific implementation code is as follows Figure 11 shown.

[0210] Fourth: Configure Apollo routing policy group information;

[0211] According to the above content, you need to configure the policy group routing policy in the Apollo management backend. The policy information is as follows: Figure 12 shown.

[0212] Fifth: Encapsulate the Apollo routing policy group information instance class (taking JAVA as an example);

[0213] The screenshot of the Java instance class for encapsulating policy group routing information is as follows: Figure 13 shown.

[0214] Sixth: The project is released into the production environment to ensure the successful launch of the project;

[0215] When starting a project, make sure that the formal production environment has been activated to ensure that the routing policy of the policy group can take effect smoothly. In addition, during the startup process, you also need to clearly specify the Apollo-related configuration information. Figure 14 Shown is a screenshot showing the startup script command.

[0216] Seventh: Use the curl command in the console to request the original interface;

[0217] Enter the old interface request command in the project console. The routing configuration policy determines whether the interface response is the old or new interface, and whether the old and new interface messages need to be compared. A screenshot of the old interface request command and response is shown in Figure 15.

[0218] 8. Receive notification of policy effectiveness; screenshots of policy effectiveness are as follows: Figure 16 shown.

[0219] Ninth: Receive the message and compare it with the abnormal broadcast information; the abnormal alarm screenshot is as follows Figure 17 shown.

[0220] By analyzing the policy group's routing configuration (including returning the old interface's execution result message and performing a comparative analysis of the old and new interface message content), we observed the message returned by curl requests to the old interface, as well as screenshots of abnormal message broadcast information, confirming that the decision maker's routing policy was successfully implemented. Furthermore, the policy's operational logic and output strictly met the established design expectations.

[0221] The fourth embodiment of the present disclosure also provides a system for seamless interface switching based on Callable technology, such as Figure 18 As shown, the system includes:

[0222] Configuration module 11, which is configured to perform Apollo configuration to configure different effective policy information for different interface codes, generate Java encapsulation class objects according to the configuration, and obtain preset policy group configuration information;

[0223] The determination module 12 is configured to determine whether to use the old interface or the new interface data to respond to the calling end according to the preset policy group configuration information when the application end initiates an interface call;

[0224] The request module 13 is configured to directly initiate a request to the old interface to obtain a response message if the old interface is used; if the new interface is used, it triggers a callable method call, executes the call logic of the new interface, and converts the response message returned by the new interface into a data object format that conforms to the old interface;

[0225] The comparison module 14 is configured to send the obtained response message to the message queue MQ, so that the MQ consumer can determine whether the original request of the message is for the old interface or the new interface based on the message information, and select another interface corresponding to the interface of the original request to initiate a request, obtain the message content returned by the interface, and compare the message contents obtained from the two interfaces to determine whether there is any difference in the data.

[0226] Furthermore, the Apollo configuration includes:

[0227] Interface name and brief description of policy logic;

[0228] Policy effective time;

[0229] Interface coding;

[0230] The source of application request interface data in the production environment is the old interface or the new interface;

[0231] Whether to compare the contents of the messages returned by the new and old interfaces;

[0232] Policy expiration time.

[0233] Furthermore, the determining module 12 is specifically configured to:

[0234] When the application initiates an interface call, the method code being called is captured and recorded, the method code is verified, and the method code is checked to see if it exists in the preset policy group configuration information;

[0235] If it exists, the selected policy group information is obtained according to the effective policy information corresponding to the interface to obtain the final effective routing policy;

[0236] The routing policy determines whether to use the old interface or the new interface data to respond to the caller.

[0237] Furthermore, the system further includes a judgment module 15;

[0238] The judgment module 15 is configured to judge whether the current operating environment is a production environment before the determination module 12 determines whether to use the old interface or the new interface data to respond to the caller according to the preset policy group configuration information;

[0239] If yes, the determining module 12 is made to execute the step of determining whether to use the data of the old interface or the new interface to respond to the calling end according to the preset policy group configuration information;

[0240] If not, the determining module 12 is automatically redirected and directly calls the old interface, and then returns the result to the calling end.

[0241] Furthermore, the determining module 12 is further configured to:

[0242] If the check method code does not exist in the preset policy group configuration information, a redirection mechanism will be automatically triggered to divert the call process to the execution path of the old interface, directly call the old interface, and make the old interface process the corresponding business logic and return the processing results to the calling end.

[0243] Furthermore, the determining module 12 is specifically configured to:

[0244] Evaluate the start and end time of each policy in the policy group configuration information corresponding to the method encoding, and determine whether the current time falls exactly within the start and end time range specified by a policy configuration;

[0245] If so, the policy is considered a candidate. If there is only one candidate, it is selected as the final routing policy. If there are multiple candidates, the policy with the highest ranking among them is selected as the final routing policy according to the priority principle.

[0246] If not, a preset redirection mechanism is activated to ensure that the calling process can be redirected to the execution path of the old interface.

[0247] Furthermore, the system further includes a notification module 16;

[0248] The notification module 16 is configured to check whether the current routing policy is applied for the first time on the day after the determining module 12 obtains the routing policy that is finally effective;

[0249] If so, a policy implementation notification process is automatically triggered to notify relevant personnel of the policy changes in a timely manner.

[0250] Furthermore, the determining module 12 is further configured to:

[0251] Before formally executing the routing policy, perform request anti-duplicate filtering to identify and eliminate all duplicate requests.

[0252] Furthermore, the comparison module 14 is specifically configured to:

[0253] Select and call the corresponding message comparison module through the predefined interface code,

[0254] The message comparison module compares the message contents obtained from the new interface and the old interface respectively.

[0255] If the comparison confirms that the two data are completely consistent, the message comparison process is terminated;

[0256] If there is a discrepancy between the two data, the code is extracted from the data object returned by the old and new interface messages, and statistical analysis is performed on it to summarize the number of exception types that appear in the old and new messages corresponding to each interface code, as well as the specific information of these current exceptions;

[0257] Based on the statistical analysis results, determine whether the new interface is ready to smoothly replace the old interface.

[0258] The interface seamless switching system based on Callable technology in the embodiment of the present disclosure is used to implement the interface seamless switching method based on Callable technology in method embodiments one to three, so the description is relatively simple. For details, please refer to the relevant description in the previous method embodiment, which will not be repeated here.

[0259] In addition, if Figure 19As shown, the fifth embodiment of the present disclosure further provides an electronic device, including a memory 100 and a processor 200, wherein the memory 100 stores a computer program. When the processor 200 runs the computer program stored in the memory 100, the processor 200 executes the above-mentioned various possible methods.

[0260] The memory 100 is connected to the processor 200 . The memory 100 may be a flash memory, a read-only memory, or other memory. The processor 200 may be a central processing unit or a single-chip microcomputer.

[0261] In addition, an embodiment of the present disclosure further provides a computer-readable storage medium, on which a computer program is stored, and the computer program is used by a processor to execute the above-mentioned various possible methods.

[0262] The computer-readable storage medium includes volatile or nonvolatile, removable or non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, computer program modules or other data). Computer-readable storage media include, but are not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable read only memory), flash memory or other memory technology, CD-ROM (Compact Disc Read-Only Memory), Digital Versatile Disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer.

[0263] It is understood that the above embodiments are merely exemplary embodiments for illustrating the principles of the present disclosure, and the present disclosure is not limited thereto. Those skilled in the art may make various modifications and improvements without departing from the spirit and substance of the present disclosure, and such modifications and improvements are also considered to be within the scope of protection of the present disclosure.

Claims

1. A method for seamless interface switching based on Callable technology, characterized in that: The method comprises: Perform Apollo configuration to configure different effective policy information for different interface codes, generate Java encapsulation class objects based on the configuration, and obtain the preset policy group configuration information; When the application initiates an interface call, it determines whether to use the old interface or the new interface data to respond to the caller based on the preset policy group configuration information; If the old interface is used, a request to the old interface is directly initiated to obtain a response message. If the new interface is used, a callable method is triggered to execute the calling logic of the new interface and convert the response message returned by the new interface into a data object format that conforms to the old interface. The obtained response message is sent to the message queue MQ, so that the MQ consumer can determine whether the original request of the message is for the old interface or the new interface based on the message information, and select another interface corresponding to the interface of the original request to initiate a request, obtain the message content returned by the interface, and compare the message contents obtained from the two interfaces to determine whether there is any difference in the data.

2. The method according to claim 1, characterized in that The Apollo configuration includes: Interface name and brief description of policy logic; Policy effective time; Interface coding; The source of application request interface data in the production environment is the old interface or the new interface; Whether to compare the contents of the messages returned by the new and old interfaces; Policy expiration time.

3. The method according to claim 1, characterized in that When the application initiates an interface call, determining whether to use data from the old interface or the new interface to respond to the caller according to the preset policy group configuration information includes: When the application initiates an interface call, the method code being called is captured and recorded, the method code is verified, and the method code is checked to see if it exists in the preset policy group configuration information; If it exists, the selected policy group information is obtained according to the effective policy information corresponding to the interface to obtain the final effective routing policy; The routing policy determines whether to use the old interface or the new interface data to respond to the caller.

4. The method according to claim 1, wherein The method further comprises: Before determining whether to use the old interface or the new interface data to respond to the caller according to the preset policy group configuration information, determine whether the current operating environment is the production environment; If so, executing the step of determining whether to use data from the old interface or the new interface to respond to the calling end according to the preset policy group configuration information; If not, it will automatically redirect and directly call the old interface, and then return the result to the caller.

5. The method according to claim 3, characterized in that The method further comprises: If the check method code does not exist in the preset policy group configuration information, a redirection mechanism will be automatically triggered to divert the call process to the execution path of the old interface, directly call the old interface, and make the old interface process the corresponding business logic and return the processing results to the calling end.

6. The method according to claim 3, characterized in that The step of obtaining the selected policy group information according to the effective policy information corresponding to the interface to obtain the final effective routing policy includes: Evaluate the start and end time of each policy in the policy group configuration information corresponding to the method encoding, and determine whether the current time falls within the start and end time range specified by a policy configuration; If so, the policy is considered a candidate. If there is only one candidate, it is selected as the final routing policy. If there are multiple candidates, the policy with the highest ranking among them is selected as the final routing policy according to the priority principle. If not, a preset redirection mechanism is activated to ensure that the calling process can be redirected to the execution path of the old interface.

7. The method according to claim 3, characterized in that The method further comprises: After obtaining the final effective routing policy, check whether the current routing policy is applied for the first time that day; If so, a policy implementation notification process is automatically triggered to notify relevant personnel of the policy changes in a timely manner.

8. The method according to claim 1, characterized in that The method further comprises: Before formally executing the routing policy, perform request anti-duplicate filtering to identify and eliminate all duplicate requests.

9. The method according to claim 1, characterized in that Comparing the contents of the messages obtained from the two interfaces to determine whether there is a difference in the data includes: Select and call the corresponding message comparison module through the predefined interface code, The message comparison module compares the message contents obtained from the new interface and the old interface respectively. If the comparison confirms that the two data are completely consistent, the message comparison process is terminated; If there is a discrepancy between the two data, the code is extracted from the data object returned by the old and new interface messages, and statistical analysis is performed on it to summarize the number of exception types that appear in the old and new messages corresponding to each interface code, as well as the specific information of these current exceptions; Based on the statistical analysis results, determine whether the new interface is ready to smoothly replace the old interface.

10. A seamless interface switching system based on Callable technology, characterized in that: The system comprises: The configuration module is set to perform Apollo configuration to configure different effective policy information for different interface codes, generate Java encapsulation class objects according to the configuration, and obtain the preset policy group configuration information; A determination module is configured to determine whether to use the old interface or the new interface data to respond to the calling end according to the preset policy group configuration information when the application end initiates an interface call; The request module is configured to directly initiate a request to the old interface to obtain a response message if the old interface is used; if the new interface is used, it triggers a callable method call, executes the call logic of the new interface, and converts the response message returned by the new interface into a data object format that conforms to the old interface; The comparison module is configured to send the obtained response message to the message queue MQ, so that the MQ consumer can determine whether the original request of the message is for the old interface or the new interface based on the message information, and select another interface corresponding to the interface of the original request to initiate a request, obtain the message content returned by the interface, and compare the message contents obtained from the two interfaces to determine whether there is any difference in the data.

11. An electronic device, characterized in that: The method comprises a memory and a processor, wherein a computer program is stored in the memory, and when the processor runs the computer program stored in the memory, the processor executes the method for seamless interface switching based on Callable technology as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method for seamless interface switching based on Callable technology according to any one of claims 1 to 9 is implemented.

Images