大神講解微服務治理的技術演進和架構實踐(轉)

中生代技術羣分享第四十三期

編輯：友強

講師：李林鋒

原文地址：http://mp.weixin.qq.com/s/ns_XR03hZ3t96ypYoQuJPQ

摘要：隨着業務的發展,規模擴大，服務愈來愈多，須要協調線上運行的各個服務，保障服務的SLA;基於服務調用的性能KPI數據進行容量管理，合理分配各服務的資源佔用;對故障業務作服務降級、流量控制、流量遷移等快速恢復業務。怎樣的服務治理框架能知足需求？

 

李林鋒，華爲PaaS平臺架構師，8年Java NIO通訊框架、平臺中間件架構設計和開發經驗，開源框架Netty中國推廣者。精通Netty、Mina、RPC框架、企業ESB總線、分佈式服務框架、雲計算等技術，《Netty權威指南》、《分佈式服務框架原理與實踐》做者，公司總裁技術創新獎得到者

 

 

我今天分享的主題是《微服務治理的技術演進和架構實踐》

本次分享，將分爲三個部分。

1. 爲何須要服務治理

2. 服務治理的技術演進歷程

3. 雲端微服務治理框架設計

 

爲何須要服務治理？

第1、業務需求

隨着業務的發展，服務愈來愈多，如何協調線上運行的各個服務，保障服務的SLA，對服務架構和運維人員是一個很大的挑戰。隨着業務規模的不斷擴大，小服務資源浪費等問題逐漸顯現，須要可以基於服務調用的性能KPI數據進行容量管理，合理分配各個服務的資源佔用，提升機器的利用率。線上業務發生故障時，須要對故障業務作服務降級、流量控制、流量遷移等，快速恢復業務。

着開發團隊的不斷擴大，服務的上線愈來愈隨意，甚至發生功能相同、服務名不一樣的服務同時上線。上線容易下線難，爲了規範服務的上線和下線，在服務發佈前，須要走服務預發佈流程，由架構師或者項目經理對須要上線的服務作發佈審覈，審覈經過的纔可以上線。爲了知足服務線下管控、保障線上高效運行，須要有一個統一的服務治理框架對服務進行統1、有效管控，保障服務的高效、健康運行。

第2、技術需求

大部分服務化框架的服務屬性經過XML配置或者Java註解的方式進行定義，以服務端流量控制爲例：

服務發佈的XML文件一般會打包到服務提供者的jar包中，部署在Java Web或者Java Container容器中，存儲在服務端的本地磁盤中。

不管採用註解仍是XML配置的方式，若是須要在運行態動態修改服務提供者的流控閾值，都須要在本地修改配置或者修改源碼，從新打包部署並升級應用。沒法實如今線、配置化的修改和動態生效。因爲諸如流控閾值、服務的超時時間等沒法預測出最優值，須要修改以後上線驗證，根據服務運行效果決定是否再作調整，所以常常須要反覆調整，採用修改源碼-從新打包部署-應用升級的方式進行服務治理，效率低下。所以，在技術上須要一個服務治理框架，提供Web Portal，微服務運維或者治理人員經過在線配置化的方式修改服務提供者或者消費者的屬性，能夠實時動態生效。

 

服務治理的技術演進歷程

第一代服務治理 SOA Governance: 以IBM爲首的SOA解決方案提供商推出的針對企業IT系統的服務治理框架，它主要聚焦在對企業IT系統中異構服務的質量管理、服務發佈審批流程管理和服務建模、開發、測試以及運行的全生命週期管理。

第二代以分佈式服務框架爲中心的服務治理：隨着電商和移動互聯網的快速發展，基於電商平臺的統一分佈式服務框架的全新服務治理理念誕生，它聚焦於對內部同構服務的線上治理，保障線上服務的運行質量。相比於傳統IT架構的服務治理，因爲服務的開發模式、部署規模、組網類型、業務特色等差別巨大，所以服務治理的重點也從線下轉移到了線上服務質量保障。

