Nacos

  • What is Nacos?

    Nacos is a dynamic service discovery, configuration management, and service management platform that makes it easier to build cloud-native applications.Copy the code

  • What can Nacos do?

    1. Service discovery and management 2. Dynamic service configuration 3Copy the code

IO /zh-cn/index…

The registry

  1. Create a spring Boot microservice, using ali Cloud image to generate initialization code project: start.aliyun.com

  2. Import the dependencies required by the built-in Nacos client

  3. Microservices are imported as web projects

# spring.application. Name =sample-service # server.port=8080# Nacos authentication information spring. Cloud. Nacos. Discovery. The username = Nacos spring. Cloud. Nacos. Discovery. The password = # Nacos Nacos service discovery and register configuration, One child property server - addr Nacos server host and port specified spring. Cloud. Nacos. Discovery. The server - addr =127.0. 01.:8848# registered to nacos specified namespace, the default to public spring. Cloud. Nacos. Discovery. The namespace = publicCopy the code

After the service is successfully registered, the service management platform can view the corresponding service information

  • heartbeat

    Heartbeat packets are sent to Nacos every 5 seconds by the Nacos client built into the microservice. The heartbeat packet contains the instance name, IP address, port, cluster name, and weight of the current microservice.

  • Heartbeat packet processing flow

The built-in logic of Nacos Server is to scan all unhealthy instances in the Instance Map every 20 seconds. If an unhealthy instance is found, it is deleted from the Instance Map.

Configuration center

  1. Create a configuration

  • Data ID: unique identifier of the configuration, in the format of {microservice ID}-{environment name}.yml
  • Group: specifies the Group of the configuration file. The default Group is DEFAULT_GROUP.
  • Description: Describes the purpose of the configuration file.
  • Configuration format: Specify the type of Configuration Content
  • Configuration content: Paste the contents of the application. Yml file of the project.

Set the Nacos configuration center address using the bootstrap.yml boot file. Note that the bootstrap.yml file name is fixed and should not be changed arbitrarily

Spring: application: name: sample-service # profiles: active: dev # cloud: nacos: config: 127.0.0.1:8848 username: Nacos password: Nacos logging # Enable debug log level: root: debugCopy the code

  1. Verify that the Nacos configuration takes effect

public class TestController {
    @Value("${datasource.username}")
    private String username;
    @Value("${datasource.password}")
    private String password;

    @GetMapping("/test")
    public String test(){
        return "username:" + username + "<br/> password:"+ password; }}Copy the code
  1. Configure central data persistence

Nacos provides a new storage schema after 1.3.0 that uses raft protocol for data consistency and Apache Derby for embedded data storage. The purpose of this approach is to reduce the cost of maintaining a mysql database cluster and simplify the cost of cluster deployment by packaging the Nacos image when deploying Nacos, rather than deploying a separate database. MySQL cluster persistence prior to 1.3.

Learn about the Nacos configuration center

  1. Hot loading of Nacos

Load Balancing -Ribbon

The Ribbon is a client-side load balancer (a consumer-held load balancer). Ribbon has been integrated with Spring Cloud’s official technology, and the runtime is embedded in each microservice instance as an SDK.

  • Ribbon Execution Process
  • Service A and service B instances are registered with Nacos at startup;
  • Before service A communicates with service B, the Ribbon queries Nacos for A list of available instances of goods and services.
  • The Ribbon selects instances from the list of available instances of service B based on the set load policy.
  • Service instance A sends A request to service instance B to complete RESTful communication.

Load Balancing Policy

  • RoundRobinRule:

Polling policy, the Ribbon default policy. By default, the server obtained for more than 10 times is unavailable and an empty server is returned.

  • RandomRule: random policy if the random server is null or unavailable. It’s going to loop and loop.

  • RetryRule:

Retry policy, retry within a specified period of time. By default, it inherits RoundRobinRule and also supports custom injection. RetryRule will check whether the selected server is null or alive after each selection, and will continue to check whether the selected server is alive within 500ms. While RoundRobinRule fails more than 10 times, RandomRule has no concept of an expired time, as long as the serverList does not fail.

  • BestAvailableRule:

Minimum number of connections policy: Iterates through the serverList to select the available server with the smallest number of connections. RoundRobinRule is called to re-select.

  • AvailabilityFilteringRule:

Filtering policies are available. If the polling policy is extended, the system selects a server through the default polling and checks whether the server is available due to timeout and whether the number of current connections exceeds the upper limit.

  • ZoneAvoidanceRule:

Regional tradeoff strategy. Expanded the polling policy. In addition to filtering servers with timeout and excessive number of connections, the system also filters out all nodes in the zone that do not meet the requirements, ensuring that all service instances in the same zone or equipment room are polled.

All load balancing policies are in the class under com.Net flix. Loadbalancer package

  • Example Modify a load balancing policy

Service communication -OpenFeign

Feign and OpenFeign

Netflix Feign is an open source declarative WebService client designed by Netflix to simplify communication between services. Netflix Feign is developed in an “interface + annotation” manner, masking the details of network communication by developing in an interface manner that mimicked RPC’s client-server pattern (CS). However, OpenFeign is not an independent technology. The underlying technology is based on Netflix Feign and encapsulated on it. Combined with the original Spring MVC annotations, the development method using OpenFeign is similar to the Spring MVC Controller.

OpenFeign use

  1. Creating a service provider

Create a plain Old Spring Cloud service (without further ado)

		<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
        </dependency>
Copy the code
  1. Create consumer projects and introduce core dependencies
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> </dependency> <! - openFeign dependence - > < the dependency > < groupId > org. Springframework. Cloud < / groupId > < artifactId > spring - the cloud - starter - openfeign < / artifactId > < version > 2.2.5. RELEASE < / version > < / dependency >Copy the code

  1. Add the startup annotation @enableFeignClientsThe @enableFeignClients annotation tells Spring to enable OpenFeign declarative communication.

  2. Creating a Communication Interface

Create a client package to store the requested client and communication interface. @feignClient indicates that the current interface is the OpenFeign communication client and the parameter value is the service ID of the service provider.

The communication interface of a consumer service can return a different type of Customer than the interface return type of a provider service. If the deserialization occurs after a successful request, only the common attributes will be deserialized.

  1. Injection of the client

OpenFeign configuration matters

  1. OpenFeign can modify load balancing policies (same as Ribbon method)

  2. OpenFeign data compression features

    Compression is also configured on the consuming server. When sending a request, the provider is told whether data compression is required. In OpenFeign, compression is not enabled by default. However, if you transfer more than 1K bytes of data between services at a time, it is highly recommended to enable data compression. By default, OpenFeign uses Gzip to compress data. For large text, the compressed size is usually only 10% to 30% of the original data, which greatly improves bandwidth utilization. However, if the CPU is computation-intensive, the CPU load exceeds 70% for a long period of time. Data compression and decompression require CPU operations. Therefore, enabling data compression imposes additional burden on the CPU.

  3. Replace the default communication component

By default, OpenFeign uses URLConnection objects in Java to create HTTP requests. The communication components can be replaced by dedicated communication components such as Apache HttpClient and OKHttp. Based on the connection pool of these components, HTTP connection objects can be better reused and managed.

(1) Introduce okHTTP communication component dependency

< the dependency > < groupId > IO. Making. Openfeign < / groupId > < artifactId > feign - okhttp < / artifactId > < version > 11.0 < / version > </dependency>Copy the code

(2) Initialize the OKHTTPClient object in the start class

