Seamless interface switching methods, devices and electronic equipment

Abstract

This invention discloses a seamless interface switching method, apparatus, and electronic device, relating to the fields of software engineering and computer application technology. The method includes: receiving an interface request for a target service initiated by a caller; making a routing decision on the interface request based on a pre-configured gray-scale strategy; if the routing decision is to route to the new interface, executing the new interface call process to obtain first target response data; returning the first target response data to the caller; if the routing decision is to route to the old interface, executing the old interface call process to obtain second original response data as second target response data; and returning the second target response data to the caller. This solution solves the problem that existing interface upgrade schemes cannot automatically adapt to differences in interface specifications, requiring callers to modify code, resulting in high upgrade costs and implementation difficulties. It achieves complete seamless switching for the caller and smooth switching under gray-scale conditions, reducing migration risks and costs.

Description

Technical Field

[0001] This invention relates to the fields of software engineering and computer application technology, and in particular to a method, apparatus and electronic device for seamless interface switching. Background Technology

[0002] In microservice architectures or distributed systems, as business functions evolve and system architecture is optimized, system interfaces often need to be upgraded from older versions to newer ones. However, the input and output parameters of the new interface (i.e., the new version of the system interface) often differ from the old interface (i.e., the old version of the system interface) according to the specified standards (hereinafter referred to as "interface specifications"). This difference means that during the upgrade, all callers that depend on the service must modify their calling programs accordingly to adapt to the new parameter format; otherwise, they will be unable to correctly call the interface or parse its return results, leading to a complex and costly upgrade process.

[0003] Therefore, when implementing interface version upgrades, existing technologies face high costs and implementation difficulties due to the need for callers to modify their code because of differences in interface specifications. This has become an urgent problem to be solved in this field. Summary of the Invention

[0004] Based on this, embodiments of the present invention provide a method, apparatus, and electronic device for seamless interface switching to solve the problem that existing interface upgrade schemes cannot automatically adapt to differences in interface specifications, causing callers to have to modify code, resulting in high upgrade costs and implementation difficulties.

[0005] Firstly, a seamless interface switching method is provided for server-side applications, including: Receive an interface request for the target service initiated by the caller, wherein the interface request conforms to the first interface specification; Based on a pre-configured gray-scale strategy, a routing decision is made for the interface request to determine whether to route the interface request to an old version interface that conforms to the first interface specification or to a new version interface that conforms to the second interface specification; wherein, the new version interface is an updated version of the old version interface; If the routing decision is to route to the new interface, then the new interface call process is executed, including: obtaining the input parameters of the interface request; converting the input parameters from a format conforming to the first interface specification to a format conforming to the second interface specification according to a preset parameter conversion rule, to obtain the converted input parameters; using the converted input parameters to call the new interface, and obtaining the first original response data returned by the new interface; converting the first original response data from a format conforming to the second interface specification to a format conforming to the first interface specification according to the preset parameter conversion rule, to obtain the first target response data; and returning the first target response data to the caller. If the routing decision is to route to the old version interface, then the old version interface call process is executed, including: obtaining the input parameters of the interface request; using the input parameters to call the old version interface, obtaining the second original response data returned by the old version interface, and using the second original response data as the second target response data; and returning the second target response data to the caller.

[0006] Secondly, a seamless interface switching device is provided for use on the server side, including: The request receiving module is used to receive interface requests for the target service initiated by the caller, wherein the interface requests conform to the first interface specification; The routing decision module is used to make routing decisions for the interface request based on a pre-configured gray-scale strategy, so as to determine whether to route the interface request to an old version interface that conforms to the first interface specification or to a new version interface that conforms to the second interface specification; wherein, the new version interface is an updated interface of the old version interface; The new interface invocation module is used to execute a new interface invocation process when the routing decision is to route to the new interface, including: obtaining the input parameters of the interface request; converting the input parameters from a format conforming to the first interface specification to a format conforming to the second interface specification according to a preset parameter conversion rule, to obtain the converted input parameters; using the converted input parameters to invoke the new interface, and obtaining the first original response data returned by the new interface; converting the first original response data from a format conforming to the second interface specification to a format conforming to the first interface specification according to the preset parameter conversion rule, to obtain the first target response data; and returning the first target response data to the caller. The legacy interface invocation module is used to execute a legacy interface invocation process when the routing decision is to route to the legacy interface, including: obtaining the input parameters of the interface request; invoking the legacy interface using the input parameters, obtaining the second original response data returned by the legacy interface, and using the second original response data as the second target response data; and returning the second target response data to the caller.

[0007] Thirdly, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the aforementioned seamless interface switching method when executing the computer program.

[0008] The technical solution provided by this invention effectively solves the problem that existing interface upgrade schemes cannot automatically adapt to differences in interface specifications, forcing callers to modify their code, resulting in high upgrade costs and implementation difficulties. Specifically, this solution achieves the following beneficial effects through the following process: The server receives an interface request initiated by the caller using the first interface specification, requiring no code modification from the caller; subsequently, it makes a routing decision based on a pre-configured gray-scale strategy to determine whether to route the interface request to the old version interface or to the new version interface using the second interface specification; crucially, when routed to the new version interface, the server automatically converts the input parameters of the interface request from the format of the first interface specification to the format of the second interface specification according to preset parameter conversion rules to complete the call, and reverses the first original response data returned by the new version interface back to the format of the first interface specification according to the same rule, returning it as the first target response data; when routed to the old version interface, the server directly completes the call based on the input parameters of the interface request, and returns its second original response data as the second target response data. Therefore, regardless of the routing result, the target response data received by the caller always conforms to its expected first interface specification. This automatically solves the adaptation problem of interface specification differences without the caller being aware of it, realizing automatic adaptation of parameter differences, complete unawareness of the caller, and smooth switching under gray-scale conditions, effectively reducing migration risks and costs. Attached Figure Description

[0009] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a schematic diagram of an application environment for a seamless interface switching method according to an embodiment of the present invention; Figure 2 This is a flowchart of an interface seamless switching method according to an embodiment of the present invention; Figure 3 This is another flowchart of the interface seamless switching method in one embodiment of the present invention; Figure 4 This is another flowchart of the interface seamless switching method in one embodiment of the present invention; Figure 5 This is another flowchart of the interface seamless switching method in one embodiment of the present invention; Figure 6 This is another flowchart of the interface seamless switching method in one embodiment of the present invention; Figure 7This is another flowchart of the interface seamless switching method in one embodiment of the present invention; Figure 8 This is another flowchart of the interface seamless switching method in one embodiment of the present invention; Figure 9 This is a schematic diagram of an interface seamless switching device in one embodiment of the present invention; Figure 10 This is another schematic diagram of an interface seamless switching device in one embodiment of the present invention; Figure 11 This is a schematic diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0011] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0012] The seamless interface switching method provided in this embodiment of the invention can be applied to, for example... Figure 1 The system application environment shown. Specifically, this seamless interface switching method can be applied to a seamless interface switching system, which includes, for example,... Figure 1 The client and server shown communicate via a network to collaboratively execute the steps of the seamless interface switching method described in this invention. The client is the physical or logical starting point of the interface request, and the software entity running on it is called the caller, i.e., the entity that initiates the interface request for the target service to the server. This can include, but is not limited to, various personal computers, smartphones, and tablets. The server can serve as the execution entity of the method, and its physical implementation can be a standalone server or a server cluster consisting of multiple servers.

