I. Micro services

1. What are microservices? How do microservices communicate independently?

What are microservices? Origin of Microservices concept: Microservices

Microservices are a group of small services to build an application. The services run independently in different processes and interact with each other through lightweight communication mechanisms (such as RESTful interfaces). In addition, the services can be deployed independently through automatic deployment. Because services are independent of each other in the microservices architecture, different services can be developed in different languages or use different types of databases depending on the needs of the business.

  • Microservice architecture is a distributed system, which is divided into different service units based on services to solve the performance deficiencies of single systems.
  • Microservices is an architectural style in which a large software application consists of multiple units of services. Service units in the system can be deployed separately and are loosely coupled.

How do microservices communicate independently?

Synchronous:

REST HTTP protocol: REST request is the most common communication method in micro services, which relies on the HTTP\HTTPS protocol. RESTFUL features are:

  • Each URI represents one resource
  • The client uses GET, POST, PUT, and DELETE to operate on server resources. GET is used to obtain resources, POST is used to create resources (or update resources), PUT is used to update resources, and DELETE is used to DELETE resources
  • Manipulate resources by manipulating their representation, in the form of XML or HTML
  • The interaction between client and server is stateless between requests, and each request from client to server must contain the information necessary to understand the request

RPC TCP: Remote Procedure Call (RPC). A node requests services provided by another node. It works like this:

Execute the client call statement and send parameters. 2. Invoke the local system to send network messages. The message is sent to the remote host 4. The server gets the message and the parameters 5. Executes the remote procedure (service) based on the call request and parameters 6. 7. The server handle returns the result, and invokes the system network service of the remote host to send the result 8. The message is sent back to the local host 9. The client handle receives the message from the network service of the local host 10. The client receives the result data returned by the calling statement

Asynchronous: message middleware

Common messaging middleware include Kafka, RabbitMQ, RocketMQ, and ActiveMQ. Common protocols include AMQP, MQTTP, STOMP, and XMPP.

2. What is the microservices stack?

  • Microservice development: Rapid development of services. Spring, SpringMVC, SpringBoot
  • Microservice Invocation protocol: REST, Remote Procedure Call (RPC), RMI (Remote Method Invocation)
  • Micro-service registration discovery: Discovery services, registration services, centralized management services. Eureka, Zookeeper, Nacos, Consul
  • Microservice configuration management: Manages the configuration information of one or more services in a centralized manner. Disconf, SpringCloudConfig, Apollo
  • Service Load Balancing: Ribbon (Client), Nginx (server)
  • Service meltdown: Disallow requests to continue when they reach a certain threshold. Hystrix, Sentinel
  • Service interface invocation: Communication between multiple services. Feign(HTTP) (HTTP), Dubbo, Apache HttpClient, Spring RestTemplate
  • API gateway: External requests are intercepted and processed by the API gateway before being forwarded to the real service. Spring Cloud GateWay, Zuul
  • Service link tracing: Identify invocation relationships between services. Zipkin, Brave,
  • Service monitoring: Displays the performance of each service (CPU, memory, traffic, etc.) in visual or non-visual form. Zabbix, Nagios, Metrics
  • Permission authentication: Users can access only authorized resources based on security rules or policies set by the system. Spring Security, Apache Shiro
  • Batch processing: Batch processing of the same type of data or things. Spring Batch
  • Scheduled task: Scheduled task. Quartz, Elastic – the job
  • Message queuing: Decouples services and processes data asynchronously. Kafka, RabbitMQ, RocketMQ, ActiveMQ
  • Log collection (ELK) : Collects service logs and provides log analysis and user portraits. Elasticsearch, Logstash, Kibana
  • Data store: Stores data. Relational types: MySql, Oracle, MsSQL, PostgreSql; Non-relational: Mongodb, Elasticsearch
  • Cache: Stores data. redis
  • Sub-database sub-table: database sub-database sub-table scheme. ShardingSphere, Mycat
  • Service deployment: project rapid deployment, online, continuous integration. Docker, Jenkins, Kubernetes(K8s), Mesos

3. Pros and cons of microservices?

Advantages of micro-service:

  • The service is simple and focuses on a single business function
  • Each microservice can be developed by a different team
  • Microservices are loosely coupled
  • It can be developed in different programming languages and tools

Disadvantages of microservices:

  • Operation and maintenance overhead, DevOps requirements
  • Distributed link tracing is difficult
  • The complexity of distributed systems, as the number of services increases, becomes more complex to manage

4. What are the differences between Spring Cloud and Dubbo?

Dubbo is an open source service framework with excellent performance, which is based on RPC invocation. For Spring Cloud Netflix, which has a high usage rate, it is based on HTTP, so its efficiency is not as high as Dubbo. However, the problem lies in the incomplete components of Dubbo system. It cannot provide one-stop solutions, for example, service registration and discovery need to be realized by Zookeeper, etc. However, Spring Cloud Netflix really provides one-stop service-oriented solutions with Spring family background.

Reference: Full comparison of Java microservices frameworks (Dubbo vs. Spring Cloud?)

Dubbo

  • Advantages:

1. Support a variety of communication protocols, and the consumer and the service use long link interaction, communication speed slightly better;

2. Using RPC, the performance is better than Spring Cloud’S RPC;

3. Dubbo’s network consumption is less than SpringCloud’s

  • Disadvantages:

1. If we use the configuration center and distributed tracking, we need to integrate them by ourselves;

2. It is difficult to develop dubbo because many large projects cannot solve the dependency problem of DUbbo JAR package;

Spring Cloud

  • Advantages:

1. It is produced by the Spring family. Spring has a long history in the enterprise development framework, which can guarantee the subsequent update and improvement.

2. Active Spring Cloud community, rich tutorials, easy to find solutions to problems;

3. Spring Cloud features more complete than Dubbo;

5. Spring Cloud adopts REST access mode, which has better effect of technology independence;

6. Spring Cloud easily completes various platform functions of fusing, balancing responsibility and service center in a few lines of code;

7. Spring Cloud has more advantages in recruiting engineers from companies, because its technology updates are more dazzling;

8. Provide a complete set of solutions for microservices: service discovery registration, configuration center, message bus, load balancing, circuit breaker, data monitoring, etc. As a big guy of micro service governance, consider very comprehensive, almost all aspects of service governance are considered, convenient development out of the box;

  • Disadvantages:

1. If there are strict requirements on the response time of the system, long links are more suitable.

2. The interface protocol is free and loose, and strong administrative measures are required to prevent the interface from being upgraded out of order

5. The relationship between Spring Cloud and Spring Boot?

Spring Boot is a set of Spring fast configuration scaffolding, you can quickly develop a single micro service based on Spring Boot, Spring Cloud is a Cloud application development tool based on Spring Boot implementation; Spring Boot focuses on fast and easy integration of a single microservice individual, while Spring Cloud focuses on the global service governance framework. Spring Boot uses the concept of default greater than configuration, many integration solutions have been selected for you, can not configure, Spring Cloud is based on a large part of the Implementation of Spring Boot, can not be based on Spring Boot? Can’t.

Conclusion: SpringBoot serves as a link between Spring Clound and Spring Clound. Spring Boot can be independently used for development projects without Spring Cloud, but Spring Cloud cannot be separated from Spring Boot, which is a dependency.

Eureka Service Registry

1. What is Eureka

Registry: A centralized component for registering and managing services, managing all service information and status. Registries include Eureka, Nacos, Consul, and Zookeeper, as shown below:

