聊聊微服务的隔离和熔断-51CTO.COM

今天来聊一聊微服务的隔离和熔断是怎么做的，如果你的项目没有用微服务，不要走开，可以看看对一个问题的解决思路。

按照码农翻身的惯例，我们先用一个例子来抛出问题：

假设Tomcat线程池有100个线程，每次有新的用户请求过来，Tomcat就会从中找出一个空闲的线程去执行，抛开那些琐碎的小细节，这些请求其实非常简单，无非就是这么几件事：

1. 根据用户ID调用用户服务，获取用户对象。

2. 获取该用户的推荐商品

3. 获取该用户的积分。

4. 把这些信息组合起来，返回给浏览器。

有意思的是前三件事情全是HTTP调用，需要调用某个地方的所谓“微服务”。

有一次，线程A去执行几个逻辑，等它调用“推荐服务”的时候，“推荐服务”迟迟没有返回，线程A也许很高兴，终于可以休息了!

新的用户请求源源不断地到来，线程池中越来越多的线程都在等待推荐服务返回。

很快，100个线程全部用光，Tomcat只好挂出一个牌子： “系统繁忙，暂停营业。”

总之，一个服务的出错竟然导致了整个Tomcat不可用，实在是难以忍受。

也许你会和运维商量一下，来个简单粗暴的办法：给Tomcat线程池在增加100个线程兄弟，可是这不能解决问题，在高并发的情况下，只要那些远程的微服务有一个阻塞，无论多少线程，很快就会被用光。

于是，你只好重启Tomcat，毁灭这个可爱的世界，但是重启后问题还是有可能发生。

隔离

怎么把一个微服务的故障给隔离起来呢?让他们互不影响呢?

Netflix的程序员们想了一个点子，对每个微服务，都分配一个线程池，像这样：

比如说调用“推荐服务”的时候，就会从“推荐服务线程池” (假设有5个线程)中找到一个线程执行。如果这个HTTP系统调用迟迟没有返回，那这个线程就会一直等待，新的请求就需用使用池中别的线程。

如果5个线程都用光了，会发生什么情况?

这很简单，可以简单地认为这个服务不可用了!马上返回，绝不等待。

这些新的线程池，是一种隔离的手段，一个微服务一旦出了问题，很快就会被识别出来。

熔断器

但是上面这种方案，还是有一定的问题，如果这个推荐服务已经不可用了，还不断地尝试去调用，那肯定是一种浪费。

所以Netflix的程序员又想了一个办法：使用熔断器(也叫断路器)，注意：当这个熔断器关闭的时候，外面的请求可以直接调用，如果打开，就把外界的请求给阻断了。

具体的做法是：系统会检测请求失败的比率(失败数/总请求数)，一旦这个比率达到一个阈值的时候，熔断器就开启，直接拒绝执行用户请求。然后休眠一段时间，尝试放过一部分流量(比如一个请求)，如果调用成功，熔断器闭合，恢复到正常状态，否则继续进行休眠周期。

API

现在有了新的线程池，对程序员来讲，该如何使用呢? 原来是这么做的：

UserService service = ... 获得用户服务... 
User user = service.getUser(userID);

现在，为了利用新的线程池，需要做一层封装：

UserService service = ... 获得用户服务... 
UserServiceCmd  cmd = new UserServiceCmd(service, userID); 
User user = cmd.execute();

看到没有? UserService 被封装了一层，放到了一个UserServiceCmd中去执行。

这个Command代码是这个样子的：

public class UserServiceCmd    extends HystrixCommand<User> { 
  private UserService userService = null; 
  private String userID = null; 
  …… 
 
  public UserServiceCmd(UserService userService, 
                        String userID) { 
    …… 
    this.userService = userService; 
    this.userID = userID; 
  } 
 
  @Override 
  protected User run(){         
    return userService.getUser(userID);         
  } 
 
  @Override 
  protected User getFallback() {         
    return annonymousUser; 
  } 
}