[0013] In one embodiment, such as Figure 2 As shown, a seamless interface switching method is provided, which is applied to... Figure 1 Taking the server-side as an example, the explanation includes the following steps: S101: Receives an interface request for the target service initiated by the caller. The interface request conforms to the first interface specification.

[0014] In this context, "caller" refers to an external system or application that initiates an interface request to the server to obtain the processing result of the target service. This includes, but is not limited to, applications running on the client (such as web browsers or mobile applications), upstream business systems or microservices deployed in a server environment (such as order services or inventory services), and other software entities such as automation scripts, batch processing programs, or API gateways. "Target service" refers to the backend service unit to which the interface request points, used to execute specific business processing logic and return processing results, such as a product search service, order query service, or user information service. "Interface request" refers to the data request sent by the caller to the target service according to the interface agreement to trigger business processing logic. The first interface specification refers to the agreement of the older version of the interface, used to define the interface definition standard for limiting the request path, input parameter format, and response data format of the interface request.

[0015] In one possible approach, the server can use a programming interceptor (such as an AOP interceptor) deployed on the service call chain to intercept the request path and input parameters. The interface request is constructed in accordance with the first interface specification. This allows for the implementation of multiple processing logics or interface implementation forms within the interface without exposing different interface specifications to the caller. This maintains consistency in the calling method during interface evolution or replacement, reducing the need for the caller to make adaptation modifications due to changes in interface specifications.

[0016] For example, in an e-commerce platform's product search interface upgrade scenario, the first interface specification stipulates that the request path is / api / v1 / search, the request method is GET, and the query parameters include the keyword and the number of items per page (pageSize). The caller always initiates requests according to the first interface specification. When the server receives a request containing keyword=mobile phone&pageSize=20, even if the server internally routes the request to a new interface implementation with parameter structure differences from the first interface specification based on a gray-scale strategy, it still uses a preset parameter conversion mechanism to convert the received request parameters conforming to the first interface specification into a parameter format adapted to the new interface implementation. After obtaining the response data returned by the new interface, the server converts the response data into a product list response format conforming to the first interface specification. During this process, the request format sent by the caller and the response format received do not change, so the caller does not need to be aware that the backend interface has been upgraded to a more efficient search algorithm and data source, achieving a completely transparent interface switch and seamless migration.

[0017] S102: Based on the pre-configured grayscale strategy, make routing decisions for interface requests to determine whether to route the interface request to the old version interface that conforms to the first interface specification or to the new version interface that conforms to the second interface specification; wherein, the new version interface is the updated interface of the old version interface.

[0018] In this context, the new interface is an updated version of the old interface. During system evolution, the new interface is developed to replace the old one. Functionally, they are related, but their interface specifications differ. Essentially, the old interface is the "old" interface, and the new interface is the "new" interface. The gray-scale strategy refers to the set of rules used to limit the selection of different interface processing paths for interface requests. Routing decision refers to the decision-making process of analyzing interface requests and determining their subsequent processing paths based on the gray-scale strategy. The old interface refers to the existing interface processing logic or interface version defined according to the first interface specification and used to process interface requests. The new interface refers to the updated interface processing logic or interface version defined according to the second interface specification and used to process interface requests. The second interface specification refers to the conventions of the new version interface, used to define the interface definition standards for the input parameter format and response data format of interface requests.

[0019] In one possible implementation, upon receiving an interface request, the server reads a pre-configured canary deployment strategy (such as traffic ratio, whitelist, user characteristics, or conditional rules) from a configuration center (e.g., Apollo or Nacos) and performs routing decisions based on this strategy. This allows the interface request to be selectively routed between the old and new versions of the interface. In this way, the server can simultaneously run both the old version conforming to the first interface specification and the new version conforming to the second interface specification within the same system. It can dynamically select the appropriate interface for processing based on the characteristics of the interface request, enabling the new version interface to gradually handle a portion of the business traffic without affecting interface requests not routed to the new version interface, thus ensuring system continuity during the interface switchover process.

[0020] For example, the gray-scale strategy pre-configures routing rules based on the user identifier field. When the user identifier carried in the interface request meets the preset conditions, the interface request is routed to the new version interface conforming to the second interface specification for processing; when the user identifier does not meet the preset conditions, the interface request is routed to the old version interface conforming to the first interface specification for processing. In this way, interface requests for the same target service can be directed to interface implementations with different interface specifications, thereby completing the gradual verification and switching of the new version interface without interrupting existing business.

[0021] For example, in an e-commerce order query interface upgrade scenario, the pre-defined gray-scale strategy is: "Requests with merchant type 'Taobao' and user ID ending in less than 50 are routed to the new interface, while all others are routed to the old interface." Upon receiving an order query request, the server extracts the merchant type and user ID for comparison: if the user ID is 12345 (last two digits are 45) and the merchant type is "Taobao," the request is routed to the new interface, and the new interface logic is called after parameter conversion and adaptation to return the result; if the user ID is 12351 (last two digits are 51), the request is routed to the old interface for direct processing. Based on this approach, operations personnel can verify the behavior of the new interface in a production environment with controlled traffic. After confirming that there are no errors, the strategy is gradually adjusted until a full switch is achieved.

[0022] S103: If the routing decision is to route to the new version interface, then execute the new version interface call process, including: obtaining the input parameters of the interface request; converting the input parameters from a format conforming to the first interface specification to a format conforming to the second interface specification according to the preset parameter conversion rules, to obtain the converted input parameters; calling the new version interface using the converted input parameters, and obtaining the first original response data returned by the new version interface; converting the first original response data from a format conforming to the second interface specification to a format conforming to the first interface specification according to the preset parameter conversion rules, to obtain the first target response data; and returning the first target response data to the caller.

[0023] Parameter conversion rules refer to preset rules used to define the conversion relationships of input parameters between different interface specifications in terms of data type, field structure, and field meaning. The new interface call flow refers to the parameter conversion, interface call, and result conversion processes performed to complete interface processing after an interface request is routed to the new interface. Input parameters of the interface request are data contents included in the interface request that describe the business processing conditions. Parameter conversion rules refer to preset conversion conventions used to define the parameter structure, field names, data type, or data encoding relationships between the first and second interface specifications. The first raw response data refers to the response data directly generated by the new interface after processing according to the second interface specification, without undergoing reverse conversion. The first target response data refers to the first target response data generated by reverse conversion of the first raw response data according to the parameter conversion rules, conforming to the first interface specification, and used to return to the caller.

