Micro-service deployment method

Abstract

The invention discloses a micro-service deployment method, which realizes dynamic switching between combined deployment and split deployment through single configuration, and solves the problems of high resource cost and rigid deployment mode in the traditional micro-service architecture. The system controls a deployment form through configuration parameters: in a merging mode, all service modules are packaged into a single application, interaction is realized through local calling, and the method is suitable for a resource limited scene; in the splitting mode, each module is independently deployed as a micro-service, dynamic discovery and remote calling are realized by means of a service registration center, and elastic expansion is supported. According to the scheme, interface uniqueness and component registration are guaranteed to be conflict-free through standardized interface definition and hierarchical component naming rules, and targeted verification is executed for different modes in the starting stage. According to the method, bimorphic deployment of the same set of codes is achieved, the hardware cost can be reduced by 50% or above through the merging mode, the resource utilization rate and the system availability are improved through the splitting mode, and the method is suitable for the full-scene requirement from small and medium-sized enterprises to a large distributed system.

Description

Technical Field

[0001] The present invention relates to the technical field of computer software deployment, and in particular to a microservice deployment method. Background Art

[0002] With the widespread adoption of microservices architecture, the number of system services has increased, leading to a corresponding increase in server resource costs and implementation and deployment costs. Currently, there is a need for a solution that supports flexible service deployment, allowing all services to be deployed together or individually through configuration. However, no mature flexible deployment solution has been found in the existing technology. The typical approach is to create a new project, reference all services, and then package them into a new service for deployment, which is costly to develop and maintain. Summary of the Invention

[0003] The purpose of this invention is to enable the same software system to flexibly adapt to two different operating modes: merge mode and split mode. In merge mode, all functions are packaged in one program and run as a whole; in split mode, different functional modules run as independent programs and call each other through the network.

[0004] To achieve the above object, the present invention provides the following technical solution: comprising the following steps: The following core steps are included: S1: Service interface contract definition: Declare inter-module communication interfaces through open source remote call components, store interface files in a separate directory named after the module, and establish a standardized service call contract; S2: Dual-mode dynamic deployment control: Switches deployment modes based on a single configuration parameter, executes differentiated scanning strategies during the Spring container startup phase, and implements logical isolation between merged and split deployments. S3: Component naming uniqueness management: Assign globally unique identifiers to system components through custom name generation rules, combined with a duplicate name verification mechanism during the startup phase to avoid component registration conflicts; S4: Mode-aware startup verification: Performs targeted configuration verification in merge mode and split mode to ensure the compatibility of the deployment environment with the selected mode.

[0005] Preferably, the dual-mode dynamic deployment control includes: When configured in merged deployment mode, the automatic registration process of remote call components is blocked, and only the local service implementation within the current module is loaded; When configured as split deployment mode, the service registration and discovery mechanism is activated, the module service is registered with the public service registration center, and the creation logic of the remote call proxy is enabled.

[0006] Preferably, the service interface contract definition includes: The interface implementation class follows the single responsibility principle and only contains the method definitions declared in the interface. It is prohibited to expose additional public call entry points. In the event of cross-module interface naming conflicts, the unique identifier field in the interface declaration is used to distinguish different implementations, ensuring the global uniqueness of the contract.

[0007] Preferably, the component naming uniqueness management is achieved by: Adopt hierarchical naming rules to combine the component's package path and class name to generate a unique identifier; A full component scan is triggered during the container initialization phase, and a conflict exception is thrown for duplicated component instances, terminating the startup.

[0008] Preferably, the mode-aware startup check includes: In the merge deployment mode, verify whether the current module contains local implementations of all declared interfaces and prohibit the configuration of service registry related parameters; In split deployment mode, verify the availability of the service registry connection and prohibit the presence of local code of interfaces that should be implemented through remote calls in the service implementation module.

[0009] Preferably, the deployment mode switching is non-invasive to the business code, and the same set of code baselines can be configured to generate a single application or a microservice module to achieve seamless operation under different deployment forms.

[0010] In summary, due to the adoption of the above technology, the beneficial effects of the present invention are: 1. High deployment flexibility: The same set of code can be split and merged through configuration switching to meet the deployment requirements in different scenarios.

[0011] 2. Extremely low system intrusion: Business code does not need to be aware of the deployment mode and only needs to follow the development specifications, which reduces the impact on business code.

[0012] 3. Fail-Fast mechanism: Automatically checks at startup to avoid runtime failures caused by incorrect configuration, thus improving system stability and reliability.

[0013] 4. Significantly reduce server resource usage: In resource-constrained or lightweight application scenarios, different functional modules that originally required multiple independent servers / containers to run can be combined and packaged into an independent application to run, reducing the number of physical servers, virtual machines or container instances required, and saving the consumption of key resources such as server CPU, memory, and network bandwidth.

