編輯：友強

講師：李林鋒

我今天分享的主題是《微服務(wù)治理的技術(shù)演進和架構(gòu)實踐》

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

1. 為什么需要服務(wù)治理

2. 服務(wù)治理的技術(shù)演進歷程

3. 云端微服務(wù)治理框架設(shè)計

為什么需要服務(wù)治理？

第一、業(yè)務(wù)需求

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

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

第二、技術(shù)需求

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

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

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

服務(wù)治理的技術(shù)演進歷程

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

第二代以分布式服務(wù)框架為中心的服務(wù)治理：隨著電商和移動互聯(lián)網(wǎng)的快速發(fā)展，基于電商平臺的統(tǒng)一分布式服務(wù)框架的全新服務(wù)治理理念誕生，它聚焦于對內(nèi)部同構(gòu)服務(wù)的線上治理，保障線上服務(wù)的運行質(zhì)量。相比于傳統(tǒng)IT架構(gòu)的服務(wù)治理，由于服務(wù)的開發(fā)模式、部署規(guī)模、組網(wǎng)類型、業(yè)務(wù)特點等差異巨大，因此服務(wù)治理的重點也從線下轉(zhuǎn)移到了線上服務(wù)質(zhì)量保障。

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

第一代 SOA Governance服務(wù)治理

第一代SOA Service GovernanceSOA Governance的定位：面向企業(yè)IT系統(tǒng)異構(gòu)服務(wù)的治理和服務(wù)生命周期管理，它治理的服務(wù)通常是SOA服務(wù)。傳統(tǒng)的SOA Governance包含四部分內(nèi)容：1.服務(wù)建模：驗證功能需求與業(yè)務(wù)需求，發(fā)現(xiàn)和評估當前服務(wù)，服務(wù)建模和性能需求，開發(fā)治理規(guī)劃。2.服務(wù)組裝：創(chuàng)建服務(wù)更新計劃，創(chuàng)建和修改服務(wù)以滿足所有業(yè)務(wù)需求，根據(jù)治理策略評估服務(wù)，批準組裝完成。3.服務(wù)部署：確保服務(wù)的質(zhì)量，措施包括功能測試、性能測試和滿足度測試，批準服務(wù)部署。4.服務(wù)管理：在整個生命周期內(nèi)管理和監(jiān)控服務(wù)，跟蹤服務(wù)注冊表中的服務(wù)，根據(jù)服務(wù)質(zhì)量等級協(xié)議（SLA）上報服務(wù)的性能KPI數(shù)據(jù)進行服務(wù)質(zhì)量管理。

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

傳統(tǒng)SOA Governance的主要缺點如下：1.分布式服務(wù)框架的發(fā)展，內(nèi)部服務(wù)框架需要統(tǒng)一，服務(wù)治理也需要適應(yīng)新的架構(gòu)，能夠由表及里，對服務(wù)進行細粒度的管控。2.微服務(wù)架構(gòu)的發(fā)展和業(yè)務(wù)規(guī)模的擴大，導(dǎo)致服務(wù)規(guī)模量變引起質(zhì)變，服務(wù)治理的特點和難點也隨之發(fā)生變化。3.缺少服務(wù)運行時動態(tài)治理能力，面對突發(fā)的流量高峰和業(yè)務(wù)沖擊，傳統(tǒng)的服務(wù)治理在響應(yīng)速度、故障快速恢復(fù)等方面存在不足，無法更敏捷應(yīng)對業(yè)務(wù)需求。

第二代分布式服務(wù)框架服務(wù)治理

分布式服務(wù)框架的服務(wù)治理定位：面向互聯(lián)網(wǎng)業(yè)務(wù)的服務(wù)治理，聚焦在對內(nèi)部采用統(tǒng)一服務(wù)框架服務(wù)化的業(yè)務(wù)運行態(tài)、細粒度的敏捷治理體系。

治理的對象：基于統(tǒng)一分布式服務(wù)框架開發(fā)的業(yè)務(wù)服務(wù)，與協(xié)議本身無關(guān)，治理的可以是SOA服務(wù)，也可以是基于內(nèi)部服務(wù)框架私有協(xié)議開發(fā)的各種服務(wù)。

