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

Preface

The micro-service architecture splits each link (node or process) in the original business chain, such as users, products, orders, and payments, into independent services, which improves the fault tolerance of the system to a certain extent. For example, when payment services fail, users can still view orders and browse products through products and order services. As micro-service application development frameworks (such as springboot) and container technologies (such as K8) become more and more mature, the development and operation and maintenance of micro-services tend to be standardized. These are the reasons why microservices are becoming more and more popular. At the same time, with the increase of business complexity, more and more micro-services are developed and integrated, and the importance of service management is self-evident. Taking the link management of service invocation as the topic, this paper briefly discusses how to practice the mainstream technology of link management in micro-service governance.

Link management, which mainly refers to the calling link of recording service, is usually used to locate unreasonable service design, such as service time-consuming problem caused by long link, service stability risk caused by long link, circular dependence and so on. What aspects of link management need to be considered and how to achieve it?

First of all, we need to know which services and their service status (service registration and discovery mechanism), which can now be implemented directly through spring cloud's Eureka or, of course, through dubbo+zookeeper; with the service list, we need to intercept and record at each service call place, recording the call stack, from the initiating service to the end of the chain. There is a lot of work to implement this step, such as unifying service invocation rules, AOP interception, call chain data structure definition, call information collection, sending and storage, and so on. Finally, it is the collection, storage, transmission and final graphical display of the link data.

With this in mind, let's take a look at the current mainstream link solutions, Twitter's Zipkin, and Apache's incubation project SKYwalking. Of course, there are some hot solutions, such as South Korea's open source project Pinpoint and Meituan's CAT. Technically, these schemes can be divided into two factions, the interceptor faction and the bytecode enhancement faction. Interceptor intercepts requests through proxy classes and sends link information to the server. Both Zipkin and CAT belong to this type, but CAT requires code intrusion, that is, burying points are added to the code, while Zipkin seamlessly connects SpringBoot's micro services directly through SpringCloud's Sleuth. Bytecode enhancement technology, javaagent provided through JVMTI interface (different from JDK dynamic proxy and CGLIB proxy), bytecode manipulation technology (ASM) is used to convert class before class loading and instantiation, and then collect information and send it to proxy server (probe), such as sk*walking 's Agent service. A summary of the comparison between the two methods is as follows:

The basic principle of type zipkinSKYwalking intercepts the request and sends (HTTP,mq) data to the zipkin service java probe. Bytecode enhanced access is based on linkerd or sleuth mode. Avaagent bytecode support OpenTracing is a granular interface-level (class-level) method-level storage ES,mysql,Cassandra, memory ES,H2,TIDBagent to collector protocol http,MQhttp,gRPCZipkin practice

Zipkin is divided into two ends, the Zipkin server and the Zipkin client, which is the application of micro-service. The client configures the URL address of the server. Once an inter-service call occurs, the Sleuth listener configured in the microservice listens, and the corresponding Trace and Span information is generated and sent to the server. There are two main ways to send messages, one is HTTP message, the other is message bus, such as RabbitMQ.

Either way, we need: an Eureka service registry, first take a look at the Zipkin running architecture:

On the left is the application service, which is also Zipkin-clinet,Eureka-client, and in the middle is the dependency, including Zipkin-server and Eureka-server, and on the far right is the WebUI presentation and development interface.

Zipkin server, after using the Spring Boot 2.x version, it is not recommended to customize the compilation, but directly provides the compiled jar package for us to use.

So the official provided one-click script.

Curl-sSL https://zipkin.io/quickstart.sh | bash-sjava-jar zipkin.jar

If you use Docker, directly

Docker run-d-p 9411 9411 openzipkin/zipkin

The docker environment test is used here, and the default memory mode is selected for data storage. After starting zipkinserver, go to 9411 directly and see the management page:

After zipkinserver starts, start EurekaServer and start one locally. The port is tentatively set at 7777.

Well, now that you have dependent services, let's modify two existing microservices (configured for at least two services that have invocation relationships) as zkclient. What to do is simple, here are a few steps:

Configure EurekaClient

1) Micro services increase zipkin dependency

Compile "org.springframework.cloud:spring-cloud-starter-sleuth" compile "org.springframework.cloud:spring-cloud-starter-zipkin"

2) add EurekaClient comments to the startup class

@ EnableDiscoveryClient

3) add Eureka configuration to application configuration file