第三代以雲化爲核心的雲端微服務治理架構：2013年至今，隨着雲計算和微服務架構的發展，以AWS爲首的基於微服務架構   雲服務化的雲端服務治理體系誕生，它的核心理念是服務微自治，利用雲調度的彈性和敏捷，逐漸消除人工治理。微服務架構能夠實現服務必定程度的自治，例如服務獨立打包、獨立部署、獨立升級和獨立擴容。經過雲計算的彈性伸縮、單點故障遷移、服務健康度管理和自動容量規劃等措施，結合微服務治理，逐步實現微服務的自治。

第一代 SOA Governance服務治理

第一代SOA Service GovernanceSOA Governance的定位：面向企業IT系統異構服務的治理和服務生命週期管理，它治理的服務一般是SOA服務。傳統的SOA Governance包含四部份內容：1.服務建模：驗證功能需求與業務需求，發現和評估當前服務，服務建模和性能需求，開發治理規劃。2.服務組裝：建立服務更新計劃，建立和修改服務以知足全部業務需求，根據治理策略評估服務，批准組裝完成。3.服務部署：確保服務的質量，措施包括功能測試、性能測試和知足度測試，批准服務部署。4.服務管理：在整個生命週期內管理和監控服務，跟蹤服務註冊表中的服務，根據服務質量等級協議（SLA）上報服務的性能KPI數據進行服務質量管理。

SOA Governance 工做原理圖以下所示：

傳統SOA Governance的主要缺點以下：1.分佈式服務框架的發展，內部服務框架須要統一，服務治理也須要適應新的架構，可以由表及裏，對服務進行細粒度的管控。2.微服務架構的發展和業務規模的擴大，致使服務規模量變引發質變，服務治理的特色和難點也隨之發生變化。3.缺乏服務運行時動態治理能力，面對突發的流量高峯和業務衝擊，傳統的服務治理在響應速度、故障快速恢復等方面存在不足，沒法更敏捷應對業務需求。

 

第二代分佈式服務框架服務治理

分佈式服務框架的服務治理定位：面向互聯網業務的服務治理，聚焦在對內部採用統一服務框架服務化的業務運行態、細粒度的敏捷治理體系。

治理的對象：基於統一分佈式服務框架開發的業務服務，與協議自己無關，治理的能夠是SOA服務，也能夠是基於內部服務框架私有協議開發的各類服務。

治理策略：針對互聯網業務的特色，例如突發的流量高峯、網絡延時、機房故障等，重點針對大規模跨機房的海量服務進行運行態治理，保障線上服務的高SLA，知足用戶的體驗。經常使用的治理策略包括服務的限流降級、服務遷入遷出、服務動態路由和灰度發佈等。

分佈式服務框架典型的服務治理體系以下所示：

第三代雲端微服務治理

隨着雲計算的發展，Dev&Ops逐漸流行起來，基礎設施服務化（IaaS）爲大規模、批量流水線式軟件交付提供了便利，AWS作爲全球最大的雲計算解決方案提供商，在微服務雲化開發和治理方面積累了很是多的經驗，具體總結以下

1. 全公司統一服務化開發環境，統一簡單化服務框架（Coral Service）,統一運行平臺，快速高效服務開發；

2. 全部後端應用服務化，系統由多項服務化組件構成。

3. 服務共享、原子化、重用。

4. 服務由小研發團隊（2 Pizza Team）負責服務開發、測試、部署和治理，運維整個生命週期支撐。

5. 高度自動化和Dev&Ops支持，一鍵式服務部署和回退。

6. 超大規模支持：後臺幾十萬個服務，成千上萬開發者同時使用，平均每秒鐘有1-2個服務部署。

7. 嘗試基於Docker容器部署微服務。

8.服務治理是核心：服務性能KPI統計、告警、服務健康度管理、靈活的彈性伸縮策略、故障自動遷移、服務限流和服務降級等多種治理手段，保障服務高質量運行。

 

雲端微服務治理架構設計

雲端微服務治理架構設計的目標以下：

1. 防止業務服務架構腐化：經過服務註冊中心對服務強弱依賴進行分析，結合運行時服務調用鏈關係分析，梳理不合理的依賴和調用路徑，優化服務化架構，防止代碼腐化。

