1、路由模塊設計說明書修改記錄版本狀態擬制 人 修改 人擬制修改日期更改理由更改內容（寫要點即可）新建7/431目錄1 .引言1.1, 微應用系統建設背景近年來移動互聯網發展迅速，每年移動互聯網產生的流量增速達到， 越來越多的業務與應用系統也開始推出支持各種移動終端的版本，而移動 應用的增加反過來進一步促進了移動終端數量的快速增長。公司根據移動 互聯網時代對業務的需求，提出了微應用商店，通過微應用商店提供更精 細的業務功能。隨著互聯網流量從桌面轉向移動終端，以與物聯網浪潮的 興起，提供適配多種終端的豐富、友好的用戶體驗對于應用系統提出了更 高的要求。傳統的基于單一模型的應用系統，雖然在系統設計層面

2、采用了分層架 構設計，通常包括前端表現層、業務邏輯層、數據庫訪問層、應用集成層 等，但最終系統打包成一個或者單一文件形式，該文件包含了所有的系統 特性與功能，并通過集中部署的方式實現系統運行，通過部署在多臺服務 器上并結合負載均衡實現業務的高可用性，如所示。應用系統圖錯誤!未定義書簽。單一架構應用系統這種架構方式隨著系統的演進，系統規模越來越龐大，子系統與模塊 之間的關系也越來越復雜，后續的開發與維護成本也不斷提高，巳經無法 滿足移動互聯網應用對于系統的快速版本迭代與上線的需求，同時也嚴重 影響了系統開發的效率。針對單一架構應用系統暴露的問題，基于微服務架構的應用系統（以 下簡稱微應用系統）應

3、運而生。微應用系統由一組規模較小的服務構成, 每個服務以獨立進程的方式單獨運行，它們之間通過輕量級的進程間通信 機制如進行通信，這些服務根據業務邏輯進行劃分，每個服務有自己單獨 的數據庫，通過自動化部署方式每個服務可以獨立進行部署。微應用1應用交付層I 業務聚合層I業務服務層圖錯誤保定義書簽。微應用系統架構在微應用系統架構中，首先在業務服務層，每個業務服務以獨立進程 服務模式運行，實現特定的業務邏輯，并有獨立的數據庫實現數據存取, 與其他業務服務之間通過良好定義的接口進行交互。業務聚合層負責對業務服務層的服務進行聚合，對服務調用返回的數 據進行聚合與數據協議轉換，對外提供更粗粒度的服務接口。應

4、用交付層負責對外提供系統應用層接口，對服務調用返回的結果根 據用戶終端進行優化，根據用戶行為分析為用戶提供定制化的展示方式。1.2, 微應用系統建設面臨的挑戰微應用架構中應用內的各個服務可以獨立、動態的進行伸縮，當服務 進行伸縮時，其他調用方服務需要能夠找到該服務的服務實例，并與之進 行通信，使得請求能夠分布到所有的服務實例中，從而實現該服務的水平 可擴展性。另外在服務調用過程中也需要通過負載均衡策略能夠將針對該 服務的請求均勻分布到所有的服務實例。在大規模微應用系統服務化之前，應用可以通過或者等工具，簡單的 暴露和引用遠程服務，通過配置服務的地址進行調用，通過等硬件進行負 載均衡。但隨著微應

5、用系統中服務越來越多，系統面臨著越來越多的挑戰: 當服務越來越多時，服務配置管理變得非常困難，硬件負載均衡 器的單點壓力也越來越大。此時需要一個服務注冊中心，動態的 注冊和發現服務，使服務的位置透明。并通過在消費方獲取服務 提供方地址列表，實現軟負載均衡和，降低對硬件負載均衡器的 依賴，也能減少部分成本。 微應用中由于各個服務的獨立性，任何服務的彈性伸縮、版本升 級、系統故障等都可能導致該服務的狀態發生變化甚至不可用， 如何能夠讓服務使用者不受任何影響； 微應用中每個服務都有自己獨立的數據庫，因為微應用拆分導致 的原來在一個數據庫的表被分散到了多個數據庫，需要對服務屏 蔽分布式數據庫帶來的復雜

