Deployment mode switching method and device, equipment, medium and program product

Abstract

The invention provides a deployment mode switching method and device, equipment, a medium and a program product, relates to the technical field of computers, and can solve the problem of insufficient flexibility of an overall deployment architecture. According to the technical scheme, when a service application is started, metadata information of all services in a configuration file is analyzed, and all the services are registered to a service directory; receiving a service request of a client through the data operation service; judging a deployment mode identifier of the service application; if the mode is a distributed deployment mode, acquiring an address of a customer transaction service corresponding to the unique identifier of the target service from a service directory through a data operation service, and calling a remote customer transaction service based on the address; if the mode is the single deployment mode, corresponding service metadata information is acquired locally through the data operation service according to the unique identifier of the target service, and the business process of the local customer transaction service is executed based on the service metadata information. And a process for deploying and calling services.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of computer, and particularly relate to a deployment mode switching method, device, equipment, medium and program product. BACKGROUND

[0002] The investment and financial sales system is a key information technology platform for commercial banks to provide stock, fund, trust, bond and other investment and financial products and services to private and public customers. The performance, scalability and operation and maintenance cost of such a system are directly related to customer experience and bank operation efficiency. For different banks with a huge difference in customer size, how to flexibly and efficiently select a suitable system deployment architecture according to the actual customer data magnitude, so as to control resource consumption and operation complexity while ensuring service performance, has become a core problem to be solved.

[0003] At present, the commonly used solution is to select an architecture according to the customer magnitude: for large banks with a large number of customers, a distributed deployment is adopted, that is, customer data is stored in multiple databases, and multiple independent customer transaction service applications are deployed, while data operation services and service directory components are supplemented to realize data aggregation and operation through remote calls; for regional banks with a small number of customers, a monolithic deployment is adopted, that is, the functions of customer transaction services and data operation services are integrated into one application. However, this architecture strategy results in the need to maintain two different code versions for the same set of business functions. Specifically, in the distributed deployment, the data operation services access the customer transaction services through remote calls; while in the monolithic deployment, the remote call logic needs to be modified to direct local code calls. This code invasiveness caused by the difference in deployment architecture seriously violates the principle of "closed for modification, open for extension" in software engineering, significantly increasing the development and maintenance cost of the system. In addition, this solution also leads to a high dependence on complete distributed environments and service directory components in the testing phase, and when the testing resources are insufficient or the component functions are incomplete, the data operation services cannot be tested in the whole link, and the inherent network fluctuation risk of the distributed architecture also introduces additional system instability.

[0004] Therefore, the prior art has the following problem: unable to flexibly adapt to the distributed and monolithic two deployment architectures, resulting in insufficient flexibility of the overall architecture of the system. SUMMARY

[0005] Embodiments of the present application provide a deployment mode switching method, device, equipment, medium and program product, which can flexibly adapt to the distributed and monolithic two deployment architectures, thereby improving the flexibility of the overall architecture of the system.

[0006] To achieve the above object, the embodiments of the present application adopt the following technical solutions: In a first aspect, a deployment mode switching method is provided. The method comprises: parsing metadata information of all services in a configuration file when a service application is started, and registering all services to a service directory, the metadata of each service including a unique identifier of the service, calling parameter information of the service, and calling entry information of the service; receiving a service request of a client through a data operation service, the service request including a unique identifier of a target service and request parameters; judging a deployment mode identifier of the service application, the deployment mode identifier being used to indicate whether a distributed deployment mode or a monomer deployment mode is currently used; if the deployment mode identifier indicates the distributed deployment mode, obtaining an address of a client transaction service corresponding to the unique identifier of the target service from the service directory through the data operation service, and performing a call to the remote client transaction service based on the address; and if the deployment mode identifier indicates the monomer deployment mode, obtaining the service metadata information corresponding to the unique identifier of the target service locally according to the unique identifier of the target service through the data operation service, and performing a business process of the local client transaction service based on the service metadata information.

[0007] In the deployment mode switching method, the service metadata system including the calling entry information is registered when the service is started, and a deployment mode identifier is introduced. By judging the deployment mode identifier, the system can dynamically switch between the address-based remote call and the metadata-based local business process execution. This enables the same set of business code to adapt to the two different deployment architectures without any modification, solves the problem of maintaining multiple code branches caused by the architectural differences, reduces the development and maintenance costs of the system, and flexibly adapts to the two deployment architectures, thereby improving the flexibility of the overall architecture of the system.

[0008] In a possible implementation manner of the first aspect, the above-mentioned performing the call to the remote client transaction service based on the address comprises: sending a call request to the address through the data operation service, the call request including the unique identifier of the target service and the request parameters; after receiving the call request through the client transaction service, inputting the request parameters according to the calling entry information in the service metadata corresponding to the unique identifier of the target service to perform the business logic processing, and returning the execution result to the data operation service; and performing the remote call process on the multiple client transaction services through the data operation service, after receiving the execution results returned by all the client transaction services, performing the summary processing on all the execution results, and returning the final result after the summary to the client.

[0009] Therefore, by defining the complete steps of executing remote invocation processes on multiple customer transaction services in a distributed manner and aggregating all execution results, the implementation scheme accurately solves the problem of data operation services needing to collect and aggregate data from multiple data shards in the investment and financial management and other split database and table business scenarios, realizes the function of distributed scheduling, and ensures the integrity of data and the correctness of business logic through aggregation processing.

[0010] In a possible implementation of the first aspect, the customer transaction service comprises a service logic mapping table, the service logic mapping table associating unique identifiers of services with business logic components; and the transmitting of the request parameters according to the invocation entry information in the service metadata corresponding to the unique identifier of the target service to execute the business logic processing comprises: obtaining, based on the invocation entry information, the target business logic component corresponding to the unique identifier of the target service from the service logic mapping table of the customer transaction service; and invoking a method of the target business logic component and transmitting the request parameters to execute the business logic processing.

[0011] Therefore, by introducing the service logic mapping table, the execution mode of the business logic processing is optimized. By pre-associating the unique identifiers of the services with the business logic components, the ready business logic components can be directly obtained and invoked through one efficient mapping table query without using dynamic mechanisms with high performance overhead such as reflection when processing the request. This manner significantly reduces the response time of each service invocation, reduces the processing overhead of the system, and effectively improves the overall throughput and performance of the system.

[0012] In a possible implementation of the first aspect, the executing of the business flow of the local customer transaction service based on the service metadata information comprises: transmitting, by the data operation service, the request parameters in the service request according to the invocation entry information in the service metadata information to execute the business logic of the customer transaction service locally to generate a business execution result; and returning, by the data operation service, the business execution result to the client.

[0013] Therefore, in the monolithic deployment mode, the data operation service executes the business logic of the customer transaction service locally to generate a result, eliminating the network remote invocation link in the distributed deployment, thereby avoiding the risks of invocation failure and timeout caused by network fluctuations, delays or interruptions, greatly improving the stability and response speed of the system, and saving network bandwidth resources.