Eureka, a RESTful service framework developed by Netflix, is a basic component for service discovery and registration. It is one of the preconditions for building Spring Cloud microservices. It shields the interaction details between Server and client, enabling developers to focus on business.

Service registration and discovery consists of two parts: the Server (Eureka Server) and the customer (Eureka Client).

  • Eureka Server: 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.
  • Client (Eureka Client) : Client will own service information through a certain way to register to the Server, and within the normal range to maintain their own information consistency, convenient and other services to find himself, at the same time can get to their dependence on other services through Server information, complete the service call, also built-in load balancer, used to carry out the basic load balancing.

2. Some basic concepts of Eureka

Service Register: When the Eureka client registers with the Eureka Server, it provides its own metadata, such as IP address, port, health indicator URL, home page, and so on.

Renew: Eureka customers will send a heartbeat every 30 seconds (by default) to Renew. Renew the contract to inform the Eureka Server that the Eureka customer still exists and there is no problem. Normally, if Eureka Server does not receive a renewal from an Eureka customer within 90 seconds, it removes the instance from its registry.

Fetch Registries: The Eureka client fetches the registry information from the server and caches it locally. The client uses this information to find other services to make remote calls. This registration list information is updated regularly (every 30 seconds). The information returned from the registration list may be different from the information cached by the Eureka client. The Eureka client processes the information automatically. If for any reason the registry information does not match in time, the Eureka client retrieves the entire registry information. The Eureka server caches the registry information, and the entire registry as well as the information for each application is compressed so that the compressed content is identical to the uncompressed content. The Eureka client and Eureka server can communicate using JSON/XML format. By default, the Eureka client uses compressed JSON format to retrieve the registry information.

Service offline Cancel: The Eureka client sends a cancellation request to the Eureka server when the program is closed. After the request is sent, the client instance information is removed from the server’s instance registry. The offline request will not automatically completed, it needs to call the following content: DiscoveryManager. GetInstance () shutdownComponent ();

Service Eviction: By default, Eureka server will remove the service instance from the service registry, when the Eureka client does not send a service renewal, i.e. heartbeat, to the Eureka server for 90 consecutive seconds (3 renewal cycles).

3.Eureka infrastructure

Eureka improves system flexibility, scalability and availability through mechanisms such as heartbeat detection, health check and client caching. Github.com/Netflix/eur…

Eureka consists of two components: Eureka Server and Eureka Client. Eureka Server provides the ability of service discovery. When each micro-service is started, Eureka Client registers its own information with Eureka Server. Eureka Server stores information about the service.

  • Service providers register services in Eureka Server, and Eureka Server will synchronize data in clusters and partitions after receiving registration events. Service consumers can obtain service registration information from the registry for service invocation
  • Each Eureka Server is also a Eureka Client. Multiple Eureka servers synchronize service registration lists through replication
  • After the microservice is started, it periodically sends heartbeat (default interval is 30 seconds) to the Eureka Server to renew its information
  • If the Eureka Server does not receive the heartbeat of a microservice within a certain period of time (default: 90 seconds), the microservice node will be deregister
  • The Eureka Client caches information in the Eureka Server. When all Eureka Server nodes go down, the service consumer can still use the information in the cache to find the service provider

4. Eureka metadata

There are two types of Eureka metadata: standard metadata and custom metadata.

  • Standard metadata: information such as hostname, IP address, port number, etc. is published to the service registry for inter-service invocation
  • User-defined metadata: You can configure Eureka.instance. metadata-map in application. Yml to meet the key/value storage format. This data can be accessed from a remote customer service

Such as:

eureka:
  instance:
	metadata-map:
	  # Custom metadata (key/value custom)
	  cluster: cl1
	  region: rn1
Copy the code

DiscoveryClient can be used in an application to obtain all metadata information for a specified microservice:

// Get the specified microservice instance from EurekaServer
List<ServiceInstance> serviceInstanceList =discoveryClient.getInstances("service-user");
Copy the code

Debug allows you to see custom metadata:

5. Common Eureka configurations

Server configuration: Enable the Eureka service by setting @enableEurekaserver annotation in the Spring Boot startup class

eureka:  
  instance:    
  	hostname: xxxxx    # host name
	prefer-ip-address: true/false   Display IP address when registering
  server:    
  	enableSelfPreservation: true   Activate self-protection
	renewalPercentThreshold: 0.85  # Renew configuration percentage
Copy the code

Customer service configuration: Set @enableDiscoveryClient annotation in the Spring Boot startup class to enable Eureka

eureka:  
  client:    
  	register-with-eureka: true/false  # Whether to register yourself with the registry
  	fetch-registry: Specifies whether this client can obtain eureka registration information
  	service-url:    Expose the service center address
  	  defaultZone: http://xxxxxx   # default configuration
  instance: instance-id: xxxxx Specify the name of the current client in the registry
Copy the code

6.Eureka Client

The service provider registers the service with Eureka server and completes the service renewal, and the service consumer obtains the service list.

Service Registration (Service Provider) :

  • Add the Eureka -client dependency and set the address of the Eureka service registry
  • When a service is started, a registration request is made to the registry, carrying service metadata information
  • The Eureka registry stores information about service nodes in a Map

Service Renewal (Service Provider) :

The service is renewed to the registry every 30 seconds (heartbeat detection). If it is not renewed, the lease expires in 90 seconds and then the service expires.

Configuration in the configuration file: Generally, this parameter does not need to be modified

Register service with Eureka service center cluster
eureka:
  instance:
	Lease renewal interval, default 30 seconds
	lease-renewal-interval-in-seconds: 30
	EurekaServer will remove the service from the list if there is no heartbeat after 90 seconds
	lease-expiration-duration-in-seconds: 90
Copy the code

Get a list of services (service consumers) :

After starting the Eureka Server service, the service consumer will obtain the read-only backup service list from the Eureka Server service list and cache it locally. Data is retrieved and updated every 30 seconds. The interval can be changed by configuring eureka.client.registry-fetch-interval-seconds.

Register service with Eureka service center cluster
eureka:
  client:
  	# How often to pull the service list
	registry-fetch-interval-seconds: 30
Copy the code

7.Eureka Server Server

Service offline: When a service is normally shut down, a REST request is sent to the Eureka server to send the service offline. The registry interface puts the service offline after the request.

Failure elimination: Eureka Server will be timed (every 60 seconds eureka.server. Eviction – Interval-timer-in-MS) for inspection, If the service node does not receive the heartbeat within one point (default: 90 seconds eureka.instance.lease-expiration- durations-in-seconds), the instance is deregister.

Why there is self-protection: By default, Eureka Server will remove a microservice instance if it does not receive a heartbeat for a certain period of time (90 seconds by default). However, when the network partition failure occurs, the microservice cannot communicate with Eureka Server normally, and the microservice itself is running normally. At this time, the microservice should not be removed, so self-protection mechanism is introduced.

Self-protection enabled: If more than 85% of the client nodes have no normal heartbeat within 15 minutes, Eureka considers that there is a network failure between the client and the registry, and The Eureka Server automatically enters the self-protection mechanism.

The following information is displayed on the service center page:

In self-protection mode:

  • No service instances will be removed (possibly due to network issues between the service provider and EurekaServer), ensuring that most services are still available
  • The Eureka Server can still accept registration and query requests for new services, but will not be synchronized to other nodes to ensure that the current node is still available. When the network is stable, the new registration information of the current Eureka Server will be synchronized to other nodes

Enable-self-preservation Eureka Server enable-self-preservation eureka.server.enable-self-preservation