6、操作，為跨多個數據庫的操作提供統 一的數據訪問方法； 隨著服務的調用量越來越大，服務的容量與性能問題就暴露出來, 系統的擴容與運行優化需要性能監控與參數調整，所以需要監控 服務的調用量、響應時間等，作為容量規劃的參考指標。其次， 要可以動態調整權重，通過調整權重并在過程中記錄響應時間的 變化，直到響應時間到達閥值，記錄此時的訪問量，再以此訪問 量乘以機器數反推總容量。所以服務的動態伸縮與調用請求需要統一的底層技術服務的支撐。包 括微應用與業務服務的注冊與發現、微應用與業務服務請求的路由分發、 微應用與業務服務的運行監控等，從而為微應用的運行提供運行支撐。這 其中微應用與業務服務的注冊與發現是整

7、個微應用的基礎，微應用與業務 服務請求的路由分發是核心，它是實現業務調用、負載均衡的關鍵。微應 用與業務服務的運行監控為微應用系統的運行提供保障。2.微應用智能路由模塊需求分析為支撐微應用系統的改造與運行，公司在應用服務資源池的云應用管 理系統提供的底層技術服務基礎上，在微應用的分布式服務框架即智能路 由（包含服務的注冊發現）、微應用的使用（應用商店）、微應用的自動化 部署（部署環境）、微應用的運行優化（監控統計）等幾個方面開展了相 應的產品研發工作。這其中微應用的分布式服務框架即智能路由是實現服 務之間調用與負載均衡的關鍵組件。智能路由用于實現對應用請求的統一路由分發；提供服務智能路由機 制

8、來屏蔽因彈性伸縮、版本升級、系統故障等原因導致的服務的動態變化, 讓服務使用者不受任何影響；為由于微應用拆分導致的跨多個數據庫的操 作提供統一的數據訪問方法。應用路由軟負載均衡眼務路由分布式服務框架數據路由分布式數據庫框架（前端展示組件軟負我均衡TomcatWARWAR通這8個伙；例為不同微應用實現負載均衡服務.將用戶請求分發到不同微應用微應用1衡及路由策略實現應用與服務 之間、服務于埋務之間單調用分布式數據庫框架的前端代理服務將業務服務數據庫讀”的請求分發到后端不同數據庫服務接口調用微應用2前端展示組件）（服務接口調用：WAR業務朦勢TomcatWAR業務城務STomcatTomcat應用交

9、付原業務聚合層業務服務層圖錯誤!未定義書簽。微應用分布式框架智能路由具體內容如所示，包括如下內容: 應用路由：為資源池中的所有微應用提供統一請求入口，由統一 的路由分發到各個微應用； 服務路由：服務使用者從提供者地址列表中，基于負載均衡算法, 選擇一個提供者進行調用，如果調用失敗就再選另一個調用； 數據路由：為跨多個數據庫的操作提供統一的數據訪問方法，屏蔽因為微應用拆分導致的原來在一個數據庫的表被分散到了多個 數據庫中帶來的復雜操作;2.1 ,應用路由需求應用路由要求為資源池中的所有微應用提供統一請求入口，由統一的路由分發到各個微應用，所以應用路由要求提供高可靠性與高可用性，以 8/43確保微

10、應用的高可用性。傳統的硬件負載均衡設備如等可實現應用路由分發工作，但在微應用 架構中其也存在明顯的缺陷：集中式的負載均衡方案存在單點問題，由于所有服務調用流量都 要經過負載均衡，所以當服務量和調用量大的時候，集中負載均 衡容易成為瓶頸，而且一旦發生故障對整個系統的影響是災難性 的；基于硬件的集中式負載均衡方案其高可用依賴于硬件與網絡配置, 成本高且缺乏靈活性，不適宜彈性伸縮；微應用架構下，資源池中的不同微應用在服務訪問量與訪問流量方面 可能存在巨大差別，而且同一個微應用在不同時段負載變化也可能差異很 大，所以要求負載均衡能夠靈活的伸縮，能夠通過集群的方式實現負載均 衡本身的高可用性和可靠性，而

11、且集群本身可動態伸縮。2.2 .服務路由需求服務路由是指服務使用者在獲取服務提供方列表后，從提供者地址列 表中，基于負載均衡算法或者路由策略，選擇一個提供者進行調用，如果 調用失敗就再選另一個調用。具體需求如下：2.3 21.服務負載均衡當服務提供方有多個服務實例時，通過靈活的負載均衡策略選擇一個 實例進行服務調用: 支持多種負載均衡策略，并且可自行擴展； 支持隨機負載均衡策略，并且可以按照權重設置隨機概率； 支持負載均衡策略； 支持最少活躍調用數負載均衡策略，相同活躍數的采用隨機策略; 支持一致性策略負載均衡，保證相同參數的請求總是發送到同一 提供者，并且能夠保證當某一個提供者不可用時，原本