2. 快速故障定界定位：經過Flume等分佈式日誌採集框架，實時收集服務調用鏈日誌、服務性能KPI數據、服務接口日誌、運行日誌等，實時彙總和在線分析，集中存儲和展現，實現故障的自動發現、自動分析和在線條件檢索，方便運維人員、研發人員進行實時故障診斷。

3. 服務微管控：細粒度的運行期服務治理，包括限流降級、服務遷入遷出、服務超時控制、智能路由、統一配置、優先級調度和流量遷移等，提供方法級治理和動態生效功能，經過一系列細粒度的治理策略，在故障發生時能夠多管齊下，在線調整，快速恢復業務。

4. 服務生命週期管理：包括服務的上線審批、下線通知，服務的在線升級，以及線上和線下服務文檔庫的建設。

5. 靈活的資源調度：基於Docker容器，能夠實現微服務的獨立部署和細粒度的資源隔離。基於雲端的彈性伸縮，能夠實現微服務級別的按需伸縮和故障隔離。

 

雲端微服務治理架構設計雲端微服務治理從架構上能夠分爲三層：

• 第一層：微服務治理展現層，它的實現爲微服務治理Portal，主要面向系統運維人員或者治理人員，提供在線、配置化的治理界面。

• 第二層：微服務治理SDK，向服務治理提供治理元數據、治理接口、以及客戶端的治理類庫。

• 第三層：微服務治理服務實現層，微服務治理服務，經過服務註冊中心，刷新服務治理屬性，同時通知服務提供者和消費者集羣各節點刷新內存，使服務治理Portal下發的服務治理策略動態生效。

1.  微服務治理Portal

微服務治理Portal是微服務治理的門戶，它提供服務治理操做界面，供系統運維人員或者測試人員對線上運行的微服務進行動態治理，以保障服務的SLA。

Portal框架能夠基於AngularJS等Web框架進行開發，它的門戶界面以下所示：能夠支持同時配置多個服務註冊中心集羣，對不一樣的微服務集羣進行治理。

選擇某個微服務集羣以後，就能夠對該集羣的微服務進行治理，界面示例以下：

點擊查看，能夠查看微服務的狀態，以及各類性能指標。點擊治理，彈出選擇菜單，能夠對選擇的微服務進行相關的治理操做。

2.  微服務治理SDK

服務治理SDK層，它主要由以下幾部分組成：

1. 服務治理元數據：服務治理元數據主要包括服務治理實體對象，包括服務模型、應用模型、治理組織模型、用戶權限模型、數據展現模型等。元數據模型經過Data Mapper和模型擴展，向上層界面屏蔽底層服務框架的數據模型，實現展現層和服務框架的解耦，元數據也能夠用於展現界面的定製擴展；

2. 服務治理接口：服務治理Portal調用服務治理接口，實現服務治理。例如服務降級接口、服務流控接口、服務路由權重調整接口、服務遷移接口等。服務接口與具體的協議無關，它一般基於分佈式服務框架自身實現，能夠是Restful接口，也能夠是內部的私有協議；

3. 服務治理客戶端類庫：因爲服務治理服務自己一般也是基於分佈式服務框架開發，所以服務治理Portal須要集成分佈式服務框架的客戶端類庫，實現服務的自動發現和調用；

4. 調用示例：客戶端SDK須要提供服務治理接口的參數說明、注意事項以及給出經常使用的調用示例，方便前端開發人員使用；

5. 集成開發指南：服務治理SDK須要提供集成開發指南，指導使用者如何在開發環境中搭建、集成和使用服務治理SDK。

3.  線上服務治理

線上服務治理包含多種策略，例如：流量控制、服務降級、優先級調度等。微服務啓動的時候，將XML或者註解的服務提供者或者消費者屬性註冊到服務註冊中心，由運維人員經過服務治理Portal進行在線修改，註冊中心通知服務提供者和消費者刷新內存，動態生效。

下面就這幾種典型的治理策略進行說明。

第1、流量控制

