Introduction to common components of Spring Cloud (Netflix, Alibaba)

Introduction to common components of Spring Cloud

1. Description

With the vigorous development of Internet business in recent years and the continuous improvement and maturity of microservice technology systems, more and more system constructions have begun to develop in the direction of microservices. Among them, based on the combination of Spring Boot and Spring Cloud service governance framework, It has also been recognized by more and more development teams and has gradually become a standard solution for enterprise-level microservice construction.

1.1.What is Spring Cloud

Spring Cloud is an ordered collection of frameworks. It simplifies the development of distributed system infrastructure based on the development convenience of Spring Boot, such as service discovery registration, configuration center, load balancing, circuit breakers, data monitoring, etc., all of which can be started and started with one click using the Spring Boot development style. deploy.

Spring Cloud combines relatively mature and practical service frameworks developed by various companies, and re-encapsulates them in the Spring Boot style, shielding complex configurations and implementation principles, and ultimately leaving developers with a simple set of An easy-to-understand, easy-to-deploy and easy-to-maintain distributed system development toolkit. The main supporters and contributors of Spring Cloud include many well-known Internet technology companies at home and abroad, such as Netflix and Alibaba, which have greatly promoted the continuous progress and development of Spring Cloud.

1.2.Spring Cloud component selection

The Spring Cloud family has many components, some are deployed independently as a single service, some can be deployed in a high-availability cluster distributed manner, and some are integrated into application services as plug-ins. With the enrichment of usage scenarios and the continuous contributions of community developers, components that implement the same type of functions in Spring Cloud have gradually derived various branch sub-projects, each with its own focus on design ideas and functions. In addition, there are some open source components outside the Spring Cloud family that are often used in conjunction with Spring Cloud components due to their functional fit. This requires users to flexibly choose according to their own usage scenarios. As enterprise users, they need to consider the maturity and future support of the components when selecting components.

The following is a brief introduction to the functions and usage scenarios of common Spring Cloud components to facilitate component selection and application by developers and designers.

2. Component introduction

The following is an introduction to the key components of Spring Cloud.

2.1.Service registration and discovery

Service registration and discovery are the basis of service governance. Eureka in the Spring Cloud Netflix sub-project is currently the most commonly used Spring Cloud service registration component. In addition, there are also registration center solutions such as Nacos, a sub-project of Spring Cloud Alibaba, and Zookeeper, among which are discussed below. The widely used Netflix Eureka and Alibaba Nacos are introduced.

2.1.1.Netflix Eureka

Eureka is a service registration and discovery component based on REST services open sourced by Netflix. It is the most widely used Spring Cloud registration center component. Currently, the 1.x version is still under maintenance (not that the maintenance of the network has stopped), and the 2.x version has not been officially released.

1) Distributed model

The CAP theory of distributed systems summarizes three characteristics of distributed systems: consistency (C), availability (A), and partition fault tolerance (P). All three cannot be achieved simultaneously.

Eureka's design philosophy is to follow the AP model, which is different from Zookeeper's CP model. All nodes of Eureka Server are equal. The failure of several nodes will not affect the work of normal nodes. The remaining nodes can still provide registration and query services. When Eureka Client registers with an Eureka Server, if it finds that the connection fails, it will automatically switch to other nodes. As long as one Eureka Server is still available, the registration service can be guaranteed to be available (guaranteed availability), but the information found may not be the latest (strong consistency is not guaranteed).

2) Main components

Eureka mainly consists of two components:

Eureka Client: A Java client used to simplify interaction with Eureka Server (usually the client and server in microservices)

Eureka Server: Provides the ability to register and discover services (usually the registration center in microservices)

3) Working process

After the service is started, it is registered with Eureka. Eureka Server will synchronize the registration information with other Eureka Servers. When the service consumer wants to call the service provider, it will obtain the service provider address from the service registration center, and then cache the service provider address in Local, the next time it is called, it will be fetched directly from the local cache to complete a call.