12、發往該提 供者的請求，基于虛擬節點，平均調度到其他提供者；2 2 2.集群擴展與容錯當服務提供方有多個服務實例時，可以將多個服務實例組織成一個集 群，并對外偽裝成一個服務實例，對調用方透明： 支持多種集群容錯方案，并支持自行擴展； 支持集群方案，調用失敗時自動切換，重試其他服務實例，并且 可以設置重試次數上限； 支持集群方案，一旦調用失敗，立即報錯； 支持集群方案，失敗安全，出現異常時，直接忽略； 支持集群方案，失敗自動恢復，后臺記錄失敗請求，定時重發； 支持集群方案，并行調用多個服務實例，只要一個成功即返回， 可以設置最大并行數； 支持集群方案，廣播調用所有提供者，逐個調用，任意一個服務 實

13、例報錯則報錯；3 .2.3,服務路由擴展與規則當服務提供方有多個服務實例時，可以根據請求本身的信息（如參數、 等）、服務調用方的信息（如地址等）、服務提供方的信息（如地址等）等 進行路由過濾，最后過濾出一個或多個實例提供服務： 可根據條件設置路由規則或者通過腳本定義路由規則； 可以只針對特定服務或者特定服務實例地址設置路由規則； 對于條件路由規則，支持條件表達式定義，條件表達式可以采用 本身的字段與中的所有參數，并且支持匹配、不匹配等條件，另 外支持多值、通配等方式； 對于腳本路由規則，支持引擎的所有腳本語言，如、等； 當有多條路由規則時，可以設置優先級；2 2 4.多協議支持根據不同服務實現

14、情況與不同服務調用方的實現方式，服務支持以不 同協議來暴露服務：不同服務使用不同協議同一服務可以同時使用多種協議2.2.5.多版本支持當一個接口實現，出現不兼容升級時，可以用版本號過渡，版本號不 同的服務相互間不引用。例如在針對某個服務進行升級時，為不影響服務 的可用性，可以選擇在低壓力時間段，先升級一半提供者為新版本，再將所有消費者升級為新版本，然后將剩下的一半提供者升級為新版本。2 2 6,并發控制需求可以針對某個類的所有方法或者某個特定方法設置服務器端并發 執行數量（或者占用線程池線程數）。可以針對某個類的所有方法或者某個特定方法設置每客戶端并發 執行數量（或者占用連接的請求數量）。2

15、2 7.連接控制需求可以針對服務器端接受的連接數設置最大值；可以針對服務設置客戶端使用的最大連接數（如果是長連接，表 示該服務對每個提供者建立的長連接數）2 2 8.令牌驗證與權限擴展在微應用中，針對不同調用方，調用前，需要通過用戶鑒權，確定用 戶身份。微應用中，對于服務方，需要按照調用方提供的鑒權信息，完成用戶 身份鑒定，并且通過系統中設置的用戶權限，完成用戶授權，確定用戶是 否具有調用該服務的權限。 防止服務調用方不經過鑒權、授權直接訪問服務提供方； 統一進行鑒權控制，完成服務調用方身份確定；12 / 43 可以和巳經存在的第三方鑒權系統對接； 統一進行授權控制，完成服務調用者授權； 可以

16、和巳經存在的第三方授權系統對接；2.3 .數據路由需求微應用架構中每個服務由于可以獨立開發、部署與升級，所以為避免 不同服務之間的相互影響，每個服務都可以有自己獨立的數據庫。不同服 務對數據庫的性能要求不同，所以要求數據庫能夠支持良好的伸縮性，以 能夠滿足不同服務的性能要求，比如對于訪問量較大的服務需要實現讀寫 分離，但這種數據庫層面的伸縮性與讀寫分離需要對應用層進行屏蔽。數據路由要求能夠實現數據庫服務的可伸縮性，并且對服務透明。另 外采用數據路由后，對原有業務代碼無侵入，不需要對代碼進行修改。3.微應用智能路由模塊設計原則 可靠性對于應用路由、服務路由與數據路由，都要提供高可用性解決 方案，