[0024] In one possible implementation, when the routing decision determines that the interface request should be processed by the new version of the interface, the server executes the new version interface call flow, completing the actual call to the new version interface while maintaining the external interface specification unchanged. By performing forward format conversion on the input parameters during the new version interface call flow and reverse format conversion on the response data after obtaining the return result from the new version interface, the server can effectively shield the differences between the first and second interface specifications. This ensures that the caller always performs interface calls and result processing according to the first interface specification, thereby avoiding the need for the caller to make adaptation modifications due to changes in interface specifications during interface upgrades or replacements.

[0025] For example, in a scenario where a bank system's account balance query interface is being upgraded, the first interface specification requires the request parameters (i.e., the input parameters of the first interface specification) to include an "accountNo" field to represent the account number. The second interface specification, however, requires the request parameters (i.e., the input parameters of the second interface specification) to include a "customerAccountId" field to represent the same account number. After obtaining the input parameters of the interface request, the server converts "accountNo" to "customerAccountId" according to the parameter conversion rules and uses the converted input parameters to call the new interface to obtain the first original response data. If the balance details field returned in the first original response data is "balanceDetail", the server then converts this field back to the "BalanceInfo" structure agreed upon in the first interface specification according to the parameter conversion rules, generating the first target response data that conforms to the first interface specification and returning it to the caller. This allows the caller to be unaware of the structural differences between the old and new interfaces.

[0026] S104: If the routing decision is to route to the old version interface, then execute the old version interface call process, including: obtaining the input parameters of the interface request; calling the old version interface using the input parameters, obtaining the second original response data returned by the old version interface, and using the second original response data as the second target response data; and returning the second target response data to the caller.

[0027] The legacy API call process refers to the API call processing procedure executed to complete the API processing after the API request is routed to the legacy API. The second raw response data refers to the raw response data directly generated by the legacy API after processing according to the first API specification. The second target response data refers to the response data that is directly returned as the API result from the second raw response data, conforms to the first API specification, and is used to return to the caller.

[0028] In one possible implementation, when the routing decision determines that an interface request should be processed by the old interface, the server executes the old interface call process, directly using the input parameters obtained from the interface request to call the old interface, and uses the response data returned by the old interface as the final result returned to the caller. This ensures that while the new interface is introduced and canary routing is implemented, the processing path of the old interface remains unchanged, thus ensuring that interface requests not routed to the new interface continue to execute stably in the existing manner, avoiding any impact on existing services during the interface switchover process.

[0029] For example, the first interface specification stipulates that the interface request includes an order identifier and query condition parameters. When the routing decision results in routing the interface request to the old version interface, the server directly uses the order identifier and query condition parameters to call the old version interface to obtain the second original response data, and returns this second original response data as the second target response data to the caller. Since the input parameters and return results of the old version interface both conform to the first interface specification, the response data format received by the caller under this process is consistent with the historical call, thus requiring no adjustment to the original interface parsing logic.

[0030] For example, in a scenario where the content acquisition interface of a news recommendation system is being upgraded, the input parameter of the first interface specification is ContentRecommendReq (containing userId and category fields). When the gray-scale strategy fails (e.g., the hash value of the user ID modulo 100 is greater than or equal to 20), the server obtains the original ContentRecommendReq and directly passes it to the old interface call to obtain ContentRecommendResp containing the recommendation list as the second original response data. This is then directly returned to the caller (e.g., a news app) as the second target response data. The caller can render the recommended content normally without any changes. This perfectly complements the conversion process of the new interface branch, ensuring that the experience of most users remains completely unchanged during the gray-scale phase, achieving a smooth and controllable interface transition.

[0031] In summary, the technical solution provided by this invention effectively solves the problem that existing interface upgrade schemes cannot automatically adapt to differences in interface specifications, forcing callers to modify their code, resulting in high upgrade costs and implementation difficulties. Specifically, this solution achieves the following beneficial effects through the following process: The server receives an interface request initiated by the caller using the first interface specification, requiring no modification to the caller's code; subsequently, it makes a routing decision based on a pre-configured gray-scale strategy to determine whether to route the interface request to the old version interface or to the new version interface of the second interface specification; crucially, when routed to the new version interface, the server automatically converts the input parameters of the interface request from the format of the first interface specification to the format of the second interface specification according to preset parameter conversion rules to complete the call, and reverses the first original response data returned by the new version interface back to the format of the first interface specification according to the same rule, and returns it as the first target response data; when routed to the old version interface, the server directly completes the call based on the input parameters of the interface request, and returns its second original response data as the second target response data. Therefore, regardless of the routing result, the target response data received by the caller always conforms to its expected first interface specification. This automatically solves the adaptation problem of interface specification differences without the caller being aware of it, realizing automatic adaptation of parameter differences, complete unawareness of the caller, and smooth switching under gray-scale conditions, effectively reducing migration risks and costs.

[0032] In one embodiment, such as Figure 3 As shown, in step S103, which involves converting the input parameters from a format conforming to the first interface specification to a format conforming to the second interface specification according to preset parameter conversion rules, the converted input parameters include the following steps: S131A: Determine the first source data type of the input parameters and the second target data type required by the second interface specification; S132A: Generate a first query key based on the first source data type and the second target data type; S133A: Using the first query key, a query is performed in the preset converter mapping table to obtain the first parameter converter corresponding to the first query key. The converter mapping table stores the correspondence between different query keys and specific parameter converter instances. S134A: Call the first parameter converter to perform a conversion operation on the input parameters and obtain the converted input parameters.

[0033] As an example, parameter conversion rules refer to preset rules used to define the conversion relationships between input parameters in terms of data type, field structure, and field meaning between different interface specifications. The first source data type refers to the data type definition corresponding to the input parameter when it conforms to the first interface specification. The second target data type refers to the data type definition required for the input parameter in the second interface specification. The first query key refers to an index identifier generated by combining the first source data type and the second target data type, used to uniquely identify the parameter conversion relationship. The converter mapping table refers to a data structure used to store the correspondence between query keys and parameter converter instances. The first parameter converter refers to a specific converter instance used to perform the parameter conversion operation from the first source data type to the second target data type.

[0034] In one possible implementation, when the server executes a new version of the interface call process, it first determines the first source data type and the second target data type of the input parameters, generates a first query key based on the two, and then uses the first query key to obtain the corresponding first parameter converter from the parameter converter factory. The server can avoid hard-coding parameter conversion relationships in the business logic, making the parameter conversion process scalable and maintainable. Thus, when the interface specification changes or a new interface specification is added, only the corresponding parameter converter needs to be added to complete the adaptation.

