A nuclear power production service governance system and method based on a service mesh

Abstract

The present invention belongs to the field of computer technology, and particularly relates to a nuclear power production service governance system and method based on a service mesh, including a service mesh and a Sidecar module. The beneficial effects of the present invention are as follows: it explains the implementation principle and deployment structure of the service mesh. Compared with the traditional microservice governance solution, the service mesh, as a module that operates independently outside the application service, has simple configuration operations, realizes decoupling from the business service code, liberates the work of business developers in microservice governance, easily realizes the microservice governance function, reduces the work pressure of the development team, and at the same time facilitates the operation and maintenance personnel to uniformly manage the application services of each department and the company.

Description

Technical Field

[0001] The present invention belongs to the field of computer technology, and particularly relates to a nuclear power production service governance system and method based on a service mesh. Background Art

[0002] With the continuous growth of the user base in the Internet era, more and more enterprises use the microservice architecture to cope with high-concurrency scenarios. Subsequently, some problems between services have arisen in the microservice architecture. The traditional microservice governance solution is to handle within the microservice, by introducing a governance dependency package to add annotations or setting governance function code, which has business code invasiveness, high version upgrade costs, and cannot achieve rapid iteration. Currently, nuclear power plants have put forward higher requirements for the governance of software microservices. By adopting the service mesh method to govern microservices, the overall efficiency can be improved. The service mesh separates most of the governance functions from the application business processing, runs independently, and is deployed in the Sidecar mode to ensure the separation of business and governance functions, and the upgrade and iteration do not affect each other. Summary of the Invention

[0003] The purpose of the present invention is to provide a nuclear power production service governance system and method based on a service mesh, which can solve the problems between services brought by the existing microservice architecture.

[0004] The technical solution of the present invention is as follows: A nuclear power production service governance system based on a service mesh includes a service mesh and a Sidecar module.

[0005] The service mesh, as the infrastructure layer, is used to handle communication between services and deliver reliable network requests to application services.

[0006] The Sidecar module is deployed using containers. Based on containers as units, a Sidecar container is attached to a Pod deployed in a Kubernetes cluster. The Sidecar and the application service are deployed on the same Host. The service and the Sidecar are two independent containers, achieving physical isolation.

[0007] A nuclear power production service governance method based on a service mesh includes the following steps:

[0008] Step 1: Service mesh environment setup

[0009] Step 2: Service governance.

[0010] For the implementation of the service mesh in Step 1, a Kubernetes cluster environment is required before installation, and the service mesh image of the corresponding version is selected.

[0011] The Kubernetes cluster uses version v1.18.8.

[0012] Step 1 described above includes the following steps:

[0013] 1) Download the service mesh installation package, switch to the directory where the installation package is located, and use the install command for installation;

[0014] 2) Check whether the installation is successful. Use the kubectl get pod command to check whether the services in the namespace are deployed normally and whether the pods are running normally;

[0015] 3) Scope for enabling the service mesh

[0016] Namespace: The service mesh can be enabled under a specified namespace. All Pod applications under the namespace where the service mesh is enabled will automatically be injected with a sidecar container;

[0017] Specified service: In a namespace where the service mesh is not enabled, it is also possible to specify the deployed service and inject a sidecar into its application Pod.

[0018] Step 2 described above includes the following steps:

[0019] 1) Deployment of the service to be governed:

[0020] Prepare two versions of the demo service with images demo:v1 and demo:v2 respectively. Prepare the deployment files. Add meshSvcName:demo under the selector of the Service resource configuration file. The role of this selector is to import the traffic of this Service into the Pod instance services with this label respectively; Add the meshSvcName:demo label to the Pod configuration, corresponding to the content in the Service resource configuration selector, and create the Pod and Service resources respectively;

[0021] 2) Create a route to implement service gray scale by weight

[0022] Create two CRD resources, VirtualService and DestinationRule, respectively. The VirtualService resource is used to configure service routing related information. The host is used to set the routing service, the subset is used to specify the service version to which the route is made, and the weight is used to set the traffic weight of the routing service; The DestinationRule resource is used to define the service version. The hosts service is used to set the target service, and the subsets item is used to set the service sub-version information; Creating the resources completes the control of service gray scale by weight.

[0023] The beneficial effects of the present invention are as follows: It explains the implementation principle and deployment structure of the service mesh. Compared with the traditional microservice governance solution, as an independent module running outside the application service, the service mesh has simple configuration operations, realizes decoupling from the business service code, liberates the work of business developers in microservice governance, easily realizes microservice governance functions, reduces the work pressure of the development team, and also facilitates the operation and maintenance personnel to uniformly manage the application services of each department and the company. Detailed implementation manners

[0024] The present invention will be further described in detail below with reference to specific embodiments.

[0025] A nuclear power production service governance system based on a service mesh includes a service mesh and a Sidecar module.

[0026] The described service mesh serves as the infrastructure layer, which is used to handle the communication between services and deliver reliable network requests to the application service. In actual use, the service mesh is usually deployed together with the application program. As a lightweight network proxy for the application service, it is transparent to the application.

[0027] The described Sidecar module is generally deployed using containers. Based on containers as units, a Sidecar container will be attached when deploying a Pod in a Kubernetes cluster. The Sidecar and the application service are deployed on the same Host. The service and the Sidecar are two independent containers, realizing physical isolation and being language-independent. Therefore, it can be independently released and individually controlled. As long as it is a function unrelated to the business, multiple Sidecars can be formed without affecting the business service. Since the two are on the same Host, resources can access each other. When application services normally send and receive requests, there is no need to pay attention to other processing. The Sidecar will capture these messages and provide governance functions such as service registration discovery, intelligent routing, circuit breaking, fault recovery, and access control for the runtime service. For the service, there is no need to know about communicating with the Sidecar. Services communicate through the Sidecar proxy.