當資源成爲瓶頸時，服務框架須要對消費者作限流，啓動流控保護機制。流量控制有多種策略，比較經常使用的有：針對訪問速率的靜態流控、針對資源佔用的動態流控、針對消費者併發鏈接數的鏈接控制和針對並行訪問數的併發控制。

• 靜態流控：主要針對客戶端訪問速率進行控制，它一般根據服務質量等級協定（SLA）中約定的QPS作全局流量控制，例如訂單服務的靜態流控閾值爲100 QPS，則不管集羣有多少個訂單服務實例，它們總的處理速率之和不能超過100 QPS。

• 動態流控：它的最終目標是爲了保命，並非對流量或者訪問速度作精確控制。當系統負載壓力很是大時，系統進入過負載狀態，多是CPU、內存資源已通過載，也多是應用進程內部的資源幾乎耗盡，若是繼續全量處理業務，可能會致使長時間的Full GC、消息嚴重積壓或者應用進程宕機，最終將壓力轉移到集羣其它節點，引發級聯故障。觸發動態流控的因子是資源，資源又分爲系統資源和應用資源兩大類，根據不一樣的資源負載狀況，動態流控又分爲多個級別，每一個級別流控係數都不一樣，也就是被拒絕掉的消息比例不一樣。每一個級別都有相應的流控閾值，這個閾值一般支持在線動態調整。

• 併發控制：針對線程的併發執行數進行控制，它的本質是限制對某個服務或者服務的方法過分消費，耗用過多的資源而影響其它服務的正常運行。併發控制有兩種形式：針對服務提供者的全局控制和針對服務消費者的局部控制。

• 鏈接控制：一般分佈式服務框架服務提供者和消費者之間採用長鏈接私有協議，爲了防止由於消費者鏈接數過多致使服務端負載壓力過大，系統須要支持針對鏈接數進行流控。

4.  服務降級

大促或者業務高峯時，爲了保證核心服務的SLA，每每須要停掉一些不過重要的業務，例如商品評論、論壇或者粉絲積分等。

另一種場景就是某些服務由於某種緣由不可用，可是流程不能直接失敗，須要本地Mock服務端實現，作流程放通。以圖書閱讀爲例，若是用戶登陸餘額鑑權服務不能正常工做，須要作業務放通，記錄消費話單，容許用戶繼續閱讀，而不是返回失敗。

經過服務治理的服務降級功能，便可以知足上述兩種場景的需求。服務降級主要包括屏蔽降級和容錯降級兩種策略：

 

• 屏蔽降級：當外界的觸發條件達到某個臨界值時，由運維人員/開發人員決策，對某類或者某個服務進行強制降級。

它的處理流程以下所示：

第1步：運維人員以管理員身份登陸服務治理控制檯，管理員具有服務治理的全套權限。

第2步：運維人員選擇服務降級菜單，在服務降級界面中選擇屏蔽降級。

第3步：經過服務查詢界面選擇須要降級的服務，注意服務的分組和版本信息，指定具體的降級策略：返回null、返回指定異常仍是執行本地Mock接口實現。第4步：服務治理Portal經過服務註冊中心客戶端SDK，將屏蔽降級指令和相關信息發送到服務註冊中心。

第五、6步：服務註冊中心接收到屏蔽降級消息後，以事件的形式下分別羣發給服務提供者集羣和服務消費者集羣。

第7步：服務消費者接收到屏蔽降級事件通知以後，獲取相關內容，更新本地緩存的服務訂閱信息。當發起遠程服務調用時，須要與屏蔽降級策略作匹配，若是匹配成功，則執行屏蔽降級邏輯，不發起遠程服務調用。

第8步：服務提供者集羣接收到屏蔽降級事件通知以後，獲取相關內容，更新本地的服務發佈緩存信息，將對應的服務降級屬性修改成屏蔽降級。

第9步：操做成功以後，服務註冊中心返回降級成功的應答消息，由服務治理Portal界面展現。

第10步：運維人員查詢服務提供者列表，查看服務狀態。

第11步：服務註冊中心返回服務狀態爲屏蔽降級狀態。

 