[0035] For example, the input parameter corresponds to the data type "RepayQueryRequest" in the first interface specification, while in the second interface specification, the new version of the interface expects to receive the data type "CustomerLoanQueryReq". The server first determines that the source data type (first source data type) for this conversion is "RepayQueryRequest" and the target data type (second target data type) is "CustomerLoanQueryReq". Based on this determined type combination, the server generates a unique first query key, with a format such as "RepayQueryRequest -> CustomerLoanQueryReq". Subsequently, the parameter converter factory receives the first query key and queries its internally maintained converter mapping table (one implementation uses a HashMap data structure). Through this query, the factory obtains the first parameter converter instance (e.g., a converter named "RepayQueryToCustomerLoanReqCvt") that is pre-registered and bound to this key. The server calls the conversion method of the first parameter converter instance, taking a "RepayQueryRequest" object conforming to the first interface specification as input, and performs operations such as field mapping, format adjustment, or logical calculation defined therein, ultimately generating a "CustomerLoanQueryReq" type object that fully conforms to the requirements of the second interface specification. This converted input parameter can then be directly used by the new version of the interface implementation, thus completing the automatic adaptation of the call parameter from the old specification to the new specification.

[0036] In one embodiment, such as Figure 4 As shown, in step S103, which involves converting the first original response data from a format conforming to the second interface specification to a format conforming to the first interface specification according to a preset parameter conversion rule, to obtain the first target response data, the following steps are included: S131B: Determine the second source data type to which the first raw response data belongs and the first target data type required by the first interface specification; S132B: Generate a second query key based on the second source data type and the first target data type; S133B: Use the second query key to query the converter mapping table maintained by the preset parameter converter factory to obtain the second parameter converter corresponding to the second query key; S134B: Call the second parameter converter to perform a conversion operation on the first raw response data to obtain the first target response data.

[0037] Here, the second source data type refers to the data type definition corresponding to the first original response data when it conforms to the second interface specification. The first target data type refers to the data type definition required for the response data in the first interface specification. The second query key refers to an index identifier generated by combining the second source data type and the first target data type, used to uniquely identify the response data transformation relationship. The second parameter converter refers to a specific converter instance used to perform the response data transformation operation from the second source data type to the first target data type.

[0038] In one possible implementation, after the server completes the new version of the interface call and obtains the first raw response data, it performs a reverse conversion on the response data through a parameter converter factory. By first determining the second source data type corresponding to the first raw response data and the first target data type required by the first interface specification, and generating a second query key based on both, and then automatically retrieving the second parameter converter matching the second query key from the parameter converter factory, the server can complete the structural conversion of the response data without relying on specific business logic. This allows the data returned by the new version of the interface to be uniformly encapsulated into a response format that conforms to the first interface specification, thereby shielding the caller from the differences in response structure between the new and old versions of the interface.

[0039] For example, the first raw response data corresponds to the data type "NewPatientSearchOutput" in the second interface specification, which includes a "searchResultList" field to represent the search result set; while the first interface specification requires the response data to be of type "PatientQueryResp", where the "patientRecords" field is used to represent the result set with the same meaning. The server first determines the source data type (second source data type) of this conversion as "NewPatientSearchOutput" and the target data type (first target data type) as "PatientQueryResp". Based on this determined type combination, the server generates a unique corresponding second query key, the format of which is, for example, "NewPatientSearchOutput -> PatientQueryResp".

[0040] Subsequently, the parameter converter factory receives the second query key and queries its internally maintained converter mapping table to obtain a pre-registered second parameter converter instance (e.g., a converter named "NewSearchOutputToPatientRespCvt") bound to this key. The server calls the conversion method of this second parameter converter instance, taking a "NewPatientSearchOutput" object conforming to the second interface specification as input, and performs operations such as field mapping (e.g., mapping "searchResultList" to "patientRecords"), data format adjustment (e.g., flattening nested structures), or value domain conversion, ultimately generating a "PatientQueryResp" type object that fully conforms to the first interface specification, i.e., the first target response data. This first target response data can then be directly returned to the caller, thus completing the automatic adaptation of response data from the new specification to the old specification, ensuring zero-modification compatibility of the caller's logic.

[0041] In one embodiment, such as Figure 5 As shown, the preset converter mapping table is constructed in the following way: a. Scan all target classes in the application that implement the predefined parameter converter interface; b. Instantiate each target class detected by scanning to obtain the corresponding parameter converter instance; c. For each parameter converter instance, determine the source data type and target data type it supports; d. Using the combination of the source data type and the target data type as the index key, register the parameter converter instance to the converter mapping table of the parameter converter factory.

[0042] As an example, the initialization process refers to the preparation process executed by the parameter converter factory during the startup or loading phase. The parameter converter factory is a centralized management module that automatically discovers and instantiates all parameter converters during startup, registers them to a mapping table using the combination of source and target types as keys, and provides corresponding converter instances on demand at runtime. The predefined parameter converter interface refers to the unified interface definition used to constrain the functionality and behavior of parameter converter implementation classes. The target class refers to the class that implements the predefined parameter converter interface and is used to execute specific parameter conversion logic; it can typically be a generic interface such as ParamConverter.<S, T> The implementation class of the parameter converter. A parameter converter instance is an object instantiated from the target class that can perform parameter conversion operations. The source data type refers to the input data type definition supported by the parameter converter instance. The target data type refers to the output data type definition supported by the parameter converter instance. The index key is a key value formed by combining the source and target data types, used to uniquely identify the parameter conversion relationship. The converter mapping table is a data structure maintained by the parameter converter factory to store the correspondence between index keys and parameter converter instances.

[0043] In one possible implementation, the parameter converter factory can automatically discover, create, and register parameter converter instances during initialization by scanning target classes in the application that implement the predefined parameter converter interface. By uniformly determining the source and target data types supported by each parameter converter instance during initialization and registering them in the converter mapping table using their combination as an index key, the parameter converter factory can quickly and accurately locate the corresponding parameter converter instance based on actual parameter conversion needs during runtime. This avoids explicitly maintaining parameter conversion relationships in business processing logic and improves the scalability and maintainability of the parameter conversion mechanism.

[0044] For example, the application contains a parameter converter class (target class) that converts type "RepayQueryRequest" to type "CustomerLoanQueryReq". This parameter converter class implements a predefined parameter converter interface. During the initialization of the parameter converter factory, the target class is scanned and instantiated to obtain the corresponding parameter converter instance. Then, its source data type is determined to be "RepayQueryRequest" and its target data type to be "CustomerLoanQueryReq". This type combination is used as an index key (e.g., the string "RepayQueryRequest->CustomerLoanQueryReq") and registered in the converter mapping table. When the same type of parameter conversion is needed subsequently, the parameter converter factory can retrieve the parameter converter instance using the index key and complete the conversion operation.

[0045] Specifically, assuming the predefined parameter converter interface is defined as ParamConverter<S, T> Here, the generic type S represents the source data type, and T represents the target data type. The application contains two concrete implementation classes: (1) The RepayQueryToCustomerLoanReqCvt class is declared to implement ParamConverter.<RepayQueryRequest, CustomerLoanQueryReq> (2) The NewSearchOutputToPatientRespCvt class is declared to implement ParamConverter.<NewPatientSearchOutput, PatientQueryResp> .