When there are multiple service providers, Eureka Client will automatically perform load balancing through Ribbon.

Insert image description here

Figure 2-1 Eureka working process

4) Cluster deployment

Eureka Server clusters synchronize data with each other through Replicate. There is no distinction between master nodes and slave nodes. All nodes are equal. If an Eureka Server goes down, the Eureka Client's request will automatically switch to the new Eureka Server node. When the downed server is restored, Eureka will include it into the server cluster management again. When a node starts accepting client requests, all operations will be copied between nodes, and the requests will be copied to all nodes currently known to other Eureka Servers.

Eureka provides two concepts, Region and Zone, for partitioning. Both concepts come from Amazon AWS.

Region: It can be understood as different geographical areas, such as Asia, China or Shenzhen, etc. There is no specific size limit. According to the specific situation of the project, you can reasonably divide the regions by yourself.

Zone: It can be simply understood as the specific computer room in the region. For example, the region is divided into Shenzhen, and there are two computer rooms in Shenzhen. Two zones, zone1 and zone2, can be divided under this region.

Insert image description here

Figure 2-2 Eureka cluster

In the picture above, us-east-1c, us-east-1d, and us-east-1e represent different zones. The Eureka Client in the Zone gives priority to heartbeat synchronization with the Eureka Server in the same Zone. Similarly, the caller gives priority to obtain the service list from the Eureka Server in the Zone. When all Eureka Servers in the Zone hang up, it will obtain it from other Zones. information.

5) High availability mechanism

When the service registration center Eureka Server detects that the service provider is unavailable due to downtime or network reasons, the service registration center sets the service to the DOWN state and publishes the current service provider status to subscribers. Subscribed service consumers Update local cache.

After the service provider starts, it periodically (default 30 seconds) sends heartbeats to Eureka Server to prove that the current service is available. If Eureka Server does not receive the client's heartbeat within a certain period of time (90 seconds by default), it will consider the service to be down and log out of the instance.

When the Eureka Server node loses too many clients in a short period of time (possibly caused by a network failure), the node will enter self-protection mode and will no longer log out any microservices. When the network failure recovers, the node will automatically exit. Self-protection mode.

2.1.2.Alibaba Nacos

Nacos is an open source project of Alibaba. Its core positioning is "a dynamic service discovery, configuration and service management platform that makes it easier to build cloud native applications." Nacos provides two core functions: service registration and discovery, and dynamic configuration management. For details on dynamic configuration management, see Section 2.5.3.

1) Distributed model

Nacos is a decentralized architecture that belongs to the AP architecture in the CAP theory. It supports eventual consistency and has very good performance in distributed service discovery and registration scenarios. Currently Dubbo officially supports using Nacos instead of Zookeeper.

2) System architecture

Nacos mainly provides the following four functions.

①Service discovery and service health check: Nacos discovers other services through DNS or HTTP interfaces and provides real-time health checks of services to prevent requests from unhealthy hosts or service instances.

②Dynamic configuration management: Nacos can be used as a configuration center, see section 2.5.3 for details.

③Dynamic DNS service: Nacos supports weighted routing and can implement middle-tier load balancing, flexible routing policies, flow control and simple DNS resolution services in the production environment of the data center.

④Service and metadata management: Nacos provides an easy-to-use service dashboard that can assist in managing service metadata, configuration, kubernetes DNS, service health and indicator statistics, etc.

The Nacos system architecture is as follows.Insert image description here

Figure 2-3 Nacos architecture

3) High availability

Nacos supports two modes of deployment. One is the deployment of the AP protocol like Eureka. This mode only supports temporary instances and supports computer room disaster recovery. The other is the CP mode that supports persistent instances. In this case, dual-machine room disaster recovery is not supported.