治理策略：針對互聯(lián)網(wǎng)業(yè)務(wù)的特點，例如突發(fā)的流量高峰、網(wǎng)絡(luò)延時、機房故障等，重點針對大規(guī)?？鐧C房的海量服務(wù)進行運行態(tài)治理，保障線上服務(wù)的高SLA，滿足用戶的體驗。常用的治理策略包括服務(wù)的限流降級、服務(wù)遷入遷出、服務(wù)動態(tài)路由和灰度發(fā)布等。

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

第三代云端微服務(wù)治理

隨著云計算的發(fā)展，Dev&Ops逐漸流行起來，基礎(chǔ)設(shè)施服務(wù)化（IaaS）為大規(guī)模、批量流水線式軟件交付提供了便利，AWS做為全球最大的云計算解決方案提供商，在微服務(wù)云化開發(fā)和治理方面積累了非常多的經(jīng)驗，具體總結(jié)如下

1. 全公司統(tǒng)一服務(wù)化開發(fā)環(huán)境，統(tǒng)一簡單化服務(wù)框架（Coral Service）,統(tǒng)一運行平臺，快速高效服務(wù)開發(fā)；

2. 所有后端應(yīng)用服務(wù)化，系統(tǒng)由多項服務(wù)化組件構(gòu)成。

3. 服務(wù)共享、原子化、重用。

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

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

6. 超大規(guī)模支持：后臺幾十萬個服務(wù)，成千上萬開發(fā)者同時使用，平均每秒鐘有1-2個服務(wù)部署。

7. 嘗試基于Docker容器部署微服務(wù)。

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

云端微服務(wù)治理架構(gòu)設(shè)計

云端微服務(wù)治理架構(gòu)設(shè)計的目標如下：

1. 防止業(yè)務(wù)服務(wù)架構(gòu)腐化：通過服務(wù)注冊中心對服務(wù)強弱依賴進行分析，結(jié)合運行時服務(wù)調(diào)用鏈關(guān)系分析，梳理不合理的依賴和調(diào)用路徑，優(yōu)化服務(wù)化架構(gòu)，防止代碼腐化。

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

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

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

5. 靈活的資源調(diào)度：基于Docker容器，可以實現(xiàn)微服務(wù)的獨立部署和細粒度的資源隔離。基于云端的彈性伸縮，可以實現(xiàn)微服務(wù)級別的按需伸縮和故障隔離。

云端微服務(wù)治理架構(gòu)設(shè)計云端微服務(wù)治理從架構(gòu)上可以分為三層：

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

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

• 第三層：微服務(wù)治理服務(wù)實現(xiàn)層，微服務(wù)治理服務(wù)，通過服務(wù)注冊中心，刷新服務(wù)治理屬性，同時通知服務(wù)提供者和消費者集群各節(jié)點刷新內(nèi)存，使服務(wù)治理Portal下發(fā)的服務(wù)治理策略動態(tài)生效。

1.  微服務(wù)治理Portal

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

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

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

點擊查看，可以查看微服務(wù)的狀態(tài)，以及各種性能指標。點擊治理，彈出選擇菜單，可以對選擇的微服務(wù)進行相關(guān)的治理操作。

2.  微服務(wù)治理SDK

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

1. 服務(wù)治理元數(shù)據(jù)：服務(wù)治理元數(shù)據(jù)主要包括服務(wù)治理實體對象，包括服務(wù)模型、應(yīng)用模型、治理組織模型、用戶權(quán)限模型、數(shù)據(jù)展示模型等。元數(shù)據(jù)模型通過Data Mapper和模型擴展，向上層界面屏蔽底層服務(wù)框架的數(shù)據(jù)模型，實現(xiàn)展示層和服務(wù)框架的解耦，元數(shù)據(jù)也可以用于展示界面的定制擴展；

2. 服務(wù)治理接口：服務(wù)治理Portal調(diào)用服務(wù)治理接口，實現(xiàn)服務(wù)治理。例如服務(wù)降級接口、服務(wù)流控接口、服務(wù)路由權(quán)重調(diào)整接口、服務(wù)遷移接口等。服務(wù)接口與具體的協(xié)議無關(guān)，它通常基于分布式服務(wù)框架自身實現(xiàn)，可以是Restful接口，也可以是內(nèi)部的私有協(xié)議；
   

