A cloud-native multi-environment management method

Abstract

The present invention relates to the field of cloud native technology, and provides a method for cloud native multi-environment management, comprising the steps of: S1, initializing the parent environment; S2, building the child environment; S3, injecting the environment tag and deploying the application; S4, adding configuration to the service request header; S5, service grid scheduling; S6, providing services in multiple environments; S7, recycling the child environment. Multiple environments can be established with a small number of applications, which can save costs while improving management efficiency and improving the efficiency of microservice docking between two or more parties. A whole set of environments can be built in batches, which is different from the general single-unit deployment method. Multiple environments can be established with a small number for use by multiple people, which is different from the general multi-environment management method. The parent environment has a whole set of applications to ensure normal service response, which is different from the general multi-environment management method.

Description

Technical Field

[0001] The present invention relates to the field of cloud native technology, and in particular to a method for cloud native multi-environment management. Background Art

[0002] At present, the cloud-native environment has been developing rapidly. Many microservices have switched from traditional host deployment to container deployment. There are a large number of microservices. Each R&D team has dozens or hundreds of microservices that need to be developed and debugged every day. Each R&D staff is responsible for one or more microservices. In this process, each employee will deploy a complete set of microservice environments for verification. However, this will bring the following problems:

[0003] First, if everyone builds a complete microservice environment, management will be complex and the cost of environmental resources will be too high.

[0004] Secondly, if a public environment is used for construction, there will be a problem of multiple versions of one environment, which is difficult to manage and difficult for two or more parties to connect, resulting in low work efficiency. Summary of the invention

[0005] To solve the above problems, the present invention proposes a method for cloud-native multi-environment management, which can solve the problems in the prior art of complex management, high environmental resource costs, or the existence of multiple versions of an environment, which makes management difficult and difficult for two or more parties to connect, resulting in low work efficiency.

[0006] To achieve the above object, the technical solution adopted by the present invention is:

[0007] A method for managing cloud-native multiple environments, comprising the steps of: S1, initializing a parent environment; S2, building a child environment; S3, injecting an environment tag and deploying an application; S4, adding configuration to a service request header; the step S4 comprises: adding an environment identifier to a client service request header and adding a scheduling strategy at the same time; the environment identifier is the name of the environment that the client needs to access; the scheduling strategy is to schedule to microservices in different environments according to the content of the header when request routing; S5, service grid scheduling; the step S5 comprises: the service grid matches the environment name of the child environment according to the environment identifier, the request address and the scheduling strategy; if the match is successful, the request is scheduled to one of the microservices in the child environment; if the match fails, the request is scheduled to the microservice of the parent environment; the service grid is a dedicated infrastructure layer for using a proxy to promote service-to-service communication between services or microservices, and The routing rules of each microservice can be controlled according to the scheduling strategy; S6, providing services in multiple environments; the step S6 includes: when the upstream microservice needs to access the downstream microservice, the environment identifier is added to the request header, and the service grid schedules the microservice of the corresponding environment again according to the environment identifier; the environment name of the current environment is matched, and if the microservice does not exist in the current environment, it is scheduled to the microservice with the same name in the upper-level environment to ensure that the request can get a normal response; if the upper level does not exist, the upper-level environment is found; wherein, if the current environment is a sub-environment, the upper-level environment is the sub-environment, and the upper-level environment is the parent environment; the microservice name of the sub-environment is consistent with the microservice name of the parent environment, and the code branch deployed with the microservice of the sub-environment is different, the number of microservices is less than or equal to the number of sub-environments of the parent environment, and the environment identifier of the sub-environment is parent environment name. Sub-environment name. Sub-sub-environment name; S7, recycling the sub-environment.

[0008] In one embodiment, step S1 includes: initializing a cloud-native container environment, creating one or more parent environments as public environments; wherein the parent environment is a complete and stable environment, and the public environment is each microservice of the entire platform or system, which is used to provide services to the outside world as a whole, and the public environment is all based on container deployment.

[0009] In one embodiment, step S2 includes: building a microservice product of a child environment with one click; the microservice name of the child environment is consistent with the microservice name of the parent environment, the code branch deployed by the microservice is different from that of the microservice of the parent environment, and the number of microservices is less than or equal to the number of child environments in the parent environment; the product is a container image of the microservice.

[0010] In one embodiment, step S3 includes: injecting an environment label into the microservice of the sub-environment, and batch deploying all the microservices of the sub-environment; the environment label is that the label name of the sub-environment microservice is equal to the parent environment name.sub-environment name; wherein the . symbol represents the separator between two environments.

[0011] In one embodiment, step S7 includes: when the sub-environment does not need to provide services, all microservices on the sub-environment are recycled, and the service grid deletes the scheduling policy corresponding to the environment name.

[0012] The beneficial effects achieved by the present invention are:

[0013] Multiple environments can be set up with a smaller number of applications, which can save costs, improve management efficiency, and enhance the efficiency of microservice docking between two or more parties.

[0014] Batch build a whole set of environments, which is different from the general single-machine deployment method. Multiple environments can be built with a small number of them for multiple people to use, which is different from the general multi-environment management method. The parent environment has a whole set of application quantities to ensure normal service response, which is different from the general multi-environment management method. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 Shown is a flowchart of the multi-environment management method in the present invention.

[0016] Figure 2 Shown is a system structure block diagram of the multi-environment management method in the present invention. DETAILED DESCRIPTION

[0017] In order to make the purpose, technical solution and advantages of the technical solution more clear, the technical solution is further described in detail below in conjunction with specific implementation methods. It should be understood that these descriptions are only exemplary and are not intended to limit the scope of the technical solution.

[0018] The present invention provides a method for cloud native multi-environment management, comprising the steps of:

[0019] S1. Initialize the parent environment. In one embodiment, the code may be used:

[0020] / **

[0021] * Initialize the parent environment.

[0022] *@paramreq request parameters

[0023] *@returnResponseInit returns the result

[0024] * /

[0025] func (l *Multi) Init(req types.RequestInit) (*types.ResponseInit,error) {

[0026] return l.svcCtx.Init()

[0027] }

[0028] S2. Build a sub-environment. In one embodiment, the code may be used:

[0029] / **

[0030] * Initialize the parent environment.

[0031] *@paramreq request parameters

[0032] *@returnResponseBuildChild returns the result

[0033] * /

[0034] func (l *Multi) BuildChild(req types.RequestBuildChild) (*types.ResponseBuildChild, error) {

[0035] return l.svcCtx.BuildChild()

[0036] }

[0037] S3. Inject environment tags and deploy applications. In one embodiment, the code may be used:

[0038] / **

[0039] * Initialize the parent environment.

[0040] *@paramreq request parameters

[0041] *@returnResponseDeploy returns the result

[0042] * /

[0043] func (l *Multi) Deploy(req types.RequestDeploy) (*types.ResponseDeploy, error) {

[0044] return l.svcCtx.Deploy()

[0045] }

[0046] S4. Add configuration to the service request header. In one embodiment, the code may be used:

[0047] / **

[0048] * Initialize the parent environment.

[0049] *@paramreq request parameters

[0050] *@returnResponseConfig returns the result

[0051] * /

[0052] func (l *Multi) Config(req types.RequestConfig) (*types.ResponseConfig, error) {

[0053] return l.svcCtx.Config()

[0054] }

[0055] S5, service grid scheduling; in one embodiment, the code may be used:

[0056] / **

[0057] * Initialize the parent environment.

[0058] *@paramreq request parameters

[0059] *@returnResponseDispatch returns the result

[0060] * /

[0061] func (l *Multi) Dispatch(req types.RequestDispatch) (*types.ResponseDispatch, error) {

[0062] return l.svcCtx.Dispatch()

[0063] }

[0064] S6. Provide services in multiple environments;

[0065] S7, recycle the sub-environment. In one embodiment, the code may be used:

[0066] / **

[0067] * Initialize the parent environment.

[0068] *@paramreq request parameters

[0069] *@returnResponseRecycle returns the result

[0070] * /

[0071] func (l *Multi) Recycle(req types.RequestRecycle) (*types.ResponseRecycle, error) {

[0072] return l.svcCtx.Recycle()

[0073] }

