Service switching method and related device

Abstract

The invention provides a service switching method and a related device. The embodiment of the invention can be applied to the field of software architecture. The method comprises: according to service configuration information, obtaining a plurality of target micro-services to be merged from a first container platform, the service configuration information comprising a corresponding relationship between the target micro-services and target single services; registering a plurality of target micro-services into a target single service; combining the configurations of the plurality of target micro-services in the target single service to obtain a single configuration file corresponding to the target single service; and according to the monomer configuration file, constructing a target monomer service corresponding to the second container platform. And switching from the micro-service to the single-body service is realized, so that reasonable allocation and optimization of resources are realized.

Description

Technical Field

[0001] The present application relates to the field of software architecture technology, and in particular to a service switching method and related devices. Background Art

[0002] A monolithic service is a service that concentrates all functions in one application, while microservices is a cloud-native architectural approach that combines many small, loosely coupled and independently deployable components or services in an application.

[0003] In the process of software development, when faced with the choice of different service architectures, it is necessary to consider the application's scale, complexity, scalability, maintainability, security and other requirements. In privatization scenarios, it is generally better to choose a monolithic service architecture, which can be quickly developed and deployed, while reducing the complexity of deployment and management. At the same time, the organization needs to have full control over its data and applications; in the scenarios of to consumer (ToC) and software as a service (SaaS), users usually require fast response time and good user experience, need to support multi-tenants and multiple users, and need to be highly scalable and maintainable. Therefore, microservice architecture can be a good choice.

[0004] As the project scale expands, the monolithic service architecture may face problems such as poor scalability and maintainability, while microservices in privatization scenarios need to face problems such as high operation and maintenance costs, high deployment costs, and high image distribution costs. Currently, existing technical solutions all select different service architectures based on different scenarios. If the application scenarios of a certain software development are mostly ToC or SaaS scenarios, the microservice architecture is adopted, but during the operation of the software, there may be a need for privatization scenarios. If the microservice architecture is still used, it will face problems such as high operation and maintenance costs, high deployment costs, and high image distribution costs. If a set of software with a monolithic service architecture for privatization scenarios is reconfigured, the software development cost will be greatly increased. Summary of the invention

[0005] The embodiments of the present application provide a service switching method and related devices for implementing switching between microservices and monolithic services, thereby achieving reasonable allocation and optimization of resources.

[0006] The first aspect of the present application provides a service switching method, comprising:

[0007] According to the service configuration information, multiple target microservices to be merged are obtained from the first container platform, where the service configuration information includes a correspondence between the target microservices and the target monomer service;

[0008] Register multiple target microservices into the target monolithic service;

[0009] Merge the configurations of multiple target microservices in the target monolithic service to obtain a monolithic configuration file corresponding to the target monolithic service;

[0010] According to the monomer configuration file, a target monomer service corresponding to the second container platform is constructed.

[0011] In a possible implementation method, obtaining multiple target microservices to be merged from the first container platform according to the service configuration information includes:

[0012] Get multiple microservices from the first container platform;

[0013] According to the running framework of the microservice, multiple microservices are screened to obtain multiple target microservices, and the running framework of the target microservice is the preset framework;

[0014] According to the service configuration information, determine the correspondence between the target microservice and the target monolithic service.

[0015] In one possible implementation method, multiple target microservices are registered into the target monolithic service, including:

[0016] Get the registration template file, which is used to generate the entry layer code of the target single service;

[0017] Register multiple target microservices into the target monolithic service according to the registration template file, and generate the entry layer code of the target monolithic service.

[0018] In one possible implementation method, the configurations of multiple target microservices are merged into the target monolithic service, including:

[0019] Get the configuration template file, which includes the configuration requirements corresponding to the target microservice;

[0020] According to the configuration requirements, the configurations of multiple target microservices are merged into the target monolithic service through the entry layer code.

[0021] In one possible implementation method, the configuration requirements corresponding to the target microservice include:

[0022] If the first microservice exists, and the first microservice is a target microservice that needs to modify the decoder, the modification operation of the first microservice is configured to perform a unified response through the management plug-in.

[0023] In one possible implementation method, the configuration requirements corresponding to the target microservice include:

[0024] If there is a second microservice, and the second microservice is a target microservice that provides a data serialization function, the second microservice is configured to be isolated from other target microservices.

[0025] In a possible implementation method, the configurations of multiple target microservices are merged in the target monolithic service to obtain a monolithic configuration file corresponding to the target monolithic service, including:

[0026] In the target monolithic service, the server configuration, client configuration, and plug-in configuration of multiple target microservices are merged in sequence to obtain a monolithic configuration file corresponding to the target monolithic service.

[0027] In a possible implementation method, after building a target monomer service corresponding to the second container platform according to the monomer configuration file, the method further includes:

[0028] Perform compatibility check on the target single service according to the second container platform and output the check result;

[0029] According to the functions of multiple target microservices, the target monolithic services are tested in turn and the test results are output.

[0030] In a possible implementation method, after building a target monomer service corresponding to the second container platform according to the monomer configuration file, the method further includes:

[0031] Get the target single service;

[0032] According to the service configuration information, multiple target microservices corresponding to the target monomer service are determined; the target monomer service is split to obtain multiple target microservices.

[0033] In one possible implementation method, the target monolithic service is split into multiple target microservices, including:

[0034] Split the entry layer code of the target single service to obtain multiple microservice entry codes corresponding to multiple microservices;

[0035] Split the configuration of the target single service, and configure multiple target microservices through the corresponding microservice entry code.

[0036] In a possible implementation method, after splitting the target monolithic service to obtain multiple target microservices, the following steps are also included:

[0037] Perform corresponding functional tests on multiple target microservices respectively and output the test results.

[0038] A second aspect of the present application provides a service switching device, characterized by comprising:

[0039] A configuration module is used to obtain multiple target microservices to be merged according to service configuration information, where the service configuration information includes a corresponding relationship between the target microservices and the target monomer service;

[0040] The registration module is used to register multiple target microservices into the target monolithic service;

[0041] The merging module is used to merge the configurations of multiple target microservices in the target monolithic service to obtain a monolithic configuration file corresponding to the target monolithic service;

