綜述
軟負載是分佈式系統中極爲普遍的技術之一。在分佈式環境中，爲了保證高可用性，通常同一個應用或同一個服務的提供方都會部署多份，以達到對等服務。而軟負載就像一個引路人，幫助服務的消費者在這些對等的服務中合理地選擇一個來執行相關的業務邏輯。
1.1、ConfigServer
ConfigServer主要提供非持久配置的發佈和訂閱。07/08年間在淘寶內部開發使用的時候，由於ZooKeeper還沒有開源，不然可能會基於ZooKeeper來進行改造。主要使用場景是爲分佈式服務框架提供軟負載功能所必須的服務地址列表。
結合淘寶業務場景的發展，與ZooKeeper相比主要有以下一些特點：
- ConfigServer基於無Master架構ConfigServer是無中心化的架構，不存在單點問題，通過特定的算法進行數據增量同步。
- ConfigServer支持數據的自動聚合配置數據的聚合功能是ConfigServer結合淘寶的使用場景開發的特殊功能，主要使用場景：集羣服務地址發現。每臺機器向ConfigServer註冊自己的服務元信息，ConfigServer會根據服務名和分組自動聚合所有元數據，提供給服務訂閱方使用。
- ConfigServer是推數據的模型ConfigServer的服務端與客戶端是基於長連接的方式進行通信，在客戶端訂閱關係確定後，配置信息一旦發生變化，會主動推送配置數據到客戶端，並回調客戶端的業務監聽器。
- ConfigServer客戶端本地容災ConfigServer客戶端在收到配置數據時，會記錄到本地容災文件中。在ConfigServer服務端不可用的時候，應用繼續使用內存中數據；即使應用這時候重啓，ConfigServer的客戶端使用本地容災文件進行離線啓動。
1.2、ConfigServer雙11準備與優化
面對雙11巨大的網站請求，對ConfigServer的數據推送環節考驗尤其巨大，如何穩定、高效且正確的完成數據推送任務，成爲雙11前夕困擾ConfigServer團隊最大的問題。在平時的正常運行中，ConfigServer管理的配置數據和訂閱者數量已經達到一定量級，服務端的一次重啓可能會引起大量的數據推送。舉例來說：交易的某個服務有2000臺，每個服務發佈者信息200B，訂閱者5000個，那麼這個交易服務可用地址列表有變動，會產生2GB(2000*200B*5000)的數據推送。交易的應用有很多個服務，如果應用發佈或者重啓，會瞬間產生巨大的流量將ConfigServer服務端的網卡壓滿。當網卡壓滿後：保持長連接的心跳檢測包會超時，導致與客戶端的連接會持續在一個不穩定的狀態，集羣間數據同步也會受影響。
針對這個問題， ConfigServer在推送數據上做了兩個方面的優化：
- 流量控制加入出口流量統計和監控，通過嚴格限制出口流量預留出足夠的帶寬給維持心跳和集羣數據同步。這樣即使有數據堆積，只會暫時的影響到數據推送，客戶端的連接不會頻繁的斷開，集羣之間的同步也不會受到影響。
- 減少推送量出於兩方面考慮：壓縮數據對代碼的侵入不大；ConfigServer服務端CPU相對空閒，最終我們採用壓縮數據的方式來減小數據包。我們經過對比主流的壓縮算法（huffman，defalte，BZip2，LZMA）對真實推送數據的壓縮測試，最終選擇defalte算法。該功能上線後的檢測結果顯示1500M的推送數據最終推送大小爲170M。效果很明顯。
1.3、Diamond
Diamond主要提供持久配置的發佈和訂閱服務，最大特點是結構簡單，穩定可靠。Diamond的主要使用場景是用來進行動態數據庫切換與擴容，進行一些業務系統運行時開關配置的推送。Diamond產品專注於高可用性，基於此在架構、容災機制、數據獲取模型上有一些與同類產品的不同之處。
Diamond結構非常簡單，也屬於是無單點的架構模型，如圖1-1所示。
圖1-1-Diamond架構模型
發佈或者更新配置數據時，步驟如下：
- 寫入MySql數據庫
- 寫本地磁盤
- 通知集羣其他機器去數據庫dump更新的數據
訂閱方獲取配置數據時，直接讀取服務端本地磁盤文件，儘量減少對數據庫壓力。
這種架構用短暫的延時換取最大的性能和一致性，一些配置不能接受延時的情況下，通過API可以獲取數據庫中的最新配置。
容災機制
Diamond作爲一個分佈式環境下的持久配置系統，有一套完備的容災機制，數據存儲在：數據庫、服務端磁盤、客戶端緩存目錄以及可以手工干預的容災目錄。客戶端通過API獲取配置數據按照固定的順序去不同的數據源獲取數據：容災目錄->服務端磁盤->客戶端緩存。因此，面對如下情況，Diamond均能很好的應對：
- 數據庫主庫不可用，可以切換到備庫，Diamond繼續提供服務
- 數據庫主備庫全部不可用，Diamond通過本地緩存可以繼續提供讀服務
- 數據庫主備庫全部不可用，Diamond服務端全部不可用，Diamond客戶端使用緩存目錄繼續運行，支持離線啓動
- 數據庫主備庫全部不可用，Diamond服務端全部不可用，Diamond客戶端緩存數據被刪，可以通過拷貝備份的緩存目錄到容災目錄下繼續使用
綜上所述，只有在同時碰到如下四個條件的情況下，客戶端應用才無法啓動： 數據庫主備庫全部不可用、Diamond服務端全部不可用、Diamond客戶端緩存被清空、客戶端沒有備份的緩存文件。
1.4、Diamond雙11準備與優化
長輪詢改造
客戶端採用推拉結合的策略在長連接和短連接之間取得一個平衡，讓服務端不用太關注連接的管理，又可以獲得長連接的及時性。
- 客戶端發起一個對比請求到服務端，請求中包含客戶端訂閱的數據的指紋
- 服務端檢查客戶端的指紋是否與最新數據匹配
- 如果匹配，服務端持有連接
- 如果30秒內沒有相關數據變化，服務端持有連接30秒後釋放
- 如果30秒內有相關數據變化，服務端立即返回變化數據的ID
- 如果不匹配，立即返回變化數據的ID
- 客戶端根據變化數據的ID去服務端獲取最新的內容
Diamond通過這種多重容災機制以及推拉結合的方式，讓客戶端邏輯儘量簡單，而且高效穩定，使其成爲名副其實的“鑽石”。
小結
軟負載系統引導着分佈式請求的來龍去脈，管理着分佈式離散數據的聚合與分發，成爲了合理且最大化使用分佈式系統資源的保證。在2013年的雙11購物狂歡節中，面對巨大的消費者請求，ConfigServer集羣共10臺機器，支撐近60,000長連接，發佈配置總量700,000條，訂閱配置總量3,000,000條，數據推送峯值600MB/S。Diamond集羣共48臺，90,000條非聚合配置，380,000條聚合配置，TPS高峯期間達到18000，數據變更15000次，客戶端感知最大延時小於2秒。雙十一當天部分數據庫做了切換，用戶完全沒有感知。
系列文章：
《中間件技術及雙十一實踐之中間件總體介紹》http://jm-blog.aliapp.com/?p=3359
《中間件技術及雙十一實踐之軟負載篇》http://jm-blog.aliapp.com/?p=3450
《中間件技術及雙十一實踐·服務框架篇》http://jm-blog.aliapp.com/?p=3462
《中間件技術及雙十一實踐·EagleEye篇》http://jm-blog.aliapp.com/?p=3465
如果覺得內容還行，請分享給更多的人...