3. 服務(wù)治理客戶端類庫：由于服務(wù)治理服務(wù)本身通常也是基于分布式服務(wù)框架開發(fā)，因此服務(wù)治理Portal需要集成分布式服務(wù)框架的客戶端類庫，實現(xiàn)服務(wù)的自動發(fā)現(xiàn)和調(diào)用；

4. 調(diào)用示例：客戶端SDK需要提供服務(wù)治理接口的參數(shù)說明、注意事項以及給出常用的調(diào)用示例，方便前端開發(fā)人員使用；

5. 集成開發(fā)指南：服務(wù)治理SDK需要提供集成開發(fā)指南，指導(dǎo)使用者如何在開發(fā)環(huán)境中搭建、集成和使用服務(wù)治理SDK。

3.  線上服務(wù)治理

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

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

第一、流量控制

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

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

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

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

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

4.  服務(wù)降級

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

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

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

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

它的處理流程如下所示：

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

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

第3步：通過服務(wù)查詢界面選擇需要降級的服務(wù)，注意服務(wù)的分組和版本信息，指定具體的降級策略：返回null、返回指定異常還是執(zhí)行本地Mock接口實現(xiàn)。第4步：服務(wù)治理Portal通過服務(wù)注冊中心客戶端SDK，將屏蔽降級指令和相關(guān)信息發(fā)送到服務(wù)注冊中心。

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

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

第8步：服務(wù)提供者集群接收到屏蔽降級事件通知之后，獲取相關(guān)內(nèi)容，更新本地的服務(wù)發(fā)布緩存信息，將對應(yīng)的服務(wù)降級屬性修改為屏蔽降級。

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

第10步：運維人員查詢服務(wù)提供者列表，查看服務(wù)狀態(tài)。

第11步：服務(wù)注冊中心返回服務(wù)狀態(tài)為屏蔽降級狀態(tài)。

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

5.  服務(wù)優(yōu)先級調(diào)度

當系統(tǒng)當前資源非常有限時，為了保證高優(yōu)先級的服務(wù)能夠正常運行，保障服務(wù)SLA，需要降低一些非核心服務(wù)的調(diào)度頻次，釋放部分資源占用，保障系統(tǒng)的整體運行平穩(wěn)。

服務(wù)在發(fā)布的時候，可以指定服務(wù)的優(yōu)先級，如果用戶沒有指定，采用默認優(yōu)先級策略，它的配置如下所示：

服務(wù)的優(yōu)先級可以采用傳統(tǒng)的低、中、高三級配置策略，每個級別的執(zhí)行比例可以靈活配置，如下所示：

服務(wù)發(fā)布通過擴展priority屬性的方式指定優(yōu)先級，服務(wù)提供者將優(yōu)先級屬性注冊到服務(wù)注冊中心并通知消費者，由消費者緩存服務(wù)的優(yōu)先級，根據(jù)不同的優(yōu)先級策略進行調(diào)度。服務(wù)治理Portal通過動態(tài)修改注冊中心指定服務(wù)priority屬性的方式，實現(xiàn)運行態(tài)動態(tài)調(diào)整微服務(wù)的優(yōu)先級。

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

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

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

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

2. 輪循:按公約后的權(quán)重設(shè)置輪循比率，到達邊界之后，繼續(xù)繞接。

3. 服務(wù)調(diào)用時延：消費者緩存所有服務(wù)提供者的服務(wù)調(diào)用時延，周期性的計算服務(wù)調(diào)用平均時延，然后計算每個服務(wù)提供者服務(wù)調(diào)用時延與平均時延的差值，根據(jù)差值大小動態(tài)調(diào)整權(quán)重，保證服務(wù)時延大的服務(wù)提供者接收更少的消息，防止消息堆積。

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

5. 粘滯連接:粘滯連接用于有狀態(tài)服務(wù)，盡可能讓客戶端總是向同一提供者發(fā)起服務(wù)調(diào)用，除非該提供者宕機，再連接另一臺。

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

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