[0042] The construction module is used to merge the configurations of multiple target microservices in the target monolithic service to obtain a monolithic configuration file corresponding to the target monolithic service.

[0043] In a possible implementation method, a configuration module is specifically used to obtain multiple microservices from a first container platform; screen the multiple microservices according to an operating framework of the microservice to obtain multiple target microservices, where the operating framework of the target microservice is a preset framework; and determine a correspondence between the target microservice and the target monomer service according to service configuration information.

[0044] In a possible implementation method, the registration module is specifically used to obtain a registration template file, the registration template file is used to generate an entry layer code for a target monolithic service; the entry layer code is generated according to the registration template file; and multiple target microservices are registered into the target monolithic service through the entry layer code.

[0045] In a possible implementation method, the merging module is specifically used to obtain a configuration template file, where the configuration template file includes configuration requirements corresponding to the target microservice;

[0046] According to the configuration requirements, the configurations of multiple target microservices are merged into the target monolithic service through the entry layer code.

[0047] In one possible implementation method, the configuration requirements corresponding to the target microservice include:

[0048] If the first microservice exists, and the first microservice is a target microservice that needs to modify the decoder, the modification operation of the first microservice is configured to perform a unified response through the management plug-in.

[0049] In this embodiment, a universal plug-in is developed to manage the target microservices that need to modify the decoder.

[0050] In one possible implementation method, the configuration requirements corresponding to the target microservice include:

[0051] If there is a second microservice, and the second microservice is a target microservice that provides a data serialization function, the second microservice is configured to be isolated from other target microservices.

[0052] In a possible implementation method, the merging module is specifically used to merge the server configuration, client configuration and plug-in configuration of multiple target microservices in the target monolithic service in sequence to obtain a monolithic configuration file corresponding to the target monolithic service.

[0053] In a possible implementation method, the method further includes:

[0054] The inspection module is used to perform compatibility inspection on the target monolithic service according to the second container platform and output the inspection result; perform functional inspection on the target monolithic service in turn according to the functions of multiple target microservices and output the inspection result.

[0055] In a possible implementation method, the configuration module is further used to obtain a target monolithic service and determine a plurality of target microservices corresponding to the target monolithic service according to the service configuration information;

[0056] Also includes:

[0057] The splitting module is used to split the target single service into multiple target microservices.

[0058] In a possible implementation method, the splitting module is specifically used to split the entry layer code of the target monomer service to obtain multiple microservice entry codes corresponding to multiple microservices; split the configuration of the target monomer service, and configure multiple target microservices through the corresponding microservice entry codes.

[0059] In a possible implementation method, the inspection module is also used to perform corresponding functional tests on multiple target microservices respectively and output the test results.

[0060] A third aspect of the present application provides a computer device, including:

[0061] memories, transceivers, processors, and bus systems;

[0062] Wherein, the memory is used to store programs;

[0063] The processor is used to execute the program in the memory, including executing the above-mentioned methods;

[0064] The bus system is used to connect the memory and the processor so that the memory and the processor can communicate with each other.

[0065] A fourth aspect of the present application provides a computer-readable storage medium, in which instructions are stored. When the computer-readable storage medium is run on a computer, the computer executes the methods in the above aspects.

[0066] In a fifth aspect, the present application provides a computer program product or a computer program, the computer program product or the computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the methods provided by the above aspects.

[0067] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

[0068] The present application provides a service switching method and related devices, which obtain multiple target microservices that can synthesize a single service according to service configuration information, then register the multiple target microservices into the target single service, then merge the configurations of the multiple target microservices to obtain the overall configuration file, and finally build the target single service according to the configuration file, thereby realizing the switching from merging multiple microservices to a single service. The above method enables the microservice architecture to switch to a single service when facing a privatization scenario, so as to achieve reasonable allocation and optimization of resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] Figure 1 This is an application environment diagram of the service switching method in an embodiment of the present application;

[0070] Figure 2 A method flow chart of the service switching method provided in an embodiment of the present application;

[0071] Figure 3 A method flow chart of the service switching method provided in an embodiment of the present application;

[0072] Figure 4 A schematic diagram of a management plug-in (tRPC api) of a unified standardized response structure provided in an embodiment of the present application;

[0073] Figure 5 A brief flowchart of the service switching method provided in the embodiment of the present application;

[0074] Figure 6 A method flow chart of the service switching method provided in an embodiment of the present application;

[0075] Figure 7 A brief flowchart of the service switching method provided in the embodiment of the present application;

[0076] Figure 8 This is a schematic diagram of the structure of the service switching device in the embodiment of the present application;

[0077] Fig. 9 It is a schematic diagram of a server structure provided in an embodiment of the present application;

[0078] Figure 10a to Figure 10g A partial code diagram of the service switching method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0079] The embodiments of the present application provide a service switching method and related devices, which can realize switching between microservices and monolithic services to solve the problem that the microservice architecture can be switched to a monolithic service when facing a privatization scenario to achieve reasonable allocation and optimization of resources.

[0080] The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein, for example. In addition, the terms "including" and "corresponding to" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0081] To facilitate understanding of the technical solutions provided in the embodiments of the present application, some key terms used in the embodiments of the present application are explained here:

[0082] Monolithic Services: A monolith is a large block of code with multiple modules. These modules are tightly coupled to each other. The application and business logic are encapsulated in a deployable binary file called a monolith. Typically, a monolithic application consists of a traditional three-tier architecture, i.e., database, user interface, and server-side application.

[0083] Microservices: An architectural concept that aims to decouple solutions by breaking down functionality into discrete services.

[0084] Private: Private deployment means installing the software or application on your own servers or computers instead of using the services of a public cloud service provider. In a private deployment, the organization has full control over its data and applications to meet its specific needs and security requirements.

[0085] ToC (to consumer): It is aimed at the end customer. It is not aimed at organizations like enterprises, but at individual consumers. ToC products are the most common products on the market. They all follow specific standard processes. The development results are completely oriented to the public. They need to meet the needs and preferences of different users and need to be highly scalable and maintainable to support the growing number of users and business needs.