Eureka.instance.hostname=localhosteureka.client.serviceUrl.defaultZone = http://${eureka.instance.hostname}:7777/eureka/eureka.instance.preferIpAddress= true configuration Zipkin

1) enable sleuth client

Spring.sleuth.web.client.enabled=truespring.sleuth.sampler.percentage=1.0

Sampler.percentage is the sampling rate, 1 means to select all samples, because it is a test, so directly set to 1, the actual situation may be a decimal, 0.3 or 0.5, depending on the demand.

2) configure zipkinserver address

Spring.zipkin.base-url= http://192.168.72.101:9411/

Call the service to view the result

1) Eureka service list

2) Zipkin service link

It should be noted that since Sleuth trace filter only intercepts Spring built-in Rest calls, cross-service calls need to be announced by Spring officials, such as RestTemplate, which is directly called by apache's httpclient toolkit, and the complete link cannot be tracked.

Let's take a look at how Zipkin works at the implementation level. After the introduction of sleuth and zipkin dependent packages, the system automatically scans @ configuration,TraceAutoConfiguration in all packages is the configuration entry of the sleuth package. Take a look at its definition. The annotation is valid when spring.sleuth.enabled is enabled.

Configuration@ConditionalOnProperty (value = {"spring.sleuth.enabled"}, matchIfMissing = true) @ EnableConfigurationProperties ({TraceKeys.class, SleuthProperties.class}) public class TraceAutoConfiguration {...

Similarly, the configuration of Zipkin is as follows:

Configuration@EnableConfigurationProperties ({ZipkinProperties.class, SamplerProperties.class}) @ ConditionalOnProperty (value = "spring.zipkin.enabled", matchIfMissing = true) @ AutoConfigureBefore (TraceAutoConfiguration.class) public class ZipkinAutoConfiguration {.

As the entry point of the whole tracking, TraceFilter filters tags for all request, and sends messages asynchronously through AsyncReporter. The framed parts below are the interface address and the coding protocol (Thrift).

SKYwalking practice

Zipkin is easy to use, but because it is interface-level tracking, the information you can see is relatively limited, and the display form of the page is also relatively simple, lack of multi-angle or diversity, so let's try SKYWalking again.

The working mechanism of skywalking requires three pieces of cooperation. One is skywalking server, which is responsible for receiving, storing and displaying, so the server module contains a display web sub-module. The second block is agent, which is responsible for proxying the micro service and collecting the required information. The third block forwarded to server; is the micro service itself. You need to specify the agent at startup to generate the proxy class. The working schematic diagram is roughly as follows:

First look at the effect diagram, and then record the configuration process.

Select one of the services to view the invocation relationship and the underlying status of the service.

The topology diagram also has a flat display effect (it is very suitable for ppt introduction)

Dashboard to view service status:

In the tracking bar, see the call details:

The failed call also has an error log:

An overview of the overall risks in the warning bar:

After blowing the curative effect, take a look at how to configure, first look at server.

Download the latest skywalking, choose 6.4. when you choose bug, the topology diagram often doesn't come out. Server can run either in a container or on a virtual server such as ECS. The configuration of server is mainly related to storage. Choose either mysql or es. If the amount of data and operation is convenient and the amount of data can be controlled, just use mysql and replace the innodb engine for simplicity.

The datasource option is opened in the configuration file applicaiton.yml.

Point to the self-built database in datasource-setting.properties. Only need to build the database and access the account, the table will be initialized automatically when it is started, and there are many tables. )

The access ports of server are 11800 and 12800 respectively, which are gRPC and rest ports respectively. If you change them, you need to modify the access ports of the later config. Here prompts to open the firewall port.

There are also two ways of Agent, one is to put agent in the image, and the image of micro-service is based on this image, and the other is to copy directly to a shared directory, and each micro-service startup parameter increases the direction. The second method is more practical in the test environment, and it is more appropriate to use an image in the production environment, because the micro-service runs in the container and it is not realistic to access the shared directory.

Whichever way you choose, the configuration of config is the key.

AgentName needs to be consistent with the micro-service parameters specified. The backend service address points to oapserver.

In the last step, the microservice startup parameter is added to point to agent:

-Dskywalking.agent.application_code=agent-test

This agent-test is agentname, which needs to be consistent with the name configured by agent!

The configuration of non-container mode is mainly in these three steps, and you can see the effect when you are done. Of course, the call before the service needs to use the restTemplate provided by spring, not the httpclient toolkit of apache directly, otherwise it will not be collected. With regard to the deployment of the container environment, we will make up the record later.

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.