呼叫鏈中的異常處理

假設微服務serviceA的介面interfaceA被微服務serviceB呼叫，如果interfaceA在呼叫過程中會丟擲異常，那麼是否該將該異常以狀態碼傳給serviceB呢？

對於RPC來說（如Feign），會自動將被呼叫的遠端介面的異常在呼叫方以異常丟擲；對於Rest Api來說，可以將異常包裝到response的out中。

我建議serviceB在呼叫interfaceA時，判斷interfaceA是否出現異常應該儘量不要依賴於判斷interfaceA返回的狀態碼。因為讀取狀態碼是要獲取response物件，而這樣會造成程式碼不必要的拖沓。
儘量不要這麼寫：

@GetMapping(path = "/interfaceA")
public String methodA(@RequestParam String input)throw SomeException{
    ...
    return res;
}

應該這麼寫：

@GetMapping(path = "/interfaceA")
public String methodA(@RequestParam String input){
    try{
        ...
    }catch(SomeException e){
        logger.error("error reason"
 
, e);
        return "error reason";
    }
    return res;
}

這樣，出現異常時候，可以在serviceA記錄異常原因，同時將異常原因返回給serviceB，這樣serviceB可以通過返回字串來判斷是否執行成功。
而對於返回物件的介面，則可以在出現異常時通過返回null來告訴serviceB調用出現異常。

另外：

- 介面能返回String儘量不要返回Boolean，應該讓serviceB儘可能知悉異常原因。（返回物件就沒辦法了）
- 如果interfaceA只有前端呼叫，interfaceA丟擲異常返回狀態碼也是可以的（不過誰能保證interfaceA以後不被其他微服務呼叫呢？）

介面路徑定義原則

介面路徑

應該儘量將傳遞的變數input放在RequestParam：

@GetMapping(path = "/interfaceA")
public String methodA(@RequestParam String input){
    ...
    return res;
}

即使要放在path也應該這樣：

@GetMapping(path = "/interfaceA/{input}")
public String methodA(@PathVariable("input") String input){
    ...
    return res;
}

而不應該這樣放在path：

@GetMapping(path = "/{input}/interfaceA")

我們應該儘可能保證可以通過某種方式形成路徑命名子空間，從而隔離開各個介面，方便dispatcher分派request。第三種方式容易造成路徑命名子空間汙染。