The multi-machine room deployment solution provided by Nacos uses the Nacos-Sync component to synchronize data between data centers, which means that the Nacos cluster in each data center will have full data from multiple data centers.

Insert image description here

Figure 2-4 Nacos multi-machine room deployment

4) Comparison with Eureka

The following is a comparison of some indicators between Nacos and Eureka.

Table 2-1 Comparison between Nacos and Eureka

Compare items Nacos Eureka
CAP model Support AP and CP models AP model
How the client updates service information DNS-F client uses listen mode push/pull to pull update information The client regularly polls the server to obtain other service IP information and compare it.
Scalability Raft election algorithm has good performance, availability, and fault tolerance. New nodes do not need to broadcast synchronization information to all nodes. Using broadcast synchronization information, the Eureka cluster is under great pressure after the cluster exceeds 1,000 machines.
Health check mode/method Support server/client/closed check mode, check methods include Tcp, HTTP, Sql, support custom health checker Client sends Http heartbeat to server
load balancing support support
Manual online and offline service methods Via console page or API Call API
Cross-center synchronization solution support not support
Weights Nacos provides a weight setting function by default to adjust the traffic pressure. not support
Manufacturer Ali Baba Netflix

2.2.Flow control

Request flow control is the main means of service governance, which mainly includes request load balancing, current limit degradation, service circuit breaker and other functions.

By configuring a reasonable load balancing strategy, the service throughput rate is increased and the overall service response time is reduced; by pre-setting current limiting rules, selective access restrictions are imposed on certain requests that exceed expectations; by downgrading and circuit breaker strategies, when the service fails When unavailable or response times out, the service will be temporarily stopped to prevent an avalanche of paralysis of the entire system.

When dealing with scenarios of large traffic requests, current limiting degradation and service circuit breaker have become standard technical solutions, playing a key role in ensuring the smooth operation of the system.

Spring Cloud Netflix provides Ribbon and Hystrix to implement client load balancing and current limiting and circuit breaker respectively, which can meet the traffic control needs of most scenarios. It also provides Feign to facilitate the integration of traffic control components. Feign+Ribbon+Hystrix is ​​currently the most common Flow control scheme. In addition, there is also Alibaba’s open source Sentinel that can implement functions similar to Hystrix circuit breakers. These components and solutions are introduced below.

2.2.1.Netflix Feign+Ribbon+Hystrix

Netflix's open-source Feign+Ribbon+Hystrix is ​​currently the most common traffic control solution. It is generally used together to achieve functions such as request load balancing, current limit degradation, and service interruption.

1) Introduction to Netflix Feign

Feign is an HttpClient binder written in Java language, used in Spring Cloud microservices to implement declarative calls between microservices. Feign can define interfaces for requests to other services, which are used for calls between microservices. There is no need to write http requests yourself. It is implemented on the client. Calling this interface is like calling other services remotely. When a request error occurs, the implementation of the interface can be called. class to return

Feign is a declarative web service client that makes writing web service clients easier. Create an interface, add annotations to the interface, and use Feign. Feign can use Feign annotations or JAX-RS annotations, and also supports hot-swappable encoders and decoders. Spring Cloud adds Spring MVC annotation support to Feign, and integrates Ribbon and Eureka to provide load balancing when using Feign.

2) Introduction to Netflix Ribbon

Ribbon is an open source project released by Netflix. Its main function is to provide client-side software load balancing algorithms to connect Netflix's middle-tier services together. The Ribbon client component provides a series of complete configuration items such as connection timeout, retry, etc. To put it simply, list all the machines behind the Load Balancer in the configuration file, and Ribbon will automatically help you connect to these machines based on certain rules (such as simple polling, random connections, etc.).

Ribbon works in two steps: the first step is to select the Eureka Server, which gives priority to servers in the same zone and with less load; the second step is to select from the service registration list obtained from the server according to the policy specified by the user. an address. Ribbon provides a variety of strategies, such as polling, random, weighting based on response time, etc.