[0074] Typically, step S1 includes: initializing a cloud native container environment, creating one or more parent environments that are public environments; wherein the parent environment is a complete and stable environment, the public environment is each microservice of the entire platform or system, used to provide services to the outside world as a whole, and the public environment is all based on container deployment. Step S2 includes: building a microservice product of a child environment with one click; the microservice name of the child environment is consistent with the microservice name of the parent environment, the code branch deployed by the microservice is different from that of the microservice of the parent environment, and the number of microservices is less than or equal to the number of child environments in the parent environment; the product is a container image of a microservice. Step S3 includes: injecting an environment label into the microservice of the child environment, and batch deploying all microservices of the child environment; the environment label is that the label name of the microservice of the child environment is equal to the parent environment name. The child environment name; wherein the symbol. represents the separator of the two environments. Step S4 includes: adding an environment identifier to the client service request header, and adding a scheduling strategy at the same time; the environment identifier is the name of the environment that the client needs to access; the scheduling strategy is that when requesting routing, it is scheduled to microservices of different environments according to the content of the header. The step S5 includes: the service grid is scheduled according to the environment identifier, request address and scheduling policy, and matched with the environment name of the child environment; if the match is successful, the request is scheduled to one of the microservices in the child environment; if the match fails, it is scheduled to the microservice of the parent environment; the service grid is a dedicated infrastructure layer for using agents to promote service-to-service communication between services or microservices, and the routing rules of each microservice can be controlled according to the scheduling policy. The step S6 includes: when the upstream microservice needs to access the downstream microservice, the environment identifier is added to the request header, and the service grid dispatches the microservice of the corresponding environment again according to the environment identifier; the environment name of the current environment is matched, and if the microservice does not exist in the current environment, it is dispatched to the microservice of the same name in the upper-level environment to ensure that the request can get a normal response; if the upper level does not exist, the upper-level environment is found; wherein, if the current environment is a sub-sub environment, the upper-level environment is the sub-environment, and the upper-level environment is the parent environment; the microservice name of the sub-sub environment is consistent with the microservice name of the parent environment, and the code branch deployed with the microservice of the sub-environment is different, the number of microservices is less than or equal to the number of sub-environments of the parent environment, and the environment identifier of the sub-sub environment is the parent environment name. Sub-environment name. Sub-sub-environment name. The step S7 includes: when the sub-environment does not need to provide services, all microservices on the sub-environment are recovered, and the service grid deletes the scheduling policy corresponding to the environment name. Multiple environments can be established with a small number of applications, while saving costs, improving management efficiency, and improving the efficiency of docking microservices of both parties or multiple parties. Batch build of the entire environment is different from the general single-machine deployment method. Multiple environments can be built with a small number of units for multiple people to use, which is different from the general multiple environment management method.The parent environment has a complete set of application quantities to ensure normal service response, which is different from the general multi-environment management method.

[0075] The above contents are only preferred embodiments of the present invention. For ordinary technicians in this field, many changes can be made in the specific implementation methods and application scopes based on the ideas of the present technical content. As long as these changes do not deviate from the concept of the present invention, they all fall within the scope of protection of this patent.

Claims

1. A method for managing cloud-native multiple environments, characterized in that: Includes steps: S1, initialize the parent environment; S2, build sub-environment; S3, inject environment tags and deploy applications; S4, service request header adds configuration; the step S4 comprises: The client service request header adds an environment identifier and a scheduling strategy. The environment identifier is the name of the environment that the client needs to access; The scheduling strategy is to schedule the request to microservices in different environments according to the content of the header when routing the request; S5, service grid scheduling; the step S5 includes: The service grid is scheduled according to the environment identifier, request address and scheduling strategy, and matches the environment name of the sub-environment; if the match is successful, the request is scheduled to one of the microservices in the sub-environment; if the match fails, it is scheduled to the microservice of the parent environment; The service grid is a dedicated infrastructure layer that uses proxies to facilitate service-to-service communication between services or microservices, and can control the routing rules of each microservice according to the scheduling policy; S6. Multi-environment provisioning; step S6 includes: When the upstream microservice needs to access the downstream microservice, the environment identifier is added to the request header. The service grid dispatches the microservice of the corresponding environment based on the environment identifier. Match the environment name of the current environment. If the microservice does not exist in the current environment, it will be dispatched to the microservice with the same name in the previous environment to ensure that the request can get a normal response. If the previous environment does not exist, it will search for the previous environment. If the current environment is a sub-environment, the previous environment is the sub-environment, and the previous environment is the parent environment. The microservice name of the sub-sub-environment is consistent with the microservice name of the parent environment, the code branch deployed with the microservice of the sub-sub-environment is different, the number of microservices is less than or equal to the number of sub-environments of the parent environment, and the environment identifier of the sub-sub-environment is parent environment name.sub-environment name.sub-sub-environment name; S7. Recycle the sub-environment.

2. The multi-environment management method according to claim 1, characterized in that: The step S1 comprises: Initialize the cloud-native container environment and create one or more parent environments that are public environments. The parent environment is a complete and stable environment, and the public environment is each microservice of the entire platform or system, which is used to provide services to the outside world as a whole. The public environment is all deployed based on containers.

3. The multi-environment management method according to claim 2, characterized in that: The step S2 comprises: Build microservice products of sub-environment with one click; The microservice name of the child environment is consistent with the microservice name of the parent environment, the code branch deployed by the microservice is different from that of the microservice of the parent environment, and the number of microservices is less than or equal to the number of child environments in the parent environment; The artifact is a container image of a microservice.

4. The multi-environment management method according to claim 3, characterized in that: The step S3 comprises: Inject environment tags into the microservices of the sub-environment and batch deploy all microservices of the sub-environment; The environment tag is the sub-environment microservice tag name which is equal to the parent environment name x sub-environment name; The . symbol represents the separator between two environments.

5. The multi-environment management method according to claim 4, characterized in that: The step S7 comprises: When a sub-environment no longer needs to provide services, all microservices on the sub-environment are recycled, and the service grid deletes the scheduling policy corresponding to the environment name.

Images