[0014] 5. Improved Implementation and Deployment Efficiency: By modifying configuration items, you can seamlessly switch between system architectures (merging monolithic components or splitting into microservices) without modifying code or repackaging, greatly simplifying adaptation to different customer environments (such as development, testing, production, or customer sites of varying sizes). In the merged mode, only a single application package needs to be deployed, simplifying configuration (no service registry required). In the split mode, each module follows a unified specification, is independently deployed, and registered with the service discovery center. This streamlined and standardized process speeds up delivery. The same set of code and deployment packages can be configured to adapt to different deployment scenarios, accelerating the development to delivery cycle. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The accompanying drawings, which constitute part of the present invention, are intended to provide a further understanding of the present invention and to make other features, objects, and advantages of the present invention more apparent. The accompanying drawings and descriptions of the exemplary embodiments of the present invention are intended to explain the present invention and do not constitute an undue limitation of the present invention. In the accompanying drawings: Figure 1 This is the process of starting the program of the present invention. DETAILED DESCRIPTION

[0016] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the invention for which protection is sought, but merely represents selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0017] In the description of the present invention, it should be understood that the terms indicating orientation or positional relationships are based on the orientation or positional relationships shown in the accompanying drawings and are only used to facilitate the description of the present invention and simplify the description. They do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operate in a specific orientation. Therefore, they cannot be understood as limiting the present invention.

[0018] In the present invention, unless otherwise expressly specified or limited, the terms "mounted," "connected," "connect," "fixed," etc. should be understood broadly. For example, they may refer to fixed connection, detachable connection, or integration; mechanical connection or electrical connection; direct connection or indirect connection through an intermediate medium; internal communication between two components or interaction between two components. Those skilled in the art will be able to understand the specific meanings of the above terms in the present invention based on the specific circumstances of the specification.

[0019] The present invention provides a microservice deployment method, a parallel Monte Carlo fast dose calculation method based on NVIDIA Ampere graphics card, comprising the following steps: 1. Service interface definition During service development, interfaces are defined using Feign. Each module's externally exposed services (APIs) must be declared in a dedicated interface file, using the open-source @FeignClient component. These interface files must be placed in a folder named [module name]-api, for example, product-api.

[0020] 2. Service interface implementation The Controller needs to implement the Feign interface definition in step 1. The module must have a dedicated class (marked with @RestController) to implement these publicly declared interfaces. This implementation class can only contain the methods defined in the interface and cannot add additional public call entry points. If different modules in the entire system happen to declare interfaces with exactly the same name (not recommended), they must be uniquely identified by using contextId in @FeignClient, such as contextId="product-v1", to distinguish them and avoid confusion.

[0021] 3. Deployment mode control New configuration items are added to configure the current deployment mode. When the Spring container starts, the scan scope is controlled according to the configured deployment mode: If it is a split deployment: scan and register FeignClient.

[0022] For combined deployment: disable FeignClient.

[0023] The specific configuration items are designed to add configuration options in the system configuration file to control the deployment mode. The startup operations under different deployment modes are as follows: Merge deployment: The system turns off the function of automatically searching for and connecting to other modules. When starting, it only loads the code inside the current package and ignores the configuration of communication with other modules. Split deployment: The system will enable the service discovery function and register the services it provides to a public service registration center (such as Nacos), so that other modules can discover it. At the same time, it can also discover and connect to the services of other modules it needs to call through the registration center. 4. Bean name generation optimization Customize the SpringBean name generation rules to avoid startup errors caused by defining beans with the same name in different services. Enforce unique naming rules: component name = package name + fully qualified class name. When the system loads all components at startup, it automatically checks to see if two components have the same name. If a duplicate name is found, the system will immediately report an error and stop the startup, clearly indicating the conflict.

[0024] 5. Start the inspection mechanism After the service is started, a check is performed and the service is terminated immediately if a configuration conflict is found. The specific check rules are as follows: Merge deployment: The current package must contain the specific implementation code of all declared interfaces. Configuring client information for connecting to service registries (such as Eureka / Nacos) is prohibited. If a failure occurs, the startup will be stopped immediately and an error message will be thrown. Split deployment: The system must be able to successfully connect to the designated service registry. It is prohibited for the module that provides the interface implementation to have specific implementation code of the interface that should be called through the network (to prevent short-circuit calls) and stop starting immediately after failure.

[0025] Example 1: Combined deployment mode in small and medium-sized enterprise scenarios Application Background: An e-commerce company is in its early stages of development and has limited server resources (only one physical server). It needs to quickly launch a system that includes order, inventory, and payment functions without the need for a complex distributed architecture.

[0026] Implementation process: 1. Deployment mode configuration Set deployment.mode=merge in the system configuration file to declare the use of merge deployment mode.

[0027] When the system starts, the service registry connection logic is automatically disabled and only the service implementation code of the local module is loaded.

[0028] 2. Service module integration The interface implementation classes of the order module, inventory module, and payment module are packaged into the same application, and the modules interact through local method calls (for example, directly calling the inventory deduction method of the inventory module when creating an order).

