同步自:https://sulin.me/2019/T2ZXZB....
在分佈式系統開發中,我們經常需要將各種各樣的狀態碼、錯誤信息傳遞給最外層的調用方,這個調用方通常是http/api
接口,錯誤信息比如登錄失效
、參數錯誤
等等。
最外層接口暴露的數據通常是類似於{code, msg, data}
這樣的json
格式,這一點沒有任何爭議。
但是分佈式系統的節點之間RPC調用、節點內部方法調用中,通常會用ServiceException
或Result<T>
的方式進行錯誤信息的傳遞,這兩種方式有什麼區別以及孰優孰劣呢?本文側重於開發效率
與系統性能
探討這個問題。
Result<T>
介紹
這是一種比較常見的錯誤信息傳遞方式,某些大廠甚至直接將它們設爲技術規範,強制各個團隊採用這種方式。常見的Result模板如下:
@Data
public class Result<T> {
private int code; // 也可以是String等
private String msg;
private T data;
}
在系統開發中的應用通常是這樣的:
Result<UserModel> userModelResult = userService.query(userId);
if (!userModelResult.isSuccess() || userModelResult.getData != null) {
return Result.fail(userModelResult); // 透傳錯誤
}
UserModel userModel = userModelResult.getData();
if (userModel.getStatus() != UserStatusEnum.NORMAL) {
return Result.fail("user unavaliable"); // 用戶不可用
}
// ... 正常使用UserModel
在比較複雜的分佈式微服務環境中,類似的代碼非常之多,每個依賴服務的調用都伴隨着一段類似的容錯邏輯。
這種模式比較類似Golang
語言中的錯誤碼處理,這也是Golang比較被人詬病的地方,即每一步都得進行錯誤判斷。
更殘酷的現實是,儘管有了Result
封裝,但是仍然會有後端系統的Exception
透傳過來。在我接觸過的實際應用中,這種突破Result
封裝的異常透傳絕非個例,我自己負責的系統在調用更後端的國內最強交易系統時,就曾接到過最內部交易中心TC的業務異常,排查問題時追蹤的團隊就有不止5個。
ServiceException
介紹
顧名思義,這個方式就是使用異常中斷
將正常邏輯與異常邏輯進行拆分。
在系統開發中,大部分錯誤都需要直接中斷服務,直接將錯誤反饋給用戶,正因爲如此,我們在使用Result<T>
時,經常需要寫類似if(result.isFail()){return…}
這樣的代碼。而使用ServiceException
,我們就可以省略掉絕大部分類似的代碼。
通常ServiceException
可以這樣定義:
@Getter
public class ServiceException extends RuntimeException {
private final int code;
private final String msg;
public ApiException() {
this(-1, null);
}
public ApiException(Code code) {
this(code, null);
}
public ApiException(Code code, String msg) {
super(msg);
this.code = code;
this.msg = msg;
}
}
系統內部組件在遇到數據缺失
、越權訪問
、登錄失效
、賬戶鎖定
等異常情況時,直接拋出ServiceException
中斷邏輯,然後由最外層的Filter
或Aspect
捕捉異常,提取其中的code
和msg
返回給用戶。
實際使用的代碼邏輯類似這樣:
UserModel userModel = userService.query(userId); // userID不存在、不可用等隱藏在異常中
// ... 使用userModel
這種方式明顯優雅、精簡了許多,對於開發效率的提高以及後期維護都有幫助。
但是在坊間有許多流言聲稱,使用異常中斷會影響性能,甚至有人通過簡單的性能測試推出異常中斷的性能耗時比返回Result快幾百倍云云。
性能測試
針對性能問題,我也進行了一個簡單的測試,具體測試代碼參見:
https://github.com/sisyphsu/b...
這裏使用JMH
進行性能測試,說到benchmark
,真的是羨慕golang
語言自帶的test
庫,實在是太方便了。
測試內部的業務邏輯非常簡單,只是調用一次System.currentTimeMillis()
並返回long
時間戳。
性能測試中分別使用Result<T>
返回值以及拋出Exception
,針對拋出異常的性能測試,又增加的不同深度的調用棧測試,這是因爲Java
在拋出異常時,需要分析當前Thread
的棧,而調用棧越深,所造成的性能損耗就越大。具體棧深度取值爲1、10、100:
Test.test avgt 5 0.027 ± 0.001 us/op
Test.testException avgt 5 1.060 ± 0.045 us/op
Test.testDeep10Exception avgt 5 1.826 ± 0.122 us/op
Test.testDeep100Exception avgt 5 9.802 ± 0.411 us/op
乍一看,異常棧深度爲100的性能損耗確實是普通方法調用的360倍,有的人也確實是基於這種理由得出Java異常中斷性能損耗嚴重的結論。
分析性能的影響
但是需要注意時間單位,只是微秒而已,毫秒的千分之一、秒的百萬分之一。
假設某個微服務單CPU吞吐量爲1000QPS,而其中有10%是非法請求,那麼異常中斷的性能損耗也只是萬分之一而已,對於服務耗時的影響也只是0.001毫秒而已。
在性能測試中,業務耗時
只是獲取系統時間,大概耗時爲25ns
。正因爲如此才顯得異常中斷的性能損耗達到恐怖的“幾百倍”,但是如果業務耗時從25ns
變爲25us
、25ms
呢?
再談性能瓶頸
我們在分析系統性能時,一定要搞清楚它的數量級以及性能瓶頸,切記陷入性能優化的困境。
舉個粗糙例子,在常規服務中,利用了索引的DB操作在1~10毫秒之間,訪問分佈式Cache的耗時在3~30毫秒之間,微服務RPC的網絡性能損耗在3~10毫秒之間,客戶端與服務器之間的網絡耗時在5~300毫秒之間,如此之類等等。在這種情況下,優化0.001毫秒的性能隱患無異於撿了芝麻丟了西瓜。
我曾經寫過類似TCP的底層網絡協議,在那種高頻場景中,算法優化帶來0.1微秒的性能優化就意味着每秒鐘吞吐量幾成甚至幾倍的提升,但是在分佈式調用的低頻場景中,這種性能用處沒有任何用處。
另外一個例子,幾年前我和同事在討論DB數據表設計時,因爲訂單狀態使用什麼長度的int
而爭執的面紅脖子粗,現在想想,訂單狀態上優化的1個字節,長年累月下來也只是節省不到1MB的磁盤空間而已,有什麼用呢?
RPC中的異常中斷
對於使用Dubbo、HSF這種遠程調用框架而言,使用異常中斷進行錯誤信息傳遞,需要注意一點就是,異常類型需要設計爲通用的,即各個微服務都引用的基礎類型。
在某廠的技術規範中有說到:
1) 使用拋異常返回方式,調用方如果沒有捕獲到就會產生運行時錯誤。2) 如果不加棧信息,只是new自定義異常,加入自己的理解的error message,對於調用端解決問題的幫助不會太多。如果加了棧信息,在頻繁調用出錯的情況下,數據序列化和傳輸的性能損耗也是問題。
我對這種技術規範相當的不以爲然。
首先業務異常本來就需要調用方透傳給最外層,諸如數據不存在
、登錄失效
、用戶鎖定
這種異常,中間的調用方捕獲了也往往沒有什麼用。
其次又是鬼扯性能損耗
,這種低頻的數據序列化和內網傳輸會有什麼樣的性能損耗呢?棧信息透傳給調用方也有益於故障排查,我曾經接到過TC的異常棧信息,根據棧中的package直接就繞過三四層找到了底層出錯的地方,可以說是節省了大量的時間。
結論
在分佈式微服務中,採用異常中斷可以大幅精簡業務代碼,對於性能的影響也微乎其微。
輔助以@NotNull
、@Nullable
等註解,可以讓分佈式開發如風一般的快速便捷。在複雜的服務網絡中,業務異常也可以方便開發人員精確地定位錯誤,避免大家順着調用鏈一層一層地追蹤故障點的尷尬情景。