dubbo超时重试和异常处理
dubbo超時重試和異常處理
?
參考：
https://www.cnblogs.com/ASPNET2008/p/7292472.html
https://www.tuicool.com/articles/YfA3Ub
https://www.cnblogs.com/binyue/p/5380322.html
https://blog.csdn.net/mj158518/article/details/51228649
?
?
dubbo源碼分析：超時原理以及應用場景
本篇主要記錄dubbo中關于超時的常見問題，實現原理，解決的問題以及如何在服務降級中體現作用等。
超時問題
為了檢查對dubbo超時的理解，嘗試回答如下幾個問題，如果回答不上來或者不確定那么說明此處需要再多研究研究。
我只是針對個人的理解提問題，并不代表我理解的就是全面深入的，但我的問題如果也回答不了，那至少說明理解的確是不夠細的。
- 超時是針對消費端還是服務端？
- 超時在哪設置？
- 超時設置的優先級是什么？
- 超時的實現原理是什么？
- 超時解決的是什么問題？
問題解答
RPC場景
本文所有問題均以下圖做為業務場景，一個web api做為前端請求，product service是產品服務，其中調用comment service(評論服務)獲取產品相關評論，comment service從持久層中加載數據。
超時是針對消費端還是服務端？
-
如果是爭對消費端，那么當消費端發起一次請求后，如果在規定時間內未得到服務端的響應則直接返回超時異常，但服務端的代碼依然在執行。
-
如果是爭取服務端，那么當消費端發起一次請求后，一直等待服務端的響應，服務端在方法執行到指定時間后如果未執行完，此時返回一個超時異常給到消費端。
dubbo的超時是爭對客戶端的，由于是一種NIO模式，消費端發起請求后得到一個ResponseFuture，然后消費端一直輪詢這個ResponseFuture直至超時或者收到服務端的返回結果。雖然超時了，但僅僅是消費端不再等待服務端的反饋并不代表此時服務端也停止了執行。
按上圖的業務場景，看看生成的日志：
product service:報超時錯誤，因為comment service 加載數據需要5S，但接口只等1S?。
Caused by: com.alibaba.dubbo.remoting.TimeoutException: Waiting server-side response timeout. start time: 2017-08-05 18:14:52.751, end time: 2017-08-05 18:14:53.764, client elapsed: 6 ms, server elapsed: 1006 ms, timeout: 1000 ms, request: Request [id=0, version=2.0.0, twoway=true, event=false, broken=false, data=RpcInvocation [methodName=getCommentsByProductId, parameterTypes=[class java.lang.Long], arguments=[1], attachments={traceId=6299543007105572864, spanId=6299543007105572864, input=259, path=com.jim.framework.dubbo.core.service.CommentService, interface=com.jim.framework.dubbo.core.service.CommentService, version=0.0.0}]], channel: /192.168.10.222:53204 -> /192.168.10.222:7777at com.alibaba.dubbo.remoting.exchange.support.DefaultFuture.get(DefaultFuture.java:107) ~[dubbo-2.5.3.jar:2.5.3]at com.alibaba.dubbo.remoting.exchange.support.DefaultFuture.get(DefaultFuture.java:84) ~[dubbo-2.5.3.jar:2.5.3]at com.alibaba.dubbo.rpc.protocol.dubbo.DubboInvoker.doInvoke(DubboInvoker.java:96) ~[dubbo-2.5.3.jar:2.5.3]... 42 common frames omittedcomment service : 并沒有異常，而是慢慢悠悠的執行自己的邏輯：
2017-08-05 18:14:52.760 INFO 846 --- [2:7777-thread-5] c.j.f.d.p.service.CommentServiceImpl : getComments start:Sat Aug 05 18:14:52 CST 2017 2017-08-05 18:14:57.760 INFO 846 --- [2:7777-thread-5] c.j.f.d.p.service.CommentServiceImpl : getComments end:Sat Aug 05 18:14:57 CST 2017從日志來看，超時影響的是消費端，與服務端沒有直接關系。
超時在哪設置？
消費端
- 全局控制
- 接口控制
- 方法控制
服務端
- 全局控制
- 接口控制
- 方法控制
可以看到dubbo針對超時做了比較精細化的支持，無論是消費端還是服務端，無論是接口級別還是方法級別都有支持。
超時設置的優先級是什么？
上面有提到dubbo支持多種場景下設置超時時間，也說過超時是針對消費端的。那么既然超時是針對消費端，為什么服務端也可以設置超時呢？
這其實是一種策略，其實服務端的超時配置是消費端的缺省配置，即如果服務端設置了超時，任務消費端可以不設置超時時間，簡化了配置。
另外針對控制的粒度，dubbo支持了接口級別也支持方法級別，可以根據不同的實際情況精確控制每個方法的超時時間。所以最終的優先順序為：客戶端方法級>服務端方法級>客戶端接口級>服務端接口級>客戶端全局>服務端全局
超時的實現原理是什么？
之前有簡單提到過,?dubbo默認采用了netty做為網絡組件，它屬于一種NIO的模式。消費端發起遠程請求后，線程不會阻塞等待服務端的返回，而是馬上得到一個ResponseFuture，消費端通過不斷的輪詢機制判斷結果是否有返回。因為是通過輪詢，輪詢有個需要特別注要的就是避免死循環，所以為了解決這個問題就引入了超時機制，只在一定時間范圍內做輪詢，如果超時時間就返回超時異常。
源碼
ResponseFuture接口定義
public interface ResponseFuture {/*** get result.* * @return result.*/Object get() throws RemotingException;/*** get result with the specified timeout.* * @param timeoutInMillis timeout.* @return result.*/Object get(int timeoutInMillis) throws RemotingException;/*** set callback.* * @param callback*/void setCallback(ResponseCallback callback);/*** check is done.* * @return done or not.*/boolean isDone();}ReponseFuture的實現類：DefaultFuture
只看它的get方法，可以清楚看到輪詢的機制。
public Object get(int timeout) throws RemotingException {if (timeout <= 0) {timeout = Constants.DEFAULT_TIMEOUT;}if (! isDone()) {long start = System.currentTimeMillis();lock.lock();try {while (! isDone()) {done.await(timeout, TimeUnit.MILLISECONDS);if (isDone() || System.currentTimeMillis() - start > timeout) {break;}}} catch (InterruptedException e) {throw new RuntimeException(e);} finally {lock.unlock();}if (! isDone()) {throw new TimeoutException(sent > 0, channel, getTimeoutMessage(false));}}return returnFromResponse();}超時解決的是什么問題？
設置超時主要是解決什么問題？如果沒有超時機制會怎么樣？
回答上面的問題，首先要了解dubbo這類rpc產品的線程模型。下圖是我之前個人RPC學習產品的示例圖，與dubbo的線程模型大致是相同的，有興趣的可參考我的筆記：簡單RPC框架-業務線程池
我們從dubbo的源碼看下這下線程模型是怎么用的：
netty boss
主要是負責socket連接之類的工作。
netty wokers
將一個請求分給后端的某個handle去處理，比如心跳handle?,執行業務請求的 handle等。
Netty Server中可以看到上述兩個線程池是如何初始化的：
首選是open方法，可以看到一個boss一個worker線程池。
protected void doOpen() throws Throwable {NettyHelper.setNettyLoggerFactory();ExecutorService boss = Executors.newCachedThreadPool(new NamedThreadFactory("NettyServerBoss", true));ExecutorService worker = Executors.newCachedThreadPool(new NamedThreadFactory("NettyServerWorker", true));ChannelFactory channelFactory = new NioServerSocketChannelFactory(boss, worker, getUrl().getPositiveParameter(Constants.IO_THREADS_KEY, Constants.DEFAULT_IO_THREADS));bootstrap = new ServerBootstrap(channelFactory);// ...... }再看ChannelFactory的構造函數：
public NioServerSocketChannelFactory(Executor bossExecutor, Executor workerExecutor, int workerCount) {this(bossExecutor, 1, workerExecutor, workerCount);}可以看出，boss線程池的大小為1，worker線程池的大小也是可以配置的，默認大小是當前系統的核心數+1，也稱為IO線程。
busines（業務線程池）
為什么會有業務線程池，這里不多解釋，可以參考我上面的文章。
缺省是采用固定大小的線程池，dubbo提供了三種不同類型的線程池供用戶選擇。我們看看這個類：AllChannelHandler，它是其中一種handle，處理所有請求，它的一個作用就是調用業務線程池去執行業務代碼，其中有獲取線程池的方法：
private ExecutorService getExecutorService() {ExecutorService cexecutor = executor;if (cexecutor == null || cexecutor.isShutdown()) { cexecutor = SHARED_EXECUTOR;}return cexecutor;}上面代碼中的變量executor來自于AllChannelHandler的父類WrappedChannelHandler，看下它的構造函數：
public WrappedChannelHandler(ChannelHandler handler, URL url) {//......executor = (ExecutorService) ExtensionLoader.getExtensionLoader(ThreadPool.class).getAdaptiveExtension().getExecutor(url);//...... }獲取線程池來自于SPI技術,從代碼中可以看出線程池的缺省配置就是上面提到的固定大小線程池。
@SPI("fixed") public interface ThreadPool {/*** 線程池* * @param url 線程參數* @return 線程池*/@Adaptive({Constants.THREADPOOL_KEY})Executor getExecutor(URL url);}最后看下是如何將請求丟給線程池去執行的，在AllChannelHandler中有這樣的方法：
public void received(Channel channel, Object message) throws RemotingException {ExecutorService cexecutor = getExecutorService();try {cexecutor.execute(new ChannelEventRunnable(channel, handler, ChannelState.RECEIVED, message));} catch (Throwable t) {throw new ExecutionException(message, channel, getClass() + " error when process received event .", t);}}典型問題：拒絕服務
如果上面提到的dubbo線程池模型理解了，那么也就容易理解一個問題，當前端大量請求并發出現時，很有可以將業務線程池中的線程消費完，因為默認缺省的線程池是固定大小（我現在版本缺省線程池大小為200），此時會出現服務無法按預期響應的結果，當然由于是固定大小的線程池，當核心線程滿了后也有隊列可排,但默認是不排隊的，需要排隊需要單獨配置，我們可以從線程池的具體實現中看：
public class FixedThreadPool implements ThreadPool {public Executor getExecutor(URL url) {String name = url.getParameter(Constants.THREAD_NAME_KEY, Constants.DEFAULT_THREAD_NAME);int threads = url.getParameter(Constants.THREADS_KEY, Constants.DEFAULT_THREADS);int queues = url.getParameter(Constants.QUEUES_KEY, Constants.DEFAULT_QUEUES);return new ThreadPoolExecutor(threads, threads, 0, TimeUnit.MILLISECONDS, queues == 0 ? new SynchronousQueue<Runnable>() : (queues < 0 ? new LinkedBlockingQueue<Runnable>() : new LinkedBlockingQueue<Runnable>(queues)),new NamedThreadFactory(name, true), new AbortPolicyWithReport(name, url));}}上面代碼的結論是：
- 默認線程池大小為200（不同的dubbo版本可能此值不同）
- 默認線程池不排隊，如果需要排隊，需要指定隊列的大小
當業務線程用完后，服務端會報如下的錯誤：
Caused by: java.util.concurrent.RejectedExecutionException: Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-192.168.10.222:9999, Pool Size: 1 (active: 1, core: 1, max: 1, largest: 1), Task: 8 (completed: 7), Executor status:(isShutdown:false, isTerminated:false, isTerminating:false), in dubbo://192.168.10.222:9999!at com.alibaba.dubbo.common.threadpool.support.AbortPolicyWithReport.rejectedExecution(AbortPolicyWithReport.java:53) ~[dubbo-2.5.3.jar:2.5.3]at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) [na:1.8.0_121]at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369) [na:1.8.0_121]at com.alibaba.dubbo.remoting.transport.dispatcher.all.AllChannelHandler.caught(AllChannelHandler.java:65) ~[dubbo-2.5.3.jar:2.5.3]... 17 common frames omitted通過上面的分析，對調用的服務設置超時時間，是為了避免因為某種原因導致線程被長時間占用，最終出現線程池用完返回拒絕服務的異常。
超時與服務降級
按我們文章之前的場景，web api 請求產品明細時調用product service，為了查詢產品評論product service調用comment service。如果此時由于comment service異常，響應時間增大到10S（遠大于上游服務設置的超時時間），會發生超時異常，進而導致整個獲取產品明細的接口異常，這也就是平常說的強依賴。這類強依賴是超時不能解決的，解決方案一般是兩種：
- 調用comment service時做異常捕獲，返回空值或者返回具體的錯誤碼，消費端根據不同的錯誤碼做不同的處理。
- 調用coment service做服務降級，比如發生異常時返回一個mock的數據,dubbo默認支持mock。
只有通過做異常捕獲或者服務降級才能確保某些不重要的依賴出問題時不影響主服務的穩定性。而超時就可以與服務降級結合起來，當消費端發生超時時自動觸發服務降級， 這樣即使我們的評論服務一直慢，但不影響獲取產品明細的主體功能，只不過會犧牲部分體驗，用戶看到的評論不是真實的，但評論相對是個邊緣功能，相比看不到產品信息要輕的多，某種程度上是可以舍棄的。
?
?
?
Dubbo超時機制導致的雪崩連接
BUG作者：?許曉
Bug?標題：?Dubbo超時機制導致的雪崩連接
Bug?影響：?Dubbo?服務提供者出現無法獲取?Dubbo?服務處理線程異常，后端?DB?爆出拿不到數據庫連接池，導致前端響應時間異常飆高，系統處理能力下降，核心基礎服務無法提供正常服務。
Bug?發現過程：
線 上，對于高并發的服務化接口應用，時常會出現Dubbo連接池爆滿情況，通常，我們理所應當的認為，這是客戶端并發連接過高所致，一方面調整連接池大小， 一方面考慮去增加服務接口的機器，當然也會考慮去優化服務接口的應用。很自然的，當我們在線上壓測一個營銷頁面（為大促服務，具備高并發）時，我們遇到了 這種情況。而通過不斷的深入研究，我發現了一個特別的情況。
場景描述：
壓力從Jmeter壓至前端web應用marketingfront，場景是批量獲取30個產品的信息。wsproductreadserver有一個批量接口，會循環從tair中獲取產品信息，若緩存不存在，則命中db。
壓測后有兩個現象：
1）?Dubbo的服務端爆出大量連接拿不到的異常，還伴隨著無法獲取數據庫連接池的情況
2)?Dubbo Consumer端有大量的Dubbo超時和重試的異常，且重試3次后，均失敗。
3)?Dubbo Consumer端的最大并發時91個
Dubbo Provider端的最大并發卻是600個，而服務端配置的dubbo最大線程數即為600。
這個時候，出于性能測試的警覺性，發現這兩個并發數極為不妥。
按照正常的請求模式，DubboConsumer和DubboProvider展示出來的并發應該是一致的。此處為何會出現服務端的并發數被放大6倍，甚至有可能不止6倍，因為服務端的dubbo連接數限制就是600。
此處開始發揮性能測試各種大膽猜想：
1）是否是因為服務端再dubboServerHandle處理請求時，開啟了多線程，而這塊兒的多線程會累計到Dubbo的連接上，dragoon采集的這個數據可以真實的反應目前應用活動的線程對系統的壓力情況；
2）壓測環境不純潔？我的小伙伴們在偷偷和我一起壓測？（這個被我生生排除了，性能測試基本環境還是要保持獨立性）
3）是否是因為超時所致？這里超時會重試3次，那么順其自然的想，并發有可能最多會被放大到3倍，3*91=273<<600....還是不止3倍？
有了猜想，就得小心求證！
首先通過和dubbo開發人員 【草谷】分析，Dubbo連接數爆滿的原因，猜想1被否決，Dubbo服務端連接池是計數DubboServerHandle個數的業務是否采用多線程無關。
通過在壓測時，Dump provider端的線程數，也證明了這個。
那么，可能還是和超時有很大關系。
再觀察wsproductreadserver接口的處理時間分布情況：
從?RT?的分布來看?。基本上?78.5%?的響應時間是超過?1s?的。那么這個接口方法的?dubbo?超時時間是?500ms?，此時?dubbo?的重試機制會帶來怎樣的?雪崩效應?呢？
如果按照上圖，雖然客戶端只有1個并發在做操作，但是由于服務端執行十分耗時，每個請求的執行RT遠遠超過了超時時間500ms，此時服務端的最大并發會有多少呢?
和服務端處理的響應時間有特比特別大的關系。服務端處理時間變長，但是如果超時，客戶端的阻塞時間卻只有可憐的500ms，超過500ms，新一輪壓力又將發起。
上圖可直接看到的并發是8個，如果服務端RT再長些，那么并發可能還會再大些！
這也是為什么從marketingfront consumer的dragoon監控來看，只有90個并發。但是到服務端，卻導致dubbo連接池爆掉的直接原因。
查看了wsproductreadserver的堆棧，600個dubboServerHandle大部分都在做數據庫的讀取和數據庫連接獲取以及tair的操作。
所以，為什么Dubbo服務端的連接池會爆掉？很有可能就是因為你的服務接口，在高并發下的大部分RT分布已經超過了你的Dubbo設置的超時時間！這將直接導致Dubbo的重試機制會不斷放大你的服務端請求并發。
所 以如果，你在線上曾經遇到過類似場景，您可以采取去除Dubbo的重試機器，并且合理的設置Dubbo的超時時間。目前國際站的服務中心，已經開始去除 Dubbo的重試機制。當然Dubbo的重試機制其實是非常好的QOS保證，它的路由機制，是會幫你把超時的請求路由到其他機器上，而不是本機嘗試，所以 dubbo的重試機器也能一定程度的保證服務的質量。但是請一定要綜合線上的訪問情況，給出綜合的評估。
------------?等等等，別著急，我們似乎又忽略了一些細節，元芳，你怎么看？?------------------------
我們重新回顧剛才的業務流程架構，wsproductReadserver層有DB和tair兩級存儲。那么對于同樣接口為什么服務化的接口RT如此之差，按照前面提到的架構，包含tair緩存，怎么還會有數據庫連接獲取不到的情況？
接續深入追蹤，將問題暴露和開發討論，他們拿出tair
可以看到，客戶端提交批量查詢30個產品的產品信息。在服務端，有一個緩存模塊，緩存的key是產品的ID。當產品命中tair時，則直接返回，若不命中，那么回去db中取數，再放入緩存中。
這里可以發現一個潛在的性能問題：
客 戶端提交30個產品的查詢請求，而服務端，則通過for循環和tair交互，所以這個接口在通常情況下的性能估計也得超過60-100ms。如果不是30 個產品，而是50或者100，那么這個接口的性能將會衰減的非常厲害！（這純屬性能測試的yy，當然這個暫時還不是我們本次關注的主要原因）
那么如此的架構，請求打在db上的可能性是比較小的， 由緩存命中率來保證。從線上真實的監控數據來看，tair的命中率在70%，應該說還不錯，為什么在我們的壓測場景，DB的壓力確是如此兇殘，甚至導致db的連接池無法獲取呢？
所以性能驗證場景就呼之欲出了：
場景：?準備30個產品ID，保持不變，這樣最多只會第一次會去訪問DB，并將數據存入緩存，后面將會直接命中緩存，db就在后面喝喝茶好了！
但是從測試結果來看，有兩點可以觀察到：
1）
2）
3）
于是開始檢查這30個產品到底有哪幾個沒有存入緩存。
通 過開發Debug預發布環境代碼，最終發現，這兩個產品竟然已經被用戶移到垃圾箱了。而通過和李浩和躍波溝通SellerCoponList的業務來 看，DA推送過來的產品是存在被用戶移除的可能性。因而，每次這兩個數據的查詢，由于數據庫查詢不到記錄，tair也沒有存儲相關記錄，導致這些查詢都將 經過數據庫。數據庫壓力原因也找到了。
但是問題還沒有結束，這似乎只像是冰山表面，我們希望能夠鳥瞰整個冰山！
細細品味這個問題的最終性能表象?，?這是一種變向擊穿緩存的做法啊！也就是具備一定的通用性。如果接口始終傳入數據庫和緩存都不可能存在的數據，那么每次的訪問都就落到db上，導致緩存變相擊穿，這個現象很有意思！
目前有一種解決方案，就是Null Object Pattern，將數據庫不存在的記錄也記錄到緩存中，但是value為NULL，使得緩存可以有效的攔截。由于數據的超時時間是10min，所以如果數據有所改動，也可以接受。
我相信這只是一種方案，可能還會有其他方案，但是這種變向的緩存擊穿卻讓我很興奮。回過頭來，如果讓我自己去實現這樣的緩存機制，數據庫和緩存都不存在的 數據場景很容易被忽略，并且這個對于業務確實也不會有影響。在線上存在大量熱點數據情況下，這樣的機制，往往并不會暴露性能問題。巧合的是，特定的場景， 性能卻會出現很大的偏差，這考驗的既是性能測試工程師的功力，也考驗的是架構的功力！
Bug?解決辦法：
其實這過程中不僅僅有一些方法論，也有一些是性能測試經驗的功底，更重要的是產出了一些通用性的性能問題解決方案，以及部分參數和技術方案的設計對系統架構的影響。
1）對于核心的服務中心，去除dubbo超時重試機制，并重新評估設置超時時間。
2）對于存在tair或者其他中間件緩存產品，對NULL數據進行緩存，防止出現緩存的變相擊穿問題
?
?
?
Dubbo超時和重連機制
dubbo啟動時默認有重試機制和超時機制。
超時機制的規則是如果在一定的時間內，provider沒有返回，則認為本次調用失敗，
重試機制在出現調用失敗時，會再次調用。如果在配置的調用次數內都失敗，則認為此次請求異常，拋出異常。
如果出現超時，通常是業務處理太慢，可在服務提供方執行：jstack PID > jstack.log 分析線程都卡在哪個方法調用上，這里就是慢的原因。
如果不能調優性能，請將timeout設大。
某些業務場景下，如果不注意配置超時和重試，可能會引起一些異常。
1.超時設置
DUBBO消費端設置超時時間需要根據業務實際情況來設定，
如果設置的時間太短，一些復雜業務需要很長時間完成，導致在設定的超時時間內無法完成正常的業務處理。
這樣消費端達到超時時間，那么dubbo會進行重試機制，不合理的重試在一些特殊的業務場景下可能會引發很多問題，需要合理設置接口超時時間。
比如發送郵件，可能就會發出多份重復郵件，執行注冊請求時，就會插入多條重復的注冊數據。
（1）合理配置超時和重連的思路
1.對于核心的服務中心，去除dubbo超時重試機制，并重新評估設置超時時間。
2.業務處理代碼必須放在服務端，客戶端只做參數驗證和服務調用，不涉及業務流程處理
（2）Dubbo超時和重連配置示例
| 1 2 | <!-- 服務調用超時設置為5秒,超時不重試-->? <dubbo:service?interface="com.provider.service.DemoService" ref="demoService"? retries="0" timeout="5000"/> |
2.重連機制
dubbo在調用服務不成功時，默認會重試2次。
Dubbo的路由機制，會把超時的請求路由到其他機器上，而不是本機嘗試，所以 dubbo的重試機制也能一定程度的保證服務的質量。
但是如果不合理的配置重試次數，當失敗時會進行重試多次，這樣在某個時間點出現性能問題，調用方再連續重復調用，
系統請求變為正常值的retries倍，系統壓力會大增，容易引起服務雪崩，需要根據業務情況規劃好如何進行異常處理，何時進行重試。
?
?
?
?
?
淺談dubbo的ExceptionFilter異常處理
背景
我們的項目使用了dubbo進行不同系統之間的調用。 每個項目都有一個全局的異常處理，對于業務異常，我們會拋出自定義的業務異常（繼承RuntimeException）。 全局的異常處理會根據不同的異常類型進行不同的處理。 最近我們發現，某個系統調用dubbo請求，provider端（服務提供方）拋出了自定義的業務異常，但consumer端（服務消費方）拿到的并不是自定義的業務異常。 這是為什么呢？還需要從dubbo的ExceptionFilter說起。ExceptionFilter
如果Dubbo的?provider端?拋出異常（Throwable），則會被?provider端?的ExceptionFilter攔截到，執行以下invoke方法： [java]?view plaincopy代碼分析
按邏輯順序進行分析，滿足其中一個即返回，不再繼續執行判斷。邏輯0
[java]?view plaincopy不適用于此場景，不在此處探討。
邏輯1
[java]?view plaincopyprovider端想拋出受檢異常，必須在api上明確寫明拋出受檢異常；consumer端如果要處理受檢異常，也必須使用明確寫明拋出受檢異常的api。
provider端api新增 自定義的 受檢異常， 所有的 consumer端api都必須升級，同時修改代碼，否則無法處理這個特定異常。
consumer端DecodeableRpcResult的decode方法會對異常進行處理
此處會拋出IOException，上層catch后會做toString處理，放到mErrorMsg屬性中： [java]?view plaincopy
DefaultFuture判斷請求返回的結果，最后拋出RemotingException： [java]?view plaincopy
DubboInvoker捕獲RemotingException，拋出RpcException： [java]?view plaincopy
調用棧：
FailOverClusterInvoker.doInvoke -...-> DubboInvoker.doInvoke -> ReferenceCountExchangeClient.request -> HeaderExchangeClient.request -> HeaderExchangeChannel.request -> AbstractPeer.send -> NettyChannel.send -> AbstractChannel.write -> Channels.write --back_to--> DubboInvoker.doInvoke -> DefaultFuture.get -> DefaultFuture.returnFromResponse -> throw new RemotingException 異常示例： [java]?view plaincopy
?
邏輯2
[java]?view plaincopy答案是和上面一樣，拋出RpcException。
因此如果consumer端不care這種異常，則不需要任何處理；
consumer端有這種異常（路徑要完全一致，包名+類名），則不需要任何處理；
沒有這種異常，又想進行處理，則需要引入這個異常進行處理（方法有多種，比如升級api，或引入/升級異常所在的包）。
邏輯3
[java]?view plaincopy邏輯4
[java]?view plaincopy邏輯5
[java]?view plaincopy邏輯6
[java]?view plaincopy核心思想
盡力避免反序列化時失敗（只有在jdk版本或api版本不一致時才可能發生）。如何正確捕獲業務異常
了解了ExceptionFilter，解決上面提到的問題就很簡單了。 有多種方法可以解決這個問題，每種都有優缺點，這里不做詳細分析，僅列出供參考： 1.?將該異常的包名以"java.或者"javax. " 開頭 2.?使用受檢異常（繼承Exception） 3.?不用異常，使用錯誤碼 4.?把異常放到provider-api的jar包中 5.?判斷異常message是否以XxxException.class.getName()開頭（其中XxxException是自定義的業務異常） 6.?provider實現GenericService接口 7.?provider的api明確寫明throws XxxException，發布provider（其中XxxException是自定義的業務異常） 8. 實現dubbo的filter，自定義provider的異常處理邏輯（方法可參考之前的文章給dubbo接口添加白名單——dubbo Filter的使用）?給dubbo接口添加白名單——dubbo Filter的使用具體內容如下：
在開發中，有時候需要限制訪問的權限，白名單就是一種方法。對于Java Web應用，Spring的攔截器可以攔截Web接口的調用；而對于dubbo接口，Spring的攔截器就不管用了。
dubbo提供了Filter擴展，可以通過自定義Filter來實現這個功能。本文通過一個事例來演示如何實現dubbo接口的IP白名單。
?
實現com.alibaba.dubbo.rpc.Filter接口：
[java]?view plaincopy
dubbo自己會對這些bean進行注入，不需要再標注@Resource讓Spring注入，參見擴展點加載
參考：調用攔截擴展
在resources目錄下添加純文本文件META-INF/dubbo/com.alibaba.dubbo.rpc.Filter，內容如下：
[plain]?view plaincopy
[html]?view plaincopy
這樣就可以實現dubbo接口的IP白名單功能了。
?
轉載于:https://www.cnblogs.com/xuwc/p/8974709.html
總結
以上是生活随笔為你收集整理的dubbo超时重试和异常处理的全部內容，希望文章能夠幫你解決所遇到的問題。