• 容錯降級：當非核心服務不可用時，能夠對故障服務作業務邏輯放通，以保障核心服務的運行。容錯降級的工做原理以下所示：

5.  服務優先級調度

當系統當前資源很是有限時，爲了保證高優先級的服務可以正常運行，保障服務SLA，須要下降一些非核心服務的調度頻次，釋放部分資源佔用，保障系統的總體運行平穩。

服務在發佈的時候，能夠指定服務的優先級，若是用戶沒有指定，採用默認優先級策略，它的配置以下所示：

服務的優先級能夠採用傳統的低、中、高三級配置策略，每一個級別的執行比例能夠靈活配置，以下所示：

服務發佈經過擴展priority屬性的方式指定優先級，服務提供者將優先級屬性註冊到服務註冊中心並通知消費者，由消費者緩存服務的優先級，根據不一樣的優先級策略進行調度。服務治理Portal經過動態修改註冊中心指定服務priority屬性的方式，實現運行態動態調整微服務的優先級。

 

總結除了上面介紹的幾種經常使用線上治理策略，比較重要的微服務治理策略還包括：

微服務超時控制：因爲微服務調用一般使用RPC方式，是同步阻塞的，所以須要設置服務調用超時時間，防止對端長時間不響應致使的應用線程掛死。超時控制支持在服務端或者消費端配置，須要支持方法級超時控制。

微服務路由策略：負載均衡策略是服務治理的重要特性，分佈式服務框架一般會提供多種負載均衡策略，同時支持用戶擴展負載均衡策略。經常使用的路由策略包括：

1. 隨機：採用隨機算法進行負載均衡，一般在對等集羣組網中，隨機路由算法消息分發仍是比較均勻的。

2. 輪循:按公約後的權重設置輪循比率，到達邊界以後，繼續繞接。

3. 服務調用時延：消費者緩存全部服務提供者的服務調用時延，週期性的計算服務調用平均時延，而後計算每一個服務提供者服務調用時延與平均時延的差值，根據差值大小動態調整權重，保證服務時延大的服務提供者接收更少的消息，防止消息堆積。

4. 一致性Hash:相同參數的請求老是發到同一個服務提供者，當某一臺提供者宕機時，本來發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引發劇烈變更。

5. 粘滯鏈接:粘滯鏈接用於有狀態服務，儘量讓客戶端老是向同一提供者發起服務調用，除非該提供者宕機，再鏈接另外一臺。

集羣容錯策略：消費者根據配置的路由策略選擇某個目標地址以後，發起遠程服務調用，在此期間若是發生了遠程服務調用異常，則須要服務框架進行集羣容錯，從新進行選路和調用。集羣容錯是系統自動執行的，上層用戶並不須要關心底層的服務調用過程。集羣容錯和路由策略的關係以下所示：

經常使用的集羣容錯策略以下：  

1. Failover策略:服務調用失敗自動切換策略指的是當發生RPC調用異常時，從新選路，查找下一個可用的服務提供者。一般能夠配置失敗切換的最大次數和間隔週期，以防止E2E服務調用時延過大。  

2. Failback策略：在不少業務場景中，消費者須要可以獲取到服務調用失敗的具體信息，經過對失敗錯誤碼等異常信息的判斷，決定後續的執行策略，例如非冪等性的服務調用。

3. Failcache策略:Failcache策略是失敗自動恢復的一種，在實際項目中它的應用場景以下：- 服務有狀態路由，必須定點發送到指定的服務提供者。當發生鏈路中斷、流控等服務暫時不可用時，服務框架將消息臨時緩存起來，等待週期T，從新發送，直到服務提供者可以正常處理該消息。- 對時延要求不敏感的服務。系統服務調用失敗，一般是鏈路暫時不可用、服務流控、GC掛住服務提供者進程等，這種失敗不是永久性的失敗，它的恢復是可預期的。若是消費者對服務調用時延不敏感，能夠考慮採用自動恢復模式，即先緩存，再等待，最後重試。-通知類服務。例如通知粉絲積分增加、記錄接口日誌等，對服務調用的實時性要求不高，能夠容忍自動恢復帶來的時延增長。

