Several sets of implementation scheme reference

Spring Cloud base technology points

Eureka: Service registration and discovery for service management

Feign: Inter-service invocation, which simplifies the invocation of HTTP interfaces

Ribbon: Client-based load balancing

Hystrix: Fuse downgrading prevents service avalanches

Zuul: indicates a gateway route that provides functions such as route forwarding, request filtering, and traffic limiting degradation

Config: configuration center for distributed configuration management

Sleuth: service link tracing

Admin: Health management

Satisfies most scenarios and is still used by many companies. The following is based on this set of implementations

Distributed common architecture diagram:

Spring Cloud Alibaba

Sentinel: Take traffic as the entry point to protect the stability of services from multiple dimensions, such as flow control, fuse downgrading and system load protection

Nacos: A dynamic service discovery, configuration management, and service management platform that makes it easier to build cloud-native applications

RocketMQ: An open source distributed messaging system that provides low-latency, highly reliable message publishing and subscription services based on highly available distributed clustering technology

Dubbo: Apache Dubbo™ is a high-performance Java RPC framework

Seata: Alibaba open source product, an easy-to-use high-performance microservices distributed transaction solution

Alibaba Cloud ACM: an application configuration center that centrally manages and pushes application configurations in a distributed architecture environment

Alibaba Cloud OSS: Alibaba Cloud Object Storage Service (OSS) is a massive, secure, low-cost and highly reliable Cloud Storage Service provided by Alibaba Cloud. You can store and access any type of data in any application, anytime, anywhere

Alibaba Cloud SchedulerX: a distributed task scheduling product developed by Alibaba Middleware team, which provides second-level, accurate, highly reliable and highly available timed (Cron expression based) task scheduling service

Alibaba Cloud SMS: global SMS service, friendly, efficient and intelligent interconnected communication capabilities, to help enterprises quickly build customer access channels

In the future, more and more companies will embrace Spring Cloud Alibaba with easier calls, more elegant implementations, and a more active community

Principles of microservice design

Single responsibility principle: Focus on a single, bounded part of the overall system function

Principle of service autonomy: Can be independently developed, tested, built, deployed, run, decoupled from other services

Lightweight communication principles: light, cross-platform, cross-language. REST, it, etc

Granularity control: combined with their own reality. Don’t strive for perfection, adjust as the business evolves. Book The 10 Years of Taobao Technology

Service registration and discovery

Registry component

Eureka, Nacos, Consul, Zookeeper, etc

The server side

A Server is a public service. It provides service registration and discovery functions for clients, maintains information about clients registered with it, and provides interfaces for clients to obtain information about other services in the registry, enabling dynamic clients to invoke each other

The client

The Client registers its service information with the Server in a certain way and maintains its information consistency within the normal range to facilitate other services to discover it. In addition, the Client can obtain information about other services it depends on from the Server to complete service invocation. The Client also has a built-in load balancer for basic load balancing

The Client function

  1. Registration: When each microservice starts, it registers its network address and other information with the registry, which stores this information (in memory)

  2. Obtaining the service registry: The service consumer queries the network address of the service provider from the registry and invokes the service provider using the address. To avoid checking the registry information every time, the client periodically pulls the registry information from the server and caches it to the client

  3. Heartbeat: Each microservice communicates with the registry through some mechanism (heartbeat). If the registry does not communicate with the service for a long time, the instance will be unregistered

  4. Call: Actual service invocation. Through the registry, the corresponding relationship between the service name and the specific address is resolved to find the address of the specific service for actual invocation

Server registry function

  1. Service registry: Records the information of each micro-service, such as service name, IP, port, etc. The registry provides a query API (to query available micro-service instances) and a management API (to register and deregister services).

  2. Service registration and Discovery:

    Register: Register microservice information to the registry

    Discover: Queries the list of available microservices and their network addresses

  3. Service check: Periodically checks registered services. If an instance is found to be inaccessible for a long time, it is removed from the registry

Had a high availability

This can be achieved by running multiple Instances of Eureka Server and registering them with each other, with Server nodes incrementally synchronizing information with each other to ensure consistent data across the nodes

To protect themselves

  1. By default, if the Eureka Server does not receive a micro-service heartbeat within a certain period of time, it will cancel a micro-service (90S). However, when the network is faulty, the communication between the micro-service and the Server cannot be normal. This behavior is very dangerous, because the micro-service is normal and should not be canceled

  2. The idea of self-preservation: it is better to keep healthy and unhealthy than blindly cancel any healthy service

  3. By default, self-protection is turned on, but many companies turn it off because the presence of an offline service in the service instance list can affect normal invocation, the likelihood of an abnormal service going offline is not very high, and the Admin component can be used to notify the service going offline

  4. Triggering conditions for self-protection:

    1. Enable self-preservation –> eureka.server.enable-self-preservation=true

    2. When the heartbeat (less than numberOfRenewsPerMinThreshold renewsLastMin) per minute