[0086] In the field of software development, monolithic service and microservice architectures have their own advantages and disadvantages, and are suitable for different scenarios. Monolithic service architecture integrates all functions into one application, which is simple and easy to maintain, suitable for small and medium-sized projects, but as the project scales up, it may face challenges such as poor scalability and difficult deployment; on the contrary, microservice architecture splits the application into multiple independent services, which has the advantages of decoupling, isolation, and elasticity, and is suitable for large projects. However, microservice architecture makes the system more complex, and it is necessary to consider aspects such as service splitting, calling, and deployment, and the development and maintenance costs are high.

[0087] When choosing different architectures, you need to consider the application's scale, complexity, scalability, maintainability, security and other requirements. In privatization scenarios, it is generally better to choose a monolithic service architecture, which can be quickly developed and deployed, while reducing the complexity of deployment and management. At the same time, the organization needs to have full control over its data and applications. In ToC and SaaS scenarios, users usually require fast response time and good user experience, need to support multi-tenants and multiple users, and need to be highly scalable and maintainable. Therefore, microservice architecture can be a good choice. Microservice architecture can decompose an application into multiple small services, each of which runs independently, can support multi-tenants and multiple users, and improve scalability and maintainability.

[0088] As the project scale expands, the monolithic service architecture may face problems such as poor scalability and maintainability, while microservices in privatization scenarios need to face problems such as high operation and maintenance costs, high deployment costs, and high image distribution costs. Currently, existing technical solutions all select different service architectures based on different scenarios. If the application scenarios of a certain software development are mostly ToC or SaaS scenarios, the microservice architecture is adopted, but during the operation of the software, there may be a need for privatization scenarios. If the microservice architecture is still used, it will face problems such as high operation and maintenance costs, high deployment costs, and high image distribution costs. If a set of software with a monolithic service architecture for privatization scenarios is reconfigured, the software development cost will be greatly increased.

[0089] In order to solve the above problems, the present application provides a service switching method and related devices, so that the microservice architecture and the monolithic service architecture can be freely switched in different scenarios. While retaining the respective advantages of the microservice architecture and the monolithic service architecture, their disadvantages are eliminated, fundamentally solving the difficulties and challenges of balancing the service architecture selection when large-scale project products face multi-scenario requirements.

[0090] For easier understanding, see Figure 1 , Figure 1 FIG. 1 is an application environment diagram of the service switching method in the embodiment of the present application, such as Figure 1 As shown, the service switching method in the embodiment of the present application can be applied to SaaS environment and privatization environment.

[0091] In a SaaS environment, it is still deployed on a container platform in the form of a microservice architecture, including multiple microservices (MicroServer). In a private environment, microservices can be merged into a few monolithic services (Monolith) based on a monolithic service generator. Figure 1 In the SaaS environment shown, the MicroServer is virtually divided according to modules. When merged into a Monolith, each Monolith corresponds to the function of each Module.

[0092] The single service generator is used to provide the service switching method provided in the embodiment of the present application, including functions such as configuration synthesis, code generation, and image building. Among them, the configuration synthesis function is used to merge the configuration of microservices; the code generation function is used to generate the software code of the corresponding single service according to the merged configuration; the image building function is used to package the above configuration and code into an image, thereby realizing the switching of multiple microservices to single services.

[0093] The following is an introduction to the service switching method in this application from the perspective of a single service generator. Figure 2 The service switching method provided in the embodiment of the present application includes: step S201 to step S204.

[0094] Specific:

[0095] 201. Acquire multiple target microservices to be merged from a first container platform according to service configuration information, where the service configuration information includes a correspondence between the target microservices and the target monolithic service.

[0096] First, the service switching method provided in the embodiment of the present application needs to obtain all target microservices that need to be merged according to the service configuration information. The service configuration information can be located in a configuration file, which describes which single services need to be output according to the preset modules, such as Figure 1 The configuration file also describes which microservices each monolith service is composed of, i.e., monolith1 corresponds to multiple microservices under module1, monolith2 corresponds to multiple microservices under module2, etc. In other words, the configuration file includes the correspondence between the target microservices and the monolith services, which can be expressed as: one or more target microservices corresponding to each target monolith service.

[0097] For example, part of the configuration file could be: Fig.10a shown.

[0098] Understandably, Fig.10a The code in is used to define how to merge microservices into a monolithic service. It includes a list called 'modules', each module has a name and a set of merged services. For example, the first module is called 'monolith-module1', and it has two merged services: 'microserver1' and 'microserver2'. Similarly, the second module is called 'monolith-module2', and it has two merged services: 'microserver3' and 'microserver4'. This configuration file is used to guide the service merging process, merging small, independent microservices into larger, integrated monolithic services.

[0099] A container platform refers to a virtual instance of a running service. As described above, microservices are usually built in ToC and SaaS scenarios, while monolithic services are usually built in privatization scenarios. Therefore, the container platforms running the two may be the same or different. In an embodiment of the present application, a container platform running multiple target microservices is defined as a first container platform, and a platform running a target monolithic service is defined as a second container platform. The first container platform and the second container platform may be different platforms or the same platform. The first and second here are only used to distinguish between microservices and monolithic services.

[0100] 202, register multiple target microservices into the target monolithic service.

[0101] It can be understood that registration refers to the integration and calling of microservices by registering the interfaces and functions of multiple microservices into a monolithic service. Specifically, in a microservice architecture, each microservice has specific functions and business areas, and exposes its own service interfaces. When a monolithic service needs to use these microservices, it can achieve integration by calling the interfaces of the microservices. In order to achieve this integration, the monolithic service needs to have the ability to register microservices into the service registry and be able to discover available microservices from the service registry. The purpose of this is to integrate the functions and data of these microservices into one service to provide more complete functions and data. For example, an e-commerce website may contain multiple microservices, such as user management, product management, order management, etc. These microservices can be registered into the target monolithic service to form a complete e-commerce website. Register multiple target microservices into the target monolithic service to achieve the merging and integration of services to meet more complex functional requirements.

[0102] Therefore, in the embodiment of the present application, in order to achieve the purpose of merging multiple target microservices into a single service, after obtaining the target microservices to be merged, the multiple target microservices need to be registered into the corresponding target single service.

