在微服務架構中異常如何正確使用

這篇文章跟大家介紹一下在微服務架構中異常正確使用的方法。有一定的參考價值，有需要的朋友可以參考一下，希望對大家有幫助。

異常的正確使用在微服務架構中的重要性排前三，沒什麼意見吧

異常的正確使用在微服務架構中的重要性排前三，沒什麼意見吧

Curdboy 們好久不見，先祝大家端午節快樂。最近想說說異常，我的思考儼然形成了閉環，希望這套組合拳能對你的業務代碼有所幫助。

以下只討論世界上最好的語言和生態最完整的語言，沒什麼意見吧。

異常的異同

PHP 在PHP7 異常的設計和Java 保持一致了Exception extends Throwable  ，不過在歷史原因和設計理念上還是有一些細微的差別。例如 PHP 中的異常是有 code 屬性的，這樣就存在多種異常聚類為同一個異常，然後在catch 區塊裡根據 code 寫不同的業務邏輯代碼。

而 Java 例外則沒有code ，不能這樣設計，只能針對不同的情況使用不同的例外。所以我們習慣服務對外暴露的透過包裝類別來封裝，而不是直接依賴異常的透傳。

統一異常的處理

在 Java 程式碼裡，最讓人詬病的就是漫山遍野的try catch  ，沒什麼意見。隨便抓一段程式碼

@Override
public DataResult<List<AdsDTO>> getAds(Integer liveId) {
    
    try {
        List<AdsDTO> adsDTO = new ArrayList<>();
        //...业务逻辑省略
        DataResult.success(adsDTO);
    } catch (Exception e) {
        log.error("getAds has Exception:{}", e.getMessage(), e);
        DataResult.failure(ResultCode.CODE_INTERNAL_ERROR, e.getMessage()); // 将异常信息返回给服务端调用方
    }
    
    return dataResult;
}

很多時候都是無腦上來就先寫個 try catch 再說，不管裡面是否會有非運行時異常。比較好的方式是使用 aop 的方式來攔截所有的服務方法的調用，統一接管異常然後做處理。

@Around("recordLog()")
public Object record(ProceedingJoinPoint joinPoint) throws Throwable {
  //... 请求调用来源记录
  
  Object result;

  try {
    result = joinPoint.proceed(joinPoint.getArgs());
  } catch (Exception e) {
    //... 记录异常日志
    
    DataResult<Object> res = DataResult.failure(ResultCode.CODE_INTERNAL_ERROR, e.getMessage());
    result = res;
  }

    //... 返回值日志记录
  
  return result;
}

有一點小問題，如果直接將A 服務的異常訊息直接回傳給呼叫者B，可能存在一些潛在的風險，永遠不能相信呼叫者，即使他根正苗紅三代貧農也不行。因為不能確定呼叫者會將該錯誤訊息作何處理，可能就直接作為 json 回傳給了前端。

RuntimeException

在Java 中異常可以分為運行時異常和非運行時異常，運行時異常是不需要捕獲的，在方法上也不需要標註throw Exception，例如我們在方法裡使用guava 套件裡的Preconditions工具類，拋出的IllegalArgumentException也是執行時期例外。

@Override
public DataResult<List<AdsDTO>> getAds(Integer liveId) {
  Preconditions.checkArgument(null != liveId, "liveIds not be null");
  
  List<AdsDTO> adsDTOS = new ArrayList<>();
  //...业务逻辑省略
  return DataResult.success(adsDTOS);
}

我們也可以使用該特性，自訂自己的業務例外類別繼承RuntimeException

XXServiceRuntimeException extends RuntimeException

對於不符合業務邏輯情況則直接拋出XXServiceRuntimeException

@Override
public DataResult<List<AdsDTO>> getAds(Integer liveId) {

  if (null == liveId) {
    throw new XXServiceRuntimeException("liveId can&#39;t be null");
  }
  
  List<AdsDTO> adsDTOS = new ArrayList<>();
  //...业务逻辑省略
  return DataResult.success(adsDTOS);
}

然後在aop 做統一處理做相應的優化，對於前面比較粗暴的做法，應該將除了XXServiceRuntimeException和IllegalArgumentException之外的異常內部記錄，不再對外暴露，但是一定要記得通過requestId將分佈式鏈路串起來，在DataResult中返回，方便問題的檢查。

@Around("recordLog()")
public Object record(ProceedingJoinPoint joinPoint) throws Throwable {
  //... 请求调用来源记录
  
  Object result;

  try {
    result = joinPoint.proceed(joinPoint.getArgs());
  } catch (Exception e) {
    //... 记录异常日志①
    log.error("{}#{}, exception:{}:", clazzSimpleName, methodName, e.getClass().getSimpleName(), e);
    
    DataResult<Object> res = DataResult.failure(ResultCode.CODE_INTERNAL_ERROR);
    if (e instanceof XXServiceRuntimeException || e instanceof IllegalArgumentException) {
       res.setMessage(e.getMessage());
    }
 
    result = res;
  }

  if (result instanceof DataResult) {
      ((DataResult) result).setRequestId(EagleEye.getTraceId()); // DMC 
  }

    //... 返回值日志记录
  
  return result;
}