3) Introduction to Netflix Hystrix

Hystrix has powerful functions such as service degradation, service circuit breaker, thread isolation, request caching, request merging and service monitoring. It is the most commonly used traffic control component of Spring Cloud.

Hystrix aims to provide greater fault tolerance to delays and failures through circuit breakers. It solves this problem through the following four mechanisms.

①Isolation (thread pool isolation and semaphore isolation): Limit the use of resources for calling distributed services. Problems with a certain called service will not affect other service calls.

②Elegant downgrade mechanism: downgrade due to timeout or insufficient resources (threads or semaphores). After downgrading, you can cooperate with the downgrade interface to return the underlying data.

③Circuit: When the failure rate reaches the threshold, degradation is automatically triggered (such as a high failure rate due to network failure/timeout), and rapid failure triggered by the fuse will result in rapid recovery.

④Cache: Provides request caching and request merging implementation.

In addition, Hystrix also supports real-time status monitoring of traffic based on Hystrix Dashboard. The details are introduced in Section 2.4.2.

4) The relationship between Feign+Ribbon+Hystrix

Insert image description here

Figure 2-5 Flow control mechanism

Under the Spring Cloud microservice system, mutual calls between microservices can be made declaratively through Feign. During this service call process, Feign will obtain the server address list of the target microservice from the service registration center through Ribbon, and then make a network request In the process, Ribbon will load the request to different instances of the microservice in a load balancing manner, thereby realizing the most critical functions in the Spring Cloud microservice architecture, namely service discovery and client load balancing invocation.

On the other hand, in the process of microservices calling each other, in order to prevent the failure of a certain microservice from consuming the connection resources of all microservices in the entire system, during the process of implementing the microservice call, we will require the caller to implement a method for the called Current limiting circuit breaker logic for microservices. To realize this logical scenario, we implement it through the Hystrix framework under the Spring Cloud microservice framework.

The caller will set the call timeout for the called microservice. Once it times out, it will enter the circuit breaker logic, and this fault indicator information will also be returned to the Hystrix component. The Hystrix component will judge the fault situation of the microservice being adjusted based on the circuit breaker situation and turn on the circuit breaker. After that, all requests for the microservice will directly enter the circuit breaker logic until the fault of the adjusted microservice is restored and the Hystrix circuit breaker is closed.

2.2.2.Alibaba Sentinel

Sentinel is a lightweight and highly available traffic control component for distributed service architecture developed by the Alibaba middleware team. Sentinel mainly uses traffic as the entry point to help users improve service stability from multiple dimensions such as flow control, circuit breaker degradation, system load protection, and real-time monitoring.

Sentinel is a fully functional high-availability traffic management and control component. Its core sentinel-core does not have any redundant dependencies and only takes less than 200 KB after packaging, making it very lightweight. Developers can safely introduce sentinel-core without worrying about dependencies. Sentinel, like Hystrix, supports integration with Feign to facilitate client calls. At the same time, Sentinel provides a variety of extension points, so users can easily expand according to their needs and seamlessly integrate into Sentinel.

1) Flow control

Sentinel can control the flow of resource calls based on different calling relationships and based on different operating indicators (such as QPS, number of concurrent calls, system load, etc.), and adjust random requests into appropriate shapes.

Sentinel supports diverse traffic shaping strategies and can automatically adjust the traffic into an appropriate shape when the QPS is too high. Commonly used strategies include:

① Direct rejection mode: that is, excessive requests are directly rejected.

② Slow start preheating mode: When the flow surges, the rate of flow is controlled to slowly increase the passing flow, gradually increasing to the upper limit of the threshold within a certain period of time, giving the cold system a time to warm up and preventing the cold system from being stressed. collapse.

③ Uniform speed mode: The uniform speed mode implemented by the Leaky Bucket algorithm strictly controls the time interval for request passing. At the same time, accumulated requests will be queued, and requests that exceed the timeout period will be directly rejected.