[0046] In the initialization method of the parameter converter factory (such as a method annotated with @PostConstruct or a constructor), perform the following steps: (1) Use the getBeansOfType(ParamConverter) method of the Spring framework's ApplicationContext (or a similar dependency injection container) to obtain all bean definitions of type ParamConverter in the container. This process will discover the two implementation classes mentioned above. (2) The dependency injection container will automatically create and manage instances of RepayQueryToCustomerLoanReqCvt and NewSearchOutputToPatientRespCvt as beans. The factory directly obtains these instances from the container. (3) The factory iterates through each ParamConverter instance obtained.

[0047] For the `RepayQueryToCustomerLoanReqCvt` instance, its generic parameter information is obtained through reflection or by directly parsing to extract the source data type `RepayQueryRequest` and the target data type `CustomerLoanQueryReq`. Then, a unique key is constructed using this type combination, for example, the string format "RepayQueryRequest->CustomerLoanQueryReq". Finally, this key, along with a reference to the `RepayQueryToCustomerLoanReqCvt` instance, is stored in the factory's internal `converterMap` (a HashMap).<String, ParamConverter> (in the structure).

[0048] Similarly, for the NewSearchOutputToPatientRespCvt instance, the source data type NewPatientSearchOutput and the target data type PatientQueryResp are parsed out, the key "NewPatientSearchOutput->PatientQueryResp" is generated, and the key and instance reference are stored in the converterMap.

[0049] After initialization, the converterMap contains two explicit mapping records. When business logic requires converting the source data type RepayQueryRequest to the target data type CustomerLoanQueryReq, it simply calls the conversion method of the parameter converter factory, passing in the source data type RepayQueryRequest and the target data type CustomerLoanQueryReq. The parameter converter factory will then generate the same query key "RepayQueryRequest->CustomerLoanQueryReq", retrieve the previously registered RepayQueryToCustomerLoanReqCvt instance from the converterMap, and call its convert method to complete the conversion task.

[0050] This mechanism ensures centralized management and on-demand invocation of converters. Adding new conversion logic only requires creating a new ParamConverter implementation class and having it managed by the Spring container, without modifying the factory or caller code.

[0051] In one embodiment, such as Figure 6 As shown, the method further includes the following steps: S105: Asynchronously trigger the comparison task, which is executed when the first target response data or the second target response data is returned to the caller; S106: In the comparison task, obtain the first comparison data and the second comparison data for the same interface request. The first comparison data is the comparison data returned by the new version interface, and the second comparison data is the comparison data returned by the old version interface. S107: Perform a consistency comparison between the first comparison data and the second comparison data to obtain the comparison results; S108: If the comparison results are inconsistent, a difference report will be generated.

[0052] As an example, a comparison task refers to a processing task used to perform consistency checks on data returned by different interface implementations. Asynchronous triggering refers to a triggering method that starts task execution without blocking the main processing flow. The first comparison data refers to the data obtained in the comparison task, returned by the new version of the interface, and used for consistency comparison (this can be the response data for the first target). The second comparison data refers to the data obtained in the comparison task, returned by the old version of the interface, and used for consistency comparison (this can be the response data for the second target). The difference report refers to a data report used to record inconsistencies between the first and second comparison data.

