消息隊列中間件是分散式系統中重要的組件，主要解決應用耦合，非同步消息，削峰填谷等問題。實現高性能、高可用、可伸縮和最終一致性架構。 ...
背景說明
- HSF是閉源的，考慮用開源產品（dubbo）進行替代。
- 如果是考慮要從一個rpc框架轉成另一個，或許也可以參考本文。
- 主要思想：進行rpc的發佈、訂閱操作，其實是集中在2個類裡面（provider/consumer），而不是散落在每個實現類裡面。而替換成其它rpc時候，就是針對父類（providerFather/consumerFather）進行適配即可。
架構對比
可行性分析
- HSF、dubbo都出自阿裡（只不過後來dubbo開源了，捐給了apache）。它們的開發設計團隊好像是不同的，但它們設計思想很類似；
- 這2種rpc都是基於spring的吧？（意思它們沒有依賴springboot，或者其它什麼東西）；
- 這2種方式都是通過發佈訂閱來實現rpc的，都可以使用xml配置，api調用方式。（dubbo還有註解方式，hsf好像沒有）
源項目(hsf)說明
- 1，本地使用，是用alitomcat+pandora的方式。
- 2，具體版本是：taobao-tomcat-7.0.59、edas-lightweight-server-1.0.0、pandora不記得是哪個版本了，反正不是最新的。（感覺pandora跟alitomcat有對應關係，不然會註冊不到註冊中心）
- 3，代碼中自定義了註解，集中處理provider、consumer，會把provider註冊到註冊中心，把consumer緩存到map，調用的時候通過getObject的方式，創建代理對象獲取遠程結果。整體來講，用到了繼承+切麵，這些思想，通過少量侵入，實現了rpc調用。
具體實操
- 1，引入包。需要引入dubbo的包，還有dubbo連edas的包。具體就不列舉了，如果註冊中心是其它，需要對應引入其它包；
- 2，通過適配的方式，寫關於dubbo的provider/consumer初始化類。
- 3，處理一些異常問題。
中間遇到的一些問題
- 1，dubbo，provider、consumer都需要設置應用名稱。如果一個同時啟provider、consumer會有點問題，可以用代碼解決；
- 2，註冊到註冊中心(edas)時候，如果長度過長，超過2048，會註冊不進去。這個應該可以通過調整pandora版本解決（具體看pandora 容器版本說明），也可以換註冊中心解決；
- 3，dubbo遠程調用返回對象時，對象需要可序列號，這個可以通過改代碼解決。