[0029] 3. Start verification The system checks whether the current package contains local implementations of all interfaces (such as the implementation classes of the order query interface and inventory deduction interface). It starts normally after verification.

[0030] Because it is configured in merge mode, the system skips the connection verification of the service registry (such as Nacos).

[0031] 4. Final effect Only a single application package needs to be deployed to the server, which reduces resource usage by 60% (compared to traditional microservice split deployment), saving approximately RMB 30,000 in hardware costs per year.

[0032] Development teams no longer need to maintain multiple service instances, and troubleshooting efficiency is improved by 50% (problem location is centralized in a single code base).

[0033] Example 2: Split deployment mode in large enterprise scenarios Application Background: An internet company needs to support millions of daily active users. The system must be highly scalable and fault-tolerant. Each service module must be independently deployed and dynamically scaled.

[0034] Implementation process: 1. Deployment mode configuration Set deployment.mode=split and configure the service registry address (such as spring.cloud.nacos.discovery.server-addr=cluster.nacos.com).

[0035] When the system starts, the Feign remote call mechanism is activated and each module service is registered with Nacos (for example, the order service is registered as order-service and the inventory service is registered as stock-service).

[0036] 2. Inter-module communication The order module declares the call requirements for the inventory module through the Feign interface (such as "query inventory balance"). When actually calling, it obtains the real-time IP and port of the inventory service through Nacos and initiates an HTTP request.

[0037] When the inventory service needs to be expanded due to a surge in traffic, new instances can be deployed independently, and Nacos will automatically load balance the requests to all available instances.

[0038] 3. Start verification The system verifies whether it can successfully connect to Nacos (by sending heartbeat packets). If the connection fails, the startup is terminated and the prompt "Registration Center Unavailable" is displayed.

[0039] Check each module to see if there is any local code for interfaces that should be implemented through remote calls (for example, it is prohibited to directly write inventory deduction logic in the order module) to avoid short-circuiting the call chain.

[0040] 4. Final effect Order service, inventory service, and payment service are independently deployed as three microservice clusters. The failure of a single module does not affect the operation of other modules, and the system availability is improved to 99.95%.

[0041] Dynamic optimization of resource utilization: During promotional periods, the order service can be expanded to 100 instances, and reduced to 10 instances under normal traffic conditions, saving 40% of cloud resource costs compared to fixed deployment.

Claims

1. A microservice deployment method, characterized by: The following steps are involved: S1: Service interface definition and isolation: Declare inter-module communication interfaces through open-source remote call components, store interface files in a separate directory named after the module, and establish standardized service call contracts. S2: Dynamically switch deployment modes: Switch deployment modes based on a single configuration parameter, execute differential scanning strategies during the Spring container startup phase, and achieve logical isolation between merged and split deployments. S3: Ensure component naming uniqueness: Customize the bean name generator, enforce the use of the package name + fully qualified class name combination rule to generate a unique identifier, and trigger the duplicate name verification mechanism at startup; S4: Dual-mode startup verification: Perform targeted configuration verification in merge mode and split mode respectively. If the verification fails, the service startup is terminated and a clear error log is output.

2. A microservice deployment method according to claim 1, characterized in that: The dynamic switching of the deployment mode specifically includes: When configured in merged deployment mode, the automatic registration process of remote call components is blocked, and only the local service implementation within the current module is loaded; When configured as split deployment mode, the service registration and discovery mechanism is activated, the module service is registered with the public service registration center, and the creation logic of the remote call proxy is enabled.

3. A microservice deployment method according to claim 1, characterized in that: The service interface definition and isolation further includes: The interface implementation class follows the single responsibility principle and only contains the method definitions declared in the interface. It is prohibited to expose additional public call entry points. In the event of cross-module interface naming conflicts, a unique identifier field in the interface declaration is used to distinguish different implementations, ensuring the global uniqueness of the contract.

4. A microservice deployment method according to claim 1, characterized in that: The component naming uniqueness is guaranteed by: Adopt hierarchical naming rules to combine the component's package path and class name to generate a unique identifier; A full component scan is triggered during the container initialization phase, and a conflict exception is thrown for duplicated component instances, terminating the startup.

5. A microservice deployment method according to claim 1, characterized in that: The dual-mode startup verification includes: Merge mode verification: Verify whether the current module contains local implementation classes of all declared interfaces, and prohibit the configuration of service registry related parameters; Split mode validation: Verify the availability of the service registry connection and prohibit the existence of local implementation code of the interface that should be called through Feign in the interface implementation module.

6. The microservice deployment method according to any one of claims 1 to 5, characterized in that: It also includes deployment-agnostic business development specifications: Business code does not need to rely on deployment mode switching logic, and only needs to be developed according to the Feign interface definition specification; The same code baseline can be configured to directly generate a single application package or a microservice module package, achieving "one-time development, dual-mode deployment".

Images