[0053] In one possible approach, the server can trigger a comparison task using an asynchronous task framework (such as Spring's `@Async` or `CompletableFuture`) when returning either the first or second target response data to the caller, or after returning either the first or second target response data to the caller; this is not limited to this approach. Triggering the comparison task asynchronously ensures that its execution is independent of and parallel to the API response return process. This feature allows the server to simultaneously obtain data returned by the new and old versions of the API for the same API request and perform a consistency comparison without affecting the API response timeliness. This enables continuous verification of the new API's processing results without causing additional delays or interference to the caller's normal API calls.

[0054] For example, when an interface request is routed to the new version of the interface and returns the first target response data to the caller, the server asynchronously triggers a comparison task. In this comparison task, the server re-acquires the second comparison data returned by the old version of the interface request and compares it with the first comparison data returned by the new version of the interface. If the comparison result shows that there are differences between the two in field values ​​or data structures, the server generates a corresponding difference report.

[0055] Specifically, during the upgrade of the dynamic information flow (Feed) query interface of a social platform, a user request was routed to the new interface according to the gray-scale strategy. After the server completes the main process (including parameter conversion, calling the new interface and reverse conversion of the result), it returns the first target response data that conforms to the old specification to the mobile client and immediately triggers the comparison task asynchronously. In the triggered comparison task: (1) Obtain comparison data: Since the main process has called the new interface, the first target response data returned by it can be directly used as the first comparison data. The task then uses the original request parameters to synchronously call the original interface once to obtain the second original response data returned by it as the second comparison data. (2) Perform consistency comparison: Perform a deep comparison of the two sets of data. In this scenario, since the new interface uses the optimized Feed sorting algorithm, the order of the returned post list is different from that of the original interface. For example, the comparison logic found that at the list index position 3 (feedList[3]), the post ID (postId) returned by the new interface is 789, while the post ID returned by the original interface at the same position is 456. (3) Generate and report: Based on this inconsistency, an automatic difference report is generated, which may include detailed information such as request identifier, path of the difference field (feedList[3].postId), value of the new interface (postId=789) and value of the original interface (postId=456). The difference report can be sent to the monitoring platform or alarm system through the preset monitoring reporting channel. Through this mechanism, the development team can promptly discover behavioral differences introduced by changes such as sorting algorithm optimization in the new interface without affecting the real-time user experience, and quickly intervene to analyze them, thereby ensuring that the function of the new interface is fully aligned with the original interface before the gray-scale range is expanded.

[0056] In one embodiment, such as Figure 7 As shown, step S107, which involves comparing the first and second comparison data to obtain the comparison results, includes the following steps: S171: If the first comparison data and the second comparison data meet the consistency condition, then the comparison result is determined to be consistent; S172: If the first comparison data and the second comparison data do not meet the consistency condition, then the comparison result is determined to be inconsistent.

[0057] The consistency conditions include that the object types of the first comparison data and the second comparison data are the same, that fields with the same name in the first comparison data and the second comparison data are not null, and that the names and values ​​of the attributes at each level contained in the first comparison data and the second comparison data are the same.

[0058] As an example, object type refers to the type information used to describe the structure or class definition to which data belongs in a program. A null value indicates that the data object does not contain any actual content or has not been assigned a value.

[0059] In one possible implementation, the above consistency comparison can be performed using a hierarchical, progressive comparison method, with the following execution logic: First layer: Object type comparison. Obtain the class definition information of the first and second comparison data in the program, and determine if their object types are the same. If the object types are different, the consistency condition is not met, and the comparison ends.

[0060] The second layer: comparison of null values ​​in fields with the same name. Assuming the object types are the same, fields with the same name are retrieved from the first and second comparison data respectively, and it is determined whether the values ​​of these fields are all non-null. If any field with the same name has a null value in at least one of the comparison data, the consistency condition is not met, and the comparison ends.

[0061] The third layer: Recursive comparison of attribute names and values ​​at each level. If the conditions of the first two layers are met, the attributes at each level contained in the first and second comparison data are recursively traversed, comparing the values ​​of attributes with the same name at the same level to see if they are completely equal. If any inconsistency in name or value is found at any attribute level, the consistency condition is not met; if all attributes at all levels correspond one-to-one and their values ​​are equal, the consistency condition is met.

[0062] For example, consider the scenario of a gray-scale switch of a user information query interface in an e-commerce platform. Suppose a user query request is routed to the new version of the interface, and an asynchronous comparison task is triggered after the main process is completed to obtain the first comparison data returned by the new version of the interface and the second comparison data returned by the old version of the interface. Both of them are UserInfo objects.

[0063] First, an object type comparison is performed. It is determined that both the first and second comparison data are instances of the `com.example.dto.UserInfo` class, meaning they have the same object type, and the first-level comparison passes. Next, a comparison of identically named fields with null values ​​is performed. The `UserInfo` class contains fields such as `userName`, `age`, and `address`. Checking the values ​​of these identically named fields in the first and second comparison data confirms that both have a non-empty string for the `userName` field, a non-empty integer for the `age` field, and a non-empty nested object for the `address` field. No identically named fields are found to be empty in either case, and the second-level comparison passes.

[0064] Then, the attribute names and values ​​at each level are recursively compared. The recursive process is as follows: Comparing the first-level attributes: the userName attribute value is "Zhang San" in both cases, and the age attribute value is 28 in both cases, so the results are consistent.

[0065] Entering the nested address property, we recursively compared its internal properties: the province property value was "Guangdong Province" and the city property value was "Shenzhen City", and the results were consistent.

[0066] The recursive traversal is complete, and no inconsistencies have been found.

[0067] Since the consistency conditions at all three levels are met, the comparison result of this consistency comparison is determined to be consistent according to step S171. If, in any of the above steps, for example, the address.city attribute is "Shenzhen" in the first comparison data but "Guangzhou" in the second comparison data, the third-level recursive comparison finds an inconsistency and immediately determines that the consistency condition is not met. According to step S172, the comparison result is determined to be inconsistent, and a difference record can be generated for subsequent monitoring and alarms. Through this hierarchical progressive comparison method, consistency verification can be completed in an orderly and complete manner even when the data object structure is complex or has multiple nested layers. This accurately reflects the degree of difference between the data returned by the new version of the interface and the old version of the interface, providing a reliable verification basis for the smooth replacement of the interface.

[0068] In one embodiment, that is, after step S108, i.e. after generating a difference report if the comparison results are inconsistent, the method further includes at least one of the following steps: S108A: Write the difference report to the local log file; S108B: Encapsulates the difference report into monitoring indicator data and pushes the monitoring indicator data to the pre-configured remote monitoring system; S108C: Generates alarm information based on the difference report and pushes the alarm information to the pre-configured alarm receiver.

[0069] As an example, a local log file refers to a log file used to store runtime information locally on the server. Monitoring metric data refers to measurement data that conforms to the data reception specifications of a remote monitoring system, formed by encapsulating difference reports according to a predefined data format. A remote monitoring system refers to an external monitoring platform used to centrally receive, store, and display monitoring metric data. Alarm information refers to notification content generated based on difference reports to indicate abnormal situations. An alarm receiver refers to a terminal system or application used to receive and display alarm information.

[0070] In one possible implementation, after a difference report is generated, at least one of the following processes is executed sequentially or in parallel: (1) appending the difference report to a specified local log file in JSON or structured format using a logging framework (such as Logback); (2) encapsulating the difference report into monitoring metric data and pushing it to a remote monitoring system; (3) constructing alarm titles and details based on the difference report and calling an alarm API (such as WeChat or DingTalk interface) to push it to the alarm receiver. This allows the difference report to be retained long-term through logs, and to be centrally monitored and promptly notified through monitoring metrics or alarms, thereby providing multi-dimensional data support for problem localization and operational status analysis during interface switching.

[0071] For example, in a scenario where the reconciliation query interface of a financial transaction system is being upgraded, when the asynchronous comparison task detects that the new interface's return value for the critical transaction amount field is inconsistent with that of the original interface, the server performs multi-channel reporting: First, a difference report containing detailed request identifiers, paths to the differing fields, and specific values ​​is written to the application server's local log file (such as interface_diff.log) for developers to conduct subsequent offline investigations and in-depth reviews; the difference report is then encapsulated into a file named reconcile_query_diff_count. The monitoring metrics data (with labels such as interface name and difference fields) are pushed to a remote monitoring system (such as Prometheus) for statistical analysis and display of abnormal trends in a visualization dashboard (such as Grafana). Alarm information is generated based on the difference report, such as "Reconciliation query interface gray-scale comparison anomaly: Transaction amount inconsistent, Transaction ID: 987654, New value: 1500.00, Old value: 1499.99," and this alarm information is pushed in real time to a pre-configured alarm receiving end (such as a WeChat group or DingTalk maintenance group), enabling relevant personnel to promptly learn about the data differences between the new and original interfaces, effectively ensuring the controllability of the gray-scale verification process and the stability of the production system.

[0072] In one embodiment, such as Figure 8 As shown, in step S102, which is the routing decision for interface requests based on the pre-configured grayscale strategy, the following steps are included: S121: Parse the value of the pre-configured grayscale determination field from the request header or request body of the interface request; S122: Match the value of the grayscale determination field with a predefined set of grayscale rules. The set of grayscale rules defines the mapping relationship between different combinations of field values ​​and the routing target. S123: Based on the matching results, generate a routing decision to route the interface request to the new version of the interface or the old version of the interface.

[0073] As an example, a grayscale strategy refers to a set of pre-configured strategies used to control the selection of interface requests among different interface implementations. A request header refers to the request component included in the interface request, carrying control information or metadata. A request body refers to the request component included in the interface request, carrying business parameter data. A grayscale decision field refers to a specific field (such as user identifier, merchant ID, device identifier, or custom business tag) extracted from the request header or request body of the interface request and used to participate in the grayscale strategy judgment. A grayscale rule set refers to a set of rules consisting of multiple grayscale rules used to define the mapping relationship between the values ​​or combinations of values ​​of the grayscale decision fields and a specific routing target (i.e., the new version of the interface or the old version of the interface). A routing decision refers to the specific result generated after analyzing and matching the interface request according to the grayscale strategy, indicating whether it should be routed to the new version of the interface or the old version of the interface.

[0074] In one possible implementation, after receiving an interface request, the server performs the following steps to generate a routing decision: First, it parses the values ​​of predefined grayscale determination fields from the request header or request body of the interface request; second, it matches one or more of the parsed field values ​​with a pre-defined set of grayscale rules. This matching process supports conditional judgments on precise values, numerical ranges, regular expressions, and logical combinations between multiple fields (such as AND and / or OR); finally, it generates a clear routing decision based on the matching results, determining whether to route the current interface request to the new version or the old version. This allows for flexible control over the routing of interface requests based on the information carried by the interface request itself, enabling the new and old versions of the interface to run in parallel within the same system. The new version of the interface is gradually introduced to carry business requests according to preset rules, thus achieving controllability in the interface switching process.

[0075] It should be noted that the set of canary rules can be maintained in a distributed configuration center (such as Nacos or Apollo). The server can load the set of canary rules through routing decision components (such as interceptors or gateway filters).

[0076] For example, in an online medical system's appointment registration interface upgrade scenario, the gray-scale rule set is defined as two rules: Rule 1, "When the value of the hospitalId field in the request body is 'XXXX01' and the value of the userAge field is greater than 60, route to the new version interface"; Rule 2, "When the value of the channel field in the request header is 'app' and the result of hashing and moduloing the userId field value is less than 10, route to the new version interface"; requests that do not match any of the above rules are routed to the old version interface by default. When the server receives an interface request, it parses hospitalId=XXXX01 and userAge=65 from the request body and channel=web from the request header. After the rule engine evaluates each rule, the request matches Rule 1, so the routing decision is "route to the new version interface". For another interface request with userAge=45, since it cannot match Rule 1 or Rule 2, the decision is "route to the old version interface". This enables precise gray-scale deployment for specific user groups (such as elderly patients in specific hospitals) or specific access channels. After monitoring and confirming that the new interface is running stably, operations and maintenance personnel can dynamically add or modify rules through the configuration center to gradually expand the gray-scale range, ultimately achieving a smooth and secure switchover of all traffic.

[0077] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0078] Secondly, a seamless interface switching device is provided for use on the server side, and this seamless interface switching device corresponds one-to-one with the seamless interface switching method in the above embodiments. For example... Figure 9 As shown, the seamless interface switching device includes a request receiving module 201, a routing decision module 202, a new interface calling module 203, and an old interface calling module 204. Detailed descriptions of each functional module are as follows: The request receiving module 201 is used to receive an interface request for the target service initiated by the caller, wherein the interface request conforms to the first interface specification; The routing decision module 202 is used to make routing decisions for the interface request based on a pre-configured grayscale strategy, so as to determine whether to route the interface request to an old version interface that conforms to the first interface specification or to a new version interface that conforms to the second interface specification; wherein, the new version interface is an updated interface of the old version interface; The new interface invocation module 203 is used to execute a new interface invocation process when the routing decision is to route to the new interface, including: obtaining input parameters of the interface request; converting the input parameters from a format conforming to the first interface specification to a format conforming to the second interface specification according to a preset parameter conversion rule, to obtain converted input parameters; using the converted input parameters to invoke the new interface, and obtaining the first original response data returned by the new interface; converting the first original response data from a format conforming to the second interface specification to a format conforming to the first interface specification according to the preset parameter conversion rule, to obtain first target response data; and returning the first target response data to the caller. The legacy interface invocation module 204 is used to execute a legacy interface invocation process when the routing decision is to route to the legacy interface, including: obtaining input parameters of the interface request; invoking the legacy interface using the input parameters, obtaining the second original response data returned by the legacy interface, and using the second original response data as the second target response data; and returning the second target response data to the caller.