2) Load protection

Sentinel provides protection for system dimensions, and the load protection algorithm draws on the idea of ​​TCP BBR. When the system load is high, if requests continue to come in, the system may crash and become unable to respond. In a cluster environment, network load balancing will forward the traffic that should be carried by this machine to other machines. If other machines are also in an edge state at this time, the increased traffic will cause this machine to crash, and eventually the entire cluster will become unavailable. In response to this situation, Sentinel provides a corresponding protection mechanism to achieve a balance between the system's inlet traffic and the system's load, ensuring that the system can handle the most requests within its capabilities.

3) Real-time monitoring and control panel

Sentinel provides HTTP API to obtain real-time monitoring information, such as call link statistics, cluster point information, rule information, etc. If the user is using Spring Boot/Spring Cloud and uses Sentinel Spring Cloud Starter, they can also easily obtain some runtime information through its exposed Actuator Endpoint.

4) Comparison with Netflix Hystrix

Sentinel is a flow control component similar to Hystrix. The two main similarities and differences are as follows.

Table 2-2 Similarities and differences between Sentinel and Hystrix

Insert image description here

2.3.Gateway

With the rise of microservices, API Gateway has also become the standard configuration of microservices. API Gateway is an entrance located at the boundary of the service cluster. It mainly solves problems such as request routing, access control, and permission authentication.

Insert image description here

Figure 2-6 API Gateway

Microservice gateways generally include the following features and functions.

l High availability: Microservice gateway should be highly available and stateless.

l Request routing: including functions such as dynamic configuration of routing policies and grayscale publishing.

l Traffic control: including request load balancing, current limit degradation, service circuit breaker and other functions.

l Permission authentication: including request permission authentication, parameter decryption, black and white lists and other functions.

l Request link record: including request time-consuming monitoring, link log support and other functions.

The following is an introduction to the two most commonly used gateway components of Spring Cloud.

2.3.1.Spring Cloud Gateway

Spring Cloud Gateway is a gateway component officially developed by Spring based on Spring 5.0, Spring Boot2.0 and Project Reactor technologies. Spring Cloud Gateway aims to provide a simple, effective and unified API routing management method for microservice architecture. As the gateway in the Spring Cloud ecosystem, Spring Cloud Gateway aims to replace Netflix Zuul and play a very important role in the Spring Cloud2.x microservice architecture system.

1) Main concepts

Several important concepts of Spring Cloud Gateway are as follows:

① Routing: Routing is the most basic part of the gateway. Routing information consists of ID, destination URL, a set of assertions and a set of Filters. If the assert route is true, it means that the requested URL and configuration match.

②Assertion: The input type of the assertion function in Spring Cloud Gateway is ServerWebExchange in the Spring 5.0 framework. Assertion functions allow developers to define matches for any information from an HTTP Request, such as request headers and parameters.

③Filter: The Filter in Spring cloud gateway is divided into two types of Filter, namely Gateway Filter and Global Filter. The filter Filter will modify the request and response.

2) Workflow

After Spring Cloud Gateway receives the request, it finds the route that matches the request in Gateway Handler Mapping and sends it to Gateway Web Handler. The Handler then sends the request to our actual service to execute the business logic through the specified filter chain. Finally, Return execution results.

The workflow example of Spring Cloud Gateway is as follows.

Figure 2-7 Spring Cloud Gateway processing flow

3) Main functions and implementation methods

As a traffic entrance, the gateway plays a very important role in the microservice system. Common functions include the following aspects.

①Permission authentication

Spring Cloud Gateway can implement JWT and other authentication strategies based on Filter, and realize request permission authentication and Token verification distribution by parsing request parameters.

The following is an example process for Spring Cloud Gateway to perform permission authentication.

Insert image description here

Figure 2-8 Spring Cloud Gateway permission authentication

