微服務架構，客戶端如何catch服務端的異常？

萤火架构發表於2024-03-06
微服務架構客戶端服務端

在微服務架構或者分散式系統中，客戶端如何捕捉服務端的異常？

這裡說的客戶端指呼叫方、服務端指被呼叫方，它們通常執行在不同的程序之中，這些程序可能執行在同一臺伺服器，也可能執行在不同的伺服器，甚至不同的資料機房；其使用的技術棧可能相同，也可能存在很大的差異。

為什麼

在Java、C#等高階語言中，程式遇到無法處理的情況，或者不滿足執行條件時，比如除數是0的情況，底層程式碼通常會透過丟擲異常（Exception）的方式向上層傳遞問題，上層程式碼透過 try-catch 的方式捕捉異常並進行處理，不過這種方式一般只能在同一個程序中使用，如果跨程序就沒辦法直接使用了。

有的同學可能會問：為什麼要跨程序傳遞異常呢？

大家呼叫遠端介面的時候可能有過這樣的體驗：

  • 首先遠端介面可能會返回一些提前定義好的錯誤碼，此時我們需要從返回資料中提取這些錯誤碼，然後再根據不同的值進行相應的業務處理；
  • 其次我們還需要處理一些未知的錯誤，它們可能來源於服務端未注意到的地方，比如空指標問題，也可能是底層框架、作業系統或者硬體等丟擲的一些問題，比如請求或者返回格式不匹配、網路中斷、磁碟故障、記憶體溢位、檔案系統損壞等各種技術問題。

如此我們實際上需要面對兩種錯誤，而且需要採用不同的方式在不同的地方處理它們，這相當繁瑣，心智負擔比較大。從Java、C#等轉Go的同學可能對此也深有體會，隨處可見的error判斷，還要留心panic的問題，當然Go有自己的意圖和堅持，只是寫起來真的很糟心。

那我們有什麼辦法來處理這個問題呢？我的選擇是全部統一為處理異常（Exception），異常中可以包含錯誤碼、錯誤描述，完全可以覆蓋錯誤碼的處理方式；而且異常不可避免，錯誤碼則都是上層應用自己定義的。

基本原理

異常資訊也是一種資料，所以傳遞異常也是傳輸資料。我們想要把資料從一個程序傳遞給另一個程序有很多種方法，在微服務架構或者分散式系統中，服務之間就是各種遠端網路呼叫，服務的具體實現可能是基於Http協議的Restful、gRPC，也可能是基於TCP的Dubbo等等，我們的異常資訊傳遞也要基於這些框架的約定和底層通訊協議。

以Restful為例，當服務端產生異常時，我們透過攔截器或者程式內部的中介軟體捕捉到這個異常，提取出其中的異常資訊，並中斷這個異常的繼續丟擲，然後把拿到的異常資訊寫到HTTP Header中，返回到客戶端。客戶端的HTTP請求程式則從HTTP響應的Header中讀取到這些異常資訊，然後再把他們包裝成異常（Exception），throw 出來。最後客戶端中的業務程式碼就可以使用 try-catch 捕捉到這個異常，並根據錯誤碼進行相應的處理。

微服務架構，客戶端如何catch服務端的異常？

使用WCF、gPRC和Dubbo等框架時也是類似的方法，只是傳遞異常時其寫入和讀取的位置不同。比如Dubbo可以在其資料包的訊息頭中宣告這是一個錯誤相應，並在訊息體中包含詳細的異常資訊；gPRC則可以利用它提供的Status來傳遞錯誤碼、錯誤描述和一些額外的參考資訊。

使用Restful、gRPC等協議或者技術還有一個好處，那就是這些技術使用的協議是跨平臺的，你用Java開發，他用Go開發，你的程式跑在Windows上，他的程式跑在Linux上，這些都沒有問題，都可以按照一套規則正常通訊，傳遞異常也完全沒有問題。

有的同學可能會擔心效能的問題，因為丟擲異常時，程式通常要把整個呼叫堆疊回溯一遍，這個過程可能會消耗一些計算資源，特別是當異常頻繁發生或堆疊層次很深時。不過正常情況下，各種防護到位時，異常應該很少發生；而且現代編譯器和執行時環境也會對異常處理進行最佳化，以減少效能開銷。最後，異常處理機制的設計初衷是為了提高程式碼的健壯性和可維護性，在大多數情況下，異常處理所帶來的效能開銷是可以接受的。

最佳實踐

接下來聊一些具體實現、遇到的問題和應對方法。

丟擲業務異常

