服務的路由和負載均衡

公共的業務被拆分出來，形成可共用的服務，最大程度的保證了代碼和邏輯的復用，避免重復建設，這種設計也被成為SOA(Service-Oriented Architecture)
SOA架構中，服務消費者通過服務名稱，在眾多服務中找到要調用的服務的地址列表，成為服務的路由：

而對于負載較高的服務來說，往往對應著由多臺服務器組成的集群。在請求到來時，為了將請求均衡地分配到后端服務器，負載均衡程序將從服務對應的地址列表中，通過相應的負載均衡算法和規則，選取一臺服務器進行訪問，這個過程稱為服務的負載均衡：

當服務的規模較小時，可以采用硬編碼的方式將服務地址和配置寫在代碼中，通過編碼的方式來解決服務的路由和負載均衡問題，也可以通過傳統的硬件負載均衡設備如F5等，或者采用LVS或Nginx等軟件解決方案，通過相關配置，來解決服務的路由和負載均衡問題。由于服務的機器數量在可控范圍內，因為維護成本能夠接受。

當服務越來越多，規模越來越大時，對應的機器數量也越來越龐大。單靠人工來管理和維護服務及地址的配置信息等，已經越來與困難。并且，依賴單一的硬件負載均衡設備或者使用LVS、Nginx等軟件解決方案進行路由和負載均衡調度，單點故障的問題也開始凸顯，一旦服務路由或者負載均衡服務器宕機，依賴它的所有服務均將失效。

此時，需要一個能夠動態注冊和獲取服務信息的地方，來統一管理服務名稱和其對應的服務器列表信息，稱之為服務配置中心。服務提供者在啟動時，將其提供的服務名稱、服務地址注冊到服務配置中心，服務消費者通過服務配置中心來獲得需要調用的服務的機器列表，通過相應的負載均衡算法，選取其中一臺服務器進行調用。當服務器宕機或者下線時，相應的機器需要能夠動態的從服務配置中心里面移除，并通知相應的服務消費者，否則服務消費者就有可能因為調用到已經失效的服務而發生錯誤。在這個過程中，服務消費者只有在第一次調用服務時需要查詢服務配置中心，然后將查詢到的信息緩存到本地，后面的調用直接使用本地緩存的服務地址列表信息，而不需要重新發起請求到服務配置中心去獲取相應的服務地址列表，直到服務的地址列表有變更（機器上線或者下線）。這種無中心化的結構解決了之前負載均衡設備所導致的單點故障問題并且大大減輕了服務配置中心的壓力。
基于Zookeper的持久和非持久節點，我們能夠近乎實時的感知到后端服務器的狀態（上線、下線、宕機）。通過集群間zab協議，使得服務配置信息能夠保持一致。而Zookeeper本身容錯特性和leader選舉機制，能保障我們方便的進行擴容。通過Zookeeper來實現服務動態注冊、機器上線與下線的動態感知、擴容方便、容錯性好，且無中心化結構能夠解決之前使用負載均衡設備所帶來的單點故障問題，只有當配置信息更新時才會去Zookeeper上獲取最新的服務地址列表，其他時候使用本地緩存即可。

負載均衡算法

服務消費者從服務配置中心獲取到服務的地址列表后,需要選擇其中一臺來發起RPC調用。如何選擇，則取決于具體的負載均衡算法，對應于不同的場景，選擇負載均衡算法也不盡相同。

• 輪詢法(Round Robin)
  將請求按順序輪流的分配到后端服務器上，它均衡的對待后端每一臺服務器，而不關心服務器實際的連接數和當前的系統負載
• 隨機法
  通過系統隨機函數，根據后端服務器列表大小值來隨機選取其中一臺進行訪問。
• 源地址哈希（Hash）法
  獲取客戶端訪問的IP地址值，通過哈希函數計算得到一個數值，用該數值對服務器列表的大小進行取摩運算，得到的結果便是要訪問的服務器的序號。采用哈希發進行負載均衡，同一IP地址的客戶端，當后端服務器列表不變時，它每次都會被映射到同一臺后端服務器進行訪問。
• 加權輪詢法（Weight Round Robin）
  不同的后端服務器可能機器的配置和當前系統的負載并不相同，因為他們的抗壓能力也不盡相同。給配置高、負載低的機器配置更高的權重，讓其處理更多的請求，而低配置、負載高的機器，則給其分配較低的權重，降低其系統負載。加權輪詢能吹該問題并將請求順序且按照權重分配到后端。
  注意：目前的代碼實現是如果某機器A權重配的比較高，則serverlist中該機器A會按照權重被加入多次，即serverlist中有多個A，則按照輪詢法則會處理更多請求.
• 加權隨機法(Weight Random) 與加權輪詢法類似，加權隨機法也根據后端服務器不同的配置和負載情況，配置不同的權重、不同的是，它是按照權重來隨機選取服務器的，而非順序。
• 最小連接數法（Least Connections） 根據后端服務器當前的連接情況，動態的選取其中當前積壓連接數最少的一臺服務器來處理當前請求，盡可能的提高后端服務器的利用效率，將負載合理的分流到每一臺機器。

路由和負載均衡的實現

服務配置中心節點樹分成三層結構，最上面一層為根節點，用來聚集服務節點，通過它可以查詢到所有的服務，而服務名稱節點掛載的是服務提供者的服務器地址，服務消費者通過負載均衡算法選擇其中一個地址發起遠程調用。根節點和服務名稱采用的是ZoooKeeper的持久節點，也就是persistent節點，而服務提供者的地址節點則采用非持久節點，即ephemeral節點，一旦服務器宕機或者下線，節點也就隨之消失。

Http網關

gateway接收外部各種app的http請求，完成相應的權限與安全校驗。當校驗通過后，根據傳入的服務名稱，到服務配置中心找到相應的服務名稱節點，并加載對應服務提供者的地址列表，通過前面提到的負載均衡算法，選取機器發起遠程調用，將客戶端參數傳遞到后端服務端。服務提供方根據所傳入的參數，給出正確的響應，當gateway接收到響應后，再將響應輸出給客戶端APP.
對于外部的APP來說，它依賴gateway進行服務的路由以及請求的轉發，gateway是整個網絡的核心節點，一旦gateway失效，所有依賴它的外部app都將無法使用且流量之大。所以考慮到系統流量的監控和容量規劃以及gateway集群的可擴展性，以便在流量達到極限之前，能夠快速的方便的進行系統擴容。

一組對等的服務器組成網關集群，接收外部APP的http請求，當流量水位達到警戒值時，能夠較為方便的增加機器進行擴容。網關的前面有兩臺負載均衡設備，負載對網關集群進行負載均衡，負載均衡設備之間進行心跳檢測，一旦其中一臺進行宕機，另一臺則變更自己的地址，接管宕機的這臺設備的流量。平時兩臺機器均對外提供服務。

分布式系統基礎措施

• 分布式協作及配置管理系統ZooKeeper
• 分布式緩存系統
• 持久化存儲
• 分布式消息系統
• 搜索引擎
• CDN系統
• 負載均衡系統
• 運維自動化系統
• 實時計算系統
• 離線計算系統
• 分布式文件系統
• 日志收集系統
• 監控系統
• 數據倉庫