eureka:
  server:
	enable-self-preservation: false  # Turn off self-protection mode (default: turn on)
Copy the code

Summary and reference

The service provider starts up with a registration request to the registry, carrying service metadata information, and sends a heartbeat to the registry every 30 seconds to renew. If the lease is not renewed, the service will expire after 90 seconds. The service consumer retrieves the read-only backup list list from the registry and caches it locally, retrieving and updating the data every 30 seconds.

When the Eureka client is normally shut down, the server takes the service offline (this is not done automatically). The server checks every 60 seconds. If the instance does not receive heartbeat messages within 90 seconds, the server deregisters the instance. Within 15 minutes, more than 85% of the customer service nodes did not have normal heartbeat. The server went into self-protection mode, did not exclude any service instances, and could still accept new service registration and query requests.

Eureka (AP) improves system flexibility, scalability, and availability through heartbeat detection, health check, and client caching.

Reference links:

  • Eureka in Spring Cloud
  • In-depth understanding of Eureka
  • SpringColud Eureka service registration and discovery

3.Ribbon Load Balancing

1. Overview of load balancing

Load balancing is generally divided into server load balancing and customer load balancing:

  • Server-side load balancers, such as Nginx and F5, route the request to the target server according to certain algorithms after the request arrives at the server
  • Customer side load balancing, such as the Ribbon. The service consumer client has a list of server addresses. Before making a request, the caller selects a server to access using a load balancing algorithm

Ribbon is a load balancer released by Netflix. Eureka works with the Ribbon. The Ribbon reads service information from Eureka and loads the service provided by the service provider based on certain algorithms.

2. The Ribbon core component IRule

When service A calls service B, service B has multiple instances. In this case, how does service A choose to call service B instances? The ribbon can choose the following load balancing policies.

IRule: Selects a service to access from a list of services based on a specific algorithm:

  • RoundRobinRule: indicates a polling policy.
  • RandomRule: a RandomRule strategy.
  • AvailabilityFilteringRule: available filtering strategy. Services in the state of disconnection and trip due to multiple access failures and those with concurrent connections exceeding the threshold are first filtered out, and then the remaining list of services is accessed according to the polling policy
  • WeightedResponseTimeRule: weight polling strategy. The weight of all services is calculated based on the average response time. The faster the response time, the higher the service weight and the higher the probability of being selected. If the statistics are insufficient, the RoundRobinRule policy is used
  • RetryRule: Retry policy. Add a retry mechanism to RoundRobinRule, which repeatedly uses a linear polling strategy to select available instances within a specified retry time
  • BestAvailableRule: Minimum connection number policy. Filter out services that are in the breaker trip state due to multiple access failures, and then select a service with the least concurrency
  • ZoneAvoidanceRule: Zone tradeoff policy (default rule). Double filtering is adopted to filter the instances that are not in the same zone and the faulty instances, and the instances with smaller concurrency are selected

Ribbon already has strategy applications:

Global Settings:

@Configuration
public class ConfigBean {

    @Bean
    @LoadBalanced
    public RestTemplate getRestTemplate(a){
        return new RestTemplate();
    }