17、以確保微應用的可用性；對于應用路由，需要負載均衡通過集群模式實現應用請求分發 的高可靠性；對于服務路由，即使服務注冊與發現功能不可用后，服務提供 方和服務調用方仍能通過本地緩存通訊；服務提供方無狀態，任意一臺宕掉后，不影響使用；13 / 43服務提供方全部宕掉后，服務調用方應用將無法使用，并無限 次重連等待服務提供方恢復；對于數據路由，某臺后端數據庫的異常不應影響后續的所有數 據庫讀寫訪問，并且通過數據庫同步技術能夠盡快恢復發生異 常的數據庫； 伸縮性對于應用路由、服務路由與數據路由，都要求能夠根據負載情 況進行動態伸縮；對于應用路由，軟負載均衡要求能夠動態增加或減少服務實例 來適應負載的變化

18、；對于服務路由，服務提供方無狀態，可動態增加機器部署服務 實例，并會推送新的服務提供方信息給服務調用方；對于數據路由，后端可以動態增加數據庫，而對服務透明； 可管理性必須保證對智能路由系統中的每個模塊進行統一管理與監控, 維護和管理的操作要簡單方便,并且能夠從中收集到統計信息 為系統優化與參數調整提供依據。4微應用智能路由模塊設計方案4.1, 應用架構設計軟負載均衡分布式數據庫框架圖錯誤!未定義書簽,應用架構圖 軟負載均衡：負責客戶端到微應用的路由處理，詳細介紹見章節。 分布式服務框架：負責微應用到聚合服務業務服務的路由處理,以與聚合服務到業務服務的路由處理，詳細介紹見章節。 分布式數據庫框架

19、：負責業務服務到數據庫的路由處理，詳細介紹見章節。4.2, 技術架構設計 .2.1.軟負載均衡設計待補充。 .2.2.分布式服務框架設計4.2.2.1. 分布式服務框架模型初始化 異步 同步注冊中心1.注冊2.訂閱3 .通知0.開始5.訪問計數監控中心圖錯誤!未定義書簽，分布式服務框架模型 節點角色說明 服務提供方：暴露服務的服務提供方。 服務調用方：調用遠程服務的服務調用方。 注冊中心：服務注冊與發現的注冊中心。 監控中心：統計服務的調用次調和調用時間的監控中心。 服務容器:作為單獨進程運行或者運行在容器中，在服務容器開始運 行時加載和運行所有服務提供方，供服務調用方調用服務，當服務容器停

20、止后相關服務不再可用。 調用關系說明.服務容器加載和運行服務提供方。.服務提供方在啟動時，向注冊中心注冊自己提供的服務。.服務調用方在啟動時，向注冊中心訂閱自己所需的服務。.注冊中心返回服務提供方地址列表給消費者，如果有變更，注冊中 心將基于長連接推送變更數據給消費者。.服務調用方，從提供者地址列表中，基于軟負載均衡算法，選一臺 提供者進行調用，如果調用失敗，再選另一臺調用。.服務調用方和提供者，在內存中累計調用次數和調用時間，定時每 分鐘發送一次統計數據到監控中心。422.2.注冊中心Web控制臺服務提供方查詢服務調用方查詢服務通知服務授權27 / 43Zookeeper 集群圖錯誤!未定義

21、書簽。注冊中心架構圖注冊中心分為控制臺和后端（集群）兩部分。1 .后端集群是注冊中心的關鍵部分，負責接收服務提供方的服務注冊、保存 服務提供方信息，接收服務調用方的訂閱并通知服務列表給服務調用方, 其具體工作原理如下圖所示：圖錯誤!未定義書簽.注冊中心功能設計 基于的目錄節點實現服務提供方的注冊，將服務提供方信息保存在節點上 基于目錄節點上的監聽和事件通知功能實現服務調用方對服務提 供方的訂閱和發布通知 基于集群的主節點選舉、數據同步功能實現注冊中心的。2 .控制臺服務提供方查詢需能通過調用的獲取到巳經注冊的所有服務提 供方，以與訂閱了該服務的服務調用方。服務調用方查詢需能通用通過的獲取巳經訂

