為什麼要使用Dubbo

一般專案初期的單應用架構如下：

隨著使用者量的增多，可以增加應用伺服器進行負載，短期內可以產生非常大的成效，但是長期來看投入產出比會逐漸的下降。這時候會對服務進行拆分。

各種業務層、服務層之間的呼叫一定是通過某種遠端RPC技術進行呼叫。這時候就涉及到以下幾個問題：

1.地址維護（當服務越來越多時，服務 URL 配置管理變得非常困難）；

2.負載均衡（當服務越來越多時，F5 硬體負載均衡器的單點壓力也越來越大）；

3.限流/容錯/降級；

4.鏈路監控；

如果我們使用比如WebService或者簡單的使用Http進行呼叫是沒有辦法解決這幾個問題的。因為這些技術只能實現一個遠端的呼叫，但是在大規模服務化後很多問題都無法解決。Dubbo就是其中一種解決方案。

1.關於地址服務，這時候需要一個服務註冊中心，動態的註冊和發現服務，使服務的位置透明；

2. 通過在消費方獲取服務提供方地址列表，實現軟負載均衡和 Failover，降低對 F5 硬體負載均衡器的依賴，也能減少部分成本。 

3.當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪個應用要在哪個應用之前啟動，架構師都不能完整的描述應用的架構關係。 這時需要自動畫出應用間的依賴關係圖，以幫助架構師理清理關係。 

4.服務的呼叫量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什麼時候該加機器？ 

為了解決這些問題，第一步，要將服務現在每天的呼叫量，響應時間，都統計出來，作為容量規劃的參考指標。 其次，要可以動態調整權重，在線上，將某臺機器的權重一直加大，並在加大的過程中記錄響應時間的變化，直到響應時間到達閥值，記錄此時的訪問量，再以此訪問量乘以機器數反推總容量。