1. Failover策略:服務(wù)調(diào)用失敗自動切換策略指的是當發(fā)生RPC調(diào)用異常時，重新選路，查找下一個可用的服務(wù)提供者。通?？梢耘渲檬∏袚Q的最大次數(shù)和間隔周期，以防止E2E服務(wù)調(diào)用時延過大。  

2. Failback策略：在很多業(yè)務(wù)場景中，消費者需要能夠獲取到服務(wù)調(diào)用失敗的具體信息，通過對失敗錯誤碼等異常信息的判斷，決定后續(xù)的執(zhí)行策略，例如非冪等性的服務(wù)調(diào)用。

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

4. Failfast策略：在業(yè)務(wù)高峰期，對于一些非核心的服務(wù)，希望只調(diào)用一次，失敗也不再重試，為重要的核心服務(wù)節(jié)約寶貴的運行資源。此時，快速失敗是個不錯的選擇。

服務(wù)灰度發(fā)布：灰度發(fā)布是指在黑與白之間，能夠平滑過渡的一種發(fā)布方式。AB test就是一種灰度發(fā)布方式，讓一部用戶繼續(xù)用A，一部分用戶開始用B，如果用戶對B沒有什么反對意見，那么逐步擴大范圍，把所有用戶都遷移到B上面來。灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時候就可以發(fā)現(xiàn)、調(diào)整問題，以保證其影響度。

基于微服務(wù)的多版本管理機制   灰度路由策略，即可實現(xiàn)基于業(yè)務(wù)規(guī)則的灰度發(fā)布。

多版本管理：服務(wù)上線之后，隨著業(yè)務(wù)的發(fā)展，需要對功能進行變更，或者修復(fù)線上的BUG，服務(wù)升級之后，往往需要對服務(wù)做多版本管理。服務(wù)多版本管理是分布式服務(wù)框架的重要特性，它涉及到服務(wù)的開發(fā)、部署、在線升級和服務(wù)治理。

調(diào)用分組管理：可以對服務(wù)按照業(yè)務(wù)領(lǐng)域、部署的DC信息、服務(wù)提供商等角度對微服務(wù)進行群組化管理，同群組之間的微服務(wù)可以自由調(diào)用，跨群組的微服務(wù)需要進行審批和授權(quán)，以實現(xiàn)不同分組之間的微服務(wù)隔離。不同分組之間可以有同名同接口的微服務(wù)的不同實現(xiàn)，分組信息也是服務(wù)路由的一個因子。

全在線服務(wù)文檔

相對于平臺產(chǎn)品，業(yè)務(wù)服務(wù)的升級和修改非常頻繁，傳統(tǒng)依靠Java DOC進行接口說明和傳遞的方式，往往會因為缺乏文檔建設(shè)或API DOC沒有及時刷新，導(dǎo)致消費者拿到的接口定義說明不準確。相比于沒有文檔，拿到過時、錯誤的API DOC文檔對使用者的危害更大。

為了解決這個問題，需要建立服務(wù)文檔中心，方便線上運維人員查看和多團隊之間的協(xié)作，它的工作原理如下：

可以基于Swagger UI，構(gòu)建微服務(wù)在線文檔庫，如下所示：

可以參考如下鏈接：https://github.com/swagger-api/swagger-ui

服務(wù)上線審批下線通知機制

當團隊規(guī)模擴大之后，會劃分成平臺基線組、業(yè)務(wù)定制組等不同研發(fā)團隊，一些團隊甚至跨多地協(xié)同開發(fā)和運維。服務(wù)的上線和下線必須要嚴格管控起來，一旦不合格的服務(wù)上線并被消費者消息，再想下線就非常困難了。

對于需要下線的服務(wù)管控也很重要，有些服務(wù)雖然調(diào)用頻次不高，業(yè)務(wù)量也不大。但是如果貿(mào)然下線，很有可能導(dǎo)致依賴它的消費者業(yè)務(wù)調(diào)用失敗，這會違反服務(wù)的SLA協(xié)定，給服務(wù)提供商造成損失。

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