22、閱服務的所有服務 調用方，以與其訂閱的服務提供方。服務通知模塊需能夠接收的服務提供方變更通知，結合服務調用 方對服務提供方的訂閱信息以與服務授權情況，將服務方信息發送給 服務調用方。服務授權模塊需能接收用戶在控制臺前端頁面配置并由控制臺 后端保存在節點中，同時提供授權情況的查詢接口供服務通知模塊引 用O4223監控數據上報協議與傳輸眼務容器圖錯誤味定義書簽。服務提供方功能模塊設計圖服務提供方由服務容器與運行在其上的各子模塊組成，具體設計見以 下各子章節。4.2.23.1. 服務容器服務容器需能夠以獨立進程方式持續運行，服務容器啟動后需完成以 下初始化處理，以確保服務調用方可以調用服務提供方：1

23、 .讀取服務提供方的配置文件獲取服務信息保存在緩存中2 .根據服務信息將服務注冊到注冊中心3 .根據服務的協議類型開放相應協議的訪問接口4 .生成服務對應的代理服務對象5 .為代理服務對象添加附加服務鏈，服務鏈中的服務需要根據服務 配置信息生成。4.2.23.2. 服務配置以文件的方式配置所有的服務提供方與注冊中心。服務提供方配置項包含對應的名字、注冊中心、協議名稱、最大并 發數、最大連接數、令脾。注冊中心配置項包含的和，以與服務容器與通信的。服務配置還需提供服務查詢接口供服務容器初始化服務。4.2.23.3. 服務注冊服務被容器加載后需要注冊到注冊中心。服務注冊模塊先讀取服務配置獲取的信息，

24、再通過調用的將服務名稱、 服務協議、令牌、版本號發送到上。4.2.23.4. 協議與傳輸協議與傳輸模塊負責建立服務方的通信服務端、等待調用方的連接和 請求，并在處理完畢后響應調用方。支持和協議如果協議是，則通過框架創建通信服務端，調用方使用框架創建通信 客戶端，并相互通信。如果協議是，則通過框架礦建通信服務端，調用方使用框架創建通信 客戶端，并相互通信。4.2.23.5. 代理服務基于技術在容器中產生代理服務類，在代理原生服務的功能基礎上還 要完成令牌校驗、訪問統計、并發控制、連接控制等功能，各附加功能需 要調用附加服務鏈完成。4.2.23.6. 附加服務鏈每個代理服務都包含一個附加服務鏈，由

25、一系列附加服務組成，附加 服務包含令牌校驗、訪問統計、并發控制、連接控制。代理服務類在處理服務請求時，先順序執行附加服務鏈中的附加服務, 然后再調用原生服務的處理邏輯。若附加服務產生異常，則終止處理立即 響應異常給調用方。當請求處理完畢返回給調用方的時候，依然要經過附加服務鏈，僅處 理訪問統計和并發控制。令牌校驗：從請求中獲取服務令牌，與緩存中的服務令牌比較，若相 同則校驗通過繼續處理，否則響應鑒權失敗。訪問統計：在本地緩存中保存各服務的訪問統計數，當處理新的請求 時根據服務名讀取緩存中的統計數，并進行累加，同時記錄請求到來時間, 當請求處理完畢后還要經過訪問統計，此時再用當前時間減去請求到來

26、時 間計算出本次請求處理時長，并保存在緩存中。并發控制：在本地緩存中保存各服務當前并發數，當處理新的請求時 根據服務名讀取當前并發數，計算并發數加是否超過服務的最大并發數, 如果超出則響應異常，否則繼續執行下一個附加服務。當請求響應階段再 次經過并發控制時，將對應并發數減。連接控制：在本地緩存中保存各服務巳建立的連接，當處理新的請求 時根據服務名和客戶端判斷巳建立連接數是否超過最大連接數，如果超出 則響應異常、斷開連接并刪除緩存中的連接記錄，否則繼續執行下一個附 加服務。4.2.23.7. 監控數據上報監控數據上報需要每分鐘觸發一次，完成以下處理：1 .從緩存中讀取所有服務的調用統計數與每次訪

27、問處理時長。2 .清空緩存中服務調用統計數和訪問處理時長。3 .用訪問處理總時長除以訪問次數得出平均處理時長。4 .將調用統計書和平均處理時長發送給監控中心。4.2.2.4.服務調用方調川方配汽訂閱與接收監控數據上報附加服務鏈 容錯集群協議與傳輸圖錯誤!未定義書整。服務調用方功能模塊設計圖服務調用方由上圖中的各子模塊組成，具體設計見以下各子章節。4.2.2.4.1, 服務調用方配置以文件的方式配置所有的服務提供方與注冊中心。服務提供方配置項包含對應的名字、注冊中心、協議名稱、最大并發 數、最大連接數、令牌。注冊中心配置項包含的和，以與服務容器與通信的。服務配置還需提供服務查詢接口供服務容器初始