服務在改變資料狀態之前，通常需要對資料進行一些驗證，比如必填驗證、格式驗證、資料一致性驗證等等，如果驗證不透過，就要返回錯誤資訊。

在傳統的方案中，我們可能會定義一個通用的訊息格式，其中包含錯誤碼、錯誤描述，以及正常的業務欄位，如下這樣：

public class Response{
  // 處理狀態：錯誤碼、錯誤描述
  public int ErrCode{get;set;}
  public string ErrMsg{get;set;}

  // 處理成功時返回的業務資料
  public string UserId{get;set;}
  public string UserName{get;set;}
  ...
}

需要返回錯誤時，我們就會建立一個Response的例項，然後返回它，就像下邊這樣：

if(stirng.IsNullOrEmpty(id)){
  return new Response(100,"Id為空");
}

為了實現更為統一的錯誤處理方式，我們這裡可以把返回Response例項的方式改為丟擲異常。

if(stirng.IsNullOrEmpty(id)){
  throw new FireflySoftException(100,"Id為空");
}

如此，我們只需要在攔截器或者中介軟體中捕捉異常，並進行相應的處理就可以了，不管它是一個業務上的驗證錯誤，還是底層框架中的某種未知異常。

比如在ASP.NET Core的異常攔截器中可以這樣統一處理：

/// <summary>
/// WebAPI異常過濾器
/// </summary>
internal class WebAPIAsyncExceptionFilter : IAsyncExceptionFilter
{
    /// <summary>
    /// 非同步異常處理
    /// </summary>
    /// <param name="context"></param>
    /// <returns></returns>
    public async Task OnExceptionAsync(ExceptionContext context)
    {
          // 將自定義的異常或系統自帶異常都轉換為一種異常
          FireflySoftException ex;
          if(context.Exception is FireflySoftException){
            ex = (FireflySoftException)context.Exception;
          }else{
            ex = ConvertToFireflySoftException(context.Exception);
          }

          // 將異常資訊寫到 Http Header 中
          context.HttpContext.Response.StatusCode = 500;
          context.HttpContext.Response.Headers.Add("errcode", ex.Code.ToString());
          context.HttpContext.Response.Headers.Add("errmsg", System.Web.HttpUtility.UrlEncode(ex.Message));
          // 異常描述也寫到 Http Body 中，方便人看
          var bodyContent = Encoding.UTF8.GetBytes(ex.Message);
          await context.HttpContext.Response.Body.WriteAsync(bodyContent, 0, bodyContent.Length).ConfigureAwait(false);
          
          context.ExceptionHandled = true;
    }
}

在底層處理異常

不應該讓業務程式開發者關心異常的傳遞實現，比如上邊編寫的攔截器應該內建到團隊的開發框架或者規範類庫中，業務程式開發者只需要丟擲異常或者捕捉異常就夠了。

服務端的異常攔截器上邊已經給了個例子，對於客戶端，我們可以透過包裝網路請求方法來達到相同的目的。這裡還是用ASP.NET Core舉個例子：

// 包裝的Post請求方法
public async Task<HttpResponseMessage> PostAsync<TRequest>(string hostAndPort, string resourceUri, TRequest request)
{
    string requestJson = JsonConvert.SerializeObject(request);
    var content = new StringContent(requestJson, Encoding.UTF8, "application/json");

    // 在實際的網路請求外邊包一層
    return await DoHttp(async client =>
    {
        var uri = new Uri(client.BaseAddress, resourceUri);
        var requestMessage = new HttpRequestMessage()
        {
            Method = HttpMethod.Post,
            RequestUri = uri,
            Content = content
        };

        return await client.SendAsync(requestMessage).ConfigureAwait(false);
    }, hostAndPort).ConfigureAwait(false);
}

// 攔截HTTP錯誤幷包裝為自定義的異常
private async Task<HttpResponseMessage> DoHttp(Func<HttpClient, Task<HttpResponseMessage>> action, string hostAndPort)
{
    HttpResponseMessage response;
    try
    {
        var client = GetHttpClient()；
        response = await action(client).ConfigureAwait(false);
        return response.EnsureSuccessStatusCode();
    }
    catch (Exception ex)
    {
        // 如果 HTTP StatusCode 是錯誤碼，會進入這裡
        // 從 HTTP Header中提取錯誤碼和錯誤描述
        // 然後可以建立並丟擲對應的異常
         if (response.Headers.TryGetValues("errcode", out IEnumerable<string> errcodes))
         {
             var code = errcodes.FirstOrDefault();
             throw new FireflySoftException(code,"xxxxx");
         }
         ...
    }
}