[0014] In a possible implementation of the first aspect, the method further includes: when the number of servers of the test environment is less than the minimum number of nodes required by the distributed architecture, configuring the deployment mode identifier to indicate the monolithic deployment mode; and executing, by the data operation service, the business logic of the customer transaction service within a process of the data operation service in the monolithic deployment mode.

[0015] In this way, when the test resources are limited (the number of servers is insufficient), the deployment mode identifier is configured to the monolithic deployment mode, so that the data operation service can complete the full-link logic execution within a single process, and the development and test personnel can perform the integration test of the business function in advance and continuously under the condition of limited resources, thereby greatly improving the flexibility and fault tolerance of the development and test process.

[0016] In a possible implementation of the first aspect, the method further includes: when the service directory is in an unstarted or unavailable state, configuring the deployment mode identifier to indicate the monolithic deployment mode, so as to perform the function verification of the data operation service by locally executing the business logic of the customer transaction service.

[0017] In this way, when the service directory is unavailable, the system can bypass the faulty component to perform the function verification by switching to the monolithic deployment mode, so as to ensure that the verification and test of the core business function can continue to be performed in parallel with the repair of the distributed environment when part of the infrastructure fails, thereby effectively shortening the development and test blocking time caused by the middleware dependency problem.

[0018] In a possible implementation of the first aspect, for a system with a customer data volume reaching a preset threshold, the distributed deployment mode is adopted; and for a system with a customer data volume not reaching the preset threshold, the monolithic deployment mode is adopted, and the data operation service and the customer transaction service are combined and deployed on a single server.

[0019] In this way, by associating the selection of the deployment mode with the customer data volume, the distributed mode is adopted when the data volume is large to ensure the performance, and when the data volume is small, the data operation service and the customer transaction service can be combined and deployed, and after the combination and deployment, the dependence on the service directory can be eliminated, and the risk of remote call failure, timeout and the like caused by network fluctuation can be eliminated.

[0020] In a possible implementation of the first aspect, the calling entry information is determined by an interface name, a method name and a request parameter form.

[0021] In this way, the calling entry information is defined, so as to ensure the calling relationship between the data operation service and the service provider (the local or remote customer transaction service), thereby ensuring the accuracy and reliability of the entire dynamic routing architecture.

[0022] Secondly, a deployment mode switching device is provided, comprising: a processing module, configured to parse the metadata information of all services in the configuration file and register all services to the service directory when the service application starts, wherein the metadata of each service includes the service's unique identifier, service call parameter information, and service call entry information; a receiving module, configured to receive service requests from clients through a data operation service, wherein the service request contains the unique identifier of the target service and request parameters; the processing module is further configured to determine the deployment mode identifier of the service application, wherein the deployment mode identifier indicates whether the current deployment mode is distributed or monolithic; the processing module is further configured to, if the deployment mode identifier indicates distributed deployment mode, obtain the address of the customer transaction service corresponding to the unique identifier of the target service from the service directory through the data operation service, and execute a call to the remote customer transaction service based on the address; the processing module is further configured to, if the deployment mode identifier indicates monolithic deployment mode, obtain the corresponding service metadata information locally based on the unique identifier of the target service through the data operation service, and execute the business process of the local customer transaction service based on the service metadata information.

[0023] It should be noted that the beneficial effects of the deployment mode switching device can be found in the relevant description of the beneficial effects of the deployment mode switching method mentioned above, and will not be repeated here to avoid repetition.

[0024] Thirdly, an electronic device is provided, the method comprising: a memory and at least one processor. The memory is communicatively connected to the processor. The memory is used to store computer program code, the computer program code including computer instructions. When the processor executes the computer instructions, it causes the electronic device to perform the method as described in the first aspect and any possible implementation thereof.

[0025] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer instructions. When executed by a processor, these computer instructions are used to implement the method described in the first aspect and any possible implementation thereof.

[0026] Fifthly, embodiments of this application provide a computer program product that, when run on a computer or executed by a computer's processor, implements the method described in the first aspect and any possible design thereof. The computer may be the electronic device described in the third aspect and any possible implementation thereof.

[0027] It is understood that the beneficial effects achieved by the apparatus of the second aspect, the electronic device of the third aspect, the computer-readable storage medium of the fourth aspect, and the computer program product of the fifth aspect provided above can be referred to as the beneficial effects of the first aspect and any possible implementation thereof, which will not be repeated here. Attached Figure Description

[0028] Figure 1 A flowchart illustrating a deployment mode switching method provided in an embodiment of this application; Figure 2 A flowchart illustrating another deployment mode switching method provided in this application embodiment; Figure 3 A flowchart illustrating another deployment mode switching method provided in this application embodiment; Figure 4 A flowchart illustrating a remote service call during distributed deployment, provided as an embodiment of this application; Figure 5 A flowchart illustrating a service invocation during a monolithic deployment is provided as an embodiment of this application. Figure 6 This is a schematic diagram of a deployment mode switching device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0029] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0030] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0031] The technical solutions provided in this application, including the collection, storage, use, processing, transmission, provision, and disclosure of financial data or user data, comply with relevant laws and regulations and do not violate public order and good morals.

[0032] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0033] The deployment mode switching device and the deployment mode switching method applicable to the deployment mode switching device provided in this application will be explained and described below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0034] This application's embodiments can be applied to scenarios such as investment and wealth management sales systems that require flexible adjustments to the system architecture based on the volume of customer data. In this system, the data operation service is responsible for receiving client requests and processing data statistics and aggregation, while the customer transaction service provides the specific investment and wealth management product transaction logic.

[0035] An investment and wealth management sales system is a system that provides investment services (such as stocks, funds, wealth management products, trusts, bonds, etc.) to a bank's individual and corporate clients. Banks with different systems and geographical limitations have vastly different customer volumes. For large banks, the sheer number of customers places higher demands on the system's data processing and capacity. A common approach is to split customer-related data according to the customer's category and persist it to different databases—a database sharding approach. Then, corresponding service applications (referred to as customer transaction services) are deployed based on the number of databases. Each service application provides the same functionality but caters to different customers. This improves the system's capacity, ensures a good customer service experience, and avoids the risk of a single application failure affecting all customers. Furthermore, for banks with different customer volumes, the number of database shards for customer data can be flexibly adjusted, allowing for adjustments to the number of deployed applications, selecting appropriate server resources and reducing costs while maintaining a good customer experience.

[0036] In addition to the aforementioned customer transaction services, in order to provide external services such as statistical analysis of data in each sub-database, unified modification of data in various customer transaction services, and location of specific customers in a particular customer transaction service, it is also necessary to deploy an application (referred to as a data operation service) that can receive requests for the above functions initiated by clients and process data statistics. Depending on the deployment of the customer transaction services and the support of the service catalog, the relevant functions of the customer transaction services can be remotely invoked over the network to process customer data, and the results can be analyzed, summarized, and returned to the client.

[0037] In the aforementioned distributed deployment method, due to limitations in architecture and related specifications, when it is necessary to collect certain data of customers across all databases, the data operation service needs to make multiple remote calls to obtain the relevant customer data from all databases and perform aggregate processing before it can be displayed.