28、化服務。42242.訂閱與接收圖錯誤味定義書簽服務訂閱與接收令訂閱服務調用方啟動時，在引用服務前首先將自身需要引用的服務注冊到 注冊中心（），然后訂閱系統需要的服務。如果同時引用多個接口，則上面的過程會重復執行多次。令接收完成了服務訂閱以后，服務調用方會與注冊中心建立一個長連接，隨 后，會接收到注冊中心主動發送的訂閱信息。注冊中心主動推送訂閱信息 的的條件如下：1 .新的服務調用方注冊2 .服務調用方訂閱的服務發生變化（如：新服務上線、下線等）例如：一個消費者注冊了一個，系統在啟動時，首先聲明自己是的一 個消費者，然后再向注冊中心聲明自己需要訂閱，最后，接收注冊中心推 送訂閱的服務，緩存到本地

29、。如果服務提供方發生任何變化，也會接收到 注冊中心推送的更新信息。4.2.2.43,監控數據上報監控數據上報需要每分鐘觸發一次，完成以下處理：1 .從緩存中讀取所有服務的調用統計數與每次訪問處理時長。2 .清空緩存中服務調用統計數和訪問處理時長。3 .用訪問處理總時長除以訪問次數得出平均處理時長。4 .將調用統計和平均處理時長發送給監控中心。42244.附加服務鏈每個代理服務都包含一個附加服務鏈，由一系列附加控制組成，附加 控制包含令牌校驗、訪問統計、并發控制、連接控制。代理服務類在處理服務請求時，先順序執行附加服務鏈中的附加服務, 然后再調用原生服務的處理邏輯。若附加服務產生異常，則終止處理

30、立即 響應異常給調用方。當請求處理完畢返回給調用方的時候，依然要經過附加服務鏈，僅處 理訪問統計和并發控制。令牌校驗：從本地獲取服務令牌，附加在請求中一并上傳。訪問統計：在本地緩存中保存各服務的訪問統計數，當處理新的請求 時根據服務名讀取緩存中的統計數，并進行累加，同時記錄請求到來時間, 當請求處理完畢后還要經過訪問統計，此時再用當前時間減去請求到來時 間計算出本次請求處理時長，并保存在緩存中。并發控制：在本地緩存中保存各服務當前并發數，當處理新的請求時 根據服務名讀取當前并發數，計算并發數加是否超過服務的最大并發數, 如果超出則響應異常，否則繼續執行下一個附加服務。當請求響應階段再 次經過并

31、發控制時，將對應并發數減。連接控制：在本地緩存中保存各服務巳建立的連接，當處理新的請求 時根據服務名和客戶端判斷巳建立連接數是否超過最大連接數，如果超出 則響應異常、斷開連接并刪除緩存中的連接記錄，否則繼續執行下一個附 加服務。4.2.245容錯集群圖錯誤味定義書簽。容錯集群結構圖令容錯容錯的主要功能是在服務調用方實現的。調用代理之后，是容錯處理 模塊，它根據不同的容錯模式，處理調用時產生的錯誤。具體支持的容錯 模式包括：/ （缺省模式）失敗自動切換，當出現失敗，重試其它服務器。增加配置項設置重試次數。快速失敗，只發起一次調用，失敗立即報錯。失敗安全，出現異常時，直接忽略。失敗自動恢復，后臺記

32、錄失敗請求，定時重發。令路由規則需要支持的路由規則包含：按條件規則過濾服務，以條件表達式形式配置，路由時解析實際 是否符合條件表達式。條件表達式支持匹配、不匹配，匹配規則 需支持多值和統配。令負載均衡負載均衡的主要功能是在服務調用方實現的。容錯處理模塊在完成條 件過濾以后，選擇出合適的服務提供方列表，然后根據不同的負載均衡模 式，確定具體的服務提供方。具體支持的負載均衡模式包括：/隨機，按權重設置隨機概率。輪循，按公約后的權重設置輪循比率。/最少活躍調用數，相同活躍數的隨機，活躍數指調用前后計數 差。42246.協議與傳輸協議與傳輸模塊負責建立服務方的通信服務端、等待調用方的連接和 請求，并在

