Shulou(Shulou.com)06/01 Report--

This article focuses on "how to use the service mesh of microservices". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "how to use service mesh of microservices".

1. Service mesh (Service Grid) 1. The birth background of service mesh

Since the rise of micro-services and cloud computing, numerous excellent micro-service architectures have been born, which have brought great convenience to development and deployment, and agile development has obtained the best practice scenarios. However, while micro-service mode brings convenience and high performance, it will inevitably lead to the expansion of the number of services, the complexity of processing links, and the differentiation of underlying architecture and micro-service framework, so service governance has become a new pain point. in order to solve the above scenarios, the concept of service mesh was born.

Service mesh (Service Grid) plays the role of message forwarding by adding some service instances decoupled from business services in the micro-service network. In essence, it adds a communication management layer in the application layer to manage the service interoperability, service discovery, service governance, link tracking, health monitoring and other problems of micro-services in the network. After using the service grid, without any changes at the business level, cross-team service design, language selection, heterogeneous architecture communication, link management, service governance and other problems that need to be considered in previous complex systems can be solved in a unified infrastructure framework.

So how exactly did you do it? By adding a proxy service, the service grid runs in parallel with the original micro-service on the same infrastructure, which can be a physical machine or a container. This proxy service has two main functions:

(1) request proxy, all requests sent directly to the micro-service will be intercepted by the proxy instance, and the agent will forward the request to the real micro-service for processing, and all requests initiated by the original micro-service will be forwarded to the agent first. The agent initiates the request to the external micro-service network.

(2) to form visible micro-service network nodes, this agent needs to expose itself to the micro-service network world in some way, such as registering with a distributed service center, participating in the service network on behalf of business service instances, and performing complex service governance policies, call chain tracking, routing control and other functions.

Proxy in the following figure represents service grid instance, and server represents micro-service instance, which is the main mode of service grid. You can see that each micro-service instance has a separate service grid instance to serve it, which can be understood as two micro-services running side by side in the driveway. Server handles business requests and is responsible for business-level work. Proxy services block traffic in and out of server, and are responsible for micro-service communication and governance issues.

This paper mainly introduces the implementation of service grid with Apache project servicecomb-mesher, and other projects are not introduced.

Figure 1 aerial view of the service grid

II. Servicecomb-mesher

Servicecomb-mesher is the service grid project of Apache servicecomb. Using go language based on go-chassis open source framework, go-chassis framework supports micro-service capabilities such as load balancing, flow control, call chain tracking, circuit breaker degradation, service governance and dynamic configuration management in the form of plug-ins. Mesher currently supports both sidecar and edgeservice operation modes. Support for communication between services using http, grpc protocols, with good scalability, users can expand their own protocols. Mesher handles requests in the form of a call chain, and you can tailor the processing function freely according to the configuration. In the control plane, mesher can naturally access the apache servicecomb micro-service system. And it is compatible with the current mainstream service-mesh, supports kubernetes, and can be connected to Istio.

Fig. 2 mesher interaction model diagram

2.1 Analysis of the principle of Servicecomb-mesher

We run mesher in sidecar mode and introduce what mesher has done through a specific http protocol communication.

(1) We start a real http server as a business service. There are no restrictions on the implementation language and service framework of http server.

(2) starting mesher,mesher starts two http services based on configuration information, which listen on local loopback and local ip (such as 127.0.0.1 ip 30101 and 192.168.88.64 ip 30101). Mesher handles request traffic from internal business services to external through 127.0.0.1 30101; listens for services at 192.168.88.64 to handle external request traffic to internal business services

(3) as shown in the figure, client is a request initiator, and the request of client is forwarded to the mesher bound to it through the proxy (127.0.0.1 mesher 30102)

(4) after receiving the request, mesher (127.0.0.1 client 30102) processes the request using LocalRequestHandler, first prepares the consumer call chain, obtains and parses the service name and port of the client call, creates an Invocation, then processes it through the consumer call chain, and finally establishes a rest-client to initiate the call to the external destination service (192.168.88.64 client 30101).

(5) after listening to the mesher of 192.168.88.64 provider 30101 to receive the request, call RemoteRequestHandler to process the request, first convert the request to Invocation, prepare the provider call chain, resolve the address, replace the destination address with the address of the business service, then call the processing chain to handle the request, and finally initiate a http call to the internal real business server

Listen to the mesher at 127.0.0.1 consumerChain 30101 as the consumer, and use the request processing method. By default, the consumerChain call chain contains the following handler:

ChassisHandler.Router,chassisHandler.RatelimiterConsumer

ChassisHandler.BizkeeperConsumer

ChassisHandler.Loadbalance