[0079] In one embodiment, the new interface call module 203 is further configured to: Determine the first source data type to which the input parameter belongs and the second target data type required by the second interface specification; Generate a first query key based on the first source data type and the second target data type; Using the first query key, a query is performed in the converter mapping table maintained by the preset parameter converter factory to obtain the first parameter converter corresponding to the first query key. The converter mapping table stores the correspondence between different query keys and specific parameter converter instances. The first parameter converter is invoked to perform a conversion operation on the input parameters to obtain the converted input parameters.

[0080] In one embodiment, the new interface call module 203 is further configured to: Determine the second source data type to which the first original response data belongs and the first target data type required by the first interface specification; Generate a second query key based on the second source data type and the second target data type; Using the second query key, a query is performed in the converter mapping table maintained by the preset parameter converter factory to obtain the second parameter converter corresponding to the second query key; The second parameter converter is invoked to perform a conversion operation on the first original response data to obtain the first target response data.

[0081] In one embodiment, the preset parameter converter factory is constructed in the following manner: During the initialization process of the parameter converter factory, all target classes in the application that implement the predetermined parameter converter interface are scanned; Instantiate each of the target classes scanned to obtain the corresponding parameter converter instance; For each parameter converter instance, determine the source data type and target data type it supports; Using the combination of the source data type and the target data type as the index key, the parameter converter instance is registered in the converter mapping table of the parameter converter factory.

[0082] In one embodiment, such as Figure 10 As shown, the device also includes an asynchronous processing module 205; The asynchronous processing module 205 is used for: The comparison task is triggered asynchronously, and the execution of the comparison task is parallel to the process of returning the first target response data or the second target response data to the caller. In the comparison task, the first comparison data returned by the new version of the interface and the second comparison data returned by the old version of the interface are obtained for the same interface request. A consistency comparison is performed between the first comparison data and the second comparison data to obtain the comparison result; If the comparison results are inconsistent, a difference report will be generated.

[0083] In one embodiment, the asynchronous processing module 205 is further configured to: If the first comparison data and the second comparison data meet the consistency condition, then the comparison result is determined to be consistent; If the first comparison data and the second comparison data do not meet the consistency condition, then the comparison result is determined to be inconsistent; The consistency conditions include that the first comparison data and the second comparison data have the same object type, that fields with the same name in the first comparison data and the second comparison data are not empty, and that the names and values ​​of the attributes at each level contained in the first comparison data and the second comparison data are the same.

[0084] In one embodiment, the device is further configured to perform at least one of the following steps: Write the difference report to a local log file; The difference report is encapsulated into monitoring indicator data, and the monitoring indicator data is pushed to a pre-configured remote monitoring system; An alarm message is generated based on the difference report, and the alarm message is pushed to a pre-configured alarm receiver.

[0085] In one embodiment, the routing decision module 202 is further configured to: Parse the value of the pre-configured grayscale determination field from the request header or request body of the interface request; The value of the grayscale determination field is matched with a predefined set of grayscale rules, which defines the mapping relationship between different combinations of field values ​​and routing targets. Based on the matching results, a routing decision is generated to route the interface request to either the new version of the interface or the old version of the interface.

[0086] Specific limitations regarding the interface seamless switching device can be found in the limitations of the interface seamless switching method described above, and will not be repeated here. Each module in the aforementioned interface seamless switching device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of the processor in the electronic device, or stored in software in the memory of the electronic device, so that the processor can call and execute the corresponding operations of each module.

[0087] Thirdly, an electronic device is provided, the internal structure of which can be shown in the following diagram. Figure 11 As shown, the electronic device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores data required to implement a seamless interface switching method. The network interface communicates with external terminals via a network connection. The computer program is executed by the processor to implement a seamless interface switching method.