33、處理完畢后響應調用方。支持和協議如果協議是，則通過框架創建通信服務端，調用方使用框架創建通信28 / 43請求舉響應問個蜜務的兩個不同實例服務調用方客戶端，并相互通信。如果協議是，則通過框架礦建通信服務端，調用方使用框架創建通信 客戶端，并相互通信。4.2.2.I服務調用服務提供方圖錯誤!未定義書簽,服務調用流程調用流程中各處理模塊的設計見和章節。4.2.2, 6.監控中心數據接收監控數據查詢監控圖表處理服務調用方服務提供方監控中心圖錯誤味定義書簽。監控中心架構圖監控中心負責獲取各服務調用方對各服務的累計訪問次數和處理時間，以與服務提供方響應服務調用方的累計訪問次數和響應時間，并能夠 提供頁面

34、展示監控數據。監控中心需按下圖方式獲取監控數據。7.服務提供者被調用計數9服務提供者被調用計數圖錯誤!未定義書簽。監控中心活動圖4.2.3, 分布式數據庫框架設計4.2.3.1. 系統架構簡介整個分布式數據庫框架如下圖。它分為通信層、處理層、數據庫通信 層和系統監控模塊。30 / 43應用1應用1OracleMySQL圖錯誤味定義書簽。分布式數據庫框架通信層指的是的二進制適配層，他將整個分布式數據庫框架偽裝成一 個的數據庫，兼容所有的客戶端，如:、等。為了能夠得到更高的性能， 系統設置了前端的應用連接池。處理層主要完成語句的解析和路由分發，并且將語句在數據庫中執行 的結果返回給用戶。數據庫通信

35、層是一數據庫連接池，通過二進制協議連 接數據庫；或者通過，連接其他兼容數據庫。監控模塊的主要功能是對分布式數據庫框架的工作狀態進行全面的 管理和監控。423.2.讀寫分離數據庫讀寫分離對于大型系統或者訪問量很高的互聯網應用來說，是 必不可少的一個重要功能。從數據庫的角度來說，對于大多數應用來說，從集中到分布，最基本 31 / 43的一個需求不是數據存儲的瓶頸，而是在于計算的瓶頸，即查詢的瓶頸, 我們知道，正常情況下，就是幾十個亳秒的時間內寫入完成，而系統中的 大多數則要幾秒到幾分鐘才能有結果，很多復雜的，其消耗服務器的能力 超強，不亞于死循環的威力。在沒有讀寫分離的系統上，很可能高峰時段 的一

36、些復雜查詢就導致數據庫服務器爆表，系統陷入癱瘓，嚴重情況下可 能導致數據庫崩潰。因此，從保護數據庫的角度來說，我們應該盡量避免 沒有主從復制機制的單節點數據庫。分布式數據庫框架就是自動完成語句讀寫分離的高性能代理。4.23.2.1. 分布式數據庫框架支持的讀寫分離圖錯誤床定義書簽。分布式數據庫框架讀寫分離當數據庫按照主從復制方式配置好集群以后，就可以通過分布式數據 庫框架實現讀寫分離機制。數據庫訪問客戶端直接連接在分布式數據庫框架上。框架通過對語句的解析，分辨出數據查詢語0句和數據操作語句（），然后將數據查詢 32 / 43語句發送到從庫集群上實現數據查詢，將數據操作語句發送到主庫上實現 數據

37、操作。所有的數據庫操作通過主從復制的方式，將所有的數據修改發送到從 庫上，實現主庫和從庫的數據同步。分布式數據庫框架還會和所有的數據庫定時握手，當發現數據庫出現 故障時，會自動將故障服務器剔除出集群。如果主庫出現故障，則涉與到 分布式數據庫框架高可用，請參見“分布式數據庫框架高可用”章節。4.23.2.2. 數據庫主從復制方案主從復制對于數據庫來說，標準的讀寫分離是主從模式，一個主庫后面跟著多 個從庫，從庫的數量取決于系統的壓力，通常是個從庫的配置，如下圖所 示：主庫Write Host圖錯誤!未定義書簽。數據庫主從復制配置除了一主多從，數據庫還支持更多的主從復制的拓撲關系，如下圖所 示，但通

