[] Hystrix implement service isolation and relegation

One, background

  Today, SOA-based architecture has become very popular. With the SOA architecture and services associated fuse, demotion, and other limiting thoughts, also occur frequently in a variety of technical seminars.
  With the improvement of the complexity of the business, constantly split system, a user-oriented side API, RPC calls its internal layers of nested call chain may be very long. This can cause the following problems:

  • API interface to reduce the availability of: a reference example Hystrix official, assuming a tomcat application to provide both its internal dependencies of the 30 services, the availability of each service are very high, 99.99%. That is, the availability of the entire applicatiion: 99.99% 30 th power = 99.7%, i.e. 0.3% failure rate. This means that every 100 million request, there are 300,000 failed; a time to count, that is, downtime per month over two hours.

1.1 Service fuse

  In order to solve the above problems, the idea of fusing services have been proposed. Similar to the real world, " Fuse ", when an abnormal condition is triggered, directly fuse the entire service, not always wait for this service timeout. Fuse trigger conditions can vary according to different scenarios, such as statistical number of calls failed within a time window.

1.2 Service downgraded

  With fuse, you have to downgrade. The so-called demotion, when a service is blown, the server will no longer be called, this time a client can prepare their own local fallback callback returns a default value. In doing so, although the reduction in the level, but whatever the outcome is available, stronger than hang directly, of course, this also depends on appropriate business scenarios. On the use of Hystrix in fallback, see the official website

1.3 Service Isolation

  1. Avalanche effect : service service accumulation avalanche effect generated in the same thread pool, because in the same thread pool, all requests to all access to a service, which can lead to other services when no thread receives a request to access, so it will have service avalanche effect.
  2. Tomcat bottom: http + thread pool, each thread is independent of the request.
  3. When most people use Tomcat, serving multiple http share a thread pool, which assume a database access http service response is very slow, which will result in service response time delay increases, most of thread blocks waiting for data response is returned, resulting in entire Tomcat thread pool are occupied by the service, even down the entire Tomcat. So, if we can isolate different http service to a different thread pool, then an http service thread pool is full nor will it result in catastrophic failure of other services. This requires a thread isolation or semaphore isolation to achieve.
  4. Service isolation : Each service interface independently of each other, service isolation, there are two ways to achieve thread pool mode , the counter
  5. Role: Service protection, the service generated when stacked, the service achieve protection. ( Accumulation request : Suppose default tomcat threads in the thread pool maximum is 50. try to request a 51, the first 51 will block a large number of requests requests are waiting, if the accumulation of too many requests, the server can cause paralysis.)
  6. Using threads or isolation signal isolation purpose for different services allocated certain resources when their own resources run out, the direct return failure instead of occupying other people's resources.

1.4 summary

  1. Service isolation : to ensure that each service independently of each other, using semaphores and thread pool mode
  2. Service degradation : When the service is not available when the wait will not be directly returned a friendly tips
  3. Services blown : When the server can withstand the maximum after, denied access to direct service, most will call the service degradation method returns prompt and friendly. The purpose is to ensure that services are not down off

Second, the use Hystrix implement service isolation and relegation

About 2.1 Hytrix

  • Hystrix is ​​a microblogging service framework for service protection, open source Netflix is ​​a distributed system for the delay and fault resolution framework, the purpose is to isolate the distributed service failures. It provides threads and semaphores isolated to reduce the interaction between different services bring competition for resources; providing graceful degradation mechanism; fuse mechanism so that services can be provided quickly fail, rather than waiting for service response has been blocked, and from the rapid recovery. Hystrix through these mechanisms to prevent cascading failures and ensure system flexibility available.
  • Hystrix resource isolation strategy, there are two, namely: the thread pool and semaphores .

2.2 thread pool mode

  1. Use the thread pool can be completely isolated isolate third-party applications can be quickly returned to the requesting thread.
  2. Request thread can continue to accept new request, if the thread pool is separate isolation appears not affect other applications.
  3. When the application failed becomes available again, the thread pool will cleanup can resume immediately, without the need for a long period of recovery.
  4. Separate pools of threads to improve concurrency

Disadvantages: The main disadvantage of the thread pool isolation is that they increase computational overhead (CPU). Relates to each command queuing, scheduling, and context switching are on a separate thread running.

public class OrderHystrixCommand extends HystrixCommand<JSONObject> {
    @Autowired
    private MemberService memberService;

    /**
     * @param group
     */
    public OrderHystrixCommand(MemberService memberService) {
        super(setter());
        this.memberService = memberService;
    }

    protected JSONObject run() throws Exception {
        JSONObject member = memberService.getMember();
        System.out.println("当前线程名称:" + Thread.currentThread().getName() + ",订单服务调用会员服务:member:" + member);
        return member;
    }