②Dynamic routing

There are two important concepts in the gateway, which are routing configuration and routing rules. Routing configuration refers to configuring a request path to be routed to a specified destination address. Routing rules refer to forwarding processing based on routing rules after matching the routing configuration.

Spring Cloud Gateway serves as the entry point for all request traffic. In order to ensure high reliability and high availability in actual production environments, restarts are avoided as much as possible. The gateway can be extended by implementing the RouteDefinitionRepository interface to implement Spring Cloud Gateway dynamic routing configuration.

③Flow control

Spring Cloud Gateway provides the current limiting filter RequestRateLimiterGatewayFilterFactory by default, and the current limiting implementation class RedisRateLimiter uses token buckets to limit current. Users can implement AbstractGatewayFilterFactory according to their own needs to achieve personalized current limiting operations.

Spring Cloud Gateway can integrate Ribbon to implement load balancing strategies.

Spring Cloud Gateway can achieve circuit breaker downgrade by integrating Hystrix, adding circuit breaker downgrade configuration under Filters, setting the route returned after downgrade, and realizing circuit breaker for requested services.

2.3.2.Netflix Zulu

Zuul is an API Gateway server open sourced by Netflix, which is essentially a Web Servlet application. Due to the delay in the release of Zuul2.x version, Spring chose to develop its own Spring Cloud Gateway as the default gateway for Spring Cloud2.x. However, Zuul is still widely used in many Spring Cloud systems.

1) Main concepts

The core of Zuul is a series of Filters, whose function can be compared to the Filter of the Servlet framework, or AOP.

Zuul routes Requests to the user processing logic. These Filters participate in some filtering processes, such as Authentication, Load Shedding, etc.

2) Workflow

The life cycle of requests in Zuul is shown in the figure below.

Insert image description here

Figure 2-9 Zuul permission authentication

3) Comparison with Spring Cloud Gateway

Since Zuul2.x has not yet been widely used, only the main indicators of Zuul1.x and Spring Cloud Gateway are listed below.

Table 2-3 Comparison between Zuul and Spring Cloud Gateway

Spring Cloud Gateway Netflix Zuul 1.x
performance The WebFlux module used is based on the Reactive Web framework, which can be used to build asynchronous, non-blocking, event-driven services, and performs very well in terms of scalability. Zuul 1.x, still based on blocking I/O model, performance is not as good as Spring Cloud Gateway
open source organization Spring Cloud Gateway is a sub-project of Spring Cloud Zuul1.x is developed by Netflix and is open source. There are no plans to integrate it into Spring Cloud in the future.
Version Based on Spring Boot 2.* Based on Spring Boot 1.*

2.4.Service monitoring

Complete microservice monitoring is a necessary means to ensure service stability. Spring Cloud also provides some excellent components to assist in monitoring service instances and service call links.

The following is an introduction to the commonly used service monitoring components of Spring Cloud.

2.4.1.Spring Boot Admin

Spring Boot Admin is used to manage and monitor SpringBoot applications. The application is registered with the Spring Boot Admin Server as a Spring Boot Admin Client (via HTTP) or discovered using a Spring Cloud registry (e.g. Eureka, Consul). The UI is a Vue.js application that displays some monitoring on the Spring Boot Admin Client's Actuator endpoint. The server uses Spring WebFlux + Netty.

Spring Boot Admin provides the following features for registered applications.

l Display health status

l Display detailed information, for example

l JVM and memory indicators

l micrometer.io indicators

l Data source indicators

l Cache indicators

l Display build information number

l Follow and download log files

l View jvm system- and environment-properties

l View Spring Boot configuration properties

l Support Spring Cloud's postable /env- and /refresh-endpoint

l Easy log-level management

l Interacting with JMX-beans

l View thread dumps

l View http-traces

l View auditevents

l View http-endpoints

l View scheduled tasks

l View and delete active sessions (using spring-session)