38、常我們不會采用雙向主從同步以與環狀的拓撲：33 / 43圖錯誤!未定義書簽。數據庫主從復制拓撲4.23.2.3. 數據庫主從復制原理第一步是在主庫上記錄二進制日志(稍后介紹如何設置)。在每次準 備提交事務完成數據更新前，主庫將數據更新的事件記錄到二進制日志中。 數據庫會按事務提交的順序而非每條語句的執行順序來記錄二進制日志。 在記錄二進制日志后，主庫會告訴存儲引擎可以提交事務了。下一步，從 庫將主庫的二進制日志復制到其本地的中繼日志中。首先，從庫會啟動一 個工作線程，稱為線程，線程跟主庫建立一個普通的客戶端連接，然后在 主庫上啟動一個特殊的二進制轉儲()線程，這個二進制轉儲線程會讀取主 庫上二

39、進制日志中的事件。如果該線程追趕上了主庫，它將進入睡眠狀態， 直到主庫發送信號量通知其有新的事件產生時才會被喚醒，從庫線程會將 接收到的事件記錄到中繼日志中。從庫的線程執行最后一步，該線程從中繼日志中讀取事件并在備庫執行，從而實現備庫數據的更新。當線程追趕上線程時，中繼日志通常巳經 34 / 43在系統緩存中，所以中繼日志的開銷很低。線程執行的事件也可以通過配 置選項來決定是否寫入其自己的二進制日志中。這種復制架構實現了獲取 事件和重放事件的解耦，允許這兩個過程異步進行。也就是說線程能夠獨 立于線程之外工作。但這種架構也限制了復制的過程，其中最重要的一點 是在主庫上并發運行的在備庫只能串行化執

40、行，因為只有一個線程來重放 中繼日志中的事件。這是很多工作負載的性能瓶頸所在。雖然有一些針對 該問題的解決方案，但大多數用戶仍然受制于單線程。4.233.高可用4.23.3.1. 分布式數據庫框架支持的高可用分布式數據庫框架作為一個代理層中間件，分布式數據庫框架系統的 高可用涉與到分布式數據庫框架本身的高可用以與后端數據庫的高可用。 本章節首先討論分布式數據庫框架自身的高可用，下面的章節討論分布式 數據庫框架所連接的后端數據庫服務的高可用性。在大多數情況下，建議 采用標準的數據庫主從復制高可用性配置并交付給分布式數據庫框架來 完成后端數據庫節點的主從自動切換。圖錯誤味定義書簽。分布式數據庫框架

41、讀寫分離如圖所示，數據庫節點開啟主從復制的配置方案，并將主節點配置為 分布式數據庫框架的主庫，從節點配置為從庫，同時分布式數據庫框架內 部定期對所有主庫與從庫節點發起心跳檢測。圖錯誤床定義書簽,分布式數據庫框架故障恢復正常情況下，分布式數據庫框架會將第一個主庫作為寫節點，所有的 數據操作語句會發送給此節點，若分布式數據庫框架開啟了讀寫分離，則 分布式數據庫框架會根據讀寫分離的策略發往從庫執行，當配置了兩個或 多個主庫的情況下，如果第一個主庫宕機，則分布式數據庫框架會在默認 的次心跳檢查失敗后，自動切換到下一個可用的主庫執行數據操作語句O當原來配置的數據庫主庫宕機恢復以后，為了保證數據庫系統中的

42、數 據一致性，恢復的節點不會自動加入集群。需要重新配置同步源，手工完 成數據庫數據同步以后，再加入分布式數據庫框架里。這個過程里，可以 先修改數據庫的密碼，讓分布式數據庫框架無法鏈接故障服務器，等同步 完成以后，恢復密碼，這樣分布式數據庫框架就自動重新將修復好的分布 式數據庫框架納管進來了。說完了數據庫部分，接下來我們看看分布式數據庫框架自身的高可用 性，由于分布式數據庫框架自身是屬于無狀態的中間件，因此分布式數據 庫框架很容易部署為集群方式，提供高可用方案。建議采用基于硬件的負 載均衡器或者軟件方式的負載均衡器。下圖是軟件負載均衡器分布式數據 庫框架集群數據庫主從復制所組成的高可用性方案：負載均衡器圖錯誤床定義書簽。分布式數據庫框架高可