為什麼在RPC環節中有熔斷以及降級的需求，詳細的原因這裡不多解釋，從網上搜索一張圖做示意。

熔斷

我理解熔段主要解決如下幾個問題：

當所依賴的物件不穩定時，能夠起到快速失敗的目的快速失敗後，能夠根據一定的演算法動態試探所依賴物件是否恢復

比如產品詳細頁獲取產品的好評總數時，由於後端服務異常導致客戶端每次都需要等到超時。如果短時間內服務不能恢復，那麼這段時間內的所有請求時間都將是最大的超時時間，這類消費時間又得不到正確結果的現象是不能容忍的。所以遇到這類情況，就需要根據一定的演算法判定服務短時間不可用，將後面的請求進行快速失敗處理，這樣可以節省服務等待時間。

同時，後端服務是有可能自主或者人為在一定時間內恢復的，所以之前被判定為快速失敗的服務，需要有能力去試探服務是否已經恢復。

上面提到的快速失敗以及自主恢復現象就是熔斷

降級

降級是指自己的待遇下降了，從RPC呼叫環節來講，就是去訪問一個本地的偽裝者而不是真實的服務，但這對呼叫端來說是沒有區別的。拿電商展示某個產品的詳細頁來說：

當載入評論時，由於評論服務不可用，此時可以返回一些預設的評論當載入產品庫存，由於庫存服務不可用，此時可以固定顯示一個庫存數

上面提供返回預設評論，固定庫存的服務就是偽裝服務，這類服務一般不依賴其它服務，穩定性最高。由偽裝者提供服務給客戶端的現象就是服務降級。

RPC如何支援熔斷與降級

一種最簡單的辦法就是借用hystrix來實現。

引入包依賴

由於示例未採用註解式方案，所以只需要引用下面兩個包即可。

<dependency>
  <groupId>com.netflix.hystrix</groupId>
  <artifactId>hystrix-core</artifactId>
  <version>${hystrix-version}</version>
</dependency>
<dependency>
  <groupId>com.netflix.hystrix</groupId>
  <artifactId>hystrix-metrics-event-stream</artifactId>
  <version>${hystrix-version}</version>
</dependency>

實現命令模式

hystrix遵循命令模式，這裡可以往這個標準的UML圖上去套。

建立一個新的類，RpcHystrixCommand，繼承自HystrixCommand即可。

我這裡採用執行緒隔離方式。

建構函式引數

由於需要遠端呼叫，所以建構函式需要接收遠端呼叫所需求必要引數

/**
 * 遠端目標方法
 */
private Method method;

/**
 * 遠端目標介面
 */
private Object obj;

/**
 * 遠端方法所需要的引數
 */
private Object[] params;

/**
 * 遠端介面客戶端引用註解
 */
private RpcReference rpcReference;

/**
 * RPC客戶端配置
 */
private ReferenceConfig referenceConfig;

建構函式方法簽名:

public RpcHystrixCommand(Object obj,Method method,Object[] params,RpcReference rpcReference,ReferenceConfig referenceConfig)

初始化hystrix

這裡只是一個示例，所以引數設定比較隨意，詳細的可參考文件。

super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("CircuitBreakerRpcHystrixCommandGroup"))
            .andCommandKey(HystrixCommandKey.Factory.asKey("CircuitBreakerRpcHystrixCommandKey"))
            .andCommandPropertiesDefaults(
                HystrixCommandProperties.Setter()
                    .withCircuitBreakerEnabled(true)
                    .withCircuitBreakerRequestVolumeThreshold(1)
                    .withCircuitBreakerErrorThresholdPercentage(50)
                    .withCircuitBreakerSleepWindowInMilliseconds(5*1000)
                    .withMetricsRollingStatisticalWindowInMilliseconds(10*1000)
            )
            .andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("CircuitBreakerRpcHystrixCommandPool"))
            .andThreadPoolPropertiesDefaults(
                HystrixThreadPoolProperties.Setter().withCoreSize(100)
        )
    );