l View Flyway/Liquibase database migration

l Download heapdump

l Status change notification (via email, Slack, Hipchat,…)

l Event log of status changes (non-persistent)

The following is a sample screenshot of Spring Boot Admin.

Insert image description here

Figure 2-10 Spring Boot Admin

Insert image description here

Figure 2-11 Spring Boot Admin

Insert image description here

Figure 2-12 Spring Boot Admin

Insert image description here

Figure 2-13 Spring Boot Admin

2.4.2.Netflix Hystrix Dashboard + Turbine

Hystrix Dashboard is a tool for real-time monitoring of Hystrix. Through Hystrix Dashboard, we can intuitively see the request response time, request success rate and other data of each Hystrix Command.

However, only using Hystrix Dashboard can only see the service information within a single application. We need to use the Turbine tool to aggregate the data of multiple services in the system and display it on Hystrix Dashboard.

Examples of HystrixDashboard interface monitoring parameters are as follows.

Insert image description here

Figure 2-14 Netflix Hystrix Dashboard interface

Insert image description here

Figure 2-15 Netflix Hystrix Dashboard interface

2.4.3.Spring Cloud Sleuth+Zipkin

Spring Cloud provides spring-cloud-sleuth-zipkin to facilitate the integration of Zipkin to implement microservice link tracking.

1) Sleuth principle

Spring Cloud Sleuth implements a distributed service link tracking solution. Using Sleuth allows us to quickly locate problems with a certain service. Simply put, Sleuth is equivalent to the client of the call chain monitoring tool. It is integrated on each microservice and is responsible for generating call chain monitoring data.

Spring Cloud Sleuth is an encapsulation of Zipkin. The generation of Span, Trace and other information, access to HTTP Request, and sending of collection information to Zipkin Server are all automatically completed.

Spring Cloud Sleuth can track the following types of components: async, hystrix, messaging, websocket, rxjava, scheduling, web (SpringWebMvc, Spring WebFlux, Servlet), webclient (Spring RestTemplate), feign, zuul. Sleuth can intercept Trance and create Span at the bottom level,

2) Main concepts

①Span (span): Span is the basic unit of work. Span includes a 64-bit unique ID, a 64-bit trace code, description information, timestamp events, key-value annotations (tags), and the ID of the span processor (usually IP).

The initial Span is called the root span. The span id and trace id values ​​in this span are the same.

②Trance (tracking): Contains a series of spans, which form a tree structure

③Annotation: used to record existing events in a timely manner. Commonly used Annotations are as follows:

l CS (Client Sent): The client sends a request indicating the beginning of span

l SR (Server Received): The server receives the request and starts processing it. (SR - CS) is equal to the delay of the network

l SS (Server Sent): The server completes processing of the request and begins to return to the server. (SR - SS) indicates the time it takes for the server to process the request

l CR (Client Received): The client completes receiving the return result, and the span ends at this time. (CR - CS) indicates the time when the client receives data from the server

3) Introduction to Zipkin

In response to the problem of full-link tracking of service-based applications, Google published a Dapper paper, which introduced how they conduct service tracking analysis. The basic idea is to add IDs to the requests and responses of service calls to indicate the relationship between upstream and downstream requests. Using this information, service call links and dependencies between services can be visually analyzed.

Zipkin is an implementation corresponding to Dpper and is open sourced by Twitter.

Insert image description here

Figure 2-16 Zipkin architecture

Instrumented client and Instrumented server are services in a distributed system. They collect tracking information through the equipment library, and the equipment library then calls Transport to send the tracking information to Zipkin.

Transport is the interface provided by Zipkin to the outside world. Currently, there are three types: HTTP, Kafka, and Scribe.

Zipkin supports persistent storage of link data.

Insert image description here

Figure 2-17 Link tracking example

Insert image description here

Figure 2-18 Link tracking example

2.5.Configuration Center