[0088] In one embodiment, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the interface seamless switching method described in the above embodiments, such as steps S101-S108 and their sub-steps, or... Figures 1 to 8 As shown, to avoid repetition, it will not be described again here. Alternatively, the processor executes a computer program to implement the functions of each module / unit in this embodiment of the seamless interface switching device, for example... Figure 9 and Figure 10 The functions of the interface seamless switching device shown are not described again here to avoid repetition.

[0089] Fourthly, a computer-readable storage medium is provided, on which a computer program is stored. When executed by a processor, the computer program implements the interface seamless switching method described in the above embodiments, such as steps S101-S108 and their sub-steps, or... Figures 1 to 8 As shown, to avoid repetition, it will not be described again here. Alternatively, when the computer program is executed by the processor, it implements the functions of each module / unit in this embodiment of the seamless interface switching device, for example... Figure 9 and Figure 10 The functions of the interface seamless switching device shown are not described again here to avoid repetition. Computer-readable storage media can be non-volatile or volatile.

[0090] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0091] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0092] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for seamless interface switching, characterized in that, Applied to the server side, including: Receive an interface request for the target service initiated by the caller, wherein the interface request conforms to the first interface specification; Based on a pre-configured gray-scale strategy, a routing decision is made for the interface request to determine whether to route the interface request to an old version interface that conforms to the first interface specification or to a new version interface that conforms to the second interface specification; wherein, the new version interface is an updated version of the old version interface; If the routing decision is to route to the new interface, then the new interface call process is executed, including: obtaining the input parameters of the interface request; converting the input parameters from a format conforming to the first interface specification to a format conforming to the second interface specification according to a preset parameter conversion rule, to obtain the converted input parameters; using the converted input parameters to call the new interface, and obtaining the first original response data returned by the new interface; converting the first original response data from a format conforming to the second interface specification to a format conforming to the first interface specification according to the preset parameter conversion rule, to obtain the first target response data; and returning the first target response data to the caller. If the routing decision is to route to the old version interface, then the old version interface call process is executed, including: obtaining the input parameters of the interface request; using the input parameters to call the old version interface, obtaining the second original response data returned by the old version interface, and using the second original response data as the second target response data; and returning the second target response data to the caller.

2. The method according to claim 1, characterized in that, The step of converting the input parameters from a format conforming to the first interface specification to a format conforming to the second interface specification according to a preset parameter conversion rule, to obtain the converted input parameters, includes: Determine the first source data type to which the input parameter belongs and the second target data type required by the second interface specification; Generate a first query key based on the first source data type and the second target data type; Using the first query key, a query is performed in a preset converter mapping table to obtain the first parameter converter corresponding to the first query key. The converter mapping table stores the correspondence between different query keys and specific parameter converter instances. The first parameter converter is invoked to perform a conversion operation on the input parameters to obtain the converted input parameters.

3. The method according to claim 1, characterized in that, The step of converting the first original response data from a format conforming to the second interface specification to a format conforming to the first interface specification, according to the preset parameter conversion rules, to obtain the first target response data, includes: Determine the second source data type to which the first original response data belongs and the first target data type required by the first interface specification; Generate a second query key based on the second source data type and the second target data type; Using the second query key, a query is performed in the preset converter mapping table to obtain the second parameter converter corresponding to the second query key; The second parameter converter is invoked to perform a conversion operation on the first original response data to obtain the first target response data.

4. The method according to claim 2 or 3, characterized in that, The preset converter mapping table is constructed in the following way: Scan all target classes in the application that implement the predefined parameter converter interface; Instantiate each of the target classes scanned to obtain the corresponding parameter converter instance; For each parameter converter instance, determine the source data type and target data type it supports; Using the combination of the source data type and the target data type as the index key, the parameter converter instance is registered in the converter mapping table of the parameter converter factory.

5. The interface seamless switching method according to claim 1, characterized in that, The method further includes: An asynchronous comparison task is triggered, which is executed when the first target response data or the second target response data is returned to the caller. In the comparison task, first comparison data and second comparison data for the same interface request are obtained. The first comparison data is the comparison data returned by the new version interface, and the second comparison data is the comparison data returned by the old version interface. A consistency comparison is performed between the first comparison data and the second comparison data to obtain the comparison result; If the comparison results are inconsistent, a difference report will be generated.

6. The interface seamless switching method according to claim 5, characterized in that, The step of performing a consistency comparison between the first comparison data and the second comparison data to obtain the comparison result includes: If the first comparison data and the second comparison data meet the consistency condition, then the comparison result is determined to be consistent; If the first comparison data and the second comparison data do not meet the consistency condition, then the comparison result is determined to be inconsistent; The consistency conditions include that the first comparison data and the second comparison data have the same object type, that fields with the same name in the first comparison data and the second comparison data are not empty, and that the names and values ​​of the attributes at each level contained in the first comparison data and the second comparison data are the same.

7. The interface seamless switching method according to claim 5, characterized in that, If the comparison results are inconsistent, after generating a difference report, the method further includes at least one of the following steps: Write the difference report to a local log file; The difference report is encapsulated into monitoring indicator data, and the monitoring indicator data is pushed to a pre-configured remote monitoring system; An alarm message is generated based on the difference report, and the alarm message is pushed to a pre-configured alarm receiver.

8. The method according to claim 1, characterized in that, The routing decision for the interface request based on the pre-configured grayscale strategy includes: Parse the value of the pre-configured grayscale determination field from the request header or request body of the interface request; The value of the grayscale determination field is matched with a predefined set of grayscale rules, which defines the mapping relationship between different combinations of field values ​​and routing targets. Based on the matching results, a routing decision is generated to route the interface request to either the new version of the interface or the old version of the interface.

9. A seamless interface switching device, characterized in that, Applied to the server side, including: The request receiving module is used to receive interface requests for the target service initiated by the caller, wherein the interface requests conform to the first interface specification; The routing decision module is used to make routing decisions for the interface request based on a pre-configured gray-scale strategy, so as to determine whether to route the interface request to an old version interface that conforms to the first interface specification or to a new version interface that conforms to the second interface specification; wherein, the new version interface is an updated interface of the old version interface; The new interface invocation module is used to execute a new interface invocation process when the routing decision is to route to the new interface, including: obtaining the input parameters of the interface request; converting the input parameters from a format conforming to the first interface specification to a format conforming to the second interface specification according to a preset parameter conversion rule, to obtain the converted input parameters; using the converted input parameters to invoke the new interface, and obtaining the first original response data returned by the new interface; converting the first original response data from a format conforming to the second interface specification to a format conforming to the first interface specification according to the preset parameter conversion rule, to obtain the first target response data; and returning the first target response data to the caller. The legacy interface invocation module is used to execute a legacy interface invocation process when the routing decision is to route to the legacy interface, including: obtaining the input parameters of the interface request; invoking the legacy interface using the input parameters, obtaining the second original response data returned by the legacy interface, and using the second original response data as the second target response data; and returning the second target response data to the caller.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the interface seamless switching method as described in any one of claims 1 to 8.

Images