A cultural and educational services you how Spring Cloud micro fuse downgrade?

Overview of current-limiting fuse

In the micro-architecture system based on Spring Cloud services, according to the division of the different functions of the system boundary, the original large and will be split into a number of different micro-services, and the corresponding micro service will provide functionality associated with a set of services interfaces, and other micro-service system to provide services. Under normal circumstances, the service functions between the various micro decoupled from each other, from the design of the software will be presented in terms of a reasonable state, but from the point of view on the call link, this split actually elongated external call link service requests.

For example, in the early start-up companies, taking into account the development and maintenance costs, system architecture design is very simple, from a software architecture point of view, is a service-oriented app api end, end a service-oriented back-office functions. To the user's shopping scene, for example, although it will go through this process logic to handle complex logic of merchandise, order, payment, logistics, inventory, etc., but because the logic is coupled in a single system, so from the user's app to the background service, service call link is not too long. Even in this case, or if there will be a sudden surge in the amount requested, the service side of the business processing thread pool is filled, the entire database back-end system connection resources, cache resources have all been exhausted, leading to the entire service is unavailable .

With the gradual development of the company, the business volume of requests and the Japanese surge, in order to increase throughput and availability of the entire system, we use the micro-service architecture will be designed to split the original system becomes a commodity, orders, payment, logistics , inventory and other micro-services, and between these services communicate over a network (after the service found that it is through our Spring Cloud said before FeignClient, HTTP way to make network calls), the formation of a shopping request will undergo app micro-side calls of goods and services to browse, select and order goods called by the central trade center orders, and orders call center payment system payment, the payment is successful, then call center orders logistics center for delivery, and this At the same time, call center logistics inventory system inventory reduction of long call link.

This process looks a bit long, in order to facilitate understanding, or come Photo:

As shown above, in the system of micro-services, although this time each micro service has a separate process resources, business thread pool and separate database, overall system throughput a lot higher than before, and each micro service They are also clustered deployment. But because the whole network link calls is very long, if at this time localized network or part of incognito service failure, it still could lead to paralysis of the entire micro-services system.

For example, assuming that the logistics service downtime occurs, the foregoing micro-services do not know, because the entire link calls are synchronous, so this time when the service call orders logistics services will be part of the micro-thread is blocked until the emergence of timeout exception, empathy call micro-logistics services that thread will appear blocking orders for services, if the service request at this time is very high concurrency, because the thread is blocked for too long, then quickly orders micro-micro services and logistics services business threads resources will be exhausted, then there will be not only the end user App shopping feature is not available, and even browse merchandise to die, at a time when requests continue to increase, the situation will worsen, if the business use of the thread pool is unbounded queue (request queue thread pool), the system will eventually lead to memory overflow, then the system automatically restored order may be more difficult, the worst case is continued service is not available, but may eventually only be used to restart the entire system the high cost comes down to solve, and this is not the ultimate solution, because after the restart case However, it may occur (if not the investigation and get rid of micro-logistics service cause of the malfunction words).

From the above examples look, the failure of one micro services can actually lead to the collapse of the entire system, and we hope that if we find logistics micro-service continuing failure, then, when orders micro-services should be able to perceive, and according to certain mechanism fault-tolerant, that is the order of micro services without knowledge of logistics micro-service exception, it being the first not to send the request to logistics micro-services, and to the logistics microService first current limiting, take a default fault-tolerant logic fuse in their own local logic immediately after the call to return to App end, for example, you may first need to send the message cache, micro-logistics services to be re-sent after recovery. In this case, the failure of logistics services, will not lead to micro-order service because synchronous calls to link timeout too long a cascading failure occurs.

So how can we achieve such a mechanism it in Spring Cloud micro service design? This involves several issues:

  • How micro service is defined as a failure, blown what conditions? That is how to determine the logistics service orders micro-micro service is not available, which can achieve fusing operation;
  • It is defined as how to restore service after a failure to make micro-blown party perception? Orders Micro can continue service when normal call micro-logistics services, to achieve fault recovery;
  • Spring Cloud code implementation mechanism is what?

These problems is this chapter tells how in Spring Cloud service implemented in the design of micro fuse service limit of the content stream! And this for a concurrent volume is very high, to achieve micro-availability of services is a very important aspect.

Spring Cloud integrated framework Hystrix

In Spring Cloud service design micro fuse protection mechanisms need to be implemented between the micro-services by integrating Hystrix framework, Hystrix framework by calling the situation between the micro-monitoring services, to decide whether to activate fuse protection. So then, let us together look at how to achieve it by fusing mechanism in the framework of integrated Hystrix Spring Cloud project!

Introducing dependence to use Hystrix Spring Cloud framework necessary to introduce Hystrix starter frame dependencies, as follows:

 <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
 </dependency>
复制代码

By introducing this stater dependencies, we can Spring Boot frame based on characteristics of the box of the implement frame, i.e. Hystrix used.

Notes open fuse enable micro fuse in Spring Cloud services, you need to add org.springframework.cloud.client.circuitbreaker.EnableCircuitBreaker comment on the Application of micro main services, such as:

@EnableDiscoveryClient
@EnableCircuitBreaker
@SpringBootApplication
@EnableFeignClients(basePackageClasses = {PaymentClient.class})
@EnableScheduling
public class Goods {

    public static void main(String[] args) {
        SpringApplication.run(Goods.class, args);
    }
}
复制代码