[0028] A nuclear power production service governance method based on a service mesh includes two parts: basic mesh environment deployment and Kubernetes CRD resource creation. Among them, establishing the mesh environment is the basis for realizing microservice governance.

[0029] Specifically:

[0030] Step 1: Build the service mesh environment

[0031] For the service mesh implementation, a Kubernetes cluster environment is required before installation, and the service mesh image of the corresponding version is selected. The Kubernetes cluster uses version v1.18.8.

[0032] There are many advantages to using a service mesh:

[0033] 1) Microservice governance can be easily achieved by using a service mesh with little or no changes to the service code.

[0034] 2) Only one special Sidecar proxy is needed to support the services in the entire environment.

[0035] 3) Rich routing rules are provided for fine-grained traffic control. Service-level control can be achieved by configuring routing rules, and functions such as canary release, failover, and fault injection can be easily completed.

[0036] 4) Comprehensive service governance functions, including load balancing, authentication and authorization, logging and tracing, monitoring, etc.

[0037] Prepare the images required for the installation environment:

[0038] 1) Download the service mesh installation package, switch to the directory where the installation package is located, and use the install command for installation. Depending on the current network and machine conditions, the installation takes some time, and the installation information of the corresponding modules will be output in the terminal.

[0039] 2) Check whether the installation is successful. Use the kubectl get pod command to check whether the services are normally deployed in the namespace and whether the pods are running normally. Generally, if the status is Running, it is considered that the service is running normally.

[0040] 3) Service mesh enablement scope

[0041] Namespace: The service mesh can be enabled in a specified namespace. All Pod applications in the namespace where the service mesh is enabled will automatically be injected with a sidecar container.

[0042] Specified service: In a namespace where the service mesh is not enabled, a deployed service can also be specified to inject a sidecar into its application Pod.

[0043] Step 2: Service governance

[0044] 1) Deployment of the services to be governed:

[0045] Prepare two versions of the demo service with images demo:v1 and demo:v2 respectively, and prepare the deployment files. Add meshSvcName:demo under the selector of the Service resource configuration file. The role of this selector is to import the traffic of this Service into the Pod instance services with this label respectively; add the meshSvcName:demo label in the Pod configuration, corresponding to the content in the Service resource configuration selector, and create the Pod and Service resources respectively.

[0046] 2) Create a route to achieve service gray scale by weight

[0047] Create two CRD resources, VirtualService and DestinationRule, respectively. The VirtualService resource is used to configure service routing related information. host is used to set the routing service, subset is used to specify the service version to be routed to, and weight is used to set the traffic weight of the routing service; the DestinationRule resource is used to define the service version. The hosts service is used to set the target service, and the subsets item is used to set the service sub-version information; creating the resources normally completes the control of service gray scale by weight. The main configuration content is as follows:

[0048] In this example, the traffic weight of the v1 version of the demo service is set to 70%, and the traffic weight of the v2 version is set to 30%. Use the following script command to send 1000 requests to the / version interface of the demo service. This interface will output the version information of the current instance. After all the requests are completed, use the command to count the number of requests for the two versions. As shown in the test results, the ratio of the traffic transferred to the v1 and v2 versions when the demo service is called is 7:3. Correspondingly, the function of routing to the specified service version can also be achieved by setting the http match item to match the request headers to match different users or different headers parameter contents.

Claims

1. A nuclear power production service governance method based on a service mesh, characterized in that, It includes the following steps: Step 1: Build the service mesh environment; The said Step 1 includes the following steps: 1) Download the service mesh installation package, switch to the directory where the installation package is located, and use the install command to install it; 2) Check whether the installation is successful. Use the kubectl get Pod command to check whether the services in the namespace are deployed normally and whether the Pods are running normally; 3) The scope for enabling the service mesh Namespace: The service mesh is enabled under the specified namespace. A sidecar container will be automatically injected into all Pod applications under the namespace where the service mesh is enabled; Specified service: In the namespace where the service mesh is not enabled, specify the deployed service and inject a sidecar into its application Pod; Step 2: Service governance; The said Step 2 includes the following steps: 1) Deployment of the service to be governed: Prepare two versions of the demo service with images demo:v1 and demo:v2 respectively. Prepare the deployment file. Add meshSvcName: demo under the selector of the Service resource configuration file. The function of this selector is to import the traffic of this Service into the Pod instance services with this label respectively; Add the meshSvcName: demo label to the Pod configuration, corresponding to the content in the Service resource configuration selector, and create Pod and Service resources respectively; 2) Create a route to achieve service gray scale by weight Create two CRD resources, VirtualService and DestinationRule, respectively. The VirtualService resource is used to configure service routing related information. host is used to set the routing service, subset is used to specify the service version to be routed to, and weight is used to set the traffic weight of the routing service; The DestinationRule resource is used to define the service version. The hosts service is used to set the target service, and the subsets item is used to set the service sub-version information; Creating the resources completes the control of service gray scale by weight.

2. The method for governing nuclear power production services based on a service mesh according to claim 1, characterized in that: For the implementation of the service mesh in the said Step 1, a Kubernetes cluster environment is required before installation, and select the service mesh image of the corresponding version.

3. The method for governing nuclear power production services based on a service mesh according to claim 2, wherein: The Kubernetes cluster uses version v1.18.8.