[0038] For regional banks with a very small number of customers, although the data volume is small, it is still necessary to deploy a customer transaction service and a data operation service, as well as an accompanying service catalog component to support remote calls. However, based on the data volume assessment, merging the customer data service and data operation service into one application can also meet the performance requirements. Therefore, the above-mentioned distributed deployment method wastes resources when the customer data volume is small. At the same time, the increase in services and components will also make application operation and maintenance more complex.

[0039] To achieve the goal of flexibly selecting server resources for application deployment under different customer volumes, the existing solution is implemented as follows: When dealing with a large number of customers, multiple customer data services, data operation services, and remote call support components are deployed. When the amount of customer data is small, the function of remotely calling customer data services within the data operation application is modified to directly call the corresponding code in the customer data service code, and then the application is deployed as a monolith. This code modification approach results in two versions of the same system's code due to different deployment methods, which does not conform to the programming principle of "closed to modification, open to extension," and significantly increases the development and maintenance costs of the code.

[0040] The existing solution has the following problems: (1) Since the differences in deployment methods cannot be shielded from the intrusion of the application code, the implementation of the same data operation service function is different. Different versions need to be maintained for cases with a large number of customers and cases with a small number of customers, which increases the development cost of the code. At the same time, during the application deployment stage, different versions need to be selected for deployment for services with different numbers of customers. It is difficult to make the application adaptable to different deployment architectures by modifying the configuration or other methods, which increases the service cost of the system.

[0041] (2) When the customer transaction service is deployed in a distributed manner, insufficient test environment resources or incomplete support functions of remote call service components may result in the application deployment not meeting the target deployment architecture or the remote call connection not being fully executed, making it impossible to fully test the relevant functions of the data operation service; it is necessary to complete the deployment of the target architecture and have complete support of the remote call component in order to conduct comprehensive testing. During distributed deployment, remote calls are required, and remote calls may fail due to network issues.

[0042] Thus, existing technologies cannot flexibly adapt to both distributed and monolithic deployment architectures, resulting in insufficient flexibility in the overall system architecture.

[0043] The technical solution provided in this application, by introducing a unified service metadata abstraction and a configurable deployment method identifier, achieves a single code-adaptive distributed and monolithic deployment architecture. During the development phase, it shields the code version from intrusive changes caused by application deployment architectures for different numbers of customers. Only one application code version needs to be maintained for different deployment architectures, significantly reducing development complexity and maintenance costs. During the deployment phase, it achieves the flexible capability of quickly switching deployment modes without modifying code, solely through configuration changes, greatly improving deployment efficiency and system elasticity. During the testing phase, this solution provides effective fault-tolerant testing methods for incomplete dependencies in a distributed environment, ensuring the continuity and reliability of end-to-end functional testing by switching to monolithic mode. Through the dynamic configurability of the architecture, the system can quickly switch between distributed and monolithic architectures according to actual business needs, completely changing the rigid pattern of the original fixed architecture and achieving a significant improvement in overall architectural flexibility.

[0044] This application provides a deployment mode switching method, which can be applied to a deployment mode switching device or an electronic device. The following illustration uses a deployment mode switching device executing the deployment mode switching method as an example. Figure 1 As shown, the deployment method switching method may include the following steps 201 to 205.

[0045] Step 201: When the service application starts, the deployment method switching device parses the metadata information of all services in the configuration file and registers all services to the service directory.

[0046] In some embodiments of this application, the metadata of each service includes a unique identifier for the service, service call parameter information, and service call entry information.

[0047] In some embodiments of this application, the aforementioned service application refers to a software program unit that can be independently deployed and run within the system. In this document, it refers to a data operation service application and a customer transaction service application. The data operation service application is responsible for receiving client requests and aggregating data, while the customer transaction service application provides specific investment and financial management business logic (such as transactions and queries).

[0048] In some embodiments of this application, the configuration file described above is a static file used to store system configuration information. This file is loaded into memory and parsed when the application starts. The configuration file predefines and stores metadata information for all available services in the system.

[0049] In some embodiments of this application, the metadata information of the above-mentioned service is used as structured data to describe the service's own information, including at least: A service’s unique identifier: a string or code that uniquely identifies a specific service function across the entire system. It serves as the service’s identity and is a key index for service discovery and routing. Service call parameter information: Defines the specifications for the structure, name, type, and format of the parameters that the requester needs to provide when calling the service; Service invocation entry point information: This specifies the precise execution location of the service's specific business logic within the program code. This information can be determined by the interface name, method name, and request parameter format. This definition maps the abstract service concept to a concrete, executable code entity.

[0050] In some embodiments of this application, the aforementioned service directory serves as a service registry center, where all services register at startup, informing the system of the service's unique identifier, network address, etc.

[0051] Step 202: The deployment mode switching device receives service requests from clients through the data operation service.

[0052] In some embodiments of this application, the service request includes a unique identifier of the target service and request parameters.

[0053] In some embodiments of this application, the client (such as a front-end webpage or APP) initiates a request to the system to execute a specific business capability. This request carries two key pieces of information: A unique identifier for the target service: indicating the service to be invoked; Request parameters: These provide the specific data required to execute the service; in other words, they are the set of input data that a client needs to provide to the service in order to request a specific service function. These parameters are the input conditions and data carriers necessary for the service to execute its business logic.

[0054] Step 203: The deployment method switching device determines the deployment method identifier of the service application.

[0055] In some embodiments of this application, the above deployment method identifier is used to indicate whether the current deployment mode is a distributed deployment mode or a monolithic deployment mode.

[0056] In some embodiments of this application, the deployment mode switching device dynamically switches to the corresponding service call and execution path according to the value of the deployment mode identifier. If the deployment mode identifier indicates a distributed deployment mode, it switches to the distributed call path; if the deployment mode identifier indicates a monolithic deployment mode, it switches to the local execution path.

[0057] In some embodiments of this application, the aforementioned deployment method identifier typically exists in the form of environment variables, command-line parameters, or configuration items in a central configuration center. The value of this identifier can be predefined.

[0058] In some embodiments of this application, the aforementioned distributed deployment mode refers to an architecture that splits different service components of the system (such as data operation services and customer transaction services) and deploys them independently to multiple different processes or servers. In this mode: Component communication: Services communicate with each other via remote calls over the network.

[0059] Data storage: Data is typically sharded and partitioned according to business rules (such as customer dimensions).

[0060] Resources and Relationships: A service catalog component needs to be deployed to support service discovery, and the services have a loosely coupled network collaboration relationship.

[0061] In some embodiments of this application, the monolithic deployment mode described above refers to an architecture that merges, packages, and deploys all service components of the system (such as data operation services and customer transaction services) within the same application process. In this mode: Component communication: Services communicate with each other through native method calls at the programming language level.

[0062] Data storage: Data is typically stored centrally in a single database.

[0063] Resources and Relationships: No separate service catalog components are required; all services are tightly coupled at the code level and collaborate.

[0064] In this way, when the deployment mode switching device needs to process a request, it will query the value of this identifier and trigger two sets of runtime logic that are completely different in terms of communication mechanism, resource dependency and execution path. Through a lightweight configuration judgment, the burden of maintaining two sets of code branches in the traditional solution is replaced. This makes the system architecture no longer fixed, but a dynamically configurable and instantaneously switchable attribute.