    // Override the default load balancing rule with the newly defined load balancing rule
    @Bean
    public IRule myRule(a){
        //return new RoundRobinRule(); / / todo polling
        //return new RandomRule(); / / todo random
        return new RetryRule();// Todo first obtains the service according to the polling policy. If it fails to obtain the service, todo will retry within a specified time to obtain the available service}}Copy the code

Local Settings: Modify the load balancing policy of a service specified in the configuration file. Format: service application name. Ribbon. NFLoadBalancerRuleClassName

# for the microservice name of the called party, if not added, it takes effect globally
# service-provider specifies the name of the invoked service
service-provider:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule Load policy adjustment
Copy the code

Customizing Ribbon load balancing policies:

  • Add @RibbonClient startup class: Our custom Ribbon configuration class can be loaded when the micro service is launched to make the configuration effective
  • Note the configuration details: The official documentation explicitly warns that custom configuration classes cannot be placed under the current package and its subpackages described by @ComponentScan or else the class will be shared by all Ribbon clients and will not be specialized

Requirements: Still polling the policy, but with new requirements, each server is required to be called five times

  • Add a annotation to the main boot class: @RibbonClient(name = “MicroServicecloud-dept “, Configuration = mySelFrule.class)

  • Inject custom load balancing algorithm:

    @Configuration
public class MySelfRule {
    @Bean
    public IRule myRule(a){
        return new RandomRule_ZY();// Todo custom load balancing algorithm}}Copy the code

  • Custom algorithm:

    public class RandomRule_ZY extends AbstractLoadBalancerRule {
    
    public Server choose(ILoadBalancer lb, Object key) { / /... }
        
	@Override
    public void initWithNiwsConfig(IClientConfig iClientConfig) {}

    @Override
    public Server choose(Object key) {
        return this.choose(this.getLoadBalancer(), key); }}Copy the code

3. Common configurations of the Ribbon

Global configuration:

ribbon:
  ConnectTimeout: 1000 Service request connection timeout (ms)
  ReadTimeout: 3000 Service request processing timeout (ms)
  OkToRetryOnAllOperations: true # enable retry for timeout requests
  MaxAutoRetriesNextServer: 1 # Maximum number of switchover retry instances
  MaxAutoRetries: 1 # Maximum number of retries after switching instances
  NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule Modify the load balancing algorithm
Copy the code

The ribbon node is attached to the service name. The following is a separate configuration for calling user-service on the ribbon service

user-service:
  ribbon:
    ConnectTimeout: 1000 Service request connection timeout (ms)
    ReadTimeout: 3000 Service request processing timeout (ms)
    OkToRetryOnAllOperations: true # enable retry for timeout requests
    MaxAutoRetriesNextServer: 1 # Maximum number of switchover retry instances
    MaxAutoRetries: 1 # Maximum number of retries after switching instances
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule Modify the load balancing algorithm
Copy the code

4.Ribbon Applications and principles

There is no need to refer to additional Jar coordinates because eureka-Client is referenced in the service consumer, which refers to the Ribbon related Jar package.

The @loadBalanced annotation gives the RestTemplate the ability to load balance: You can see that using the Ribbon for load balancing is as simple as using RestTemplate directly. Just add @loadBalanced to the RestTemplate.

@Configuration
public class RibbonConfig {

    @Bean
    @LoadBalanced	// Ribbon load balancing
    public RestTemplate restTemplate(a){
        return newRestTemplate(); }}Copy the code

Principle:

The ServiceInstance choose(String serviceId) method is defined on the LoadBalancerClient interface to obtain a specific ServiceInstance based on the service name.

SpringClientFactory class defines a Map < String, AnnotationConfigApplicationContext > contexts, the key is serviceId, The value for AnnotationConfigApplicationContext object. This means that a different load balancing policy can be set for each service. AnnotationConfigApplicationContext in the main preserved the ILoadBalancer bean, defines the realization of load balancing; The latter relies on:

  • IClientConfig: defines the client configuration, which is used to initialize the client and load balancing configuration. The default value DefaultClientConfigImpl
  • IRule: load balancing policies, such as polling. The default value ZoneAvoidanceRule
  • IPing: defines how to determine whether a service instance is healthy. The default value DumyPing
  • ServerList: defines methods to get a list of servers; The default valueRibbon:ConfigurationBasedServerList Spring Cloud Alibaba:NacosServerList
  • ServerListFilter: Select a specific server list based on the configuration or filtering rules. The default value ZonePreferenceServerListFilter
  • ServerListUpdater: Defines a policy for dynamically updating the server list. The default value PollingServerListUpdater

More than the default implementation reference RibbonClientConfiguration ZoneAwareLoadBalancer, diagram is as follows:

ILoadBalancer AnnotationConfigApplicationContext in order is: first through external configuration import, followed by the configuration class.

The Ribbon loads lazily by default. Once the service is started, the first request is very slow and the second one is much faster. Turn on hunger loading:

ribbon:
  eager-load:
    enabled: true  # Turn on hunger loading
    clients: server-1,server-2,server-3  # Enable hungry loading for which service names, separated by commas
Copy the code

reference

  • Spring Cloud Ribbon source code
  • Spring Cloud Ribbon: Load balancing service invocation
  • Ribbon Ribbon Ribbon Ribbon Ribbon

Iv.Hystrix fuse

The Hystrix component is a service protection framework provided by SpringCloud. Also known as circuit breakers, commonly known as “porcupine”, with self-protection ability.

1. Avalanche Effect

Cascading effect: A single request in a microservice may require multiple microservice interfaces to be implemented, resulting in complex invocation links. If the response time of a micro-service on the fan out link is too long or unavailable, all requests are delayed. If the delay reaches the maximum value, system resources may be exhausted and the entire distributed system becomes unavailable.

  • Fan in: represents the number of times that the microservice is called. The larger the number, the better the reusability of the module
  • Fan out: indicates the number of other microservices called by this microservice. The more the number is, the more complex the module business will be

Hystrix ensures high service availability with three technologies: service circuit breaker, service degradation, and thread isolation

  • Service fuse: When the number of interface invocation failures of a service reaches a threshold or percentage within a certain period of time, the fuse is enabled. During the service fuse, the service denies the client access to the interface that has the fuse enabled.
  • Service degradation: If a degradation method is configured on an interface, the invocation of the degradation method is triggered and the result is returned to the user when the interface fails to be invoked, times out, or access is denied
  • Thread isolation: Create a separate thread pool for the interface. Thread isolation is performed on frequently invoked interfaces to prevent them from consuming the thread pool of the Web container.

When an interface fails to be invoked, times out, or is rejected, a friendly message is sent to the client in a timely manner. In addition, the service pressure is reduced and the high availability of the service is ensured. Service fusing is generally caused by a service fault, while service degradation is generally considered from the overall load. Service downgrades always result in service fuses, and service fuses do not necessarily result in service downgrades. Through thread isolation, the avalanche effect and serial avalanche effect are solved to ensure high availability of services.

Hystrix consumes server resources. Therefore, enable Hystrix protection only for interfaces with high concurrency. Hystrix enhances the interface with @hystrixCommand (). @hystrixCommand () can be configured with parameters such as fusing time. The parameters configured in @hystrixCommand () override the Hystrix parameters configured in application.yml.

2.Hystrix applications and related configurations

2.1 Introducing dependencies:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
Copy the code

2.2 Global Configuration:

hystrix:
  command: # used to control HystrixCommand behavior
    default:
      execution:
        isolation:
          strategy: THREAD # Control HystrixCommand's isolation policy, THREAD-> THREAD pool isolation policy (default), SEMAPHORE-> SEMAPHORE isolation policy
          thread:
            timeoutInMilliseconds: 1000 HystrixCommand: HystrixCommand: HystrixCommand: HystrixCommand: HystrixCommand
            interruptOnTimeout: true Configure HystrixCommand to interrupt HystrixCommand execution when timeout occurs
            interruptOnCancel: true # configure whether to interrupt HystrixCommand execution when it is cancelled
          timeout:
            enabled: true # Configure whether timeout is enabled for HystrixCommand
          semaphore:
            maxConcurrentRequests: 10 The semaphore isolation policy is used to control the number of concurrent requests. Requests exceeding this number will be rejected. Maximum number of concurrent requests. Default value: 10. When the interface has received 10 requests and is processing them, subsequent requests trigger fuses
      fallback:
        enabled: true # Used to control whether service degradation is enabled
      circuitBreaker: # Used to control the behavior of HystrixCircuitBreaker
        enabled: true Used to control whether the breaker tracks health and fusing requests
        requestVolumeThreshold: 20 # Number of error requests allowed for interface calls in window time. Default: 20
        errorThresholdPercentage: 50 Percentage of total requests allowed for interface calls in window time. Default: 50%
        sleepWindowInMilliseconds: 5000 # Hibernation duration after fusing. Default: 5000 ms
        forceOpen: false Force the breaker on and reject all requests
        forceClosed: false Force the breaker off and accept all requests
      requestCache:
        enabled: true This controls whether request caching is enabled
      metrics:
        rollingStats:
          By default, within 10 seconds, the number of requests reaches 20, and the failure rate is more than 50%, and the active window after the trip is 5s
          ### Window time, default: 10000ms, i.e. 10s. timeInMilliseconds/numBuckets
          How many successful, Failure, timeout, rejection requests is analyzed at every 1s
          timeInMilliseconds: 10000
          ### Number of buckets. Default value: 10. When setting numBuckets, make sure timeInMilliseconds % numBuckets == 0
          numBuckets: 10  
  collapser: Controls the execution behavior of HystrixCollapser
    default:
      maxRequestsInBatch: 100 # control the maximum number of merge requests
      timerDelayinMilliseconds: 10 # control how many milliseconds requests are merged into one
      requestCache:
        enabled: true # control whether caching is enabled for merge requests
  threadpool: Control the behavior of the thread pool in which HystrixCommand is executed
    default:
      coreSize: 10 The number of core threads in the thread pool, default 10
      maximumSize: 10 # The maximum number of threads in the thread pool. Requests exceeding this number will be rejected
      maxQueueSize: - 1 # set the maximum queue size for the thread pool, as SynchronousQueue (-1) and LinkedBlockingQueue (other positive numbers)
      queueSizeRejectionThreshold: 5 # set the rejection threshold for the thread pool queue. Since LinkedBlockingQueue cannot be dynamically resized, this parameter is required to control the number of threads. Default is 5
      
# Springboot exposes health check and other breakpoints to observe trip status
management:
  endpoints:
	web:
	  exposure:
		include: "*"
  Expose health interface details
  endpoint:
	health:
	  show-details: always  
# # # visit health check interface: http://localhost:8090/actuator/health
Copy the code

Instance configuration: In instance configuration, you only need to change the default of global configuration to the corresponding key

hystrix:
  command:
    HystrixComandKey: # Replace default with HystrixComnandKey
      execution:
        isolation:
          strategy: THREAD
  collapser:
    HystrixCollapserKey: Replace default with HystrixCollapserKey
      maxRequestsInBatch: 100
  threadpool:
    HystrixThreadPoolKey: # replace default with HystrixThreadPoolKey
      coreSize: 10
Copy the code

Description of the key in the configuration file:

  • HystrixComandKey corresponds to the commandKey property in @hystrixCommand.
  • HystrixCollapserKey corresponds to the collapserKey property in the @hystrixCollapser annotation;
  • HystrixThreadPoolKey corresponds to the threadPoolKey property in @hystrixCommand.

2.3 Add @enablecircuitbreaker to the Bootstrap class to enable Hystrix’s circuit breaker function. The @Enablecircuitbreaker, @EnableDiscoveryClient, and @SpringBootApplication annotations can be replaced with **@SpringCloudApplication**.

2.4 Add Hystrix to an interface to enhance the high availability of the interface. Use the @hystrixCommand () annotation. Note: The method parameters and return values of the failed call must be the same as the original method. Service degradation only works on the consumer side.

@RestController
public class MemberController {

    // 1. Set callback method; Set the exception to be ignored. If the exception is reported, Hystrix will not catch it and perform the degrade method. The interface will throw the exception directly
    @HystrixCommand(fallbackMethod = "inserMemberFallback", ignoreExceptions = {ArithmeticException.class})
    @GetMapping("/member/insert")
    public String insertMember(a) {
        int i = 10/0;
        return "Added member info successfully!";
    }

    // 2. Set the commandProperties parameter to set the allowed error request threshold, error request percentage, and fuse duration within the window time.
    // Set the threadPoolProperties parameter to set the number of threads in the thread pool that are thread isolated and the maximum number of pending requests
    @HystrixCommand( fallbackMethod = "deleteMemberFallback", commandProperties = { @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "5"), @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value ="30000"), @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value ="60") } )
    @GetMapping("/member/delete/{id}")
    public String deleteMember(@PathVariable("id") String id) {
        if("1".equals(id)) {
            int i = 10/0;
        }
        return "Deleting member information succeeded";
    }
    
	@hystrixCommand (// Thread pool id, to keep it unique, Not only share the threadPoolKey = "findResumeOpenStateTimeoutFallback", ThreadPoolProperties = {@hystrixProperty (name="coreSize",value =" 1"), @hystrixProperty (name="maxQueueSize",value="20") CommandProperties ConfigureCommandProperties = {// Each property is a HystrixProperty @ HystrixProperty (name = "execution. The isolation. Thread. TimeoutInMilliseconds", value = "2000"), / / hystrix advanced configuration, // Within 8 seconds, the number of requests reaches 2, and the failure rate is more than 50%, Trip after the active window is set to 3 s / / statistical time window defined @ HystrixProperty (name = "metrics. RollingStats. TimeInMilliseconds," value = "8000"), / / statistics, the minimum number of requests in time Windows @ HystrixProperty (name = "circuitBreaker. RequestVolumeThreshold", value = "2"). / / statistics of the number of errors in time Windows percentage threshold @ HystrixProperty (name = "circuitBreaker. ErrorThresholdPercentage", value = "50"), / / repair of the active window length @ HystrixProperty (name = "circuitBreaker. SleepWindowInMilliseconds", value = "3000")}, FallbackMethod = "myFallBack" // fallbackMethod)
    @GetMapping("/checkStateTimeoutFallback/{userId}")
	public Integer findResumeOpenStateTimeoutFallback(@PathVariable Long userId) {
		// Using the ribbon doesn't require us to get our own service instances and then choose one to access.
		String url = "http://service-resume/resume/openstate/" + userId;
		Integer forObject = restTemplate.getForObject(url, Integer.class);
		return forObject;
	}
    
    // Note: This method takes the same parameters and returns the same values as the original method
    public Integer myFallBack(Long userId) {
    	return -123333; // Backpocket data
    }

    public String inserMemberFallback(a) {
        return InsertMember () failed, demote method executed!;
    }

    public String deleteMemberFallback(String id) {
        return "Call deleteMember() failed, execute reversion method!"; }}Copy the code

HystrixCommand

Common arguments in @hystrixCommand:

  • FallbackMethod: specifies the handling method for service degradation.
  • IgnoreExceptions: Ignore certain exceptions to prevent service degradation.
  • CommandKey: Specifies the command name, which is used to distinguish different commands.
  • GroupKey: indicates the group name. Hystrix collects statistics on command alarms and dashboard information based on different groups.
  • ThreadPoolKey: The name of the thread pool used to divide the thread pool.

Test cases:

// Sets the command, group, and thread pool names
@HystrixCommand(fallbackMethod = "getDefaultUser", commandKey = "getUserCommand", groupKey = "getUserGroup", threadPoolKey = "getUserThreadPool")
public CommonResult getUserCommand(@PathVariable Long id) {
    return restTemplate.getForObject(userServiceUrl + "/user/{1}", CommonResult.class, id);
}

// Use ignoreExceptions to ignore some exception degradation
@HystrixCommand(fallbackMethod = "getDefaultUser2", ignoreExceptions = {NullPointerException.class})
public CommonResult getUserException(Long id) {
    if (id == 1) {
        throw new IndexOutOfBoundsException();
    } else if (id == 2) {
        throw new NullPointerException();
    }
    return restTemplate.getForObject(userServiceUrl + "/user/{1}", CommonResult.class, id);
}

public CommonResult getDefaultUser(@PathVariable Long id) {
    User defaultUser = new User(-1L."defaultUser"."123456");
    return new CommonResult<>(defaultUser);
}

public CommonResult getDefaultUser2(@PathVariable Long id, Throwable e) {
    LOGGER.error("getDefaultUser2 id:{},throwable class:{}", id, e.getClass());
    User defaultUser = new User(-2L."defaultUser2"."123456");
    return new CommonResult<>(defaultUser);
}
Copy the code

4.Hystrix request caching

As the system becomes more and more concurrent, we need to use caching to optimize the system to reduce the number of concurrent request threads and provide response speed.

Related notes:

  • @cacheresult: Enables caching. By default, all parameters are used as cache keys. CacheKeyMethod Specifies a key using a method of type String.
  • @cachekey: specifies the CacheKey. You can specify a parameter or attribute value as the CacheKey. CacheKeyMethod can also be specified using a method that returns a String.
  • @cacheremove: Specifies a commandKey to remove the cache.

Test cases:

@CacheResult(cacheKeyMethod = "getCacheKey")
@HystrixCommand(fallbackMethod = "getDefaultUser", commandKey = "getUserCache")
    public CommonResult getUserCache(Long id) {
    LOGGER.info("getUserCache id:{}", id);
    return restTemplate.getForObject(userServiceUrl + "/user/{1}", CommonResult.class, id);
}

/** * The method that generates the key for the cache */
public String getCacheKey(Long id) {
    return String.valueOf(id);
}

// The remote microservice is invoked
@GetMapping("/testCache/{id}")
public CommonResult testCache(@PathVariable Long id) {
    userService.getUserCache(id);
    userService.getUserCache(id);
    userService.getUserCache(id);
    return new CommonResult("Operation successful".200);
}
Copy the code

The testCache method was called remotely, which queried the id three times, but only printed the log once in the console.

HystrixRequestContext needs to be initialized and closed before and after each cache request. Otherwise, the following exception will occur:

java.lang.IllegalStateException: Request caching is not available. Maybe you need to initialize the HystrixRequestContext?
	at com.netflix.hystrix.HystrixRequestCache.get(HystrixRequestCache.java:104) ~[hystrix-core-1.518..jar:1.518.]
	at com.netflix.hystrix.AbstractCommand$7.call(AbstractCommand.java:478) ~[hystrix-core-1.518..jar:1.518.]
	at com.netflix.hystrix.AbstractCommand$7.call(AbstractCommand.java:454) ~[hystrix-core-1.518..jar:1.518.]
Copy the code

HystrixRequestContext can be initialized and closed before and after each request using filters:

@Component
@WebFilter(urlPatterns = "/*",asyncSupported = true)
public class HystrixRequestContextFilter implements Filter {
    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        HystrixRequestContext context = HystrixRequestContext.initializeContext();
        try {
            filterChain.doFilter(servletRequest, servletResponse);
        } finally{ context.close(); }}}Copy the code

reference