After the system is microserviced, the configuration items that originally existed in the single application are scattered and split into many sub-services. How to reasonably maintain the numerous configuration items and efficiently complete the update of the configuration items in multiple running instances has become an urgent problem to be solved. dimensionality problem.

Spring Cloud provides Spring Cloud Config as the configuration center component to implement configuration management in microservice scenarios. In addition, there are Apollo and Nacos, which are more powerful and more suitable for enterprise application scenarios, as configuration center options.

The following is a comparative introduction to these configuration center components.

2.5.1.Spring Cloud Config

Spring Cloud Config provides server and client support for external configuration in distributed systems. Convenient deployment and operation and maintenance.

The Spring Cloud Config server, also known as the distributed configuration center, is an independent microservice application used to connect to the configuration server and provide access interfaces for clients to obtain configuration information, encrypt/decrypt information, etc. The client manages application resources and business-related configuration content by specifying a configuration center, and obtains and loads configuration information from the configuration center at startup. By default, GIT is used to maintain configuration information, and databases, SVN, local files, etc. can also be used as persistent storage.

Spring Cloud Config has the following advantages.

① Management based on three dimensions: application, environment and version

②Configuration storage supports Git, SVN and other methods

③Seamless integration with Spring, low migration cost

Spring Cloud Config also has the following flaws.

① The dynamic configuration capability is weak. Adjusting the configuration requires redeployment and adding a lot of code.

②Weak governance and security audit capabilities

③Not strictly enterprise level, only suitable for small projects

2.5.2.Apollo

Apollo is an open source configuration management center developed by Ctrip's framework department. It can centrally manage the configuration of different application environments and different clusters. After the configuration is modified, it can be pushed to the application end in real time, and it has standardized permissions, process management and other features.

Apollo supports 4 dimensions to manage configuration in Key-Value format.

l application

l environment

l cluster

l namespace (namespace)

The comparison between Apollo and Spring Cloud Config is as follows.

Table 2-4 Comparison between Spring Cloud Config and Apollo

function points Apollo Spring Cloud Config
Configuration interface Unified interface management none
Configuration effective time real time Restart to take effect/refresh/git webhook+MQ
Version management Interface operation none
Grayscale release support none
Authorization/Audit/Review Interface operation supports separation of modification and publishing permissions git operation is required and permissions cannot be separated
Instance configuration monitoring See the client configuration none
Configuration acquisition performance Fast, DB + cache support git clone repo, read local files
client support Java,.Net,Spring Annotation Spring application + anotation support

2.5.3.Alibaba Nacos

As mentioned in Chapter 2.1.2, Nacos can not only serve as the registration center component of Spring Cloud, but also includes the function of the configuration center, which is briefly introduced below.

Dynamic configuration management is one of the three major functions of Nacos. Through the dynamic configuration service, we can manage the configuration information of all applications or services in a centralized and dynamic manner in all environments.

The dynamic configuration center can make the corresponding configuration information effective without redeploying applications and services during configuration updates, which greatly increases the system's operation and maintenance capabilities.

The Nacos server saves the configuration information. After the client connects to the server, the group can obtain the specific configuration information based on the dataID. When the server configuration changes, the client will receive a notification. When the client gets the latest changed configuration information, it can do its own processing, which is very useful. All scenarios that require configuration can be managed through Nacos.

Nacos does not push the latest configuration information of the server to the client. Instead, the client maintains a long polling task, regularly pulls the changed configuration information, and then pushes the latest data to the Listener. holder.

The comparison between Nacos and Apollo is as follows.

In general, Apollo and Nacos have wider ecological support than Spring Cloud Config and do better in the configuration management process. Apollo is more comprehensive in configuration management than Nacos, but it is also more troublesome to use. Nacos is relatively simple to use and is more suitable for large-scale scenarios with high performance requirements.

Guess you like

Origin blog.csdn.net/Java__EE/article/details/131167660