除了以上介紹的常用服務(wù)治理措施，線下服務(wù)治理還包括：1.業(yè)務(wù)的梳理、服務(wù)劃分原則和方法論；2.服務(wù)跨團隊協(xié)作流程、準則、工具和方法論；3.服務(wù)的接口兼容性原則和規(guī)范；4.其它...線下服務(wù)治理依團隊和業(yè)務(wù)不同，需求也不同，需要業(yè)務(wù)團隊和服務(wù)框架團隊長期梳理、實踐和優(yōu)化，才能夠提升線下服務(wù)治理的效率，它的建設(shè)是個長期過程，并非一蹴而就。

云端自治理

微服務(wù)彈性伸縮

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

基于PaaS平臺部署微服務(wù)架構(gòu)示例如下：

基于Docker容器部署微服務(wù)示例如下：

基于云的動態(tài)資源調(diào)度，可以實現(xiàn)微服務(wù)的彈性伸縮：基于CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)帶寬等資源占用率的彈性伸縮策略。當VM或者容器的資源占用達到設(shè)置的閾值之后，自動執(zhí)行擴容策略，動態(tài)創(chuàng)建微服務(wù)的運行環(huán)境，部署并運行新的微服務(wù)實例。基于業(yè)務(wù)指標的彈性伸縮策略。例如微服務(wù)的平均時延、吞吐量、成功率等。通過對微服務(wù)的性能指標進行分布式采集、匯總和計算，判斷業(yè)務(wù)指標是否達到伸縮閾值，如果達到，則自動觸發(fā)微服務(wù)的伸縮流程，執(zhí)行彈性伸縮。用戶自定義的彈性伸縮策略?？梢詫谫Y源占用率的伸縮策略和基于業(yè)務(wù)指標的伸縮策略做組合，實現(xiàn)更復(fù)雜的彈性伸縮?；谠破脚_的微服務(wù)彈性伸縮流程如下所示：

E2E微服務(wù)生命周期管理

利用云平臺對資源的動態(tài)編排和調(diào)度，可以實現(xiàn)基礎(chǔ)設(shè)施自動化。利用ALM（應(yīng)用生命周期管理）可以實現(xiàn)微服務(wù)的E2E生命周期管理。

基于Docker容器的微服務(wù)基礎(chǔ)設(shè)施自動化流程如下所示：

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

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

微服務(wù)治理全景圖

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

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

微服務(wù)治理總體結(jié)構(gòu)圖如下所示：

Q&A

Q1：請問在實際使用時，前端網(wǎng)關(guān)有什么來源框架，還有分布式跟蹤系統(tǒng)，有推薦嗎？

A1: 前端網(wǎng)關(guān)，開源的有WSO2，基于Java語言的，GO語言的有Tyk。

Q2:能展開講一下優(yōu)先級調(diào)度么

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

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

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

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

2、基于服務(wù)性能指標的擴容；

3、混合模式；

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

Q4:怎樣從傳統(tǒng)的系統(tǒng)轉(zhuǎn)化到云服務(wù)上，在系統(tǒng)設(shè)計及技術(shù)架構(gòu)有什么需要注意點。

A4: 不知道你講的傳統(tǒng)系統(tǒng)是不是指的非云系統(tǒng)。非云應(yīng)用轉(zhuǎn)到云化服務(wù)有幾點設(shè)計考慮：1、服務(wù)化；2、利用云的動態(tài)性，例如彈性伸縮等；3、統(tǒng)一配置，使用云化的統(tǒng)一配置服務(wù)。

Q5：那mq 緩存 數(shù)據(jù)庫的client都要改造  支持后端自動發(fā)現(xiàn)了，好多中間價的client都是配置死的，有可分享的開源實現(xiàn)么

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

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

A6： 幾種場景考量：1、如果服務(wù)看中的是標準化、開放性，對性能要求不是特別苛刻。則建議采用 Restful   JSON的方式；2、如果是內(nèi)部各模塊之間的服務(wù)化調(diào)用，對性能、時延要求非常高，則建議采用二進制   私有協(xié)議的方式，例如可以參考或者選擇ProtocolBuf、Thrift等。通常而言，服務(wù)跟協(xié)議是解耦的，也就是說某個服務(wù)，可以同時發(fā)布成多種協(xié)議。

中生代技術(shù)

連接技術(shù)大咖的橋梁
促進科技技術(shù)的交流