springCloud (microservice) foundation and five components

Definition: Microservice architecture is an architectural pattern or an architectural style, which advocates dividing a single application into a set of small services, each of which runs in its own independent process, and coordinates between services , and cooperate with each other to provide users with the ultimate value. Services communicate with each other using a lightweight communication mechanism (usually an HTTP-based RESTful API). Each service is built around a specific business and can be independently built in a production environment or a production-like environment. In addition, a unified and centralized service management mechanism should be avoided. For a specific service, an appropriate language and tool should be selected according to the business context to construct it. A very lightweight centralized management can be used to To coordinate these services, the services can be written in different languages or use different data stores.

Technical dimension understanding: The core of micro-service is to split the traditional one-stop application into services one by one according to the business, and completely decouple them. Each micro-service provides a single business function service, and one service does one thing. , from a technical point of view is an independent processing process for children.

Microservice: The emphasis is on the size of the service. It focuses on a certain point and is a service application that specifically solves a certain problem and provides corresponding services.

SpringBoot is for the independent development of microservices, and springCloud is a microservice governance (coordination) framework

Advantages and disadvantages of Spring Cloud:

advantage:

Each service is cohesive enough, small enough, and the code is easy to understand so that it can gather a specified business function or business requirement
Simple development and high efficiency, a service may be dedicated to only one thing
Microservices are loosely coupled, and services with functional meaning are independent in both the development phase and the deployment phase
Microservices can be developed in different languages---cross-language
Easy to integrate with third parties, microservices allow easy integration in a flexible manner with automatic deployment, through continuous integration tools. Docker+Jenkins
Microservices are easy to be modified and maintained by a developer immediately, so that small teams can pay more attention to their own work results, and can reflect value without cooperation

shortcoming:

Developers deal with the complexities of distributed systems
Difficulty in multi-service operation and maintenance, as the number of services increases, the pressure on operation and maintenance also increases
system deployment dependencies
Inter-service communication cost
data consistency
System Integration Test
performance monitoring

Microservice architecture is not perfect! It is necessary to plan the overall structure after analyzing the requirements of the project.

SpringCloud provides a one-stop microservice architecture

Dubbo is semi-automatic, and SpringCloud is fully automatic.

Why choose Spring Cloud as the solution for the microservice framework?

Overall solution and framework maturity
Community popularity (spring has a great influence on java)
maintainability
learning curve

What are the current microservice architectures of Internet companies?

Ali: Dubbo/HSF

Jingdong: JSF

Sina Weibo: Motan

Dangdang: Dubbox

Alibaba Cloud: Spring Cloud

Five components of SpringCloud Netflix: Euraka, Ribbon, Feign, Hystrix, Zuul

Eureka Registry

When Netflix designed eureka, it followed the AP principle

Eureka cluster strategy

local:

Add in the c://windows/system32/driver/etc/hosts directory

Create multiple eurekas in the project and assign them

Cluster: It is equivalent to bundling multiple server environments together to provide services to the outside world

Common cluster environment: Eureka cluster environment, Tomcat cluster environment, MySql cluster environment, Solr cluster environment...

The cluster is mainly to solve high resistibility, high concurrency, and high load scenarios

CAP principle (CAP theorem):
The CAP principle, also known as the CAP theorem, refers to the fact that in a distributed system, Consistency (consistency), Availability (availability), and Partition tolerance (partition tolerance) cannot be combined.

In the microservice architecture, the CAP principle cannot be satisfied at the same time, so the difference between Eureka and Zookeeper is here.

What Zookeeper guarantees is that the availability of the CP principle is reduced

When querying the service list from the registration center, it can be tolerated that the registration center returns registration information a few minutes ago, but it cannot accept that the service is directly down and unavailable.

Eureka guarantees that the consistency of the AP principle is reduced

Eureka understands this, so it will give priority to ensuring availability during design. All nodes of Eureka are equal, and the failure of several nodes will not affect the work of normal nodes, and the remaining nodes can still provide registration and query services. Ensure high availability of microservices through Eureka self-protection mechanism + heartbeat check.

The CAP principle is the cornerstone of the NOSQL database. Consistency. Availability (availability). Partition tolerance (partition fault tolerance).

CAP theory of distributed systems: The theory first summarizes the three characteristics of distributed systems as follows:
        Consistency (C): Whether all data backups in a distributed system have the same value at the same time. (Equivalent to all nodes accessing the same latest data copy)
        Availability (A): After some nodes in the cluster fail, whether the cluster as a whole can still respond to the client's read and write requests. (High availability for data updates)
        Partition tolerance (P): In terms of practical effects, partitions are equivalent to the time limit requirements for communication. If the system cannot achieve data consistency within the time limit, it means that a partition has occurred, and a choice between C and A must be made for the current operation.
        Theorem: Any distributed system can only satisfy two points at the same time, and cannot take care of all three.
        Architects should not waste their energy on how to design a perfect distributed system that can satisfy the three, but should make trade-offs.