[0065] Step 204: If the deployment mode identifier indicates a distributed deployment mode, the deployment mode switching device obtains the address of the customer transaction service corresponding to the unique identifier of the target service from the service directory through the data operation service, and executes a call to the remote customer transaction service based on the address.

[0066] In some embodiments of this application, the deployment method switching device can obtain addresses from the service directory: In a distributed architecture, the same service (specified by a unique identifier of the target service) may have multiple instances deployed on different network nodes. The data operation service, as the caller, does not hardcode the addresses of these instances, but instead initiates a query to the service directory (a centralized registry). The service directory returns the network addresses (e.g., IP addresses and ports, or internal domain names) of one or more available client transaction service instances that can provide the target service.

[0067] In some embodiments of this application, the deployment mode switching device executes calls to remote customer transaction services based on addresses: after obtaining the specific network address, the data operation service initiates a remote procedure call. This process includes: Serialization: Converts a call request (containing the target service identifier and request parameters) from an object in memory into a byte stream that can be transmitted over a network; Network transmission: Sending serialized data to the target address using a specific communication protocol; Deserialization and Execution: After receiving the request, the remote client transaction service instance performs the reverse operation (deserialization), and then locates and executes the actual business logic; Result return: The execution result is then transmitted back to the data operation service via the network.

[0068] In some embodiments of this application, combined with Figure 1 ,like Figure 2 As shown, step 204 can be implemented through steps 204a to 204d as described below.

[0069] Step 204a: If the deployment mode identifier indicates a distributed deployment mode, the deployment mode switching device obtains the address of the customer transaction service corresponding to the unique identifier of the target service from the service catalog through the data operation service.

[0070] In some embodiments of this application, the data operation service acts as a client, initiating a query to the service directory. The key to this query is the unique identifier of the target service, which, as a logical name, masks the physical location of the service instance. The service directory returns a list of one or more currently available, registered physical network endpoints that can provide the logical service.

[0071] Step 204b: The deployment mode switching device sends a call request to the address through the data operation service.

[0072] In some embodiments of this application, the above-mentioned invocation request includes a unique identifier of the target service and request parameters.

[0073] In some embodiments of this application, the data operation service sends a call request to a remote client transaction service instance via a network (such as an IP address) based on the obtained address. The request includes: A unique identifier for the target service: Even within a service instance, multiple service functions may be deployed. This identifier is used for secondary routing within the instance, ensuring that requests are received by the correct internal handler; Request parameters: The actual data payload required for the execution of business logic.

[0074] This request is typically encapsulated into a specific Remote Procedure Call Protocol (RPC) and serialized.

[0075] Step 204c: After receiving the call request through the customer transaction service, the deployment mode switching device passes in the request parameters to execute business logic processing based on the call entry information in the service metadata corresponding to the unique identifier of the target service, and returns the execution result to the data operation service.

[0076] In some embodiments of this application, after receiving a request, the customer transaction service instance internally implements efficient routing through a service logic mapping table. This mapping table is essentially a locally cached routing table that directly maps the unique identifier of the service to the instantiated business logic component in memory.

[0077] In some embodiments of this application, after a client transaction service instance receives a request, its internal process is as follows: Request parsing: Deserialize network data to recover the target service identifier and request parameters; Logical location: Based on the unique identifier of the target service, find the service metadata registered locally and obtain its call entry information (such as interface and method name). Logic execution: Based on the call entry information, the specific business logic component is located through reflection or a better service logic mapping table, the request parameters are passed in and its method is called; Result return: The execution result of the business logic is serialized and returned to the caller (data operation service) over the network.

[0078] In some embodiments of this application, the above-mentioned call entry information is determined by the interface name, method name, and request parameters.

[0079] In some embodiments of this application, the specific components of the call entry information precisely map an abstract service call to a specific location in the program code. These three elements together constitute a unique, locatable, and executable coordinate at the programming language level.

[0080] In some embodiments of this application, the interface name refers to the abstract type name that defines a set of related method specifications in object-oriented programming. It determines the contract scope to which the service belongs.

[0081] In some embodiments of this application, the method name refers to the specific operation name defined within the aforementioned interface for performing a specific business function. It determines the specific capabilities provided by the service.

[0082] In some embodiments of this application, the request parameter format refers to the structure information of the parameter list that needs to be passed in when calling the above method, including the type, number, and order of the parameters.

[0083] When these three elements are combined, they uniquely locate an execution entry point in the code. The system (or framework) can then use reflection or a service logic mapping table to find the specific method of the interface at runtime and execute the business logic by passing in the actual request parameters.

[0084] In this way, a precise mapping from business logic (service) to code implementation (method) is achieved, enabling the system to dynamically locate and execute code without hard coding, ensuring that service call requests can be unambiguously routed to the correct code segment.

[0085] In some embodiments of this application, the aforementioned customer transaction service includes a service logic mapping table that associates a service's unique identifier with a business logic component.

[0086] In some embodiments of this application, the aforementioned service logic mapping table is a core routing query table maintained in memory by the customer transaction service instance. Essentially, it is a key-value pair data structure, where the key is a unique identifier for the service and the value is an instantiated and ready business logic component object corresponding to that identifier.

[0087] In some embodiments of this application, the aforementioned service logic mapping table is initialized when the service starts, establishing a fast query channel from logical service identifiers to physical code objects. When a request arrives, there is no need to slowly search for the method using reflection based on the interface name and method name in the call entry information; instead, a single efficient hash lookup using the unique identifier can directly obtain the business object that handles the request.

[0088] In some embodiments of this application, the step 204c above, "passing in request parameters to perform business logic processing based on the call entry information in the service metadata corresponding to the unique identifier of the target service", can be specifically implemented through the following steps 204c1 and 204c2.

[0089] Step 204c1: The deployment method switching device obtains the target business logic component corresponding to the unique identifier of the target service from the service logic mapping table of the customer transaction service based on the call entry information.

[0090] In some embodiments of this application, the target business logic component refers to a software module object that has been instantiated and loaded into memory within the customer transaction service, specifically responsible for handling specific business functions. It is the final code carrier that carries and executes the specific logic corresponding to the "target service".

[0091] In some embodiments of this application, business logic refers to code that implements business rules and operations in a specific domain. Examples include "calculating the returns of financial products" and "querying customer holdings details." A component refers to a software unit in object-oriented programming or modern application frameworks that can be managed by the system and referenced by other parts. It is typically an instance of a class.

[0092] It's understandable that when a request looks up a service in the service logic mapping table using the service's unique identifier, it finds the specific component object. This component is the actual executor of the entry point information in the service metadata at runtime.

[0093] In some embodiments of this application, after receiving a request and resolving the unique identifier of the target service, the client transaction service uses it as a key to directly query the local service logic mapping table. The query result is an object instance (i.e., the target business logic component) that already exists in memory and is immediately available, rather than a class that needs to be additionally instantiated or a method that needs to be found using reflection.