4. Failfast策略：在業務高峯期，對於一些非核心的服務，但願只調用一次，失敗也再也不重試，爲重要的核心服務節約寶貴的運行資源。此時，快速失敗是個不錯的選擇。

服務灰度發佈：灰度發佈是指在黑與白之間，可以平滑過渡的一種發佈方式。AB test就是一種灰度發佈方式，讓一部用戶繼續用A，一部分用戶開始用B，若是用戶對B沒有什麼反對意見，那麼逐步擴大範圍，把全部用戶都遷移到B上面來。灰度發佈能夠保證總體系統的穩定，在初始灰度的時候就能夠發現、調整問題，以保證其影響度。

基於微服務的多版本管理機制   灰度路由策略，便可實現基於業務規則的灰度發佈。

多版本管理：服務上線以後，隨着業務的發展，須要對功能進行變動，或者修復線上的BUG，服務升級以後，每每須要對服務作多版本管理。服務多版本管理是分佈式服務框架的重要特性，它涉及到服務的開發、部署、在線升級和服務治理。

調用分組管理：能夠對服務按照業務領域、部署的DC信息、服務提供商等角度對微服務進行羣組化管理，同羣組之間的微服務能夠自由調用，跨羣組的微服務須要進行審批和受權，以實現不一樣分組之間的微服務隔離。不一樣分組之間能夠有同名同接口的微服務的不一樣實現，分組信息也是服務路由的一個因子。

全在線服務文檔

相對於平臺產品，業務服務的升級和修改很是頻繁，傳統依靠Java DOC進行接口說明和傳遞的方式，每每會由於缺少文檔建設或API DOC沒有及時刷新，致使消費者拿到的接口定義說明不許確。相比於沒有文檔，拿到過期、錯誤的API DOC文檔對使用者的危害更大。

爲了解決這個問題，須要創建服務文檔中心，方便線上運維人員查看和多團隊之間的協做，它的工做原理以下：

能夠基於Swagger UI，構建微服務在線文檔庫，以下所示：

能夠參考以下連接：https://github.com/swagger-api/swagger-ui

服務上線審批下線通知機制

當團隊規模擴大以後，會劃分紅平臺基線組、業務定製組等不一樣研發團隊，一些團隊甚至跨多地協同開發和運維。服務的上線和下線必需要嚴格管控起來，一旦不合格的服務上線並被消費者消息，再想下線就很是困難了。

對於須要下線的服務管控也很重要，有些服務雖然調用頻次不高，業務量也不大。可是若是貿然下線，頗有可能致使依賴它的消費者業務調用失敗，這會違反服務的SLA協定，給服務提供商形成損失。

服務的上線審批、下線通知機制須要創建完善起來，它的工做原理以下所示：

除了以上介紹的經常使用服務治理措施，線下服務治理還包括：1.業務的梳理、服務劃分原則和方法論；2.服務跨團隊協做流程、準則、工具和方法論；3.服務的接口兼容性原則和規範；4.其它...線下服務治理依團隊和業務不一樣，需求也不一樣，須要業務團隊和服務框架團隊長期梳理、實踐和優化，纔可以提高線下服務治理的效率，它的建設是個長期過程，並不是一蹴而就。

雲端自治理

微服務彈性伸縮

基於PaaS雲化平臺或者Docker容器服務，能夠實現基於負載的微服務彈性伸縮。

基於PaaS平臺部署微服務架構示例以下：

基於Docker容器部署微服務示例以下：

基於雲的動態資源調度，能夠實現微服務的彈性伸縮：基於CPU、內存、磁盤、網絡帶寬等資源佔用率的彈性伸縮策略。當VM或者容器的資源佔用達到設置的閾值以後，自動執行擴容策略，動態建立微服務的運行環境，部署並運行新的微服務實例。基於業務指標的彈性伸縮策略。例如微服務的平均時延、吞吐量、成功率等。經過對微服務的性能指標進行分佈式採集、彙總和計算，判斷業務指標是否達到伸縮閾值，若是達到，則自動觸發微服務的伸縮流程，執行彈性伸縮。用戶自定義的彈性伸縮策略。能夠對基於資源佔用率的伸縮策略和基於業務指標的伸縮策略作組合，實現更復雜的彈性伸縮。基於雲平臺的微服務彈性伸縮流程以下所示：