[0103] 203 , merging configurations of multiple target microservices in the target monolithic service to obtain a monolithic configuration file corresponding to the target monolithic service.

[0104] It can be understood that there are corresponding configuration items in each microservice. In the process of merging multiple target microservices into a target monomer service, it is necessary to merge the configurations of all target microservices, and finally generate the configuration of the corresponding target monomer service, and then generate the configuration files corresponding to the target monomer service in turn.

[0105] 204. Construct a target monomer service corresponding to the second container platform according to the monomer configuration file.

[0106] After the monomer configuration file is generated, the monomer configuration file is constructed and rendered according to the second container platform, and finally a product of the target monomer service is generated.

[0107] The service switching method provided in the embodiment of the present application obtains multiple target microservices that can synthesize a single service according to the service configuration information, then registers the multiple target microservices into the target single service, then merges the configurations of the multiple target microservices to obtain the overall configuration file, and finally builds the target single service according to the configuration file, thereby realizing the switching from merging multiple microservices to a single service. The above method enables the microservice architecture to switch to a single service when facing a privatization scenario, so as to achieve reasonable allocation and optimization of resources.

[0108] In this application Figure 2 In an optional embodiment of the service switching method provided in the corresponding embodiment, please refer to Figure 3 , Figure 3 The method flow chart of the service switching method provided in the embodiment of the present application includes:

[0109] 301, obtaining multiple microservices from the first container platform;

[0110] 302, screening multiple microservices according to the running framework of the microservice to obtain multiple target microservices, where the running framework of the target microservice is a preset framework;

[0111] 303. Determine the correspondence between the target microservice and the target monolithic service according to the service configuration information.

[0112] It can be understood that the above steps 301 to 303 are Figure 2 A possible implementation method of the corresponding step 201 is described in detail below for steps 301 to 303.

[0113] It is understandable that for microservices, different operating frameworks may be tried in their development process, such as tRPC-Go, tRPC-Cpp, SPP, LSF, etc. (all existing service operating frameworks, which will not be described here). There are differences in the protocols between different operating frameworks, and it is difficult to merge microservices using different operating frameworks. Therefore, the preferred solution is to filter the microservices according to the operating framework after obtaining multiple microservices, and obtain the target microservice under the specified preset framework. The type of the preset framework is not limited. For example, in document processing products, most services use the standard tRPC-Go framework, so the preset framework is the tRPC-Go framework.

[0114] After determining the target microservices running under multiple preset frameworks, the corresponding relationship between the target microservices and the target monolithic services is determined according to the configuration service information.

[0115] 304, obtaining a registration template file, where the registration template file is used to generate an entry layer code for a target single service;

[0116] 305, generating an entry layer code according to the registration template file, and registering multiple target microservices into the target monolithic service through the entry layer code.

[0117] It can be understood that the above steps 304 and 305 are Figure 2 A possible implementation method of the corresponding step 202 is described in detail below for steps 304 and 305.

[0118] After obtaining all the microservices that need to be merged, a registration template file can be obtained. The registration target file can be a preset target file used to generate the service entry layer code of the single service.

[0119] The entry layer code of a single service refers to the entry code of a single service module in a large application. For a single service, it usually includes multiple modules, each with its own functions and responsibilities. The entry layer code is the entry point of each module in this service, that is, the starting point of each module code execution. The entry layer code of a single service is the entry point of each module. It is responsible for introducing necessary dependencies, configuring necessary parameters, registering routes, and starting services, so that the module can run normally and provide services.

[0120] Specifically, the registration target file includes a Register function, where all microservice implementations are registered in the single service. Part of the code of the registration template file is as follows Fig.10b shown.

[0121] Understandably, Fig.10b In the code, the comment " / / Code generated by backend / tools / monolith,DO NOT EDIT." indicates that this code is generated by the backend / tools / monolith tool, which is the execution subject of the service switching method provided in the embodiment of the present application. "func Register(s*server.Server){" defines a function named Register, which accepts a pointer of type server.Server as a parameter. Register each microservice to the monolithic service so that these microservices can be accessed through this monolithic service from other places.

[0122] 306, obtaining a configuration template file, where the configuration template file includes configuration requirements corresponding to the target microservice;

[0123] 307, according to the configuration requirements, the configurations of multiple target microservices are merged in the target monolithic service through the entry layer code.

[0124] It is understandable that the above steps 306 and 307 are Figure 2 A possible implementation method of the corresponding step 203 is described in detail below for steps 306 and 307.

[0125] It is understandable that, taking business configuration as an example, in the privatization scenario, some services read local configurations, and some services read business configurations through the plugin of trpc_go.yaml. In this case, the path of using local files to read configurations may conflict because they are basically ${APPPATH} / config / app.yaml. Therefore, in an embodiment of the present application, by obtaining a preset configuration template file, according to the configuration requirements corresponding to the target microservice, and the entry layer code generated by the above steps, the configurations of multiple target microservices are merged so that the business configuration can be read through a unified plug-in later.

[0126] For example, some of the code for the configuration structure of microservices and monolithic services is as follows Fig.10c and Fig.10d As shown, Fig.10c Part of the code configured for microservices, Fig.10d Part of the code configured for a single service.

[0127] In addition, similar problems also exist in the merging of some plug-in configurations. For example, the code of a plug-in configuration structure is as follows: Fig.10e shown.

[0128] This configuration is fine when running alone in a microservice environment. However, after being merged into a single service, conflicts will arise if the configurations of each service are different. To solve this problem, the present application embodiment has modified this type of plug-in to form its code as follows: Fig.10f The configuration structure shown:

[0129] In addition, each microservice may modify global variables at will. For example, the tRPC-Go framework provides many global variables for users to use, so that business developers can flexibly adjust certain functional features, such as http.DefaultServerCodec and restful.Marshaller. In a microservice environment, modifying these global variables at will may not have a big impact. But for a single service, any change to these global variables may affect the functions of other services.

[0130] Therefore, this application provides the following two configuration strategies to solve the above problems:

[0131] 1) Develop general plug-ins:

[0132] For the target microservice that needs to modify the codec (such as http.DefaultServerCodec), define it as the first microservice. The configuration requirements for the first microservice include:

[0133] If the first microservice exists in the multiple target microservices, the modification operation of the first microservice is configured to perform a unified response through the management plug-in.

[0134] It is understandable that, for the first microservice, this application provides a unified standardized response structure, such as Figure 4 As shown, Figure 4 A schematic diagram of the management plug-in (tRPC api) with a unified standardized response structure provided in an embodiment of the present application. Using the tRPC api, different microservices can expose their respective functions in a standardized manner, and can use a common interface description language to describe the interface, thereby simplifying the calls and interactions between different microservices. The tRPC api not only provides a common response structure, but also can implement functions such as asynchronous calls and streaming processing between different microservices. The microservices access the management plug-in through the corresponding interface. When one of the microservices modifies the global variables, its code is shown in the http tesponse body. After a unified standardized response is made through the tRPC api, a standard response structure such as xx.proto and *errs.Error is generated.

[0135] 2) Hard isolation by modules:

[0136] For the target microservice that needs to provide data serialization functions (such as restful.Marshaller), it is defined as the second microservice. The configuration requirements for the second microservice include:

[0137] If the second microservice exists in the multiple target microservices, the second microservice is configured to be isolated from the other target microservices.

[0138] It is understandable that since the services that need to modify restful.Marshaller belong to the same type of services and their modifications to this global variable are consistent, these services can be separated into a single module to fundamentally isolate them from the services that do not need to modify this variable.

[0139] 308. In the target monolithic service, the server configuration, the client configuration, and the plug-in configuration of the multiple target microservices are sequentially merged to obtain a monolithic configuration file corresponding to the target monolithic service.

[0140] In this embodiment, the configuration of the target microservice is merged, specifically in the order of server configuration, client configuration and plug-in configuration. The reason is that these configuration items play different roles in the microservice architecture, and the dependencies between them need to be accurately handled.

[0141] Server configuration: Server configuration usually contains the core configuration information required to run microservice applications, such as database connections, external service calls, etc. These configurations are the basis for the operation of microservice applications, so they need to be considered first when merging configurations. Ensuring the accuracy and completeness of server configuration is crucial because it directly affects the stability and performance of microservice applications.

[0142] Client configuration: The client configuration includes configuration information related to the interaction with the client application, such as request parameters, API keys, etc. These configurations are required for interaction between the server and the client, so they need to be merged after the server configuration. The correctness of the client configuration can ensure the correctness of the microservice application's processing and response to requests, thereby providing a better user experience.

[0143] Plugin configuration: Plugin configuration usually includes configuration information of some third-party libraries or plugins, which may provide additional functions or optimizations for microservice applications. The merging of plugin configuration is after the server and client configuration, because the configuration of plugins often depends on the specific implementation of the server and client. Only when the core configuration and client configuration are merged correctly, the plugin can work properly.

[0144] This sequential merging ensures the consistency and accuracy of the overall configuration of the target microservice. When dealing with complex microservice architectures, clearly distinguishing and merging different configuration items in the correct order helps reduce errors and maintenance costs, while improving the reliability and maintainability of the system.

[0145] After merging the configurations of all microservices, you can configure all services as follows Figure 10g The tRPC configuration template shown is rendered to merge the configurations of all microservices into a large configuration file, and finally generate the tRPC configuration file of the single service.

[0146] Understandably, Figure 10g In the code shown, the configuration template is roughly divided into three main nodes. The server node describes the server configuration, the client node describes the client configuration, and the plugins node describes the service plug-in configuration.

[0147] 309 , construct a target monomer service corresponding to the second container platform according to the monomer configuration file.

[0148] It is understandable that the above step 309 is Figure 2 The corresponding step 204 is similar and will not be described again here.

[0149] 310, performing a compatibility check on the target monomer service according to the second container platform, and outputting the check result;

[0150] 311, according to the functions of the multiple target microservices, the target single service is tested for functions in turn, and the test results are output.

[0151] It is understandable that after achieving flexible switching between monolithic services and microservices, you may encounter problems caused by various changes. For example, a service suddenly fails after running for a period of time after being merged. If some measures are not taken, this situation may become difficult to avoid in a monolithic service merged from hundreds of microservices.

[0152] In this regard, the embodiment of the present application performs automatic checks through the pipeline in each merge request (MR), including checking whether the service still meets the merge constraints (such as whether the configuration can still be merged, whether the code structure still complies with the specification, etc.), and integrates automated functions such as interface testing and end-to-end (e2e) testing to ensure that microservice changes will not destroy the compatibility of the single-body merge.

[0153] Compatibility checks on single services can include the following aspects:

[0154] Application version compatibility: Checks whether the service is compatible with other versions of the application. If there are compatibility issues between the service and different versions of the application, it may cause the application to crash or not run properly.

[0155] Dependency compatibility: Checks whether other components or libraries that the service depends on are compatible with the current environment of the application. For example, if the service uses an old version of a dependency, and the dependency version in the application environment is a new version, the service may not run properly.

[0156] Database compatibility: If the service interacts with a database, you need to check whether the service is compatible with the database version. If the service uses an old version of the database schema and the database version is a new version, the service may not run properly.

[0157] Hardware compatibility: If the service requires specific hardware requirements to run, you need to check whether the server meets these hardware requirements. For example, if the service requires more memory or a faster processor to run properly, it may cause the service to not run properly.

[0158] Network compatibility: If the service needs to communicate with other systems or external services, you need to check whether the network connection is stable and reliable, and whether it is compatible with external services. For example, if the service uses an old version of the network protocol, and other systems or external services use a new version, the service may not run properly.

[0159] After the compatibility check, the check results can be output as a detailed report. The report can include the following:

[0160] Check Results Summary: A brief overview of the overall compatibility check and whether there are any compatibility issues.

[0161] Detailed inspection results: For each compatibility inspection aspect, the specific inspection results are listed, including which aspects have problems and the specific circumstances of the problems.

[0162] Affected versions: List the service versions affected by the compatibility issue so that other developers or administrators can understand the specific versions affected.

[0163] Suggested Solutions: For each issue, provide a solution or suggestion so that other developers or administrators can resolve or mitigate the compatibility issue.

