溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
小編給大家分享一下java在微服務架構中異常怎么用，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！
異常的正確使用在微服務架構中的重要性排前三，沒什么意見吧
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 返回給了前端。
在 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'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
這里監控的是記錄異常日志① 的日志
上面 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 的錯誤轉成異常之后主動記錄，但是不對外拋出異常即可。
以上是“java在微服務架構中異常怎么用”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