  • Spring Cloud Hystrix: Service fault tolerance protection
  • N ways to play Hystrix timeout configuration
  • SpringCloud2.0: Hystrix
  • Hystrix Dashboard: Circuit breaker execution monitoring

Feign remote call component

1. Summary of Feign

Feign is a lightweight RESTful HTTP service client developed by Netflix. It invokes HTTP requests in the way of Java interface annotations, instead of directly invoking HTTP request packets by encapsulating them in Java. Feign is widely used in Spring Cloud solutions.

  • Feign does not require us to concatenate the url and call the restTemplate API. In SpringCloud, we create an interface (the consumer side) and add annotations to the interface
  • SpringCloud enhances Feign to support SpringMVC annotations (OpenFeign)

Essence: Encapsulates Http call flow, interface oriented programming, similar to Dubbo service call.

2. The application of Feign

Netflix’s Open Feign is Spring’s alternative to Ribbion’s RestTemplate. Define the interface on the consumer side that maps to the service side, and then you can invoke the service on the provider side (the target REST service) by calling the interface methods on the consumer side. Developers don’t need to write code to invoke the service other than the interface definition, which is a common approach today.

Introducing dependencies:

<dependency>    
    <groupId>org.springframework.cloud</groupId>    
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
Copy the code

Add Feign configurations as required:

feign:
  client:  
	config:   
	  default:   
		connectTimeout: 5000  # Specify a timeout for Feign clients to connect to providers, depending on the network environment ************
		readTimeout: 5000   # specify that the Feign client timeout from the request to the response from the provider depends on the business logic operation time ************
  compression:    
	request:      
	  enabled: true   Enable compression of requests
	  mime-types: text/xml,application/xml,application/json    
	  min-request-size: 2048   # specify the minimum file size to enable compression
	response:      
	  enabled: true   Turn on compression of the response
  hystrix:	
    enabled: true  # Enable the fuse breaker function
    command:
      default:
        circuitBreaker:
          sleepWindowInMilliseconds: 30000
          requestVolumeThreshold: 50
        execution:
          timeout:
            enabled: true
          isolation:
            strategy: SEMAPHORE
            semaphore:
              maxConcurrentRequests: 50
            thread:
              timeoutInMilliseconds: 100000  # Global timeout fusing time ************
            
ribbon:
  # request connection timeout ************
  ConnectTimeout: 2000
  # request processing timeout ************
  ReadTimeout: 5000
  All operations are retried
  OkToRetryOnAllOperations: true
  #### Based on the configuration above, when a failed request is reached, it tries to access the current instance again (the number of times is specified by MaxAutoRetries).
  #### If not, another instance is accessed, if not, another instance is accessed (the number of changes is configured by MaxAutoRetriesNextServer),
  #### If you still fail, a failure message is displayed.
  MaxAutoRetries: 0 Number of retries for the currently selected instance, not including the first call
  MaxAutoRetriesNextServer: 0 Number of retries for switching instances
  NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule  Load policy adjustment
Copy the code

Add the @enableFeignClients annotation to the startup class to enable the Feign client

Remote call client Service layer:

// use @feignClient to represent the service where the value is the name of the provider
The name attribute is used to specify the name of the calling service provider, consistent with spring.application.name in the service provider yaml file
@FeignClient(name="provider-application")// The value here is the corresponding path to the provider
@RequestMapping("/provider")
public interface FeginService {
    // The path must be the same as the provider and the parameters must be the same
    // You can use @pathVariable, @requestParam, and @requestheader when binding parameters. The value attribute is mandatory
    @GetMapping("/{id}")
    Map providerMethod(@PathVariable(value = "id") int id);
}
Copy the code

The controller layer:

@RestController
public class FeignController {
    // Invoke the service
    @Autowired
    private FeginService feginService;
    