ChassisHandler.Transport

The mesher listening on 192.168.88.64 handler 30101 handles the request as provider. The providerChain call chain contains the following processor by default:

ChassisHandler.RatelimiterProvider

ChassisHandler.Transport

Fig. 3 mesher communication model diagram

As can be seen from the above analysis, mesher actually acts as a proxy in the application layer to intercept and replace business services to initiate and receive requests. Mesher and business services perform their respective functions. As long as business services ensure normal business functions, mesher is responsible for service governance and building reliable communication links. As long as we ensure the interoperability between mesher and business and the communication between mesher and other external mesher, we can guarantee the provision of services, so how does mesher do it here? This problem involves the service discovery and control plane management capabilities of the go-chassis open source framework. Mesher uses the register package on the go-chassis base to register itself with the service center instance. Here we use Apache's servicecomb-servicecenter, which is a service center that receives registration and management of microservices. All services connected to servicecenter can expose themselves to other services through the service center, and obtain the ip and port of other service instances through the microservice name. The control plane function of mesher supports circuit breaker, load balancing, frequency limit, error injection, etc. You can connect to istio or use archaius to read the configuration.

Background of body mass index (Bmi) entry case 3.1

After understanding the principles of mesher, we use a specific use case to help users quickly get started with mesher's sidecar pattern. Through this example, users can quickly get started with mesher services, gain an in-depth understanding of the working mode and principle of mesher, and learn how to transform existing http services with the help of mesher, access to servicecomb micro-service system, and obtain micro-service capabilities such as load balancing, flow control, service governance, call chain tracking, and so on.

3.2 introduction to use case Services

Figure 4 mesher case deployment diagram

1. Httpserver_calculator: http BMI service based on Python language, which can be replaced by http service developed in any language.

2. Httpserver_webapp: web service based on nodejs language, which is used to display visual results on browsers.

3. Mesher_webapp: a mesher instance that provides services to httpserver_webapp through sidecar mode

4. Mesher_calculator: a mesher instance that provides services to httpserver_calculator through sidecar mode

5. Servicecenter: service center, which receives the registration of mesher services and provides service discovery, route query and service monitoring functions

Process details:

The browser [192.168.88.78] initiates a http call to http://192.168.88.64:4597/calculator/bmi on the httpserver_webapp service.

The httpserver_webapp service receives the request and initiates a http call to the address http://calculator/bmi, because the request initiated by the proxy http://127.0.0.1:30101 dint http server server webapp will be forwarded to the mesher_webapp service.

Mesher_webapp obtains the address of the service name from the service center servicecenter according to the requested service name (microservice.yaml configured service name calculator) and forwards it to mesher_calculator.

According to the set specific address, the mesher_calculator service forwards it to the body mass index calculator service (httpserver_calculator) bound by itself for processing.

Httpserver_calculator calculates based on the user's height and weight and returns its service ID to be displayed on the interface. The flowchart is as follows:

Fig. 5 mesher case flow chart

2.4 Test Environment Construction (linux)

