分布式01-Dubbo基礎

?1-分布式基礎理論

分布式系統是由一組通過網絡進行通信、為了完成共同的任務而協調工作的計算機節點組成的系統。分布式系統的出現是為了用廉價的、普通的機器完成單個計算機無法完成的計算、存儲任務。其目的是利用更多的機器，處理更多的數據。

首先需要明確的是，只有當單個節點的處理能力無法滿足日益增長的計算、存儲任務的時候，且硬件的提升（加內存、加磁盤、使用更好的CPU）高昂到得不償失的時候，應用程序也不能進一步優化的時候，我們才需要考慮分布式系統。因為，分布式系統要解決的問題本身就是和單機系統一樣的，而由于分布式系統多節點、通過網絡通信的拓撲結構，會引入很多單機系統沒有的問題，為了解決這些問題又會引入更多的機制、協議，帶來更多的問題。。。

分布式系統怎么將任務分發到這些計算機節點呢，很簡單的思想，分而治之，即分片（partition）。對于計算，那么就是對計算任務進行切換，每個節點算一些，最終匯總就行了，這就是MapReduce的思想；對于存儲，更好理解一下，每個節點存一部分數據就行了。當數據規模變大的時候，Partition是唯一的選擇，同時也會帶來一些好處：

• 提升性能和并發，操作被分發到不同的分片，相互獨立
• 系統的可用性，即使部分分片不能用，其他分片不會受到影響

　2-Dubbo架構演變　

　　發展演變

?

?

?

?

?3-Dubbo需求?

在大規模服務化之前，應用可能只是通過 RMI 或 Hessian 等工具，簡單的暴露和引用遠程服務，通過配置服務的URL地址進行調用，通過 F5 等硬件進行負載均衡。

當服務越來越多時，服務 URL 配置管理變得非常困難，F5 硬件負載均衡器的單點壓力也越來越大。?此時需要一個服務注冊中心，動態的注冊和發現服務，使服務的位置透明。并通過在消費方獲取服務提供方地址列表，實現軟負載均衡和 Failover，降低對 F5 硬件負載均衡器的依賴，也能減少部分成本。

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

接著，服務的調用量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什么時候該加機器？?為了解決這些問題，第一步，要將服務現在每天的調用量，響應時間，都統計出來，作為容量規劃的參考指標。其次，要可以動態調整權重，在線上，將某臺機器的權重一直加大，并在加大的過程中記錄響應時間的變化，直到響應時間到達閾值，記錄此時的訪問量，再以此訪問量乘以機器數反推總容量。

?4-Dubbo架構

?

　　調用關系說明

• 0-服務容器負責啟動，加載，運行服務提供者。
• 1-服務提供者在啟動時，向注冊中心注冊自己提供的服務。
• 2-服務消費者在啟動時，向注冊中心訂閱自己所需的服務。
• 3-注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變更數據給消費者。
• 4-服務消費者，從提供者地址列表中，基于軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
• 5-服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

?

參考文獻

1-https://www.cnblogs.com/xybaby/p/7787034.html

2-http://dubbo.apache.org/zh-cn/docs/user/preface/background.html

轉載于:https://www.cnblogs.com/wobuchifanqie/p/10359056.html

總結

以上是生活随笔為你收集整理的分布式01-Dubbo基础背景的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。