Soul原始碼中dubbo和sofa的執行程序
Soul原始碼中dubbo的執行程序
- 首先在 soul-examples-apache-dubbo-service 中依賴的soul-client中ApacheDubboServiceBeanPostProcessor對注解SoulDubboClient了向soul-admin中的 http://localhost:9095/soul-client/dubbo-register 進行了注冊,而此處我們注意到ApacheDubboServiceBeanPostProcessor并不是實作的BeanPostProcessor介面而是實作的ApplicationListener
即Spring背景關系重繪的事件 - 在該對應的介面中執行的是與前文相同的利用Spring的事件處理機制進行的資料同步操作,將資料同步到了網關soul-bootstrap,這一部分,可參考zookeeper的資料同步機制進行了解
- 緊接著是在客戶端發起對dubbo介面的請求的代理時,soul是如何處理的,處理的邏輯主要是

通過泛化呼叫,呼叫的實際上是zk內的某個service然后異步獲取結果,將結果,封裝到具體的欄位中,然后回傳給前端
整個程序中對于介面的快取的處理與http的請求基本相同,從這里就可以看出soul的設計的情況非常好
Soul原始碼中Sofa專案的執行程序
- 同樣的,第一步還是通過掃描注解通過依賴的soul-client中SofaServiceBeanPostProcessor對注解SoulDubboClient了向soul-admin中的 http://localhost:9095//soul-client/sofa-register 進行了注冊/soul-client/sofa-register,而這個類中使用的并不是與dubbo相同的事件處理器介面,而是與http請求相同的實作了BeanPostProcessor的介面對注解和引數等進行的處理,這是一個需要考慮的點,目前我還不是太清楚,后續需要再深入了解,
- 隨后的流程與Http和dubbo的流程基本相同,即在該對應的介面中執行的是與前文相同的利用Spring的事件處理機制進行的資料同步操作,將選擇器規則資料同步到了網關soul-bootstrap,這一部分幾乎所有插件都一樣,
- 后面同樣的是和dubbo相同的泛化呼叫的程序,不同的是dubbo的泛化呼叫是異步的呼叫,而sofa的泛化呼叫是異步的呼叫,從這一點上來說,在soul中使用dubbo或許性能更好,
genericService.$invoke(metaData.getMethodName(), pair.getLeft(), pair.getRight());
return Mono.fromFuture(future.thenApply(ret -> {
if (Objects.isNull(ret)) {
ret = Constants.SOFA_RPC_RESULT_EMPTY;
}
exchange.getAttributes().put(Constants.SOFA_RPC_RESULT, ret);
exchange.getAttributes().put(Constants.CLIENT_RESPONSE_RESULT_TYPE, ResultEnum.SUCCESS.getName());
return ret;
})).onErrorMap(SoulException::new);
關于ApacheDubboServiceBeanPostProcessor并不是實作的BeanPostProcessor介面而是實作的ApplicationListener 的問題
在類中的onApplicationEvent中有對應issue中有對應的https://github.com/dromara/soul/issues/415答疑,主要是上傳的順序跟dubbo暴露的順序問題導致的,使用beanPostProcessor可能導致no provider的情況,
歡迎搜索關注本人與朋友共同開發的微信面經小程式【大廠面試助手】和公眾號【微瞰技術】,以及總結的分類面試題https://github.com/zhendiao/JavaInterview


轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/253411.html
標籤:其他
上一篇:網路編程-I/O復用
下一篇:Java學習筆記(9):圖形介面