[0094] Step 204c2: The deployment mode switching device calls the method of the target business logic component and passes in the request parameters to execute the business logic processing.

[0095] In some embodiments of this application, after obtaining the target business logic component, the deployment mode switching device can directly call its corresponding method (this method is predetermined and corresponds to the call entry information) and pass in the request parameters.

[0096] Thus, by introducing a service logic mapping table, the execution method of business logic processing is optimized. By pre-associating the unique identifier of a service with the business logic component, when processing a request, there's no need to use performance-intensive dynamic mechanisms like reflection. Instead, a single efficient mapping table lookup is sufficient to directly retrieve and invoke the ready-to-use business logic component. This approach significantly reduces the response time for each service call, lowers system processing overhead, and effectively improves the overall throughput and performance of the system.

[0097] Step 204d: The deployment mode switching device performs remote call processes to multiple customer transaction services in a loop through the data operation service. After receiving the execution results returned by all customer transaction services, it summarizes and processes all execution results and returns the summarized final result to the client.

[0098] In some embodiments of this application, after all remote calls return, the data manipulation service aggregates these results into a complete view according to business rules (such as summation, sorting, and merging). In investment and wealth management systems, customer data is typically partitioned into databases and tables based on customer dimensions, with different customer transaction service instances managing different data shards. Therefore, a global data query request (such as "statistics all customer assets") requires initiating calls to all relevant customer transaction service instances (i.e., multiple addresses obtained from above). The data manipulation service needs to: send the same call request to all target instances in a loop or concurrently; wait for and collect partial result sets returned by all instances; and perform summary calculations on these partial results according to business rules (such as summation, averaging, merging lists, etc.) to generate a global, unified view.

[0099] This resolves the conflict between the dispersed nature of data in distributed systems and the global nature of business requirements. It enables upper-layer applications to operate on dispersed data from a unified perspective, which is crucial for the distributed architecture to support complex business queries. It achieves highly available distributed processing capabilities for large-scale data scenarios, ensuring system performance and fault tolerance.

[0100] Step 205: If the deployment method identifier indicates a monolithic deployment mode, the deployment method switching device obtains the corresponding service metadata information locally based on the unique identifier of the target service through the data operation service, and executes the business process of local customer transaction service based on the service metadata information.

[0101] In some embodiments of this application, during monolithic deployment, the code for the data operation service and the customer transaction service is merged into the same application process.

[0102] In some embodiments of this application, during the compilation and packaging stages, the data operation service code and the customer transaction service code, which were originally two independent projects or modules in a distributed architecture, are jointly compiled, linked, and packaged into the same deployment unit (such as a package or an executable file). At runtime, they run in the same memory space of the same operating system process.

[0103] In some embodiments of this application, since all code belongs to the same process, the service metadata information that is parsed and registered exists in local memory for the data operation service. Therefore, the data operation service does not need to initiate any network requests (such as querying the service directory) and can directly obtain the target service metadata by accessing the data structure in memory through local method calls.

[0104] In some embodiments of this application, the data operation service does not construct a network request based on the call entry information in the obtained metadata, but instead directly executes the customer transaction service business code located in the same process through a programming language-level native method call.

[0105] In some embodiments of this application, combined with Figure 1 ,like Figure 3 As shown, step 205 can be implemented through steps 205a to 205c as described below.

[0106] Step 205a: If the deployment method identifier indicates a monolithic deployment mode, the deployment method switching device obtains the corresponding service metadata information locally based on the unique identifier of the target service through the data operation service.

[0107] In some embodiments of this application, the data operation service no longer needs to query the external service directory because the metadata of all services has been loaded into local memory when the service application starts.

[0108] In some embodiments of this application, since all service code is merged into the same process, the metadata of all services is loaded into the same memory space during system initialization. The data operation service directly queries this local metadata registry in memory using the unique identifier of the target service as the key.

[0109] Step 205b: The deployment mode switching device uses the data operation service to pass in the request parameters in the service request based on the call entry information in the service metadata information, so as to execute the customer transaction service business logic locally and generate the business execution result.

[0110] In some embodiments of this application, the data operation service executes business logic directly through local method calls based on the call entry information in the metadata, and passes the request parameters in the service request as the actual input parameters of the method, calling the customer transaction service code located in the same process. This eliminates the processing of the entire network stack (serialization, network transmission, deserialization).

[0111] This eliminates the risks of network latency, jitter, and failures, resulting in faster request processing and a very high success rate. At the same time, since there is no need to deploy and maintain distributed components such as service catalogs, the system architecture is greatly simplified, reducing operational costs and resource consumption.

[0112] Step 205c: The deployment mode switching device returns the business execution results to the client through the data operation service.

[0113] In some embodiments of this application, the data operation service encapsulates the generated business execution results (already existing in its local memory) according to a protocol agreed upon with the client, and returns them to the client via the network. The client is completely unaware of whether the server's internal processes involve complex distributed calls or efficient monolithic calls.

[0114] In this way, in monolithic deployment mode, the data operation service executes the customer transaction service business logic and generates results locally, eliminating the remote network call link in distributed deployment. This avoids the risk of call failure and timeout caused by network fluctuations, delays or interruptions, greatly improving the stability and response speed of the system, while saving network bandwidth resources.

[0115] In the deployment mode switching method of this application embodiment, a service metadata system containing call entry information, registered when the service starts, is introduced. Combined with a determinable deployment mode identifier, the deployment mode switching device determines this identifier, enabling the system to dynamically switch between two paths: address-based remote calls and metadata-based local business process execution. This allows the same set of business code to adapt to both distributed and monolithic deployment architectures without any modification, solving the problem of maintaining multiple code branches due to architectural differences. This reduces system development and maintenance costs and flexibly adapts to both distributed and monolithic deployment architectures, improving the overall system architecture flexibility.

[0116] In some embodiments of this application, the above deployment mode switching method further includes the following steps 301 and 302.

[0117] Step 301: When the number of servers in the test environment is less than the minimum number of nodes required for the distributed architecture, the deployment mode switching device will configure the deployment mode identifier to indicate monolithic deployment mode.

[0118] In some embodiments of this application, complete distributed architecture testing requires the deployment of multiple service instances (such as at least one data operation service and multiple customer transaction service instances) and middleware such as service catalogs. This requires the test environment to have multiple server or container resources. In actual development, test resources often cannot meet this requirement, meaning there are situations where the number of servers in the test environment is less than the minimum number of nodes required for a distributed architecture. When insufficient environment resources are detected, the deployment mode switching device can switch the deployment mode identifier from "distributed" to "monolithic".

[0119] Step 302: The deployment mode switching device executes the business logic of the customer transaction service within the process of the data operation service in the monolithic deployment mode through the data operation service.

[0120] In some embodiments of this application, when running in monolithic deployment mode, the data operation service's call to the customer transaction service is completed through local method calls. This means that all business logic that needs to be remotely called over the network in a distributed environment is executed sequentially within the same process during testing. This bypasses testing of distributed components such as service discovery, network communication, and serialization, but fully covers all code execution paths from the data operation service entry point to the customer transaction service business logic.