Practice:
        For example, there are three machines: Server1, Server2 and Server3. In the high-availability solution, three machines need two or two register. For example, S1 needs to register with S2 and S3 respectively, but currently it cannot realize the transitivity of registration. In this way, if Server1 goes down, we can continue to get services from Server2 and 3.
In the CAP theory, zookeeper pays more attention to C and P, that is, consistency and partition fault tolerance. But Eureka cares more about A and P, and A is highly available. There is a difference between master and follower in zookeeper. When entering the election mode, it cannot provide external services normally. But in Eureka, the clusters are equal and have the same status. Although consistency cannot be guaranteed, registration services can at least be provided. According to different business scenarios, specific analysis and use.

Ribbon implements load balancing strategy

The premise of load balancing is the need for a cluster environment

What is load balancing? It is to distribute the requests on different servers for processing

LB is load balancing, a kind of fuz commonly used in microservices or distributed clusters

Load balancing is to allocate requests to different servers for processing, so as to achieve high availability

Common load balancing software includes Nginx+Tomcat to build a cluster environment, Lvs (linux virtualization service), etc.

Both dubbo (service governance development framework) and springcloud (microservice architecture development) provide me with load balancing

Classification:

soft load

1. Centralized LB

It is to use an independent LB facility between the consumer and provider of the service, such as Nginx, which is responsible for forwarding the access request to the provider of the service through a certain strategy

2. Process LB

1. Integrate LB logic into the consumer. The consumer knows which addresses are available from the service registry, and then selects a suitable server from these addresses.

2Ribbon is an in-process LB. It is just a class library that integrates with the consumer process, and the consumer obtains the service provider through it.

Hard load (purchase load balancing server)

By default, Ribbon uses polling rules to achieve load balancing

Steps to implement load balancing strategy through Ribbon:

1.pom

<!--添加Ribbon支持负载均衡添加如下依赖-->
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-ribbon</artifactId>
      <version>1.4.6.RELEASE</version>
    </dependency>

2. Add the @LoadBalance annotation to the RestTemplate Bean

Feign load balancing

Introduction

Feign is mainly a community, and everyone is accustomed to interface-oriented programming. This is the norm for many developers. Two methods of calling microservices: 1. Ribbon (RestTemplate) 2. Feign

Feign's role?

1. Feign makes it easier to write java http clients

2. When using Ribbon+Rest Template, use RestTemplate to encapsulate http requests, forming a set of templated calling methods. But in actual development, since there may be more than one call from the service, often an interface will be called in multiple places, so usually some client classes are encapsulated for each microservice to wrap these dependent service calls. Therefore, Feign has made some encapsulation on this basis, and he will help us define and implement the definition of dependent service interfaces. Under Feign's implementation, we only need to create an interface and configure it using annotations (similar to the previous Mark the Mapper annotation on the Dao interface, and now it is enough to mark a Feign annotation on a microservice interface) to complete the interface binding to the service provider, which simplifies the development of the automatic encapsulation service calling client when using springCloud Ribbon.

Feign implementation steps:

1. pom api module and consumer import dependencies

<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-feign</artifactId>
            <version>1.4.6.RELEASE</version>
</dependency>

2. Add entity Client to api

@Component
@FeignClient(value = "DEMOSPRINGCLOUDPROVIDER-8080")
public interface UserClient {
    @GetMapping("/get")
    List<User> get();
}

3. Modify the Controller in the consumer

@Resource
    private UserClient userClient;

    @GetMapping("/getUser")
    public List get(){
        return userClient.get();
    }

Hystrix (black blow dead)

service avalanche effect

In a distributed system environment, similar dependencies between services are very common, and a business call usually depends on multiple basic services. As shown below

insert image description here

If each service is running normally, everyone will be happy and happy, but what will happen if one of the services crashes? As shown below

insert image description here

When the traffic of Service A fluctuates greatly, the traffic often increases suddenly! So in this case, even if Service A can handle the request, Service B and Service C may not be able to handle the sudden request.
At this time, if Service C becomes unavailable because it cannot resist the request. Then Service B's request will also be blocked, slowly exhausting Service B's thread resources, and Service B will become unavailable. Immediately afterwards, Service A will also be unavailable.

When a service fails, causing the service of the entire link to fail, we call it a service avalanche.

For high-traffic applications, a single backend dependency can cause all resources on all servers to converge within seconds. Worse than failing, these applications can also cause delays between services. Increases, backup queues, threads, and other system resource strains, leading to more cascading failures throughout the system, all represent the need to isolate and manage failures and latencies so that the failure of a single dependency cannot take down an entire application or system .

The causes of the avalanche and the three stages of the service avalanche         There
are roughly four reasons:
        1. Hardware failure
        ;
Excessive pressure);
        4. A large number of user requests;

        The first stage of the service avalanche: the service is unavailable;
        the second stage: the caller retries to increase the traffic (user retry/code logic retry);
        the third stage: the service caller is unavailable (resource exhaustion caused by synchronous waiting );