@ SpringBootApplication @ EnableFeignClients / / start OpenFeign public class ConsumerOpenfeignApplication {/ / Spring The IOC container object initialization time build okHttpClient @ Bean public okhttp3. OkHttpClient okHttpClient () {return new okhttp3. OkHttpClient. Builder () ReadTimeout (10, timeunit.seconds) // connection timeout time.connecttimeout (10, timeunit.seconds) // writeTimeout time.writetimeout (10, writeTimeout) Timeunit.seconds) // Set connection pool.connectionPool (new connectionPool()).build(); } public static void main(String[] args) { SpringApplication.run(ConsumerOpenfeignApplication.class, args); }}Copy the code

(3) Start OkHttp configuration

API Gateway -Spring Cloud Gateway

Spring Cloud Gateway is a new generation API Gateway product developed by Spring itself. It is based on NIO asynchronous processing, rejecting Zuul’s servlet-based synchronous communication design, and thus has better performance. At the same time, Spring Cloud Gateway is further streamlined in configuration, making it simpler and more useful than Zuul. Zuul, the gateway service of the first generation of Spring Cloud, is now dead. Maintenance stopped)

What does the Gateway do

A barrier is established between the client and microservices, providing a unified access point for microservices access through the API gateway. All requests of the client are intercepted by the API gateway and additional functions can be realized on this basis.

  • Pre-processing, such as unified authentication, fusing, traffic limiting, and logging, is implemented for all requests, enabling microservices to focus on their own services.

  • Generally, API gateways provide RESTful URL interfaces externally. After a user receives a request, the API gateway converts the request to RESTful, RPC, and WebService modes required by back-end services, which greatly simplifies user access.

  • Better security: After API network authentication, users of different roles can control their access rights to back-end services, achieving more fine-grained permission control for services.

  • The API gateway is the only way for the client to access the API. From the user’s point of view, the user only needs to pay attention to the interfaces exposed by the API gateway. As for the processing details of the back-end service, the user does not need to know. In this regard, the microservices architecture decouples the client from the actual implementation of microservices by introducing an API gateway.

The gateway configuration

  • Route: A complete gateway mapping and processing process. A complete Route consists of two parts, Predicate and Filter.

  • Common Configuration Examples

spring:

  application:

    name: gateway-service

  cloud:

    nacos:

      discovery:

        server-addr: 127.0. 01.:8848

        username: nacos

        password: nacos

    gateway: 

      discovery:

        locator:

          enabled: falseGateway routing is no longer requiredroutes: # routing rule configuration # First routing configuration, service-customer routing rule - id: service_customer_route # Route unique identifier #lb indicates the gateway based load balancing policy selection instanceuri: lb://service-customer# predicate configurationpredicates: #Path Path predicate, representing that the client URI will be forwarded to the service-customer instance -path = if it starts with /customer/customer/** #After validate time predicate,2020years10month15The route can be exposed to the gateway only After - After=2020-10-05T00:00:00000.+08:00[Asia/Shanghaifilters: # ignore the layer 1 prefix for forwarding -stripprefix =1# Attach x-response = blue-addresponseHeader = x-response,Blue # Attach the second route configuration, service-contact routing rule -id: service_contact_routeuri: lb://service-contact

          predicates:

            - Path=/contact/**

          filters:

            - StripPrefix=1

Copy the code

The configuration can be found in the official documentation: docs.spring. IO /spring-clou…

  • Spring Cloud Gateway implementation principles

  1. Spring Cloud Gateway starts up based on the Netty Server listening on the specified port (which can be customized with the server.port property). When a local application sends a request to the Gateway, the Gateway enters the Gateway Handler Mapping process. The Gateway determines which microservice will process the request based on the predicates configured by the Gateway.

  2. After the microservice is determined, the request is forwarded to the Gateway Web Handler process. During this process, the Gateway sends the request to the Filter Filter chain for Pre processing in sequence according to the configuration of Filters. Pre-processing is usually used to pre-check the request, such as whether the request contains a specified header, whether the IP source of the request is valid, and whether the parameters contained in the request are correct.

  3. After Pre processing is completed, the request will be forwarded by the Gateway to the real microservice instance for processing. After the microservice processing, the response data will be returned, and the response data will be returned to the filter chain configured by the Gateway for post-processing. Post-processing usually carries out additional processing on the response. For example, logging processes, attaching additional response headers to responses, or traffic monitoring.

Custom global filters

public class ElapsedFilter implements GlobalFilter.Ordered {

    // Start time attribute name
    private static final String ELAPSED_TIME_BEGIN = "elapsedTimeBegin";

    /** * Implement the filter() method to record processing time **@param Exchange is used to get data related to the current request, response, and to set context data that is passed between filters *@param Chain Gateway Filter chain object *@return Mono corresponds to an asynchronous task, because the Gateway is based on Netty Server asynchronous processing, and the Mono pair represents the completion of asynchronous processing. * /
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        //Pre processing part
        When the request arrives, an attribute, elapsedTimeBegin, is placed in the ServerWebExchange context to hold the timestamp before the request is executed
        exchange.getAttributes().put(ELAPSED_TIME_BEGIN, System.currentTimeMillis());


        //chain.filter(exchange).then() corresponds to Post processing
        // After the response is generated, compare the end time with the start time of elapsedTimeBegin to obtain the actual execution time of the RESTful API
        return chain.filter(exchange).then(
                Mono.fromRunnable(() -> { // When the current filter gets a response, the time is calculated and printed
                    Long startTime = exchange.getAttribute(ELAPSED_TIME_BEGIN);
                    if(startTime ! =null) {
                        log.info(exchange.getRequest().getRemoteAddress() // Remote access user address
                                + "|" + exchange.getRequest().getPath()  //Gateway URI
                                + " | cost " + (System.currentTimeMillis() - startTime) + "ms"); // Processing time}})); }// Set the ElapsedFilter to the highest priority
    //return Ordered.LOWEST_PRECEDENCE; Indicates the lowest priority
    @Override
    public int getOrder() {
        returnOrdered.HIGHEST_PRECEDENCE; }}Copy the code
  • Configuration information
Cloud: nacos: discovery: server-addr: 127.0.0.1:8848 #nacos: discovery: serveraddr: 127.0.0.1:8848 #nacos: discovery: serveraddr: 127.0.0.1:8848 Nacos password: nacos gateway: # routes: # Routing rule configuration # # First routing configuration, service-a routing rule -id: Uri: lb://gateway-test # # predicates: # #Path =/gateway-test/** # # predicate configuration # filters: # -stripprefix =1 Server: port: 9007 # management: endpoints: web: exposure: include '*' # Expose all monitoring indicators in the outer zone, which is easy for monitoring systems to collect and trackCopy the code
  • Request the interface through the gateway
http:/ / 127.0.0.1:9007 / gateway - test/test
Copy the code

Gateway is the ID of the requested target service, automatically routed through NACOS, or the ID of a custom route

  • Filter processing logs
c.t.gatewayservice.filter.ElapsedFilter  : / 127.0.0.1:52606 | / gateway-test/test | cost 9ms
Copy the code

Spring Cloud Getaway related filters are used

Alibaba Sentinel

Sentinel is a flow control component for distributed service architecture. It mainly takes traffic as the entry point to help you guarantee the stability of micro services from multiple dimensions such as flow control, fusing degradation and system adaptive protection. The Sentinel’s official website

Build Sentinel Dashboard

The Sentinel Dashboard can be downloaded directly from Github to run the JAR or Sentinel Github address

Run the corresponding version of the JAR and the specified port

Java - jar - Dserver. Port = 9100 sentinel - dashboard -, version 1.8.1. JarCopy the code

Access IP + port (for example, 127.0.0.1:9100) to access the Dashboard login page. The password is sentinel.

Create a Sentinel client demo and let Sentinel monitor it

server: port: 9009 spring: application: name: sample-sentinel-client cloud: nacos: discovery: namespace: Public password: nacos server-addr: 127.0.0.1:8848 username: nacos sentinel: eager: true transport: dashboard: 127.0.0.1:9100# Monitor Sentinel addressCopy the code

The service completes the communication successfully

Configure traffic limiting rules

  1. Create a test request locally

  2. Configure flow control rules

Sentinel-dashboard is lazy-loaded and only accessed function urls appear in the cluster link menu

  • Direct mode: When the LIST interface QPS exceeds one duration stream, the browser appears “Blocked by Sentinel”.

  • Association mode: When the QPS of the Check interface associated with the List interface exceeds 1, the list interface responds to Blocked by Sentinel when it is accessed again.

  • Link mode: Link mode is relatively complex. For example, when a stand-alone e-commerce system is developed, in order to fulfill the business of “placing an order”, the program code will execute the order creation method -> inventory reduction method -> wechat payment method -> SMS sending method in turn. Methods go back and forth like a chain. If the entry resource is set to /check, only the call link of the check interface takes effect. When the number of QPS accessing the check interface exceeds 1, the flow is restricted on the List interface. The other link from the Scan interface to the List interface is not affected. The biggest difference between link mode and association mode is that the check interface and List interface must be in the same invocation link to perform traffic limiting. In association mode, any two resources can perform traffic limiting as long as the association is set.

  • Fast failure: When the traffic limit threshold is exceeded, the system directly returns a response and throws a BlockException. Fast failure is the most commonly used processing mode
  • Warm Up: used to cope with the instantaneous impact of large concurrent traffic. In case of sudden heavy traffic, Warm Up will slowly lift the threshold limit to prevent instantaneous crash of the system. During this period, access exceeding the threshold is in queue waiting state and BlockException will not be thrown immediately
  • Queuing: The request is processed at a uniform speed. If there are 100 requests, the single-node threshold is 4, indicating that one request is processed at a uniform speed for 250ms. BlockExcption is thrown if a request exceeds 1000ms. (Uniform queue only supports QPS mode, and the single-node threshold cannot exceed 1000)
  1. Verify the flow control

Fuse downgrading configuration

Microservice fusing refers to the frequent failure of a service interface during its execution. We consider this state as “unacceptable” and immediately fuse the current interface. Within the specified time, all the requests sent to the interface will directly throw BlockException, after the circuit breaker period, new requests will enter to see whether the interface is restored to normal, the operation will continue, if there is still a fault, the circuit breaker again for a period of time, and so on until the service interface is restored.

  1. Slow call ratio

SLOW_REQUEST_RATIO: Select SLOW_REQUEST_RATIO as the threshold. You need to set RT (maximum response time) for slow calls. If the response time of a request is greater than this value, the request is counted as slow calls. If the number of requests in statIntervalMs is greater than the minimum number of requests and the ratio of delayed calls is greater than the threshold, the requests will be fused automatically in the following fuse duration. After the fuse duration, the fuse will enter the probe recovery state (half-open state). If the response time of the next request is less than the set slow-call RT, the fuse will end. If the response time is longer than the set slow-call RT, the fuse will be disconnected again.

  1. Abnormal proportion

ERROR_RATIO: When the number of requests within statIntervalMs is greater than the minimum number of requests and the proportion of exceptions is greater than the threshold, the requests will be fused automatically within the following fusing period. After the fuse period, the fuse enters the probe half-open state, terminating the fuse if the next request completes successfully (without error), otherwise it will be fused again. The threshold range for the abnormal ratio is [0.0, 1.0], representing 0-100%.

  1. Number of abnormal

Number of exceptions (ERROR_COUNT) : When the number of exceptions in a unit statistics period exceeds the threshold, the circuit breaker is automatically disabled. After the fuse period, the fuse enters the probe half-open state, terminating the fuse if the next request completes successfully (without error), otherwise it will be fused again.