[0121] In this way, even if a component in the distributed environment (such as the service directory) is unstable or under debugging, it will not block business function testing based on the monolithic model, ensuring the continuity of testing.

[0122] In some embodiments of this application, the above deployment method switching method further includes the following step 303.

[0123] Step 303: When the service catalog is in an unstarted or unavailable state, the deployment mode switching device will configure the deployment mode identifier to indicate the monolithic deployment mode, so as to perform functional verification of the data operation service by executing the business logic of the customer transaction service locally.

[0124] In some embodiments of this application, when a service instance fails, the service catalog can mark it as unhealthy, thereby preventing the data operation service from sending requests to the failed instance and ensuring the availability of the overall service by calling other healthy instances.

[0125] In some embodiments of this application, the service directory is responsible for service registration and discovery in the distributed architecture. When it is not started (e.g., deployment failed, not started) or unavailable (e.g., network partition, process crash, excessive load), the entire service discovery mechanism fails. The data operation service will be unable to obtain the address of any customer transaction service, causing all distributed calls to fail and the system to malfunction. When the unavailability of this critical dependency, the service directory, is detected, the deployment mode switching device actively abandons the distributed path and falls back to the monolithic architecture path that does not depend on the service directory.

[0126] In this way, when the distributed infrastructure fails in part, the verifiability and availability of the core business logic are preserved by degrading to monolithic mode. This enables the system to partially recover from the failure of distributed components and prevents it from completely losing its functionality due to a single point of failure of a centralized component, thereby significantly improving the robustness of the development and testing process.

[0127] In some embodiments of this application, a distributed deployment mode is adopted for systems where the amount of customer data reaches a preset threshold.

[0128] In some embodiments of this application, the aforementioned preset threshold is a quantitative critical point set based on business performance indicators (such as the number of concurrent users, the number of records in the data table, etc.) and hardware capacity planning.

[0129] In some embodiments of this application, a distributed architecture can be adopted when the amount of customer data and concurrent requests exceed the processing capacity limit of a single machine. By sharding customer data into databases and tables and deploying multiple customer transaction service instances, the load can be distributed across multiple computing nodes. The data operation service supports high-concurrency access and massive data processing by making parallel remote calls to these instances and aggregating them.

[0130] In some embodiments of this application, for systems where the amount of customer data has not reached a preset threshold, a monolithic deployment mode is adopted, and the data operation service and the customer transaction service are deployed together on a single server.

[0131] In some embodiments of this application, for small and medium-sized customers, their customer data volume and access pressure are within the processing capacity of a single server. In this case, a distributed architecture would introduce certain complexities (network overhead, operation and maintenance costs). Therefore, a monolithic deployment model is adopted, and the data operation service and customer transaction service are deployed together on a single server, eliminating all remote call overhead and points of failure, simplifying the deployment structure, maximizing the utilization of the computing resources of a single server, and avoiding resource redundancy and management overhead caused by multiple nodes in a distributed architecture.

[0132] The following describes the entire implementation process of a deployment mode switching method provided in an embodiment of this application.

[0133] In this embodiment, by storing and configuring service metadata information in all applications, and locating specific service processing logic before processing the data, configuration data that identifies whether the deployment method is distributed or monolithic is added.

[0134] In this solution, whether it is a data operation application or a customer transaction application, when the application starts, it will parse the metadata information of all services in the configuration file, and then register all services to the service directory. The metadata information of a single service includes the unique identifier of the service, the format of the service request parameters, the type of the service, and the entry point of the service in the application code (determined by the interface + method name + request parameters). The service entry point can be obtained through the unique identifier of the service, and then the service logic can be processed according to the parameters passed in by the service interface and method.

[0135] When deployed in a distributed manner, the client invokes the data operation service with the following steps: Step 1: The data operation service receives the client's request, identifies the call information, parses the call parameters, and executes the data operation logic; Step 2: Determine the application's deployment method identifier. If the identifier is distributed deployment, execute the following logic; Step 3: The data operation service retrieves the address of the customer transaction service from the service catalog; Step 4: After successfully obtaining the address, send a request to that address; otherwise, the client's request processing will fail, and a failure result will be returned directly to the client. Step 5: The transaction service obtains the service metadata information corresponding to the request based on the call information; Step 6: Obtain the entry point for the processing logic based on the metadata information; Step 7: Pass in the request parameters and perform the corresponding logical processing; Step 8: Return the processing result to the calling end; Step 9: When multiple customer transaction service applications are deployed, repeat steps 1-6 above to call each customer transaction service application. Step 10: After receiving the call results from all clients, the data operation service summarizes and processes the call results. Step 11: Return the summarized call results to the client; Step 12: The client displays the results.

[0136] When the customer's data volume is small and distributed deployment is not required, a monolithic deployment can be performed. In a monolithic deployment, the client calls the data operation service through the following steps: Step 13: The data operation service receives the client's request, identifies the call information, parses the call parameters, and executes the data operation logic; Step 14: Determine the application's deployment method identifier. If the identifier is a monolithic deployment, execute the following logic; Step 15: Obtain the metadata information of the corresponding service based on the call information request; Step 16: Obtain the entry point for the processing logic based on the metadata information; Step 17: Pass in the request parameters to perform the corresponding customer transaction service logic processing; Step 18: The data operation service processes the returned results and generates the results to be returned to the client; Step 19: Return the processing result to the calling end.

[0137] Based on the above description, the application has no impact on client requests when deployed in different ways, and the internal processing of the system has the following characteristics: The application code versions are the same for distributed deployments and monolithic deployments, but different processing logics are formed based on the differences in configuration. Distributed deployment requires obtaining the address of the customer transaction service from the service catalog, while monolithic deployment does not. Monolithic deployment eliminates the possibility of remote call failures due to network fluctuations, which is present in distributed deployment.

[0138] The execution flow for distributed deployment and monolithic deployment provided in the embodiments of this application are described below.

[0139] In some embodiments of this application, such as Figure 4 The diagram shown is a flowchart illustrating a remote service invocation in a distributed deployment according to an embodiment of this application. The distributed deployment remote service invocation includes a client, a data operation service, a service catalog, and a customer transaction service. These four parts are used to implement remote service invocation in a distributed deployment. Specifically, it includes: Client-side operation: Sending requests to the data operation service: The client starts the application and prepares to send service requests; Application Launch (Data Operation Service and Customer Transaction Service): The Data Operation Service and Customer Transaction Service launch their respective applications. Parse service metadata and register services with the service directory: Data operation service and customer transaction service parse their own service metadata and register service information with the service directory. Service registration successful: The service directory has successfully received and recorded the registration information for the data operation service and the customer transaction service. At this point, the service directory contains the metadata and address information for all available services. Service processing logic invocation: After receiving a service request from the client, the data operation service begins to execute the service processing logic; Based on information such as the number of distributed services, the data operation service enters the loop processing phase based on information such as the current number of distributed services, and processes the data of each distributed service in a loop. Retrieve the destination address of the service from the service directory: The data operation service queries the service directory for the address information of the target service; Obtaining the destination address of the service based on the addressing information: The data operation service sends an addressing request to the service directory. This request contains the identification information of the target service to be called (such as service name, version number, etc.). After receiving the addressing request, the service directory searches for an available service instance that matches the identifier in its registered service list. Once found, the service directory returns the destination address of one or more service instances to the data operation service.