Solution
1) Application expansion (expanding server capacity)

Add machines, upgrade hardware
2) flow control (beyond the limited flow, return to a similar retry page for the user to try again later)

Limit current, close retry
3) Cache

Put a large amount of data that users may access into the cache to reduce requests to access the database.

4) Service downgrade

Service interface denial of service, page denial of service, delayed persistence, random denial of service
5) Service fusing

What is Hystrix?

Hystrix is an open source library used to deal with delay and fault tolerance of distributed systems. In distributed systems, many dependencies will inevitably fail to call, such as timeouts, exceptions, etc. Hystrix can guarantee that in the case of a dependency problem, It will not cause overall service failure, avoid cascading failures, and improve the resilience of distributed systems.

"Circuit breaker" itself is a switching device. When a service unit fails, through the fault monitoring of the circuit breaker, an expected and processable alternative response [fallback] is returned to the caller, instead of a long time Waiting or throwing exceptions that cannot be handled by the calling method can ensure that the thread of the service caller will not be occupied for a long time and unnecessary, thereby avoiding the spread of faults in the distributed system, and even avalanches.

What is service fuse: The fuse mechanism is a microservice link protection mechanism corresponding to the avalanche effect.

When a microservice of the fan-out link is unavailable or the response time is too long, the service will be degraded, and then the call of the microservice of the node will be broken, and the wrong response information will be returned quickly. When it is detected that the microservice call response of the node is normal, the call link is resumed. In the SpringCloud framework, the fusing mechanism is implemented by Hystrix. Hystrix will monitor the calls between microservices. When the failed calls reach a certain threshold, the fusing mechanism will be activated by default if 20 calls fail within 5 seconds. When commenting on the fuse mechanism @HystrixCommand

Service degradation: Shut down unneeded microservices.

Steps for usage:

1. Add pom to the microservice

<!--增加熔断机制-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-hystrix</artifactId>
            <version>1.4.6.RELEASE</version>
        </dependency>

2. Add the annotation @EnableDiscoveryClient @EnableCircuitBreaker to the consumer main

@SpringBootApplication
@EnableEurekaClient
@EnableFeignClients(basePackages = {"cn.pro.api.service"})
@EnableDiscoveryClient
@EnableCircuitBreaker
public class Demo1ConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(Demo1ConsumerApplication.class,args);
    }
}

3. Add the annotation @EnableHystrix to the microservice startup class

4. Interface settings in microservices

@RestController
public class UserController {
    @GetMapping("/get")
    @HystrixCommand(fallbackMethod = "getByFallBack")
    public List<User> get() throws Exception{
        List<User> list= new ArrayList<>();
        list.add(new User(1001,"大娃",12));
        list.add(new User(1001,"大娃",12));
        list.add(new User(1001,"大娃",12));
        list.add(new User(1001,"大娃",12));
        if (list.size() != 0){
            throw new Exception("出错啦，进入雪崩");
        }
        return list;
    }

    public List<User> getByFallBack(){
        List<User> list= new ArrayList<>();
        list.add(new User(1001,"出错啦",12));
        list.add(new User(1001,"出错啦",12));
        list.add(new User(1001,"出错啦",12));
        list.add(new User(1001,"出错啦",12));
        return list;
    }
}

Zuul routing gateway

What is Zuul: Zuul includes the two main functions of request routing and filtering

Zuul services will eventually be registered into Eureka

The role of Zuul: request routing, request filtering

Gateway steps:

1. Create a maven project and import pom

<dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
      <groupId>org.projectlombok</groupId>
      <artifactId>lombok</artifactId>
    </dependency>
    <dependency>
      <groupId>cn.pro</groupId>
      <artifactId>demo1-api</artifactId>
      <version>1.0-SNAPSHOT</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-eureka</artifactId>
      <version>1.4.6.RELEASE</version>
    </dependency>
    <!--增加熔断机制-->
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-hystrix</artifactId>
      <version>1.4.6.RELEASE</version>
    </dependency>
<!--  增加网关  -->
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-zuul</artifactId>
      <version>1.4.6.RELEASE</version>
    </dependency>

2. Add annotations to the startup class @EnableZuulProxy //Enable gateway proxy

@SpringBootApplication
@EnableZuulProxy //开启网关代理
public class Demo1ZuulApplication {
    public static void main(String[] args) {
        SpringApplication.run(Demo1ZuulApplication.class,args);
    }
}

3. Set in application.yml

server:
  port: 5050
spring:
  application:
    name: demo1-zuul
eureka:
  client:
    service-url:
      defaultZone: http://eureka7070:7070/eureka,http://eureka7071:7071/eureka,http://eureka7072:7072/eureka
zuul:
  routes:
    provider8080.serviceId: DEMOSPRINGCLOUDPROVIDER-8080
    provider8080.path: /user/**