    private static Setter setter() {

        // 服务分组
        HystrixCommandGroupKey groupKey = HystrixCommandGroupKey.Factory.asKey("orders");
        // 服务标识
        HystrixCommandKey commandKey = HystrixCommandKey.Factory.asKey("order");
        // 线程池名称
        HystrixThreadPoolKey threadPoolKey = HystrixThreadPoolKey.Factory.asKey("order-pool");
        // #####################################################
        // 线程池配置 线程池大小为10,线程存活时间15秒 队列等待的阈值为100,超过100执行拒绝策略
        HystrixThreadPoolProperties.Setter threadPoolProperties = HystrixThreadPoolProperties.Setter().withCoreSize(10)
                .withKeepAliveTimeMinutes(15).withQueueSizeRejectionThreshold(100);
        // ########################################################
        // 命令属性配置Hystrix 开启超时
        HystrixCommandProperties.Setter commandProperties = HystrixCommandProperties.Setter()
                // 采用线程池方式实现服务隔离
                .withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.THREAD)
                // 禁止
                .withExecutionTimeoutEnabled(false);
        return HystrixCommand.Setter.withGroupKey(groupKey).andCommandKey(commandKey).andThreadPoolKey(threadPoolKey)
                .andThreadPoolPropertiesDefaults(threadPoolProperties).andCommandPropertiesDefaults(commandProperties);

    }
    
//############   服务降级  ##########
    @Override
    protected JSONObject getFallback() {
        // 如果Hystrix发生熔断,当前服务不可用,直接执行Fallback方法
        System.out.println("系统错误!");
        JSONObject jsonObject = new JSONObject();
        jsonObject.put("code", 500);
        jsonObject.put("msg", "系统错误!");
        return jsonObject;
    }
    }

Scenario:

  1. Third-party applications or interfaces
  2. Concurrent large

2.3 Semaphore

  • Counter mode: the bottom layer using atomic counter for each service: after all set up their own independent limit threshold, such as setting each service interface can simultaneously access up to 50 times, exceeding the buffer queue request, refused to implement their own strategies.
  • Using a counter atom (or semaphores) to record the current number of threads running, when a request comes first determination value of the counter exceeds the maximum number of threads is set to reject the request, if the traffic exceeds this time counter + 1, requesting the success counter returns -1.
  • Thread pool isolation biggest difference is that a thread of execution code is still dependent on the requesting thread, the semaphore can dynamically adjust the size of the thread pool size can not

code show as below:

public class OrderHystrixCommand2 extends HystrixCommand<JSONObject> {
    @Autowired
    private MemberService memberService;

    /**
     * @param group
     */
    public OrderHystrixCommand2(MemberService memberService) {
        super(setter());
        this.memberService = memberService;
    }

    protected JSONObject run() throws Exception {

        // Thread.sleep(500);
        // System.out.println("orderIndex线程名称" +
        // Thread.currentThread().getName());
        // System.out.println("success");
        JSONObject member = memberService.getMember();
        System.out.println("当前线程名称:" + Thread.currentThread().getName() + ",订单服务调用会员服务:member:" + member);
        return member;
    }

    private static Setter setter() {
        // 服务分组
        HystrixCommandGroupKey groupKey = HystrixCommandGroupKey.Factory.asKey("order");
        // 命令属性配置 采用信号量模式
        HystrixCommandProperties.Setter commandProperties = HystrixCommandProperties.Setter()
                .withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.SEMAPHORE)
                // 使用一个原子计数器(或信号量)来记录当前有多少个线程在运行,当请求进来时先判断计数
                // 器的数值,若超过设置的最大线程个数则拒绝该请求,若不超过则通行,这时候计数器+1,请求返 回成功后计数器-1。
                .withExecutionIsolationSemaphoreMaxConcurrentRequests(50);
        return HystrixCommand.Setter.withGroupKey(groupKey).andCommandPropertiesDefaults(commandProperties);
    }
    
//############   服务降级  ##########
    @Override
    protected JSONObject getFallback() {
        // 如果Hystrix发生熔断,当前服务不可用,直接执行Fallback方法
        System.out.println("系统错误!");
        JSONObject jsonObject = new JSONObject();
        jsonObject.put("code", 500);
        jsonObject.put("msg", "系统错误!");
        return jsonObject;
    }
    }

Scenario:

  1. Internal applications or middleware (Redis)
  2. Little concurrency requirements

Guess you like

Origin www.cnblogs.com/haoworld/p/hystrix-shi-xian-fu-wu-ge-li-he-jiang-ji.html