What components of spring cloud have you used and what is their principle?

preface

See the title of the article? It is such an abstract and general question, which is really the real interview question of a shared truck platform I was asked in the interview. Spring cloud was indeed used, but it was three or four years ago. At that time, spring cloud just became popular. Our technical director asked us to investigate. Then, including my three colleagues, I bought a book on spring cloud and began to read and study. At that time, DDD was also popular, Then we study the spring cloud and build our own project according to the DDD model. But it took three months to complete the first phase of the project. I withdrew before the second phase started. Therefore, the total use time of spring cloud is only two or three months, so I don't have a solid grasp of this knowledge. Moreover, after joining the new company, I use the framework encapsulated by the company, and I haven't used spring cloud for three years. This time I'm going to change my job in an interview, so I decided to summarize this knowledge.

Service governance spring cloud Eureka

When we used to call each other between services, we usually relied on some static configuration. For example, when service a calls service B to complete a business operation, in order to achieve high availability of service B, the maintenance of service instance list of service B is generally completed through manual configuration. With the development of business, the system functions are becoming more and more complex, the corresponding services are increasing, and the IP of services is still changing. It will become more and more difficult to maintain services by static configuration.

Spring cloud Eureka mainly focuses on the service registration and service discovery mechanism to complete the automatic management of microservices.

Service registration

Eureka provides a server-side component, which we also call the registry. Each service registers the metadata of the service provided by itself, including the IP address, port number, version number, communication protocol, etc. to Eureka's service registry. In this way, the registry maintains each service in a service list (double-layer map, the first layer key is the service name, the second layer key is the instance name, and value is the service address plus port).

Service discovery

Eureka provides not only a server, but also a client. The client runs in various services. Eureka client has two main functions:

The services registered in Eureka server call each other, no longer through the specified specific instance address, but by sending a request to the service name, because each service is multi instance, and the instance address may change frequently. However, you do not know the specific service instance location through the service name call. Therefore, you need to consult the registry, obtain the list of all service instances, and then realize the requested access to the service.

give an example

To sum up, Eureka client mainly registers the service itself in Eureka server, queries the registered service list of Eureka server and caches it locally. Eureka server: Registration Center, which stores metadata of all registration services, including IP address, port and other information.

Client load balancing spring cloud ribbon

The caller of the service, after caching to the local registry through Eureka client, finds the instance address corresponding to the specific service through the service name, but there are multiple service addresses of the callee, so which address should be used for calling?

服务A：
192.168.12.10:9001
192.168.12.11:9001
192.168.12.12:9001

At this time, the spring cloud ribbon appeared. It is designed to solve this problem. Its function is to do load balancing and distribute requests evenly to each machine.

By default, the ribbon uses the round ribbon policy for load balancing, specifically polling for requests.

In addition to round ribbon, the ribbon has other policies and user-defined policies. It mainly includes:

The specific implementation examples of spring cloud ribbon are as follows:

Example code

The following code is the code example of calling the service through the ribbon.

@RestController
public class ConsumerController {
    @Autowired
    RestTemplate restTemplate;
    @GetMapping("/ribbon-consumer")
    public String helloConsumer(){
        return restTemplate.getForEntity("http://example-service/index",String.class).getBody();
    }
}

You can see that the ribbon is also called by initiating an HTTP request, which is only realized by calling the address of the service name. Although the ribbon does not need to specifically request the IP address or domain name of the service instance, it is cumbersome to manually initiate an HTTP request every time an interface is called, and the return type is also abstract. Therefore, spring cloud upgrades and encapsulates the call method.

Declarative service calls spring cloud feign

In order to simplify calls between services, spring cloud further encapsulates on the basis of ribbon. Spring cloud feign is a separate component. After introducing spring cloud feign, we only need to create an interface and configure it by annotation to complete the interface binding to the service provider.

Spring cloud feign has pluggable annotation support and extends the annotation support of spring MVC.

Let's take a specific example:

The specific interface definition and implementation code of the service party are as follows:

import org.springframework.cloud.netflix.feign.FeignClient;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RequestParam;
/**
 * 接口定义
 */
@FeignClient(value="service-hi",fallback = TestFeignServiceImpl.class)
public interface TestFeignService {

    @RequestMapping(value="/hi",method = RequestMethod.GET)
    String sayHi(@RequestParam("name") String name);
}
/**
 * 具体的服务实现
 */