A formula to calculate

NumberOfRenewsPerMinThreshold = expectedNumberOfRenewsPerMin * relet percentage (eureka. Server. RenewalPercentThreshold, 0.85 by default)

ExpectedNumberOfRenewsPerMin = current registration application number 2 x

Why do I multiply by 2? By default, the registered application instance is renewed every half minute, so heartbeat beats twice a minute

The basic principle of

Interested students this part of the advice with their own source

Eureka Client life cycle

The Eureka Server receives heartbeat messages

Eureka Server registered

The Eureka service is offline

Interservice invocation

Several ways of

  1. HTTP: hard coded and difficult to maintain

    Service instances can be stored using the Map< Service name, Service Instance List > data structure

  2. RestTemplate: Provides freedom to call third-party apis

  3. Feign: It requires a bit of configuration, but it’s more elegant

  4. Dubbo: byte level, fast

RestTemplate

@Beanpublic RestTemplate restTemplate() { return new RestTemplate(); }Copy the code

Feign and OpenFeign

  1. Feign itself does not support Spring MVC annotations; it has its own set of annotations

  2. OpenFeign is a Spring Cloud annotation that supports Spring MVC on top of Feign. For example, @RequesMapping and so on, @FeignClient of OpenFeign can parse the interface under @RequestMapping annotation of SpringMVC and generate implementation classes through dynamic proxy, which can perform load balancing and call other services

Feign principle

  1. Add the @enableFeignClients annotation to the main program entry to enable the FeignClient scanning loading process. Define the interface and annotate it with @FeignClient according to the FeignClient development specification

  2. When the program starts, a package scan is performed, scanning all @FeignClient-annotated classes, and injecting this information into the Spring IoC container. When a method in the defined Feign interface is called, a concrete RequestTemplate is generated using the JDK proxy. When the proxy is generated, Feign creates a RequestTemplate object for each interface method, which encapsulates all the information required for HTTP requests, such as request parameter names, request methods, and so on

  3. The RequestTemplate generates the Request and sends it to the Apache Http Client (URLConnection). It could also be Okhttp. Finally, the Client is packaged into the LoadBalanceClient class, which uses the Ribbon load balancing to initiate calls between services

Timeout and retry

Feign supports the Ribbon by default. The Ribbon retry mechanism conflicts with Feign’s retry mechanism. Therefore, the Ribbon retry mechanism is disabled by default in the source code

Ribbon: # ConnectTimeout: 1000 # Service logic timeout: 6000Copy the code

With the Ribbon retry mechanism, a failed request is retried every 6 seconds

Ribbon: # the same instance maximum retries, not including was first called MaxAutoRetries: 1 # retry load balance other instances of maximum retries, first call MaxAutoRetriesNextServer does not include: 1 # whether all operating retry OkToRetryOnAllOperations: falseCopy the code

Load balancing

classification

  1. Hardware load: F5

  2. Software load: client and server

The difference between

The essential difference between client load and server load is: where are the service list addresses and load algorithms placed

Nginx is server load, Ribbon is client load

implementation

  1. The Ribbon can be used as a standalone load balancing component. We just need to manually configure the service address list

  2. When the Ribbon works with Eureka, the Ribbon automatically obtains a service provider address list (DiscoveryClient) from the Eureka Server and requests one service provider instance based on the load balancing algorithm

  3. The Ribbon works seamlessly with OpenFeign and RestTemplate to enable load balancing. OpenFeign is based on Feign, and Feign integrates the Ribbon by default

Load strategy

The default policy

ZoneAvoidanceRule: Composite determines the performance of the zone where the Server is located and the availability of the Server, polling to select the Server

Other strategies

  1. BestAvailableRule (Minimum Concurrency policy) : Filters out the services that are in the circuit breaker tripping state due to multiple access failures, and selects the service with the least concurrency. Find services one by one and ignore them if the circuit breaker is on

  2. RoundRobinRule: Select a server by simple polling. Select a Server in a sequential loop

  3. RandomRule: Select a server at random

  4. AvailabilityFilteringRule filtering strategy (available) : will be filtered access failure many times in the circuit breaker tripped state service and filtering exceeding the number of concurrent connection valve is worth service, then install the polling list of remaining service strategy for a visit

  5. WeightedResponseTimeRule: All services are weighted according to average response time. The faster the response time, the more weighted the service is and the more likely it is to be easily selected. At first, if the statistics are incomplete, the RoundRobinRule policy is used, and the weightedresponse Rule automatically switches to the Weightedresponse Rule when the statistics are sufficient. Long response time, low weight, low probability of being selected. And vice versa. This strategy incorporates various factors (network, disk, IO, etc.) that directly affect response time

  6. RetryRule: The system obtains services based on the RoundRobinRule policy. If the obtained services fail, the system tries again at a specified time to obtain available services. If you fail to obtain a service for several times, you will not obtain the service again. It is mainly in a period of time, if the selection of a service is not successful, continue to find available services until the timeout