    @RequestMapping(value = "/consumer/{id}")    
    public Map consumerTest(@PathVariable(value = "id")Integer id) {        
        returnfeginService.providerMethod(id); }}Copy the code
Feign annotation analysis

The @feignClient annotation is primarily decorated by @target ({elementtype.type}) to indicate that the annotation is primarily used on the interface. It has the following properties:

  • Name: Specifies the name of FeignClient. If the Ribbon is used, name is used as the name of the microservice for service discovery
  • Path: defines the unified prefix of the current FeignClient
  • Fallback: Defines a fault-tolerant processing class. When the remote interface fails to be called or times out, the fault-tolerant logic of the corresponding interface will be called. The class specified by fallback must implement the @feign interface
  • FallbacjFactory: Factory class used to generate fallback class instances. This property implements fault tolerant logic common to each interface
  • Configuration: Feign configuration class, you can customize or configure Feign Encoder, Decoder, LogLevel, Contract
  • Url: THE URL is used for debugging. You can specify the address of the @feignClient call
  • Decode404: When a 404 error occurs, if the field is true, decoder will be called for decoding, otherwise FeignException will be thrown

3. Set Feign timeout

Feign calls are made in two layers, the Ribbon layer and Hystrix, with higher versions of Hystrix turned off by default.

Support for load balancing ribbon: Feign has a default request processing timeout period of 1s. You can adjust the request processing timeout period. Feign has its own timeout Settings. You can use ribbon. Xx for global configuration, or you can use the service name.ribbon. Xx for detailed configuration of a specific service.

If the preceding error occurs, you need to add the following configuration: The Feign timeout period is the same as the Ribbon timeout period

ribbon:
  # request connection timeout ************
  ConnectTimeout: 3000
  # request processing timeout ************
  ReadTimeout: 6000
Copy the code

Support for fuse Hystrix: After Hystrix is enabled, all methods in Feign will be managed, and the corresponding fallback logic will be applied in case of problems. There are currently two timeout Settings (Feign/ Hystrix), and fuses are performed according to the minimum values of these two timeout Settings. That is, if the processing time exceeds the minimum timeout, fuses will enter the fallback downgrade logic.

feign:
  hystrix:
	enabled: true  # Enable Feign's fusing function
Copy the code

If Hystrix is enabled, the Hystrix timeout message is as follows:

You can add the following configuration:

hystrix:
  command:
    default:
      circuitBreaker:
        sleepWindowInMilliseconds: 30000
        requestVolumeThreshold: 50
      execution:
        timeout:
          enabled: true
        isolation:
          strategy: SEMAPHORE
          semaphore:
            maxConcurrentRequests: 50
          thread:
            timeoutInMilliseconds: 16000  # Global timeout fusing time ************
Copy the code

Custom FallBack handling classes (FeignClient interface required)

The fallback logic needs to define a class that implements the FeignClient interface and the methods in that interface
@Component // Don't forget this annotation, it should also be scanned
public class UserFallback implements UserServiceFeignClient {
    @Override
    public Integer findDefaultResumeState(Long userId) {
        return 6; }}Copy the code

Add the fallback attribute to the @FeignClient annotation with the value userFallback.class. Note that the url prefix of the @requestMapping annotation on the class needs to be configured in the @FeignClient path attribute when using the Fallback attribute.

How Feign works

The @enableFeignClients annotation is added to the main program entry to enable the FeignClient scan loading process. Define the interface and annotate it with @FeignClientd according to the FeignClient development specification.

When the program starts, it does a package scan, scans all @FeignClients annotated classes, and injects this information into the Spring IOC container. When the Feign interface methods defined are called, the JDK proxy generates a specific RequestTemplate. When the proxy is generated, Feign creates a RequestTemplate for each interface method. When generating a proxy, Feign creates a RequestTemplate object for each interface method, which encapsulates all the information needed to make HTTP requests, such as request parameter names, request methods, and so on.

RequestTemplate then generates the Request and sends it to the Client to process. The Client can use JDK native URLConnection,Apache HttpClient, or OKhttp. Finally, the Client is packaged into the LoadBalanceClient class, which uses the Ribbon to load balance calls between generator services.

Feign Enables GZIP compression

Feign supports GZIP compression of requests and responses to reduce performance losses during communication. To enable request and response compression, use the following parameters:

feign:
  compression:    
	request:      
	  enabled: true   Enable compression of requests
	  mime-types: text/xml,application/xml,application/json # Set the data type to be compressed, default
	  min-request-size: 2048   # specify the minimum file size to enable compression
	response:      
	  enabled: true   Turn on compression of the response
Copy the code

ResponseEntity<byte[]> ResponseEntity<byte[]> ResponseEntity<byte[]>

@FeignClient(name = "github-client")
public interface HelloFeignService {
    /* The ResponseEntity
      
        returns the ResponseEntity
       []>
      []>
    @RequestMapping(value = "/search/repositories",method = RequestMethod.GET)
    ResponseEntity<byte[]> searchRepositories(@RequestParam("q")String parameter);
}
Copy the code
Feign Enables logging

Feign is an HTTP request client, similar to a browser. It prints detailed log information (response headers and status codes) when requesting and receiving responses. By default, Feign logging is not enabled. It is recommended to add a configured class to the annotation class, or not:

@FeignClient(name = "github-client",configuration = FeignConfig.class)
Copy the code

The code for the annotation class looks like this:

// Feign log level (Feign request process information)
// NONE: By default, no logs are displayed ---- best performance
// BASIC: only the request method, URL, response status code, and execution time are recorded ---- Production problem tracing
// HEADERS: Records the HEADERS of the request and response at the BASIC level
// FULL: Logs headers, body, and metadata for requests and responses ---- is suitable for locating problems in development and test environments
@Configuration
public class FeignConfig {

    /** * logger. Level Indicates the following levels: NONE: records no information. BASIC: records only the request method, URL, response status code, and execution time. Records the details of all requests and responses, including headers, request bodies, metadata *@return* /
    @Bean
    Logger.Level feignLoggerLevel(a) {
        returnLogger.Level.FULL; }}Copy the code

Set the log level to DEBUG:

logging:
  level:
    # Feign Logs respond only to logs with the log level debug
	com.fishleap.client.UserServiceFeignClient: debug
Copy the code

reference

  • Spring Cloud OpenFeign source code parsing
  • How Feign works
  • Feign source code analysis: remember the first time to use Feign to step on some pits

6. The GateWay GateWay

1. Overview of GateWay

Gateway is an API Gateway service built on top of the Spring ecosystem, relying on Spring Boot 2.0, Spring WebFlux, and Project Reactor, Many familiar synchronous libraries (such as Spring-Data and Spring-Security) and synchronous programming patterns do not apply in Spring Cloud Gateway. Spring Cloud Gateway official document address

The Spring Cloud Gateway has the following features:

  • It is constructed based on Spring Framework 5, Project Reactor and Spring Boot 2.0.
  • Dynamic routing: can match any request attribute;
  • You can specify Predicate and Filter for a route;
  • Integrated Circuit breaker function of Hystrix;
  • Integrate Spring Cloud service discovery;
  • Request traffic limiting function;
  • Path rewriting is supported.

Route: A Route is a basic component of a gateway. It is defined by the ID, target URI, Predicate collection, and filter collection. If predicate aggregation is judged to be true, the route is matched.

Predicate: Uses java.util.Predicate, introduced in Java8 based on functional programming. When predicate (aggregate) judgment is used, the input parameter is of type ServerWebExchange, which allows developers to match arbitrary parameters from HTTP requests, such as HTTP request headers, HTTP request parameters, and so on.

Filter: The GatewayFilter instance created by the specified GatewayFilter factory is used to modify the request (parameter) or response (parameter) before or after the request is sent downstream.

Predicates predicate is the matching condition, and Filter is the interceptor. Combined with URL, a specific route forwarding can be realized.

The client sends a request to the Spring Cloud GateWay, then finds the route matching the request in the GateWay Handler Mapping and sends it to the GateWay Web Handler. The Handler then sends the request through the specified filter chain to our actual service to perform the business logic, and then returns. The filters are separated by dashed lines because the filter may perform business logic before (PRE) or after (POST) sending the proxy request. Filter The Pre Filter can perform parameter verification, permission verification, traffic monitoring, log output, and protocol conversion. The POST Filter can perform response content, response header modification, log output, and traffic monitoring.

2. The application GateWay

Introducing dependencies:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
Copy the code

Route configuration:

Gateway provides two different ways to configure routes, one through YML files and the other through Java beans

Configure in application.yml:

server:
  port: 9201
spring:
  cloud:
    gateway:
      routes:
        - id: path_route # Route ID
          uri: ${service-url.user-service}/user/{id} # match the back route address
          predicates: # assert that the path matches the route
            - Path=/user/{id}
service-url:
  user-service: http://localhost:8201            
Copy the code

Using Java Bean Configuration: Add the relevant configuration classes to configure a RouteLocator object

@Configuration
public class GatewayConfig {

    @Bean
    public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
        return builder.routes()
                .route("path_route2", r -> r.path("/user/getByUsername")
                        .uri("http://localhost:8201/user/getByUsername")) .build(); }}Copy the code

3.GateWay Routing rules

The Spring Cloud Gateway itself includes a number of built-in routing predicate factories. These predicates match different attributes of an HTTP request. Multiple routing predicate factories can be combined using the logic of and.

Specify a date-time routing predicate
  • Match requests before the specified date and time.
  • Match request after the specified date and time.
  • Match requests between the specified date and time.

The configured date and time must meet the ZonedDateTime format: [America/Denver] 2017-01-20T17:42:47.789-07:00[America/Denver]

server 
  port: 9090
spring:
  cloud:
    gateway:
      routes:
      - id: between_route
        uri: https://example.org
        predicates:
        - Between=2019-05-01T00:00:00+08:00[Asia/Shanghai],2019-05-02T00:00:00+08:00[Asia/Shanghai]

Copy the code
Cookie routing predicate

CookieRoutePredicateFactory need to provide two parameters, respectively is the name of the Cookie and a regular expression (value). The route is matched only when the name and value of the Cookie in the request match the value configured in the Cookie routing predicate.

server 
  port: 9090
spring:
  cloud:
    gateway:
      routes:
       - id: cookie_route
        uri: https://example.org
        predicates:
         - Cookie=doge,aaa
Copy the code

The request can be routed to https://example.org only with a Cookie whose name is doge and value matches the regular expression “aaa”.

Header routing predicate

HeaderRoutePredicateFactory need to provide two parameters, respectively is the Header name and a regular expression (value). A route is matched only if the name and value of the Header in the request match the values configured in the Header routing predicate.

Host routing predicate

HostRoutePredicateFactory only need to specify a host list, each element in the list of support Ant named style, use. Used as a separator between multiple elements. The Host routing predicate actually addresses the Host attribute in the HTTP request header.

spring:
  cloud:
    gateway:
      routes:
        - id: host_route
          uri: http://localhost:9091
          predicates:
            - Host=localhost:9090
Copy the code
Request method routing predicates

MethodRoutePredicateFactory need only one parameter: to match the HTTP request method.

spring:
  cloud:
    gateway:
      routes:
        - id: method_route
          uri: http://localhost:9091
          predicates:
            - Method=GET
Copy the code
Request path routing predicates

PathRoutePredicateFactory need PathMatcher model path list and an optional matchOptionalTrailingSeparator flags parameter. This is one of the most common routing predicates.

spring:
  cloud:
    gateway:
      routes:
        - id: path_route
          uri: http://localhost:9091
          predicates:
            - Path=/order/path
Copy the code
Request query parameter routing predicates

QueryRoutePredicateFactory need a must request query parameters (param name) and an optional regular expressions (regexp).

spring:
  cloud:
    gateway:
      routes:
      - id: query_route
        uri: http://localhost:9091
        predicates:
        - Query=doge,aaa.
Copy the code
Remote IP address routing predicate

RemoteAddrRoutePredicateFactory matching rules by CIDR notation (IPv4 or IPv6) a list of strings (minimum value is 1), for example, 192.168.0.1/16 (192.168.0.1 is remote 16 IP address and subnet mask).

spring:
  cloud:
	gateway:
	  routes:
	  - id: remoteaddr_route
		uri: https://example.org
		predicates:
		- RemoteAddr = 192.168.1.1/24
Copy the code
Multiple routing predicates combined

Because the predicates attribute in the routing configuration is actually a list, you can add multiple routing rules directly:

spring:
  cloud:
    gateway:
      routes:
      - id: remoteaddr_route
        uri: http://localhost:9091
        predicates:
        - RemoteAddr=xxxx
        - Path=/yyyy
        - Query=zzzz,aaaa
Copy the code
GateWay Dynamic Routing

GateWay supports automatic retrieval and access of a list of services from the registry, known as dynamic routing.

For dynamic routing, the URI starts with lb: // (lb means to obtain the service from the registry), followed by the name of the service to be forwarded

4. The GateWay filter

GatewayFilter factory

GatewayFilter Allows you to modify incoming HTTP requests or returned HTTP responses. The scope of a route filter is a specific route configuration. Spring Cloud Gateway provides a rich set of built-in GatewayFilter factories that can be selected on demand.

At present, the built-in implementation of GatewayFilter factory is as follows:

ID The name of the class type function
StripPrefix StripPrefixGatewayFilterFactory pre Removes the first part of the request URL path, e.g. the original request path was /order/query and the processed request path is /query
SetStatus SetStatusGatewayFilterFactory post Set the status code of request and response, from org. Springframework. HTTP. HttpStatus in parsing
SetResponseHeader SetResponseHeaderGatewayFilterFactory post Sets (adds) the response header for the request response
SetRequestHeader SetRequestHeaderGatewayFilterFactory pre Set (add) the request header
SetPath SetPathGatewayFilterFactory pre Sets (overrides) the request path
SecureHeader SecureHeadersGatewayFilterFactory pre To set the security-related request headers, see SecureHeadersProperties
SaveSession SaveSessionGatewayFilterFactory pre Save the WebSession
RewriteResponseHeader RewriteResponseHeaderGatewayFilterFactory post Reresponse header
RewritePath RewritePathGatewayFilterFactory pre Override request path
Retry RetryGatewayFilterFactory pre Retry the request based on the condition
RequestSize RequestSizeGatewayFilterFactory pre Limits the size of a request, in bytes, beyond which a return is returned413 Payload Too Large
RequestRateLimiter RequestRateLimiterGatewayFilterFactory pre Current limiting
RequestHeaderToRequestUri RequestHeaderToRequestUriGatewayFilterFactory pre Changes the request URL by the value of the request header
RemoveResponseHeader RemoveResponseHeaderGatewayFilterFactory post Removes the configured response header
RemoveRequestHeader RemoveRequestHeaderGatewayFilterFactory pre Removes the configured request header
RedirectTo RedirectToGatewayFilterFactory pre To redirect, you need to specify the HTTP status code and redirect URL
PreserveHostHeader PreserveHostHeaderGatewayFilterFactory pre Set the attribute preserveHostHeader carried by the request to true
PrefixPath PrefixPathGatewayFilterFactory pre Request path add lead path
Hystrix HystrixGatewayFilterFactory pre Integrated Hystrix
FallbackHeaders FallbackHeadersGatewayFilterFactory pre Hystrix execution if hit degrade logic allows exception details to be carried through the request header
AddResponseHeader AddResponseHeaderGatewayFilterFactory post Add a response header
AddRequestParameter AddRequestParameterGatewayFilterFactory pre Add request parameters that are only limited to the Query parameters of the URL
AddRequestHeader AddRequestHeaderGatewayFilterFactory pre Add headers

When using the GatewayFilter factory, you need to know its ID and configuration mode. The configuration mode can be found in the public static internal class XXXXConfig of the corresponding factory class.

GlobalFilter factory

GlobalFilter functions in the same way as GatewayFilter except that GlobalFilter is scoped to all route configurations rather than bound to a specific route configuration. Multiple GlobalFilters can specify the Order in which each GlobalFilter is executed using the @Order or getOrder() methods. The smaller the Order value, the higher the priority of GlobalFilter execution.

The Spring Cloud Gateway currently provides the following built-in GlobalFilter:

The name of the class function
ForwardRoutingFilter redirect
LoadBalancerClientFilter Load balancing
NettyRoutingFilter Netty HTTP client route
NettyWriteResponseFilter The Netty responds with a write operation
RouteToRequestUrlFilter Update URL based on route configuration
WebsocketRoutingFilter Websocket requests are forwarded downstream

The built-in GlobalFilter is mostly related to the ServerWebExchangeUtils attribute.

5. Interzone configurations and Actuator endpoints

Cross-domain configuration:

Gateways can be configured to control global CORS behavior. The corresponding class for the global CORS configuration is CorsConfiguration, which is a MAPPING of THE URL pattern. For example, the application.yaml file is as follows:

spring:
  cloud:
    gateway:
      globalcors:
        corsConfigurations:
          '[/ * *]':
            allowedOrigins: "https://docs.spring.io"
            allowedMethods:
            - GET
Copy the code

For all requested paths, CORS requests from docs.spring. IO that are GET methods will be allowed.

Actuator endpoints:

To import spring-boot-starter-actuator, do the following to enable gateway monitoring endpoints:

management.endpoint.gateway.enabled=true 
management.endpoints.web.exposure.include=gateway
Copy the code

List of endpoints currently supported:

ID Request path HTTP method describe
globalfilters /actuator/gateway/globalfilters GET Displays the GlobalFilter list in the route configuration
routefilters /actuator/gateway/routefilters GET The GatewayFilter list bound to the route configuration is displayed
refresh /actuator/gateway/refresh POST Clear the route configuration cache
routes /actuator/gateway/routes GET The route configuration list is displayed
routes/{id} /actuator/gateway/routes/{id} GET Displays the route configuration defined by the corresponding ID
routes/{id} /actuator/gateway/routes/{id} POST Add a new routing configuration
routes/{id} /actuator/gateway/routes/{id} DELETE Example Delete the route configuration with the specified ID

Where/physical/gateway/routes / {id} add a new routing configuration request parameter format is as follows:

{
  "id": "first_route"."predicates": [{
    "name": "Path"."args": {"doge":"/example"}}]."filters": []."uri": "https://example.org"."order": 0
}
Copy the code

reference

  • Spring Cloud Gateway: a new generation of API Gateway services
  • Spring Cloud Gateway
  • Getting started with Spring Cloud Gateway

Refer to the link

  • Spring Cloud website
  • Spring Cloud Chinese community
  • Spring Cloud China community
  • At the risk of failing, I’m going to give you a primer on Spring Cloud
  • Spring Cloud learning
  • Spring Cloud Config: External centralized configuration management
  • Spring Cloud Bus: Message Bus