With such a simple configuration annotations, this time on the micro-services based on open circuit breaker functions of Hystrix. It should be noted that, in a micro-breaker open service, the realization that fuse function of the micro-micro service to its downstream services, rather than the micro-fuse its upstream service call, that we do not confuse, because in Spring Cloud micro-service system, blown implementation is based on Hystrix local library to implement, in essence, is the client blown fuse instead of server-side. Compared to talk about more recent Based Service Mesh limiting fuse function, the client-based application form from fusing point of view, it is the integration of micro service itself together, rather than independent service.

FeignClient open Hystrix after opening the circuit breaker in micro service, does not mean that you can immediately use in the previous section we talked about in Spring Cloud micro-service system, the communication interaction between the micro-services need to be used FeignClient carried out, and by default is disabled by Hystrix, so if you need to enable Hystrix fuse function in micro-services, you need to open the manual configuration FeignClient Hystrix function by default, so FeignClient client communication calls between microService when, in order to abnormalities in the perception of micro-services case, the error indicator information back to Hystrix framework to Hystrix can start and stop (Hystrix specific operating principle on the state of the fuse according to their own logic, we chapters later in the introduced).

The following is our bootstrap.yml project file, open FeignClient configuration Hystrix support:

feign:
  hystrix:
    enabled: true
复制代码

Achieve FeignClient service degradation Code

Service calls between micro Spring Cloud service is based, in actual engineering practice, FeignClient call-side code we usually alone will be pulled FeignClient micro services and to publish SDK jar package dependent manner. Under normal circumstances, can each micro-engineering services are pulled out of a FeignClient code so that more clear; if you feel too much trouble, can also be coupled FeignClient client-side code number of different micro-services together, all of which rely on micro-services a SDK can, but more later if the number of micro-services and maintenance teams more dispersed, then it will also lead to a very bloated project appear more cumbersome to maintain and upgrade it, it can be planned according to the actual situation of the team.

We talk in front of the fuse mechanism through micro-based Spring Cloud service is actually fuse mechanism based on customer Hystrix frame end, that is to say upstream service when you call micro-micro downstream services through FeignClient, if the downstream micro perceived service call abnormal need to Hystrix framework abnormal upward feedback, if Hystrix framework to calculate abnormal indicators have reached the threshold will open fuse. After FeignClient the client calls and services for the downstream micro, need to be a corresponding local callback method downgraded after Hystrix fusing, thereby achieving service degradation.

The FeignClient from a code perspective has supported such a design, when we @FeignClient notes written by micro-services client calls the code, you can downgrade to handle the logic behind the service is blown by specifying the appropriate Fallback class. Here we have an example project exemplified herein, to write orders micro services FeignClient client SDK code: order-client.

Code Example:

@FeignClient(value = "order", configuration = OrderClientConfiguration.class, fallback = OrderClientFallback.class)
public interface OrderClient {

    // 查询购物订单扣费状态(内)
    @RequestMapping(value = "/order/queryOrderCost", method = RequestMethod.GET)
    QeuryOrderCostResVo queryOrderCost(@RequestParam(value = "orderId") String orderId) throws InternalApiException;
}
复制代码

According to the order of service in the micro-service interface definition, we define an annotation by @FeignClient OrderClient.class class that declares the service interface definition of micro, micro orders assumption here provides a service order query interface (a micro-service general there will be more next service interface, an interface to cite here just for a good example).

We can see in @FeignClient annotation properties, there is a fallback attribute that specifies the class OrderClientFallback.class configure a service degradation. Thus, it may be implemented in the class logic downgrading the corresponding method of micro-services:

public class OrderClientFallback implements OrderClient {

    @Override
    public OrderCostDetailVo orderCost(String orderId, long userId, String busiId, String orderType, int duration,
            int bikeType, String bikeNo, String countryName, int cityId, int orderCost, String currency, int strategyId,
            String tradeTime) {
        return new OrderCostDetailVo();
    }
}
复制代码

Can be seen that a downgrade is actually class OrderClient implementation class, so the interface where each of the micro and services will be forced to implement the corresponding fuse degraded code. Degraded and specific logic, it can be written according to the specific circumstances and services, as used herein is to return an empty message object.

The above model is in Spring Cloud by calling upon FeignClient, basic processing routines after turning Hystrix fuse function of the. Next, we pass a specific test results, look at the entry into force of circumstances fuse function:

1, the introduction of micro-order services in the micro-service goods in FeignClient client SDK

<dependency>
        <groupId>com.wudimanong.client</groupId>
        <artifactId>order-client</artifactId>
        <version>1.0.0</version>
</dependency>
复制代码

2, in order to observe, we need to open HystrixDashboard

Introducing HystrixDashboard dependence:

<dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
</dependency>
复制代码

Open HystrixDashboard notes in the application's main class:

@EnableHystrixDashboard
@EnableDiscoveryClient
@EnableCircuitBreaker
@SpringBootApplication
@EnableFeignClients
public class GoodsApplication {

    public static void main(String[] args) {
        SpringApplication.run(GoodsApplication.class, args);
    }
}
复制代码

3, this time by accessing HystrixDashboard console you can see information about the monitoring indicators

We assume that goods call order service under normal circumstances Ciruit is close state, if broken order service at this time, then brush a few times goods call request at this time, we find the fuse switch on order service was opened.

Then we restore order service, then brush several times more call interface, you will find Ciruit will be closed.

Through the above configuration, we basically completed Spring Cloud project configuration on Hystrix the fuse.

Guess you like

Origin juejin.im/post/5dd64e8e5188255d8c4adca3