[0140] Determine whether the acquisition was successful; Otherwise, the call fails: If a failure occurs during the call process, such as failure to obtain the address from the service directory, network connection failure, remote call timeout, or service unavailability, the process directly points to processing the service call result. This means that whether it succeeds or fails, the call result still needs to be processed. If so, a remote call is initiated based on the service destination address information: the data operation service initiates a remote service call based on the address information obtained from the service directory; Remote Invocation: The invocation request is sent to the client's transaction server via the network; Processing service calls and returning call results: The customer transaction service receives and processes remote call requests, and after processing, returns the call results to the data operation service; Processing service call results: The data operation service receives the call results returned by the customer transaction service, and processes and parses the results accordingly; Displaying operation results: The client receives the final operation result and displays it to the user.

[0141] It should be noted that for a detailed explanation of each step in this embodiment, please refer to the description in the above embodiments, which will not be repeated here.

[0142] In some embodiments of this application, such as Figure 5 The diagram shown is a flowchart illustrating a service invocation process during a monolithic deployment, as provided in an embodiment of this application. The service invocation during a monolithic deployment includes a client and a server, which together implement the service invocation process. Specifically, it includes: Client operation, sending service request: The process begins with the client performing an operation and sending a service request to the server; Obtaining service metadata information: After receiving a request, the server first obtains the metadata information of the required service. Service processing logic invocation: The server invokes the corresponding service processing logic based on the metadata information; Determine if retrieval was successful: Confirm that the service's metadata information has been successfully retrieved and is available. This is a ready state, meaning that all the necessary information to execute local calls is available, and the actual business logic call can be performed. If not, proceed directly to the service call result processing step. This indicates that the service metadata retrieval or initialization of the processing logic failed. In this case, a service call result representing the failure (such as an error code or exception information) needs to be generated, and then proceed directly to the result processing step. If so, the call is initiated based on the service metadata information: the server initiates a specific service call based on the obtained service metadata information; Local call: Since this is a monolithic deployment, this call is a local call and does not involve network communication; Execute local calls based on service metadata and obtain call results: The server executes the call locally and directly obtains the call results; Processing service call results: The server processes the obtained call results (such as formatting, encapsulation, etc.). Displaying operation results: The server returns the final processing result to the client, which then displays the result to the user.

[0143] It should be noted that for a detailed explanation of each step in this embodiment, please refer to the description in the above embodiments, which will not be repeated here.

[0144] The technical solution provided in this application introduces service metadata information configuration, which allows for the acquisition of information such as the service's logical processing entry point. It also introduces deployment method identification configuration, which distinguishes between distributed and monolithic deployments. During development, it shields the application deployment architecture from intrusive changes to the code version caused by different numbers of customers, requiring only one set of application code versions for different deployment architectures. During deployment, there's no need to select versions based on the differences between distributed and monolithic deployments; changes in application functionality can be achieved simply and quickly by adjusting the configuration. Even when test environment resources are insufficient to meet the target deployment architecture, a monolithic deployment can be used to test the data operation service's related functions. When remote call service component support is incomplete, a monolithic deployment can be used to test the data operation service's completion chain. Under suitable circumstances, the data operation service and customer transaction service can be deployed together, eliminating the need for a service catalog, reducing application and component complexity, and saving application costs. When the database size is small, the data operation service and customer transaction service can be deployed together, eliminating service catalog dependencies and mitigating the risks of remote call failures and timeouts caused by network fluctuations.

[0145] Figure 6 This is a schematic diagram of a deployment mode switching device provided in an embodiment of this application, as shown below. Figure 6 As shown, the deployment mode switching device 100 includes a processing module 101 and a receiving module 102.

[0146] The aforementioned processing module 101 is used to parse the metadata information of all services in the configuration file when the service application starts, and register all services to the service directory. The metadata of each service includes the service's unique identifier, the service's call parameter information, and the service's call entry information.

[0147] The receiving module 102 described above is used to receive service requests from clients through the data operation service. The service requests contain a unique identifier of the target service and request parameters.

[0148] The aforementioned processing module 101 is also used to determine the deployment mode identifier of the service application, which indicates whether the current deployment mode is distributed or monolithic.

[0149] The aforementioned processing module 101 is further configured to, if the deployment method identifier indicates a distributed deployment mode, obtain the address of the customer transaction service corresponding to the unique identifier of the target service from the service directory through the data operation service, and execute a call to the remote customer transaction service based on the address.

[0150] The aforementioned processing module 101 is also used to, if the deployment method identifier indicates a monolithic deployment mode, obtain the corresponding service metadata information locally through the data operation service based on the unique identifier of the target service, and execute the business process of local customer transaction service based on the service metadata information.

[0151] In some embodiments of this application, the processing module 101 described above is specifically used for: sending a call request to an address through a data operation service, the call request containing a unique identifier of the target service and request parameters; after receiving the call request through a customer transaction service, passing in the request parameters to execute business logic processing based on the call entry information in the service metadata corresponding to the unique identifier of the target service, and returning the execution result to the data operation service; performing remote call processes on multiple customer transaction services in a loop through the data operation service, and after receiving the execution results returned by all customer transaction services, summarizing all execution results and returning the summarized final result to the client.

[0152] In some embodiments of this application, the aforementioned customer transaction service includes a service logic mapping table, which associates the unique identifier of a service with a business logic component; the aforementioned processing module 101 is specifically used to: obtain the target business logic component corresponding to the unique identifier of the target service from the service logic mapping table of the customer transaction service based on the call entry information; call the method of the target business logic component and pass in request parameters to perform business logic processing.

[0153] In some embodiments of this application, the processing module 101 is specifically used to: pass in the request parameters in the service request according to the call entry information in the service metadata information through the data operation service, so as to execute the customer transaction service business logic locally and generate the business execution result; and return the business execution result to the client through the data operation service.

[0154] In some embodiments of this application, the above-mentioned processing module 101 is further configured to: when the number of servers in the test environment is less than the minimum number of nodes required by the distributed architecture, configure the deployment mode identifier to indicate a monolithic deployment mode; and execute the business logic of the customer transaction service within the process of the data operation service in the monolithic deployment mode through the data operation service.

[0155] In some embodiments of this application, the above-mentioned processing module 101 is further configured to: when the service catalog is in an unstarted or unavailable state, configure the deployment mode identifier to indicate a monolithic deployment mode, so as to perform functional verification of data operation services by executing the business logic of customer transaction services locally.

[0156] In some embodiments of this application, a distributed deployment mode is adopted for systems where the amount of customer data reaches a preset threshold; a monolithic deployment mode is adopted for systems where the amount of customer data does not reach the preset threshold, and the data operation service and the customer transaction service are deployed together on a single server.

[0157] In some embodiments of this application, the above-mentioned call entry information is determined by the interface name, method name, and request parameters.