fusing

Hystrix is a fault tolerant component that implements a timeout mechanism and a circuit breaker mode to isolate remote systems, services, or third-party libraries from cascading failures to improve system availability and fault tolerance

It has the following functions:

Hystrix is a Netflix open source library used to isolate remote systems, services, or third-party libraries to prevent cascading failures, thereby improving system availability and fault tolerance. It has the following functions:

  1. Provide protection for the system: Provide protection and control for the system in the event of high latency or failure of dependent services

  2. Preventing an avalanche: An avalanche is when a dependent service collapses, the service collapses, and other services that depend on the service collapse

  3. Package request: Use HystrixCommand (or HystrixObservableCommand) to wrap the invocation logic for dependencies, with each command running in a separate thread

  4. Trip mechanism: When the failure rate of a service reaches a certain threshold, Hystrix automatically trips and stops requesting the service for a period of time

  5. Resource isolation: Hystrix maintains a small thread pool for each requested dependency, and if the thread pool is full, requests to that dependency are rejected immediately rather than queued up, speeding up failure determination. Prevent cascading failure

  6. Fail Fast: Fail Fast. It can also recover quickly. The point is :(instead of actually requesting the service and returning with an exception), fail directly

  7. Monitoring: Hystrix monitors operational indicators and configuration changes in real time, providing near-real-time monitoring, alarm, and o&M control

  8. Fallback mechanism: Fallback logic is performed when a request fails, times out, is rejected, or a circuit breaker is turned on. Our custom fallback logic provides elegant service downgrades

  9. Self-repair: After the circuit breaker is opened for a period of time, it will automatically enter the “half-open” state, which can be opened, closed, and half-open state

The gateway

Generally speaking, the gateway is a window on the external network and requires authentication and blacklist verification. While other services are on the Intranet, there is no need to repeat security authentication

The basic function

Zuul integrates the Ribbon and Hystrix by default. The core is a series of filters that perform the following functions

  1. All microservices entry points for distribution

  2. Authentication and security: Identify legitimate requests and intercept illegitimate ones

  3. Monitoring: entrance monitoring, more comprehensive

  4. Dynamic routing: Requests are dynamically distributed to different back-end clusters

  5. Stress testing: You can gradually increase traffic to back-end services to test

  6. Load Balancing: Also with the Ribbon

  7. Limit the flow: for example, I only need 1000 times per second, 10001 times will not allow access

  8. Service fusing

Routing endpoints

During debugging, the gateway requests the address, and whether the mapping is correct. If the gateway request is incorrect, you can rectify the fault

management:  endpoint:    health:      enabled: true      show-details: always    routes:      enabled: true  endpoints:    web:      exposure:        include: '*'
Copy the code

High availability

Gateway cluster, plus a layer of Nginx/LVS

Link to track

In the face of complicated service invocation link view and slow service investigation problem, we can use link tracing technology to solve — Lu Xun

Link tracking products

At present, most of them are based on Google’s Dapper paper to achieve

Zipkin: Twitter open source, Pinpoint Pinpoint paper in strict accordance with Google Dapper: South Korea Naver company Cat: The United States group EagleEye: Taobao SkyWalking: UI good-looking, the development of a little fierce

Configuration center

scenario

  1. There are many microservices, hundreds of them, and many configurations, which require centralized management

  2. Manage configurations for different environments

  3. You need to adjust the configuration parameters dynamically

The working process

FAQ Summary

  1. Solve the problem that services are slowly registered and discovered by other services. The default value is 30 seconds

    Eureka.instance. lease-renewal-interval-in-seconds: 10

  2. A stopped microservice node is logged out slowly or not. Suggest the default

eureka server

Eureka: server: # Disable self-preservation enable-self-preservation: false # shorten the cleaning interval eviction- interval-timer-in-MS: 5000Copy the code

eureka client

# Shorten the heartbeat interval. The default value is 30 seconds, lease-renewal-interval-in-seconds: 10. The default value is 90 seconds, lease-expiration-duration-in-seconds: 90Copy the code
  1. The first request failed after hystrix integration

Cause: The default hystrix timeout period is 1 second. If there is no response within 1 second, the Fallback logic will be used. Due to Spring’s lazy loading mechanism, the first request is to get registry information, etc. So the first request usually takes more than a second

Solution 1: Configure hungry loading

Service invoker ribbon: eagle-load: enabled: true Clients: if the service is a gateway zuul: ribbon: eagle-load: enabled: trueCopy the code

Solution 2: Set a long Hystrix timeout period in the command command

execution:
  isolation:
    thread:
      timeoutInMilliseconds: 
Copy the code

= = =