注：文章中的坑出現在2.5.4版本之前，這個坑在2.5.4版本已經得到修復。
一、問題描述
問題描述
場景描述，如上圖所示：
客戶端 遠程異步調用 服務A ， 服務A 在處理客戶端請求的過程中需要遠程同步調用 服務B ，服務A 從 服務B 的響應中取數據時，得到的是 null
!!!
二、原因分析
RPC請求響應參數傳遞過程
2.1 Client的請求發送過程
1）Client在發起RPC調用請求前，將請求參數構建成 RpcInvocation ;
2）Client在發起RPC調用請求前，會經過Filter處理：
ConsumerContextFilter會將請求信息，如invoker、invocation、Address等，寫入RpcContext；
@Activate(group = Constants.CONSUMER, order = -10000)public class ConsumerContextFilter implements Filter { public Result invoke(Invoker> invoker, Invocation invocation) throws RpcException { RpcContext.getContext() .setInvoker(invoker) .setInvocation(invocation) .setLocalAddress(NetUtils.getLocalHost(), 0) .setRemoteAddress(invoker.getUrl().getHost(),invoker.getUrl().getPort()); if (invocation instanceof RpcInvocation) {((RpcInvocation) invocation).setInvoker(invoker);} try { return invoker.invoke(invocation);} finally { RpcContext.getContext().clearAttachments();}}}3）Client在發起RPC調用請求前，會經過AbstractInvoker：
AbstractInvoker會將RpcContext中的attachments內容寫入到RpcInvocation，以實現附加參數的傳遞；
Mapcontext = RpcContext.getContext().getAttachments(); if (context != null) {invocation.addAttachmentsIfAbsent(context);}
AbstractInvoker會從RPC請求參數URL中ASYNC_KEY的值，並設置到RpcInvocation的attachment中；
if (getUrl().getMethodParameter(invocation.getMethodName(), Constants.ASYNC_KEY, false)) { invocation.setAttachment(Constants.ASYNC_KEY, Boolean.TRUE.toString());}4）Client在發起RPC調用請求時，會經過DubboInvoker：
DubboInvoker會優先從
RpcInvocation的attachment中獲取並判斷ASYNC_KEY是否為true，以實現消費端的異步調用；
public static boolean isAsync(URL url, Invocation inv) { boolean isAsync; //如果Java代碼中設置優先.if (Boolean.TRUE.toString().equals(inv.getAttachment(Constants.ASYNC_KEY))) {isAsync = true;} else {isAsync = url.getMethodParameter(getMethodName(inv), Constants.ASYNC_KEY, false);} return isAsync;}5）Client在發起RPC調用請求時，會將 RpcInvocation 作為調用參數傳遞給服務提供方：
RpcInvocation中的擴展屬性attachments，實現了請求調用擴展信息傳遞的功能；
2.2 服務A的請求接收和執行過程
1）服務端在接收到RPC請求，調用真正實現接口前，會經過 ContextFilter 。
ContextFilter會將請求信息，如invoker、invocation、Address等，寫入RpcContext；ContextFilter會將請求參數RpcInvocation的attachments擴展信息取出，過濾掉某些特定KEY之後，將其餘擴展屬性設置到當前RpcContext的attachments中；
Mapattachments = invocation.getAttachments(); if (attachments != null) {attachments = new HashMap (attachments);attachments.remove(Constants.PATH_KEY);attachments.remove(Constants.GROUP_KEY);attachments.remove(Constants.VERSION_KEY);attachments.remove(Constants.DUBBO_VERSION_KEY);attachments.remove(Constants.TOKEN_KEY);attachments.remove(Constants.TIMEOUT_KEY);attachments.remove(Constants.ASYNC_KEY);//清空消費端的異步參數，2.5.4版本才新加進去的}RpcContext.getContext().setInvoker(invoker).setInvocation(invocation).setAttachments(attachments).setLocalAddress(invoker.getUrl().getHost(),invoker.getUrl().getPort());
其中 attachments.remove(Constants.ASYNC_KEY);//清空消費端的異步參數 這行代碼是在dubbo的2.5.4版本才加進去的，也就是之前的版本中並沒有這行代碼。
2）在2.5.4版本之前，對於 Client 發來的異步調用請求，其 RpcInvocation 參數中包含了 ASYNC=true 的 attachment 擴展信息：
此時
ASYNC=true的這個擴展信息就會被設置到服務A的RpcContext的擴展屬性中；在
服務A處理RPC調用，執行實際接口實現類的邏輯時，因為依賴的服務B，所以會繼續發送RPC調用請求給服務B；服務A調用服務B時，服務A的RpcContext的擴展屬性會被寫入到A -> B的RpcInvocation參數中，這就導致 ASYNC=true 的擴展屬性參數被誤傳到A -> B的RpcInvocation參數中，進而導致在服務A發起RPC請求調用時觸發了錯誤的異步調用邏輯；此時
服務A獲取到的RPC執行結果RpcResult的內容當然是個空；
else if (isAsync) { //1. 異步,有返回值ResponseFuture future = currentClient.request(inv, timeout);RpcContext.getContext().setFuture(new FutureAdapter 以上就是這個坑的產生原因
三、解決方法
自己寫了個Filter，添加到Dubbo服務提供方接收請求後、實際處理請求前的Filter執行鏈中。
從請求參數 URL 中解析出 ASYNC 擴展參數標識，而不依賴 RpcInvocation 中的值。
@Activate(group = {Constants.PROVIDER}, order = -999)public class DubboSyncFilter implements Filter { @Overridepublic Result invoke(Invoker> invoker, Invocation invocation) throws RpcException { //避免RpcContext透傳,使用配置文件的asyncboolean isAsync = invoker.getUrl().getMethodParameter(invocation.getMethodName(), Constants.ASYNC_KEY, false);RpcContext.getContext().setAttachment(Constants.ASYNC_KEY, String.valueOf(isAsync)); return invoker.invoke(invocation);}}
閱讀更多 菜根譚 的文章