1. Compile mesher: download address (https://github.com/apache/servicecomb-mesher)

Compile the project according to README.md to get the executable file mesher (linux), windows (mesher.exe)

2. Create mesher_webapp to serve httpserver_webapp:

Create the mesher_webapp by executing the following linux command in the mesher directory, where you need to copy the conf in addition to the executable file

Mkdir / usr/local/src/mesher_webapp

Change the configuration file in conf, the service name in microservice.yaml, change the service address monitored in chassis.yaml from hellomesher to webapp;, and change the address of local loopback (127.0.0.1) to private network ip (viewed via ifconfig under linux, such as 192.168.88.64):

ListenAddress: 127.0.0.1 40101-> listenAddress: 192.168.88.64 purl 40101

3. Create mesher_calculator

Mkdir / usr/local/src/mesher_calculator

Change the configuration file in conf, and change the service name in microservice.yaml to the body mass index microservice name calculator

Change the address and port on which the mesher_calculator configuration chassis.yaml listens:

ListenAddress: 127.0.0.1 40101-> listenAddress: 192.168.88.64 purl 40107

4. Start the mesher service, enter mesher_webapp and mesher_calculator, respectively, and start the service. You need to set the SPECIFIC_ADDR address of mesher_calculator, which is used to establish the logical binding relationship between mesher and http services.

Cd / usr/local/src/mesher_calculator

5. Start the httpserver_webapp service:

Cd / usr/local/src/httpserver_webapp

6. As a body mass index calculation service, httpserver_calculator needs to install python2.7 and relies on BaseHTTPServer package:

Cd / usr/local/src/httpserver_calculator

Fig. 6 servicecenter service monitoring chart

2.5 Test

1. Open the page http://192.168.88.64:30103 in the browser (if you need to open the front service in the service center service-center, please see http://servicecomb.apache.org/cn/users/setup-environment/#%E8%BF%90%E8%A1%8Cservice-center.

Look at the service, where the address of the service-center service starts, and see the interface shown in the figure.

Webapp stands for mesher_webapp service, which shows the service name configured in microservice.yaml; calculator represents mesher_calculator service, and here shows the service name configured in microservice.yaml. The capital SERVICECENTER is the service center.

Figure 7 servicecenter service monitoring chart

2. When the browser opens http://192.168.88.64:4597, you can see the following interface, which shows the static page for webapp:

Figure 8 the interface diagram showing the result of the bmi call

3. Enter parameters (180,70) and click submit to observe the result:

Figure 9 bmi call result diagram

2.6 mesher advance 2.6.1 load balancing

Figure 10 mesher load balancing case deployment diagram

Start a new mesher_calculator and httpserver_calculator instance for load balancer testing. You can use the service under the example directory test_balance:

1. Modify the service name in mesher_calculator configuration file microservice.yaml to calculator.

Change the address and port to configure chassis.yaml snooping to avoid conflicts:

ListenAddress: 127.0.0.1 40101-> listenAddress: 192.168.88.64 purl 40102

2. To start mesher_calculator, you need to set the SPECIFIC_ADDR address of mesher_calculator, which is used to establish the logical binding relationship between mesher and http services.

Export SPECIFIC_ADDR=127.0.0.1:4537

3. Roundbin (polling) load balancing algorithm is used by default, and Random and SessionStickiness load balancing algorithms are also supported. We modify the configuration file chassis.yaml of mesher_webapp to configure the load balancing method as Random:

Loadbalance:

4. Open a new instance of httpserver_calculator service and listen on port 4537.

5. Click the Submit button at this time to see the random appearance of BMI Instance ID in the following two interfaces

Figure 11 bmi call result diagram

2.6.2 flow control

1. Add the flow control configuration, restart the service, and change the mesher_calculator configuration file chassis.yaml. The flow control includes the following options:

Flowcontrol:

This frequency limit identifies that the number of requests accepted per second is 0, that is, no service is provided.

2. For verification, click the Submit button, and you can see the interface where the request has been rejected due to traffic control restrictions. The request can no longer reach httpserver_calculator.

Fig. 13 flow control diagram

2.6.3 Service Governance

2.6.3.1 Grayscale release

1. Update the version number: change the configuration file microservice.yaml of the two mesher_calculator instances, and update the version field to 1.1.1 and 1.1.2, respectively. Restart the mesher service, and you can see that the service version number has changed. As shown in the figure:

Fig. 14 Service monitoring chart

2. Configure routing information, change the configuration file router.yaml of mesher_webapp, update the weight information by instance version, and restart the service:

Servicecomb:

3. Verify. At this time, you can see that BMI Instance ID appears alternately according to the configured proportion by clicking the Submit button a lot.

2.6.3.2 Service breaker and recovery

1. Change the configuration of the breaker, change the configuration file chassis.yaml of mesher_webapp, and set the configuration of the breaker to:

Isolation:

2. Close the service instance in the test_balance directory.

3. Verify that a negative parameter is passed, the response timed out, and the mesher_webapp breaker takes effect. The three sub-images in figure 16 are:

(1) A screenshot of the mesher_webapp log shows that the breaker is enabled.

(2) the return value when a negative parameter is passed in to trigger the current breaker.

(3) indicates that after the breaker takes effect, all requests will be returned to nil as configured.

Figure 16 Service circuit breaker diagram

4. According to the configuration parameter sleepWindowInMilliseconds, the service is automatically restored after 10 seconds.

2.6.4 distributed call chain tracing

1. Add dependency to zipkin library in mesher main file:

_ "github.com/go-chassis/go-chassis-plugins/tracing/zipkin"

2. Add a default handler to the initiator bootstrap.go, as shown by the arrow in figure 17:

Figure 17 handlerchain call diagram

3. Recompile, replace the executable files of * * mesher_webapp * * and * * mesher_calculator * * respectively, and start the mesher service.

4. Use Docker to run Zipkin distributed tracking service

Docker run-d-p 9411 9411 openzipkin/zipkin

5. Click the Submit button several times to initiate the service call.

6. Open http://192.168.88.64:9411 to view the distributed tracking results as shown in figure 18. You can determine the call path by the host address:

Figure 18 distributed tracking result diagram

At this point, I believe you have a deeper understanding of "how to use micro-service service mesh". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.