run()函式

run()函式就是正常呼叫時所需要執行的方法，將呼叫遠端通訊的邏輯遷移到此，由於此處不涉及今天講的熔斷降級，所以不用關心裡面的程式碼。

@Override
protected Object run() {
 // 執行遠端呼叫
}

擴充套件rpcReference註解以支援降級

在之前的註解中增加一個屬性，用來配置服務偽裝者所屬的類物件

public @interface RpcReference {
  /**
   * 服務降級的偽裝者類物件
   * @return
   */
  Class<?> fallbackServiceClazz() default Object.class;
}

getFallback()函式

當快速失敗時，我們希望返回一些預先準備好的值給到客戶端，實現這個需求就需要實現這個fallback函式。

偽裝者的邏輯由於是客戶端控制，所以我們通過引數來動態支援。 通過rpcReference註解可以獲取配置的偽裝者

protected Object getFallback() {

    Method[] methods = this.rpcReference.fallbackServiceClazz().getMethods();
    for (Method methodFallback : methods) {
      if(this.method.getName().equals(methodFallback.getName())){
        try {
          Object fallbackServiceMock= ApplicationContextUtils.getApplicationContext().getBean(this.rpcReference.fallbackServiceClazz());
          return methodFallback.invoke(fallbackServiceMock,this.params);
        } catch (IllegalAccessException e) {
          logger.error("RpcHystrixCommand.getFallback error",e);
        } catch (InvocationTargetException e) {
          logger.error("RpcHystrixCommand.getFallback error",e);
        }
      }
    }
    throw new RpcException("service fallback unimplement");
  }

RpcProxy嵌入熔斷降級機制

代理的invoke方法，將改呼叫命令模式的execute方法來代替。

@Override
public Object invoke(Object proxy,Object[] args) throws Throwable {

  RpcHystrixCommand rpcHystrixCommand=new RpcHystrixCommand(proxy,method,args,this.reference,this.referenceConfig);
  return rpcHystrixCommand.execute();
}

客戶端使用

dubbo有一個mock機制，功能有些弱，有興趣可以自行研究。我這裡更加傾向於根據邏輯來判斷是否使用熔斷降級，降級的邏輯需要有更多的支援。

Spring Cloud的熔斷降級的做法與我的類似,它是通過註解在介面上

@FeignClient(value = "JIM-CLOUD-PROVIDER-SERVER",fallback = ProductServiceHystrix.class)
public interface ProductService {
  @RequestMapping(value = "/product/{productId}",method = RequestMethod.GET)
  String getById(@PathVariable("productId") final long productId);

}

建立偽裝者介面

定義偽裝者介面，約定成員方法的簽名與真身相同。

public interface ProductCommentMockService {
  Product getById(Long productId);
}

實現偽裝者介面

實現偽裝者介面，這裡不光是簡單的固定資料,可心任意編寫偽裝者業務邏輯，與普通的service bean 沒有區別。

@Service
public class ProductCommentMockServiceImpl implements ProductCommentMockService {
  @Override
  public Product getById(Long productId) {

    Product mockProduct=new Product();
    mockProduct.setId(0L);
    mockProduct.setName("mock product name");

    return mockProduct;
  }
}

服務引用使用熔斷降級機制

在引用遠端服務介面的註解上，配置偽裝者介面的類即可。

@RpcReference(
    maxExecutesCount = 1,fallbackServiceClazz = ProductCommentMockService.class
)
private ProductService productService;

測試

故意不啟動服務端，請求介面，此時出現mock資料說明元件功能正常。

{"id":0,"name":"mock product name"}

待解決問題

由於熔斷器採用的是新執行緒執行，所以會影響Rpc上下文傳遞的引數傳遞。

本文原始碼

https://github.com/jiangmin168168/jim-framework

文中程式碼是依賴上述專案的，如果有不明白的可下載原始碼

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支援我們。