[0164] In addition, it also includes functional testing of the functions of the microservices corresponding to each monolithic service to ensure the effectiveness of the monolithic service.

[0165] Performing functional testing on the microservices corresponding to each monolithic service can ensure that each microservice can independently provide the expected functionality. The following are some common functional testing aspects:

[0166] Verify functional correctness: Test whether the functions of the microservices meet expectations and whether they can correctly return the expected outputs under various input conditions. This can be done manually or using automated testing tools.

[0167] Verify interface stability: Test whether the interface provided by the microservice is stable, whether it can run normally under high load, and whether it has the necessary fault tolerance mechanism. You can use load testing tools for testing.

[0168] Verify security: Test whether the microservices have the necessary security measures, such as authentication, authorization, and encryption. This can be done using security testing tools or manual testing.

[0169] Verify scalability: Test whether the microservice has the necessary scalability to quickly scale to support more users and requests when demand grows. This can be done using performance testing tools.

[0170] Verify maintainability: Test whether the microservice is easy to maintain and modify, including aspects such as code clarity, comments, and architectural design. Other developers or professional testers can be invited to conduct code reviews and tests.

[0171] After performing functional testing on the microservices corresponding to each monolithic service, the test results can be output as a detailed report. The report can include the following:

[0172] Detection result summary: A brief overview of the overall functional detection of each microservice and whether there are any functional issues.

[0173] Detailed test results: For each microservice, list the specific test results, including which areas have problems and the specific circumstances of the problem.

[0174] Suggested Solutions: For each issue, provide a solution or suggestion so that other developers or administrators can resolve or mitigate the functionality issue.

[0175] In summary, please refer to Figure 5 , Figure 5 A brief flow chart of the service switching method provided in the embodiment of the present application includes: obtaining all microservices that need to be merged; rendering the registration template file and registering the microservice; judging whether the merged microservice configuration is completed: if not completed, merging the server configuration, merging the client configuration, and merging the plug-in configuration in sequence according to the configuration template file to obtain a monomer configuration file; if completed, rendering the monomer configuration file to obtain a monomer service; performing a pipeline check on the monomer service to determine the final monomer service product.

[0176] The service switching method provided in the embodiment of the present application relies on service configuration information, registration template files, and configuration template files to generate the final single service code and configuration. This concise and efficient implementation method not only improves development efficiency, but also reduces maintenance costs, and provides strong support for flexible switching between single services and microservices.

[0177] This application proposes a service switching method that can flexibly switch between single services and microservice architectures. While retaining the advantages of microservices, it can significantly reduce system resource consumption and improve performance. This flexible architecture strategy helps to achieve reasonable allocation and optimization of resources according to different scenarios and needs. As shown in Table 1, Table 1 is the performance data of a certain software. In actual applications, after the software is implemented with the solution provided by this application, the total image size of the final delivery is reduced by 75% and the total memory usage is reduced by 96%.

[0178] Table 1 Software performance data

[0179]

[0180]

[0181] Furthermore, after the merger from microservices to monolithic services is realized, the split from monolithic services to microservices can be realized by reversing the merger process, such as Figure 6 As shown, including:

[0182] 312, obtain the target monomer service;

[0183] 313, determining multiple target microservices corresponding to the target monomer service according to the service configuration information;

[0184] 314, split the target single service to obtain multiple target microservices;

[0185] It can be understood that the above steps 312 to 314 are equivalent to Figure 2 or Figure 3 The steps in the corresponding embodiments are executed in order from back to front, and the principles thereof will not be described in detail here.

[0186] In a possible implementation method, the method further includes:

[0187] 315, perform corresponding function tests on multiple target microservices respectively, and output the test results.

[0188] It is understandable that, similarly, after splitting a single service into multiple microservices, in order to ensure the availability of the microservices, it is necessary to perform functional tests on the multiple target microservices. If the platform on which the target microservice runs is the first container platform, then it also includes: performing compatibility checks on the target microservice according to the first container platform.

[0189] Wherein, step 314 specifically includes:

[0190] 3131, split the entry layer code of the target single service to obtain multiple microservice entry codes corresponding to multiple microservices;

[0191] 3132, split the configuration of the target single service, and configure multiple target microservices through the corresponding microservice entry code.

[0192] It can be understood that the operations in step 312 to step 314 are equivalent to Figure 2 or Figure 3 The reverse operation of the relevant operation in the corresponding embodiment can be performed by those skilled in the art according to the above Figure 2 or Figure 3 The relevant principles in the embodiments are implemented and will not be described in detail here.

[0193] See also Figure 7 , Figure 7 This is a brief flow chart of the service switching method provided in an embodiment of the present application, which corresponds to steps 312 to 314, including: obtaining a single service that needs to be split, where the single service is composed of multiple microservices; determining whether the splitting of the microservice is completed, and if not, executing the operations of splitting the single service entry layer code and splitting the configuration file; if completed, performing a pipeline check on the microservice to determine the microservice product.

[0194] The following is a detailed description of the service switching device in this application. Figure 8 . Figure 8 This is a schematic diagram of the structure of a service switching device 700 in an embodiment of the present application. The service switching device 700 includes:

[0195] Configuration module 701, used to obtain multiple target microservices to be merged according to service configuration information, where the service configuration information includes the correspondence between the target microservices and the target monolithic services;

[0196] A registration module 702 is used to register multiple target microservices into a target monolithic service;

[0197] A merging module 703 is used to merge the configurations of multiple target microservices in a target monolithic service to obtain a monolithic configuration file corresponding to the target monolithic service;

[0198] The construction module 704 is used to merge the configurations of multiple target microservices in the target monolithic service to obtain a monolithic configuration file corresponding to the target monolithic service.

[0199] In this embodiment, multiple target microservices that can synthesize a single service are obtained through the configuration module 701, and then the multiple target microservices are registered into the target single service through the registration module 702. Then, the configurations of the multiple target microservices are merged through the merging module 703 to obtain the overall configuration file, and finally, the target single service is constructed according to the configuration file according to the construction module 704, thereby realizing the switching from merging multiple microservices to a single service. The above method enables the microservice architecture to switch to a single service when facing a privatization scenario, so as to realize the reasonable allocation and optimization of resources.