[0158] It should be noted that the explanation of the deployment mode switching device 100 can be found in the relevant description of the deployment mode switching device in the above embodiments, and will not be repeated here to avoid repetition. The deployment mode switching device provided in this application embodiment can achieve the same effect as the above deployment mode switching method. The effect of the deployment mode switching method can be found in the relevant description of the effect of the above deployment mode switching method embodiments, and will not be repeated here to avoid repetition.

[0159] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 7 As shown, the electronic device 500 includes: a memory 501, a transceiver 502, and at least one processor 503.

[0160] Transceiver 502 is used to interact with other devices to send and receive data.

[0161] The memory 501 is used to store computer program code, which includes computer instructions. These computer instructions run in the aforementioned electronic device to implement the method shown in the above-described method embodiments. For example, the memory may include high-speed random access memory (RAM), and may also include non-volatile memory (NVM), such as at least one disk storage device, or a USB flash drive, portable hard drive, read-only memory, magnetic disk, or optical disk, etc.

[0162] Processor 503 can be a general-purpose processor, including a Central Processing Unit (CPU), a network processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Processor 503 can also be other general-purpose processors. The general-purpose processor can be a microprocessor or any conventional processor.

[0163] The memory 501, transceiver 502, and processor 503 are communicatively connected. For example, the memory 501 and transceiver 502 can be connected to the processor 503 via a system bus and communicate with each other. The system bus can be a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, an industry standard architecture (ISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the figure, but this does not mean that there is only one bus or one type of bus.

[0164] Optionally, the memory 501 can be either standalone or integrated with the processor 503. When the memory 501 is set up independently, it is connected to the processor 503 via a system bus.

[0165] This application also provides a chip for executing instructions, which is used to execute the deployment mode switching method in the above embodiments.

[0166] This application also provides a computer-readable storage medium storing computer instructions. When these computer instructions are executed by a processor, they are used to implement the deployment mode switching method described in the above embodiments. Specifically, when the computer instructions are executed by a processor, the electronic device can perform the deployment mode switching method described in the above embodiments.

[0167] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium. When the at least one processor executes the computer program, it can implement the technical solution of the deployment mode switching method in the above embodiments.

[0168] The aforementioned computer-readable storage media can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The computer-readable storage media can be any available medium accessible to a general-purpose or special-purpose computer.

[0169] An exemplary computer-readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the computer-readable storage medium can also be a component of the processor. The processor and the computer-readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the computer-readable storage medium can exist as discrete components in an electronic control unit or main control device; this application does not limit this.

[0170] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0171] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs.

[0172] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0173] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0174] It should be understood that the steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

[0175] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0176] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for switching deployment modes, characterized in that, include: When the service application starts, it parses the metadata information of all services in the configuration file and registers all services to the service directory. The metadata of each service includes the service's unique identifier, the service's call parameter information, and the service's call entry information. The service requests from clients are received through the data operation service, and the service requests contain a unique identifier for the target service and request parameters. Determine the deployment mode identifier of the service application, which indicates whether the current deployment mode is distributed or monolithic. If the deployment method identifier indicates a distributed deployment mode, then the address of the customer transaction service corresponding to the unique identifier of the target service is obtained from the service directory through the data operation service, and a call to the remote customer transaction service is executed based on the address; If the deployment method identifier indicates a monolithic deployment mode, the data operation service obtains the corresponding service metadata information locally based on the unique identifier of the target service, and executes the business process of local customer transaction service based on the service metadata information.

2. The deployment mode switching method according to claim 1, characterized in that, The step of invoking the remote client transaction service based on the address includes: The data operation service sends a call request to the address, the call request containing a unique identifier of the target service and request parameters; After receiving a call request through the customer transaction service, the request parameters are passed in according to the call entry information in the service metadata corresponding to the unique identifier of the target service to execute business logic processing, and the execution result is returned to the data operation service; The data operation service performs remote call processes to multiple customer transaction services in a loop. After receiving the execution results returned by all customer transaction services, it summarizes all execution results and returns the summarized final result to the client.

3. The deployment mode switching method according to claim 2, characterized in that, The customer transaction service includes a service logic mapping table, which associates the unique identifier of the service with the business logic component. The step of passing the request parameters to execute business logic processing based on the call entry information in the service metadata corresponding to the unique identifier of the target service includes: Based on the call entry information, the target business logic component corresponding to the unique identifier of the target service is obtained from the service logic mapping table of the customer transaction service. Invoke the method of the target business logic component and pass in the request parameters to execute the business logic processing.

4. The deployment mode switching method according to claim 1, characterized in that, The business process for executing local customer transaction services based on the service metadata information includes: The data operation service, based on the call entry information in the service metadata, passes in the request parameters in the service request to execute the customer transaction service business logic locally and generate business execution results. The data operation service returns the business execution result to the client.

5. The deployment mode switching method according to any one of claims 1 to 4, characterized in that, The method further includes: When the number of servers in the test environment is less than the minimum number of nodes required for a distributed architecture, the deployment method identifier is configured to indicate a monolithic deployment mode. In monolithic deployment mode, the business logic of customer transaction services is executed within the process of the data operation service.

6. The deployment mode switching method according to claim 1, characterized in that, The method further includes: When the service catalog is in an inactive or unavailable state, the deployment method identifier is configured to indicate a monolithic deployment mode, so as to perform functional verification of data operation services by executing the business logic of customer transaction services locally.

7. The deployment mode switching method according to claim 1, characterized in that, For systems where customer data volume reaches a preset threshold, a distributed deployment model is adopted; For systems where the amount of customer data has not reached the preset threshold, a monolithic deployment mode is adopted, and the data operation service and customer transaction service are deployed together on a single server.

8. The deployment mode switching method according to claim 1, characterized in that, The call entry information is determined by the interface name, method name, and request parameters.

9. A deployment mode switching device, characterized in that, include: The processing module is used to parse the metadata information of all services in the configuration file when the service application starts, and register all services to the service directory. The metadata of each service includes the service's unique identifier, service call parameter information, and service call entry information. The receiving module is used to receive service requests from clients through the data operation service. The service requests include a unique identifier of the target service and request parameters. The processing module is further configured to determine the deployment mode identifier of the service application, wherein the deployment mode identifier is used to indicate whether the current deployment mode is distributed or monolithic. The processing module is further configured to, if the deployment method identifier indicates a distributed deployment mode, obtain the address of the customer transaction service corresponding to the unique identifier of the target service from the service directory through the data operation service, and execute a call to the remote customer transaction service based on the address; The processing module is further configured to, if the deployment method identifier indicates a monolithic deployment mode, obtain the corresponding service metadata information locally through the data operation service based on the unique identifier of the target service, and execute the business process of local customer transaction service based on the service metadata information.

10. An electronic device, characterized in that, include: The electronic device includes a memory and at least one processor; the memory is communicatively connected to the processor; the memory is used to store computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, the electronic device performs the deployment mode switching method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions, which, when executed by a processor, are used to implement the deployment mode switching method as described in any one of claims 1-8.

12. A computer program product, characterized in that, When the computer program product is running on a computer / executed by the computer's processor, the deployment mode switching method as described in any one of claims 1-8 is implemented.

Images