異常監控

說好的閉環呢，使用了自訂異常類別之後，對異常日誌的監控警報的閾值就可以降低不少，警報更精準，以阿里雲SLS 的監控為例

* and ERROR not XXServiceRuntimeException not IllegalArgumentException|SELECT COUNT(*) AS count

這裡監控的是記錄異常日誌① 的日誌

PHP 裡的異常

#上面Java 裡說到的問題在PHP 裡也同樣存在，不用3 種方法來模擬aop 都不能體現PHP 是世界上最好的語言

//1. call_user_func_array
//2. 反射
//3. 直接 new
try {
  $class = new $className();
  $result = $class->$methodName();
} catch (\Throwable $e) {
    //...略
}

類似上面的架構邏輯不再重複寫偽代碼，基本上保持一致。也是自訂自己的業務異常類別繼承RuntimeException，然後做對外輸出處理。

但是PHP 裡有一些歷史包袱，起初設計的時候很多運行時異常都是作為Notice，Warning 錯誤輸出的，但是錯誤的輸出缺少調用棧，不利於問題的排查

function foo(){
  return boo("xxx");
}

function boo($a){
  return explode($a);
}

foo();

Warning: explode() expects at least 2 parameters, 1 given in /Users/mengkang/Downloads/ab.php on line 8

看不到特定的參數，也看不到呼叫堆疊。如果使用set_error_handler ErrorException之後，就非常清晰了。

set_error_handler(function ($severity, $message, $file, $line) {
    throw new ErrorException($message, 10001, $severity, $file, $line);
});

function foo(){
  return boo("xxx");
}

function boo($a){
  return explode($a);
}

try{
  foo();
}catch(Exception $e){
  echo $e->getTraceAsString();
}

最後印出來的訊息是

Fatal error: Uncaught ErrorException: explode() expects at least 2 parameters, 1 given in /Users/mengkang/Downloads/ab.php:12
Stack trace:
#0 [internal function]: {closure}(2, 'explode() expec...', '/Users/mengkang...', 12, Array)
#1 /Users/mengkang/Downloads/ab.php(12): explode('xxx')
#2 /Users/mengkang/Downloads/ab.php(8): boo('xxx')
#3 /Users/mengkang/Downloads/ab.php(15): foo()
#4 {main}
  thrown in /Users/mengkang/Downloads/ab.php on line 12

修改上面的函數

function boo(array $a){
  return implode(",", $a);
}

則沒辦法捕捉了，因為拋出的是PHP Fatal error:  Uncaught TypeError，PHP7新增了
class Error implements Throwable，則在PHP 系統錯誤日誌裡會有Stack，但是不能和整個業務系統串聯起來，這裡就又不得不說日誌的設計，我們期望像Java 那樣透過一個traceId 將所有的日誌串聯起來，從Nginx 日誌到PHP 裡的正常info level 日誌以及這些Uncaught TypeError，所以接管預設輸出到系統錯誤日誌，在catch 程式碼區塊中記錄到統一的地方。那這裡就簡單修改為

set_error_handler(function ($severity, $message, $file, $line) {
    throw new ErrorException($message, 10001, $severity, $file, $line);
});

function foo(){
  return boo("xxx");
}

function boo(array $a){
  return implode(",", $a);
}

try{
  foo();
}catch(Throwable $e){
  echo $e->getTraceAsString();
}

catch Throwable就能接受Error和Exception了。

但是 set_error_handler 沒辦法處理一些錯誤，例如E_PARSE的錯誤，可以用register_shutdown_function來兜底。

值得注意的是register_shutdown_function的用意是在脚本正常退出或显示调用exit时，执行注册的函数。
是脚本运行(run-time not parse-time)出错退出时，才能使用。如果在调用register_shutdown_function的同一文件的里面有语法错误，是无法注册的，但是我们项目一般都是分多个文件的，这样就其他文件里有语法错误，也能捕获了

register_shutdown_function(function(){
    $e = error_get_last();
    if ($e){
        throw new \ErrorException($e["message"], 10002, E_ERROR, $e["file"], $e["line"]);
    }
});

如果你想直接使用这些代码（PHP的）直接到项目可能会有很多坑，因为我们习惯了系统中有很多  notice 了，可以将 notice 的错误转成异常之后主动记录，但是不对外抛出异常即可。

推荐学习：php视频教程

以上是在微服務架構中異常如何正確使用的詳細內容。更多資訊請關注PHP中文網其他相關文章！