[0200] In a possible implementation method, the configuration module 701 is specifically used to obtain multiple microservices from the first container platform; screen the multiple microservices according to the running framework of the microservice to obtain multiple target microservices, and the running framework of the target microservice is a preset framework; determine the correspondence between the target microservice and the target monomer service according to the service configuration information.

[0201] In this embodiment, after acquiring multiple microservices, the configuration module 701 will filter them to obtain the target microservice under the specified preset framework.

[0202] In a possible implementation method, the registration module 702 is specifically used to obtain a registration template file, which is used to generate an entry layer code for a target monolithic service; generate an entry layer code according to the registration template file; and register multiple target microservices into the target monolithic service through the entry layer code.

[0203] In this embodiment, the registration module 702 specifically implements the registration of the target microservice in the monolithic service through the registration template file, and generates the entry layer code of the target monolithic service.

[0204] In a possible implementation method, the merging module 703 is specifically used to obtain a configuration template file, where the configuration template file includes configuration requirements corresponding to the target microservice;

[0205] According to the configuration requirements, the configurations of multiple target microservices are merged into the target monolithic service through the entry layer code.

[0206] In this embodiment, the merging module 703 specifically uses the configuration template file and the entry layer code to realize the merging of the configurations of multiple target microservices.

[0207] In one possible implementation method, the configuration requirements corresponding to the target microservice include:

[0208] If the first microservice exists, and the first microservice is a target microservice that needs to modify the decoder, the modification operation of the first microservice is configured to perform a unified response through the management plug-in.

[0209] In this embodiment, a universal plug-in is developed to manage the target microservices that need to modify the decoder.

[0210] In one possible implementation method, the configuration requirements corresponding to the target microservice include:

[0211] If there is a second microservice, and the second microservice is a target microservice that provides a data serialization function, the second microservice is configured to be isolated from other target microservices.

[0212] In this embodiment, the target microservices that provide data serialization functions are separated into separate modules to fundamentally isolate them from services that do not need to modify this variable.

[0213] In a possible implementation method, the merging module 703 is specifically used to merge the server configuration, client configuration and plug-in configuration of multiple target microservices in the target monolithic service in sequence to obtain a monolithic configuration file corresponding to the target monolithic service.

[0214] In this embodiment, the configurations of the target microservices are merged, specifically in the order of server configuration, client configuration, and plug-in configuration.

[0215] In a possible implementation method, the method further includes:

[0216] The inspection module 705 is used to perform a compatibility check on the target monolithic service according to the second container platform and output the inspection result; perform a functional test on the target monolithic service in turn according to the functions of multiple target microservices and output the test result.

[0217] In this embodiment, after the target monomer service is obtained by merging, the target monomer service is checked by the checking module 705 to ensure that the microservice change will not destroy the compatibility of the monomer merger and to ensure the validity of the monomer service.

[0218] In a possible implementation method, the configuration module 701 is further used to obtain a target monolithic service, and determine a plurality of target microservices corresponding to the target monolithic service according to the service configuration information;

[0219] It also includes: a splitting module 706, which is used to split the target single service to obtain multiple target microservices.

[0220] In a possible implementation method, the splitting module 706 is specifically used to split the entry layer code of the target monomer service to obtain multiple microservice entry codes corresponding to multiple microservices; split the configuration of the target monomer service, and configure multiple target microservices through the corresponding microservice entry codes.

[0221] In a possible implementation method, the inspection module 705 is further configured to perform corresponding functional tests on multiple target microservices respectively and output the test results.

[0222] In this embodiment, after the merging of microservices into monolithic services is realized, the splitting of monolithic services into microservices and the inspection of the split microservices can be realized by reversing the merging process.

[0223] Fig. 9: is a schematic diagram of a server structure provided in an embodiment of the present application. The server 300 may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPU) 322 (for example, one or more processors) and memory 332, and one or more storage media 330 (for example, one or more mass storage devices) storing application programs 342 or data 344. Among them, the memory 332 and the storage medium 330 can be short-term storage or permanent storage. The program stored in the storage medium 330 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations in the server. Furthermore, the central processing unit 322 can be configured to communicate with the storage medium 330 to execute a series of instruction operations in the storage medium 330 on the server 300.

[0224] The server 300 may also include one or more power supplies 326, one or more wired or wireless network interfaces 350, one or more input and output interfaces 358, and / or one or more operating systems 341, such as Windows Server 2000. TM , Mac OS X TM , Unix TM ,Linux TM , FreeBSD TM etc.

[0225] The steps performed by the server in the above embodiment can be based on the Fig. 9 The server structure shown.

[0226] In this embodiment, the CPU 322 is used to perform the following steps:

[0227] According to the service configuration information, multiple target microservices to be merged are obtained from the first container platform, where the service configuration information includes a correspondence between the target microservices and the target monomer service;

[0228] Register multiple target microservices into the target monolithic service;

[0229] Merge the configurations of multiple target microservices in the target monolithic service to obtain a monolithic configuration file corresponding to the target monolithic service;

[0230] According to the monomer configuration file, a target monomer service corresponding to the second container platform is constructed.

[0231] Optionally, the CPU 322 is specifically configured to perform the following steps:

[0232] Get multiple microservices from the first container platform;

[0233] According to the running framework of the microservice, multiple microservices are screened to obtain multiple target microservices, and the running framework of the target microservice is the preset framework;

[0234] According to the service configuration information, determine the correspondence between the target microservice and the target monolithic service.

[0235] Optionally, the CPU 322 is specifically configured to perform the following steps:

[0236] Get the registration template file, which is used to generate the entry layer code of the target single service;

[0237] Register multiple target microservices into the target monolithic service according to the registration template file, and generate the entry layer code of the target monolithic service.

[0238] Optionally, the CPU 322 is specifically configured to perform the following steps:

[0239] Get the configuration template file, which includes the configuration requirements corresponding to the target microservice;

[0240] According to the configuration requirements, the configurations of multiple target microservices are merged into the target monolithic service through the entry layer code.

[0241] Optionally, the CPU 322 is specifically configured to perform the following steps:

[0242] If the first microservice exists, and the first microservice is a target microservice that needs to modify the decoder, the modification operation of the first microservice is configured to perform a unified response through the management plug-in.

[0243] Optionally, the CPU 322 is specifically configured to perform the following steps:

[0244] If there is a second microservice, and the second microservice is a target microservice that provides a data serialization function, the second microservice is configured to be isolated from other target microservices.

[0245] Optionally, the CPU 322 is specifically configured to perform the following steps:

[0246] In the target monolithic service, the server configuration, client configuration, and plug-in configuration of multiple target microservices are merged in sequence to obtain a monolithic configuration file corresponding to the target monolithic service.

[0247] Optionally, the CPU 322 is specifically configured to perform the following steps:

[0248] Perform compatibility check on the target single service according to the second container platform and output the check result;

[0249] According to the functions of multiple target microservices, the target monolithic services are tested in turn and the test results are output.

[0250] Optionally, the CPU 322 is specifically configured to perform the following steps:

[0251] According to the service configuration information, obtain the target single service;

[0252] Split the target monolithic service into multiple target microservices.

[0253] Optionally, the CPU 322 is specifically configured to perform the following steps:

[0254] Split the entry layer code of the target single service to obtain multiple microservice entry codes corresponding to multiple microservices;

[0255] Split the configuration of the target single service, and configure multiple target microservices through the corresponding microservice entry code.

[0256] Optionally, the CPU 322 is specifically configured to perform the following steps:

[0257] Perform corresponding functional tests on multiple target microservices respectively and output the test results.

[0258] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0259] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0260] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0261] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0262] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc., and other media that can store program codes.

[0263] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some of the technical features therein by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A service switching method, characterized in that: include: Acquire multiple target microservices to be merged from the first container platform according to the service configuration information, wherein the service configuration information includes a correspondence between the target microservices and the target monomer service; Register the multiple target microservices into the target monomer service; Merging the configurations of the multiple target microservices in the target monomer service to obtain a monomer configuration file corresponding to the target monomer service; The target monomer service corresponding to the second container platform is constructed according to the monomer configuration file.

2. The method according to claim 1, characterized in that: The acquiring, according to the service configuration information, a plurality of target microservices to be merged from the first container platform includes: Get multiple microservices from the first container platform; According to the operation framework of the microservice, the plurality of microservices are screened to obtain the plurality of target microservices, wherein the operation framework of the target microservice is a preset framework; According to the service configuration information, a corresponding relationship between the target microservice and the target monolithic service is determined.

3. The method according to claim 1, characterized in that The registering the multiple target microservices into the target monomer service includes: Obtain a registration template file, wherein the registration template file is used to generate an entry layer code for the target monomer service; Generate the entry layer code according to the registration template file; The multiple target microservices are registered into the target monolithic service through the entry layer code.

4. The method according to claim 3, characterized in that The configuration of merging the multiple target microservices in the target monolithic service includes: Obtain a configuration template file, wherein the configuration template file includes configuration requirements corresponding to the target microservice; According to the configuration requirements, the configurations of the multiple target microservices are merged in the target monolithic service through the entry layer code.

5. The method according to claim 4, characterized in that The configuration requirements corresponding to the target microservice include: If there is a first microservice, and the first microservice is a target microservice that needs to modify the decoder, the modification operation of the first microservice is configured to perform a unified response through the management plug-in.

6. The method according to claim 4, characterized in that The configuration requirements corresponding to the target microservice include: If there is a second microservice, and the second microservice is a target microservice that provides a data serialization function, the second microservice is configured to be isolated from other target microservices.

7. The method according to claim 1, characterized in that The step of merging the configurations of the multiple target microservices in the target monolithic service to obtain a monolithic configuration file corresponding to the target monolithic service includes: In the target monomer service, the server configuration, client configuration and plug-in configuration of the multiple target microservices are merged in sequence to obtain a monomer configuration file corresponding to the target monomer service.

8. The method according to any one of claims 1 to 7, characterized in that: After constructing the target monomer service corresponding to the second container platform according to the monomer configuration file, the method further includes: Performing a compatibility check on the target monomer service according to the second container platform, and outputting a check result; According to the functions of the multiple target microservices, the target monolithic services are tested for functions in turn, and the test results are output.

9. The method according to claim 1, characterized in that: After constructing the target monomer service corresponding to the second container platform according to the monomer configuration file, the method further includes: Obtain the target monomer service; Determine, according to the service configuration information, a plurality of target microservices corresponding to the target monomer service; The target monolithic service is split to obtain a plurality of the target microservices.

10. The method according to claim 9, characterized in that The target monolithic service is split to obtain a plurality of target microservices, including: Splitting the entry layer code of the target single service to obtain multiple microservice entry codes corresponding to the multiple microservices; The configuration of the target single service is split, and multiple target microservices are configured through the corresponding microservice entry code.

11. The method according to claim 9 or 10, characterized in that: After splitting the target monolithic service to obtain a plurality of target microservices, the method further includes: Perform corresponding function tests on the multiple target microservices respectively, and output the test results.

12. A service switching device, characterized in that: include: A configuration module, used to obtain multiple target microservices to be merged according to service configuration information, wherein the service configuration information includes a correspondence between the target microservices and the target monomer service; A registration module, used to register the multiple target microservices into the target monomer service; A merging module, used to merge the configurations of the multiple target microservices in the target monomer service to obtain a monomer configuration file corresponding to the target monomer service; A construction module is used to merge the configurations of the multiple target microservices in the target monolithic service to obtain a monolithic configuration file corresponding to the target monolithic service.

13. A computer device, characterized in that: include: memories, transceivers, processors, and bus systems; Wherein, the memory is used to store programs; The processor is used to execute the program in the memory, including executing the service switching method according to any one of claims 1 to 11; The bus system is used to connect the memory and the processor so that the memory and the processor can communicate with each other.

14. A computer-readable storage medium comprising instructions, which, when executed on a computer, enables the computer to execute the service switching method according to any one of claims 1 to 11.

15. A computer program product comprising a computer program, characterized in that The computer program is executed by a processor to implement the service switching method according to any one of claims 1 to 11.

Images