E2E微服務生命週期管理

利用雲平臺對資源的動態編排和調度，能夠實現基礎設施自動化。利用ALM（應用生命週期管理）能夠實現微服務的E2E生命週期管理。

基於Docker容器的微服務基礎設施自動化流程以下所示：

微服務上線運行以後，利用雲平臺的ALM服務，能夠對微服務進行上下線、升級、回滾等生命週期管理操做：

基於雲平臺提供的微服務生命週期管理服務，能夠實現海量微服務的高效部署、升級和管理，而不須要關心物理基礎設施的環境準備和安裝，以及資源規劃等，極大的提高了微服務的上線運行效率，下降了微服務的管理成本。

微服務治理全景圖

微服務治理涵蓋的範圍很是廣，不少治理手段也須要業務在實際開發中積累和沉澱，並無統一的標準，這就是實施微服務治理的困難之處。

在微服務治理髮展的同時，雲化和容器化革命也正在進行，結合雲平臺的敏捷性和彈性資源調度，微服務治理將逐步由人工治理向自動化治理演進。

微服務治理整體結構圖以下所示：

Q&A

Q1：請問在實際使用時，前端網關有什麼來源框架，還有分佈式跟蹤系統，有推薦嗎？

A1: 前端網關，開源的有WSO2，基於Java語言的，GO語言的有Tyk。

 

Q2:能展開講一下優先級調度麼

A1：分佈式跟蹤系統打印 埋點日誌比較簡單，可是複雜的是後端的大數據分析。採集能夠基於FLume等，後端的分析能夠基於HBase   Spark

 

Q3:請教一下，對應用層擴容很容易，不少時候一個服務慢了，根本緣由是依賴的存儲  數據庫  外部接口的緣由，這個時候對應用層擴容解決不了問題，paas的擴容還有什麼意義呢？  數據庫擴容  涉及數據遷移，應用層鏈接池更新等等  paas不能簡單擴容

A3：PaaS層的擴容一般會有幾種策略：

一、基於資源使用率的擴容；

二、基於服務性能指標的擴容；

三、混合模式；

四、業務自定義擴容策略，這種場景一般是級聯擴容，也就是應用依賴的服務也須要同時作擴容，例如緩存、MQ等。可是，不是全部的PaaS都支持策略4。

 

Q4:怎樣從傳統的系統轉化到雲服務上，在系統設計及技術架構有什麼須要注意點。

A4: 不知道你講的傳統系統是否是指的非雲系統。非雲應用轉到雲化服務有幾點設計考慮：一、服務化；二、利用雲的動態性，例如彈性伸縮等；三、統一配置，使用雲化的統一配置服務。

 

Q5：那mq 緩存 數據庫的client都要改造  支持後端自動發現了，好多中間價的client都是配置死的，有可分享的開源實現麼

A5：包括前端的URL地址，MQ服務端的URL等，雲化以後，MQ等服務也是一種雲化服務，例如AWS的S3服務。在咱們的實踐中，原來的本地配置都統一放到了配置服務上，它是基於ZK的雲化統一配置服務，地址都是從註冊中心讀取的，而不是本地配置。這樣，就能夠支持動態發現。

 

Q6：應用服務化後，涉及服務與服務之間的遠程rpc，請問數據傳輸過程當中通常採用哪一種系列化方式，之間的優缺點都有哪些？還有場景

A6： 幾種場景考量：一、若是服務看中的是標準化、開放性，對性能要求不是特別苛刻。則建議採用 Restful   JSON的方式；二、若是是內部各模塊之間的服務化調用，對性能、時延要求很是高，則建議採用二進制   私有協議的方式，例如能夠參考或者選擇ProtocolBuf、Thrift等。一般而言，服務跟協議是解耦的，也就是說某個服務，能夠同時發佈成多種協議。