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

李林鋒，資深架構專家，超過10年Java NIO通信框架、平臺中間件架構設計和開發經驗，開源框架Netty中國推廣者。精通Netty、Mina、RPC框架、企業ESB總線、分布式服務框架、云計算等技術，《Netty權威指南》、《分布式服務框架原理與實踐》作者，公司總裁技術創新獎獲得者

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

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

為什么需要服務治理

服務治理的技術演進歷程

云端微服務治理框架設計

1

? ?

為什么需要服務治理？

1.1

? ?

第一、業務需求

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

著開發團隊的不斷擴大，服務的上線越來越隨意，甚至發生功能相同、服務名不同的服務同時上線。上線容易下線難，為了規范服務的上線和下線，在服務發布前，需要走服務預發布流程，由架構師或者項目經理對需要上線的服務做發布審核，審核通過的才能夠上線。為了滿足服務線下管控、保障線上高效運行，需要有一個統一的服務治理框架對服務進行統一、有效管控，保障服務的高效、健康運行。

1.2

? ?

第二、技術需求

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

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

無論采用注解還是 XML 配置的方式，如果需要在運行態動態修改服務提供者的流控閾值，都需要在本地修改配置或者修改源碼，重新打包部署并升級應用。無法實現在線、配置化的修改和動態生效。由于諸如流控閾值、服務的超時時間等無法預測出最優值，需要修改之后上線驗證，根據服務運行效果決定是否再做調整，因此經常需要反復調整，采用修改源碼-重新打包部署-應用升級的方式進行服務治理，效率低下。因此，在技術上需要一個服務治理框架，提供 Web Portal，微服務運維或者治理人員通過在線配置化的方式修改服務提供者或者消費者的屬性，可以實時動態生效。

2

? ?

服務治理的技術演進歷程

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

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

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

2.1

? ?

第一代 SOA Governance 服務治理

第一代 SOA Service GovernanceSOA Governance 的定位：面向企業 IT 系統異構服務的治理和服務生命周期管理，它治理的服務通常是 SOA 服務。傳統的 SOA Governance 包含四部分內容：

服務建模：驗證功能需求與業務需求，發現和評估當前服務，服務建模和性能需求，開發治理規劃。

服務組裝：創建服務更新計劃，創建和修改服務以滿足所有業務需求，根據治理策略評估服務，批準組裝完成。

服務部署：確保服務的質量，措施包括功能測試、性能測試和滿足度測試，批準服務部署。4.服務管理：在整個生命周期內管理和監控服務，跟蹤服務注冊表中的服務，根據服務質量等級協議（SLA）上報服務的性能 KPI 數據進行服務質量管理。

SOA Governance 工作原理圖如下所示：

傳統 SOA Governance 的主要缺點如下：

分布式服務框架的發展，內部服務框架需要統一，服務治理也需要適應新的架構，能夠由表及里，對服務進行細粒度的管控。

微服務架構的發展和業務規模的擴大，導致服務規模量變引起質變，服務治理的特點和難點也隨之發生變化。

缺少服務運行時動態治理能力，面對突發的流量高峰和業務沖擊，傳統的服務治理在響應速度、故障快速恢復等方面存在不足，無法更敏捷應對業務需求。

2.2

? ?

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

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

治理的對象：基于統一分布式服務框架開發的業務服務，與協議本身無關，治理的可以是 SOA 服務，也可以是基于內部服務框架私有協議開發的各種服務。

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

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

2.3

? ?

第三代云端微服務治理

隨著云計算的發展，DevOps 逐漸流行起來，基礎設施服務化（IaaS）為大規模、批量流水線式軟件交付提供了便利，AWS 做為全球最大的云計算解決方案提供商，在微服務云化開發和治理方面積累了非常多的經驗，具體總結如下

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

所有后端應用服務化，系統由多項服務化組件構成。

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

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

高度自動化和 DevOps 支持，一鍵式服務部署和回退。

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

嘗試基于 Docker 容器部署微服務。

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

3

? ?

云端微服務治理架構設計

云端微服務治理架構設計的目標如下：

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

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

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

