聊聊微服務的隔離和熔斷

作者：劉欣 2018-12-06 14:56:46

企業動態

今天來聊一聊微服務的隔離和熔斷是怎么做的，如果你的項目沒有用微服務，不要走開，可以看看對一個問題的解決思路。

按照碼農翻身的慣例，我們先用一個例子來拋出問題：

假設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; 
  } 
}