如此，開發者透過Post呼叫介面時就可以這樣寫：

// 根據實際情況，可能需要try-catch，也可能不需要
try
{
  PostAsync("localhost:8080","api/getweather",new Request{
    City="帝都"
  })
}
catch(FireflySoftException ex)
{
    // 這裡處理可能的業務異常
}

統一記錄異常日誌

有的同學為了方便跟蹤異常資訊，喜歡在程式中catch異常，並記錄到日誌中。

如果使用統一的異常方式來處理錯誤，則都可以在攔截器或者中介軟體中來做這件事，只需要在其中加入日誌的記錄邏輯就可以了。

當然有些異常可能還是要 catch 一下的，比如“新增資訊時重複提交”、“給使用者發訊息時使用者已取消授權”等等，這些異常可能都是要被忽略的，catch 住它們之後，程式可以吞掉這些異常，因為服務呼叫方也不關心這些異常，就沒必要再向上丟擲。

區分Warn和Error

這裡是說要給異常分個等級，有些異常就是個警告級別的，比如使用者沒有填寫某個引數，只要告訴使用者就行了，運維或者開發者不太關心這些訊息。有些異常則十分嚴重，比如空指標異常、除0異常等等，這往往說明程式存在BUG，需要反饋給開發者進行修復。

我們可以在自定義的異常建構函式中增加一個異常等級的引數，如下所示：

if(stirng.IsNullOrEmpty(id)){
  throw new FireflySoftException(100,"Id為空",ErrorLevel.Light);
}

注意也不是所有的警告都無需管理員過問，比如對於一個網路請求庫，我們可能只是把請求超時作為一種警告，但是如果超時發生的非常頻繁，也需要通知管理員來進行關注。

根據異常級別，我們就可以記錄不同級別的日誌，然後監控程式就可以根據日誌級別和相應的頻率為管理員提供相應的處理建議。

返回200還是500

使用HTTP作為服務之間的通訊協議時，發生異常時服務端一般會返回500錯誤，也就是 HTTP StatusCode = 500，這一般是底層通訊框架的預設設計。但是這會導致一個監控問題，監控程式會跟蹤服務呼叫之間的HTTP狀態，如果遇到500錯誤，它就會認為程式發生了錯誤，而這個錯誤可能只是一個引數驗證不透過的情況，管理員不需要關心這個問題。

此時我們可以在攔截器中處理異常的地方稍微改造一下，將所有的HTTP狀態碼都改為200，或者當錯誤級別比較輕（ErrorLevel.Light）時設定為200，錯誤級別比較重（ErrorLevel.Heavy）時設定為500。

context.HttpContext.Response.StatusCode = 200;

這樣做並不影響客戶端對錯誤的處理，因為不管HTTP的狀態碼如何，客戶端都可以從HTTP Header中提取處理錯誤所需的錯誤碼和錯誤描述。

自動重試

有時服務端的錯誤可能只是瞬時的，或者只是多個節點中的少數節點不可用，重新發起請求就能成功完成呼叫。

我們可以把這個重試機制包裝到網路請求方法中，減少業務程式中處理重試的程式碼量，此舉也能更好的規範程式碼，避免BUG或者效能問題。

一種可行的方法是，我們根據異常的型別或者提前約定好的錯誤碼，在包裝的網路請求方法中針對這些異常進行特殊處理。具體實現可以參考下邊的程式碼：

private async Task<HttpResponseMessage> DoHttp(Func<HttpClient, Task<HttpResponseMessage>> action, string hostAndPort)
{
  int tryCount = 0;
  while (true)
  {
      HttpResponseMessage response;
      try
      {
          var client = GetHttpClient()；
          response = await action(client).ConfigureAwait(false);
          return response.EnsureSuccessStatusCode();
      }
      catch (Exception ex)
      {
           // 遇到某種特定的異常時，我們就進行一次重試
           if (ex is TaskCanceledException)
           {
              if(tryCount<1){
                tryCount++;
                continue;
              }
              throw;
           }
           ...
      }
  }
}

以上就是本文的主要內容，文章雖然描述了微服務架構下異常傳遞的基本原理，也探討了一些具體的實踐方法，但要完完整整的實現並整合到自己的開發框架中，必然還有很多的工作要做，比如錯誤碼的定義，異常處理與限流、熔斷等的整合，等等。

文章難免錯漏，如有問題歡迎交流討論。

關注螢火架構，加速技術提升！

相關文章