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
