問題現象
10-26上午，收到同事反饋，線上庫存執行業務不合法。
庫存業務執行時，有時會反饋頂業數據或組織數據不合法。而實際數據是合法的。
問題排查過程
收到問題時，正在外地。
查看了同事發過來的異常請求的軌跡日誌，發現庫存業務執行時進行頂業或組織數據校驗時，調用另外一個應用用戶中心進行數據校驗時，該應用返回null，導致校驗不通過。反饋後轉另外一個應用同事處理。(認爲是另一個模塊問題，未再關注)
下午4：30左右，收到電話，上午的問題還在(꒦_꒦)，用戶中心有數據返回，且下午做業務時，數據不合法基本上是必現了。查看了線上的日誌。自己發請求(dubbo)，請求用戶中心的頂業校驗服務，數據返回正常。
dubbo consumer數據解析異常了？ 用arthas跟蹤了一下庫存業務調用用戶服務的代碼，發現確實沒有返回數據。這個模塊最近也沒有修改過，why？
由於故障時間較長，下午基本是必現，影響到現場的作業。而昨天晚上做了一次系統發佈。把庫存所屬應用做了一次版本回滾。
回滾後現場反饋作業正常，沒有出現錯誤。
自身查了下代碼，驗證測試環境服務，未重現異常。現場作業完成後，晚上又重新把昨天發佈的版本發佈到線上。模擬現場做業務驗證，未重現異常，一切ok。
why？ 這下有點困惑了。
晚上重新分析了出錯的請求日誌和正常的請求日誌，發現了一個關鍵點。調用用戶中心服務返回null時，dubbo服務是異步調用執行的。查看了其他幾次出錯了，均是異步調用返回了null，導致校驗不通過。
查看了今天庫存所屬應用對外發出的dubbo請求，上午異步、同步均有，下午有大量的異步請求，同步很少。這個和反饋的異常現象相吻合，由於異步導致了校驗不通過。
但爲什麼會變成異步調用。dubbo consumer裏面配置的是同步的。誰會來修改這個配置
27號上午現場又反饋昨天的問題重現了。分析了第一次異步調用的請求，是商品導入業務，去異步請求搜索中心接口。之後出現了頂業、組織、XX數據請求異步執行。搜索中心接口是異步執行的，但爲什麼其他同步接口會異步化。同事(xc，一起在排查)發了篇blog給我“Dubbo異步方法調用裏有個坑”(https://blog.csdn.net/windrui/article/details/52150345)。看了下里面的問題現象、原因、解決方案，問題現象很像。看了下我們自身實現的dubbo provider過濾器，
Rpc上下文設置的時候，移除了了異步標識(上面blog中的解決方案)，但後面又把invocation的附屬參數信息設置進去了。debug調試的時候，看到裏面有async:true的信息。
dubbo服務請求會從RPC上下文參數中取信息。而我們的服務，絕大部分都是默認的同步調用，沒有顯示設置 async:false，後續這個線程發起dubb服務調用時，會取到該線程RpcContext中的 async:true參數，故會變爲異步調用。
Map<String, String> context = RpcContext.getContext().getAttachments();
if (context != null) {
invocation.addAttachmentsIfAbsent(context);
}
這裏會把當前RpcContext中的attachments添加到調用ServiceB的RpcInvocation中，這時候async=true已經添加了，接着執行如下代碼段，
if (getUrl().getMethodParameter(invocation.getMethodName(), Constants.ASYNC_KEY, false)){
invocation.setAttachment(Constants.ASYNC_KEY, Boolean.TRUE.toString());
}
上述代碼修復後，問題解決，作業正常，後續未收到該問題反饋。
附屬信息
我們使用的dubbo版本： 2.8.4
參考資料
dubbo異步方法調用裏有個坑(https://blog.csdn.net/windrui/article/details/52150345)