服務生命周期管理：包括服務的上線審批、下線通知，服務的在線升級，以及線上和線下服務文檔庫的建設。靈活的資源調度：基于 Docker 容器，可以實現微服務的獨立部署和細粒度的資源隔離。基于云端的彈性伸縮，可以實現微服務級別的按需伸縮和故障隔離。

云端微服務治理架構設計云端微服務治理從架構上可以分為三層：

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

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

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

3.1

? ?

微服務治理 Portal

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

Portal 框架可以基于 AngularJS 等 Web 框架進行開發，它的門戶界面如下所示：可以支持同時配置多個服務注冊中心集群，對不同的微服務集群進行治理。

選擇某個微服務集群之后，就可以對該集群的微服務進行治理，界面示例如下：

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

3.2

? ?

微服務治理 SDK

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

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

服務治理接口：服務治理 Portal 調用服務治理接口，實現服務治理。例如服務降級接口、服務流控接口、服務路由權重調整接口、服務遷移接口等。服務接口與具體的協議無關，它通常基于分布式服務框架自身實現，可以是 Restful 接口，也可以是內部的私有協議；

服務治理客戶端類庫：由于服務治理服務本身通常也是基于分布式服務框架開發，因此服務治理 Portal 需要集成分布式服務框架的客戶端類庫，實現服務的自動發現和調用；

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

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

3.3

? ?

線上服務治理

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

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

第一、流量控制

當資源成為瓶頸時，服務框架需要對消費者做限流，啟動流控保護機制。流量控制有多種策略，比較常用的有：針對訪問速率的靜態流控、針對資源占用的動態流控、針對消費者并發連接數的連接控制和針對并行訪問數的并發控制。

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

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

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

連接控制：通常分布式服務框架服務提供者和消費者之間采用長連接私有協議，為了防止因為消費者連接數過多導致服務端負載壓力過大，系統需要支持針對連接數進行流控。

第二、服務降級

大促或者業務高峰時，為了保證核心服務的 SLA，往往需要停掉一些不太重要的業務，例如商品評論、論壇或者粉絲積分等。

另外一種場景就是某些服務因為某種原因不可用，但是流程不能直接失敗，需要本地 Mock 服務端實現，做流程放通。以圖書閱讀為例，如果用戶登錄余額鑒權服務不能正常工作，需要做業務放通，記錄消費話單，允許用戶繼續閱讀，而不是返回失敗。

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

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

它的處理流程如下所示：

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

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

第 3 步：通過服務查詢界面選擇需要降級的服務，注意服務的分組和版本信息，指定具體的降級策略：返回 null、返回指定異常還是執行本地 Mock 接口實現。

第 4 步：服務治理 Portal 通過服務注冊中心客戶端 SDK，將屏蔽降級指令和相關信息發送到服務注冊中心。

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

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

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

第 9 步：操作成功之后，服務注冊中心返回降級成功的應答消息，由服務治理 Portal 界面展示。

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

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

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

?????????????????

第三、服務優先級調度

當系統當前資源非常有限時，為了保證高優先級的服務能夠正常運行，保障服務 SLA，需要降低一些非核心服務的調度頻次，釋放部分資源占用，保障系統的整體運行平穩。

服務在發布的時候，可以指定服務的優先級，如果用戶沒有指定，采用默認優先級策略，它的配置如下所示：

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

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

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

微服務超時控制：由于微服務調用通常使用 RPC 方式，是同步阻塞的，因此需要設置服務調用超時時間，防止對端長時間不響應導致的應用線程掛死。超時控制支持在服務端或者消費端配置，需要支持方法級超時控制。

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

隨機：采用隨機算法進行負載均衡，通常在對等集群組網中，隨機路由算法消息分發還是比較均勻的。

輪循: 按公約后的權重設置輪循比率，到達邊界之后，繼續繞接。

服務調用時延：消費者緩存所有服務提供者的服務調用時延，周期性的計算服務調用平均時延，然后計算每個服務提供者服務調用時延與平均時延的差值，根據差值大小動態調整權重，保證服務時延大的服務提供者接收更少的消息，防止消息堆積。

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

