最近在根據公司所學到的知識將大學寫的一個項目改成分佈式SOA架構，分佈式SOA架構的思想前面帖子寫過了，就是將一個項目拆分成很多的服務，並互相調用構成我們項目，但是自己開始有個疑問，我們起了很多服務，我們直接通過url（http請求json數據）去請求另一個服務服務器上方法不就好了？簡單易懂。像下面這種樣子
這樣感覺也可以實現項目拆分，也能遠程調用啊。自己想的是，服務端我們遠程調用的代碼需要我們自己編寫，會很不方便。所以就有了框架。光憑這個原因感覺還是不夠能說服自己。所以上網查了一些資料。我上面說的存在下面這些問題：大規模服務化之前，應用可能只是通過RMI或Hessian等工具，簡單的暴露和引用遠程服務，通過配置服務的URL地址進行調用，通過F5等硬件進行負載均衡。
(1) 當服務越來越多時，服務URL配置管理變得非常困難，F5硬件負載均衡器的單點壓力也越來越大。此時需要一個服務註冊中心，動態的註冊和發現服務，使服務的位置透明。並通過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover，降低對F5硬件負載均衡器的依賴，也能減少部分成本。
(2) 當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪個應用要在哪個應用之前啓動，架構師都不能完整的描述應用的架構關係。這時，需要自動畫出應用間的依賴關係圖，以幫助架構師理清理關係。
(3) 接着，服務的調用量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什麼時候該加機器？爲了解決這些問題，第一步，要將服務現在每天的調用量，響應時間，都統計出來，作爲容量規劃的參考指標。其次，要可以動態調整權重，在線上，將某臺機器的權重一直加大，並在加大的過程中記錄響應時間的變化，直到響應時間到達閥值，記錄此時的訪問量，再以此訪問量乘以機器數反推總容量。
我的理解是問題主要歸結於路由管理，以及負載方面均衡與管理，下面看看dubbo是怎麼做的。
節點角色說明：
Provider: 暴露服務的服務提供方。
Consumer: 調用遠程服務的服務消費方。
Registry: 服務註冊與發現的註冊中心。
Monitor: 統計服務的調用次調和調用時間的監控中心。
Container: 服務運行容器。
調用關係說明：
0. 服務容器負責啓動，加載，運行服務提供者。
1. 服務提供者在啓動時，向註冊中心註冊自己提供的服務。
2. 服務消費者在啓動時，向註冊中心訂閱自己所需的服務。
3. 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
4. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
5. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。
上面挺好理解的，dubbo就類似與一個服務之間的一個遠程調用+協調者的感覺，服務的一些路由信息dubbo無法保存，他是通過註冊到zookeeper來保存。