@Component
public class TestFeignServiceImpl implements TestFeignService {
    @Override
    public String sayHi(String name) {
        return "你好,"+name;
    }
}

The use code of the caller is as follows:

@RestController
public class TestController
{
    @Resource
    private TestFeignService testFeignService;

    @RequestMapping(value="/hi",method = RequestMethod.GET)
    public String sayHi(@RequestParam String name)
    {
    	// 调用远程服务
        return testFeignService.sayHi(name);
    }
}

Through the above code, we can see that when the caller calls the remote service through the feign process, it is very simple, just like calling the local service.

The previous operations such as establishing a connection, constructing a request, initiating a request, obtaining a response, parsing a response, etc. are transparent to the user. The user does not care how the service is called, but can use it directly.

So how does feign implement this package logic?

In fact, feign's bottom layer mainly relies on dynamic agents to realize the whole service invocation process. The main logic is as follows:

Spring cloud hystrix fault tolerant protection services

In the microservice architecture, we split the system into multiple service units, and each service depends on each other through service registration and subscription.

We take the process of placing an order on an e-commerce website as an example. In the process of placing an order, we need to call inventory services, payment services, points, logistics and other services. Assuming that the order service can only process 50 requests at most at the same time, if the point service hangs at this time, it will be stuck for such a period of time every time the order service calls the point service, and then the timeout exception will be returned.

What are the problems in this scenario?

As shown in the above figure, if multiple services call each other without any protection measures, one service will hang, resulting in a chain reaction and other services will hang.

In fact, even if the point service is suspended, it should not lead to the suspension of the order service. If the point service is suspended, we can skip the point service, or put a default value, and then continue to go down. When the point service is restored, we can manually restore the data.

Spring cloud hystrix is the component to solve this problem. It mainly plays the role of fusing, isolation and degradation.

Spring cloud hystrix actually opens up a thread pool for each service, and then the threads in each thread pool are used for calling requests for services. In this way, even if the integration service hangs, it is only a problem with the thread pool calling the integration service, and the thread pools of other services are still working normally. This is the isolation of services.

In this way, when the order service calls the point service, if there is a problem, the point service can return a default value through the hystrix (the default is that 20 calls fail in 5 seconds. In this way, the order service does not have to get stuck here and can continue to call other services for business operations. This is the fusing of the service.

Although it is said that the points service has hung up and returned to the default value, what should I do if the points service is restored later? At this time, the point service can record the request received by the sister or log it, which can provide a basis for later data recovery. This is service degradation.

The whole process is roughly as shown in the figure below:

API gateway service spring cloud zuul

Through the combination of the above components, a basic microservice architecture can be completed. However, when the number of micro services in a system gradually increases, some general logic, such as permission verification mechanism, request filtering, request routing, flow restriction, etc., which should be considered when providing external capabilities for each service, will become redundant.

At this time, the concept of API gateway came into being. It is similar to the facade mode (facade mode / appearance mode) in object-oriented design mode. All external client access needs to be scheduled and filtered through it. It mainly realizes the functions of request routing, load balancing, verification filtering, service flow restriction and so on.

Spring cloud zuul is an API gateway component provided by spring cloud. It integrates with Eureka, registers itself as an application under Eureka, and obtains all service instances from Eureka to route services.

Zuul also provides a set of filter mechanism. Developers can specify which rule requests need to execute verification logic. Only requests passing the verification logic will be routed to specific service instances, otherwise an error message will be returned.

Spring cloud starter zuul's dependency package spring cloud starter zuul itself contains dependencies on spring cloud starter hystrix and spring cloud starter ribbon modules. Therefore, zuul naturally has the functions of thread isolation, self-protection of circuit breaker, and client load of service invocation.

Zuul's routing is also implemented through path and serviceid. Path is a method path after removing IP and port number from HTTP request, for example: http://192.168.20.12:9001/api -Zuul / 123, then path is / API zuul / 123. Zuul supports fuzzy matching during configuration. If 123 is a dynamic parameter, you can configure path as / PAI zuul / * *, and serviceid is the service name registered in Eureka.

zuul.routes.api-zuul.path= /api-zuul/**
zuul.routes.api-zuul.serviceId= service-jimoer

With a unified gateway, it will become more convenient to do unified authentication, current limiting, authentication and authorization, security and so on.