粘滯連接: 粘滯連接用于有狀態服務，盡可能讓客戶端總是向同一提供者發起服務調用，除非該提供者宕機，再連接另一臺。

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

常用的集群容錯策略如下：

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

• Failback 策略：在很多業務場景中，消費者需要能夠獲取到服務調用失敗的具體信息，通過對失敗錯誤碼等異常信息的判斷，決定后續的執行策略，例如非冪等性的服務調用。

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

• 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 協定，給服務提供商造成損失。

服務的上線審批、下線通知機制需要建立完善起來，它的工作原理如下所示：

除了以上介紹的常用服務治理措施，線下服務治理還包括：

業務的梳理、服務劃分原則和方法論；

服務跨團隊協作流程、準則、工具和方法論；

服務的接口兼容性原則和規范；

其它...

線下服務治理依團隊和業務不同，需求也不同，需要業務團隊和服務框架團隊長期梳理、實踐和優化，才能夠提升線下服務治理的效率，它的建設是個長期過程，并非一蹴而就。

3.4

? ?

云端自治理

微服務彈性伸縮

基于 PaaS 云化平臺或者 Docker 容器服務，可以實現基于負載的微服務彈性伸縮。

基于 PaaS 平臺部署微服務架構示例如下：

基于Docker容器部署微服務示例如下：

基于云的動態資源調度，可以實現微服務的彈性伸縮：基于CPU、內存、磁盤、網絡帶寬等資源占用率的彈性伸縮策略。當VM或者容器的資源占用達到設置的閾值之后，自動執行擴容策略，動態創建微服務的運行環境，部署并運行新的微服務實例。基于業務指標的彈性伸縮策略。例如微服務的平均時延、吞吐量、成功率等。通過對微服務的性能指標進行分布式采集、匯總和計算，判斷業務指標是否達到伸縮閾值，如果達到，則自動觸發微服務的伸縮流程，執行彈性伸縮。用戶自定義的彈性伸縮策略。可以對基于資源占用率的伸縮策略和基于業務指標的伸縮策略做組合，實現更復雜的彈性伸縮。基于云平臺的微服務彈性伸縮流程如下所示：

E2E微服務生命周期管理

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

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

微服務上線運行之后，利用云平臺的ALM服務，可以對微服務進行上下線、升級、回滾等生命周期管理操作：

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

微服務治理全景圖

微服務治理涵蓋的范圍非常廣，很多治理手段也需要業務在實際開發中積累和沉淀，并沒有統一的標準，這就是實施微服務治理的困難之處。

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

微服務治理總體結構圖如下所示：

4

? ?

Q&A

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

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

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

A1：分布式跟蹤系統打印 埋點日志比較簡單，但是復雜的是后端的大數據分析。采集可以基于FLume等，后端的分析可以基于HBase ? Spark

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

A3：PaaS層的擴容通常會有幾種策略：

1、基于資源使用率的擴容；

2、基于服務性能指標的擴容；

3、混合模式；

4、業務自定義擴容策略，這種場景通常是級聯擴容，也就是應用依賴的服務也需要同時做擴容，例如緩存、MQ等。但是，不是所有的PaaS都支持策略

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

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

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

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

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

A6：幾種場景考量：

1、如果服務看中的是標準化、開放性，對性能要求不是特別苛刻。則建議采用 Restful ? JSON的方式；

2、如果是內部各模塊之間的服務化調用，對性能、時延要求非常高，則建議采用二進制 ? 私有協議的方式，例如可以參考或者選擇ProtocolBuf、Thrift等。通常而言，服務跟協議是解耦的，也就是說某個服務，可以同時發布成多種協議。

資深架構專家聊架構之道：規劃、簡化和演化

2021-07-01

從架構演進談 DDD 興起的原因以及與微服務的關系

2021-06-30

豬八戒玉華王：老碼農的7項靈魂思考

2021-06-25

架構專家梁勇：哈啰在分布式消息治理和微服務治理中的實踐

2021-06-23

總結

以上是生活随笔為你收集整理的资深架构专家讲解微服务治理的架构演进的全部內容，希望文章能夠幫你解決所遇到的問題。

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