原標題：有了這三個錦囊，再也不用擔心微服務治理了

微服務作為云原生時代的重要IT理念，正在眾多企業(yè)中實踐應用。隨之而來的問題是，采用什么樣的微服務治理策略，能夠確保微服務架構的可用性、敏捷性？為此，百度智能云從運維者的角度，編寫了3個錦囊妙計，確保每一個微服務都能在正確的“位置”高效運行。

這三個錦囊分別是：路由、限流和熔斷。不過，在討論微服務治理之前，我們可以先明確一下微服務的定義。

用積木來理解微服務治理

業(yè)界對微服務有很多種定義，其核心思想都大同小異。這里引述一下最早提出微服務定義的James Lewis 和 Martin Fowler關于微服務架構的闡述。

定義：“將單個應用程序拆分成多個獨立運行的小型服務；服務間基于輕量級機制通信，比如基于Http協(xié)議的Restful API；每個服務承擔獨立的業(yè)務功能，并且能夠獨立部署；服務通過去中心化的方式進行管理；服務可以各自使用不同的編程語言，并使用不同的數(shù)據(jù)存儲技術?！?/p>

其實我們可以再“翻譯”一下，將開發(fā)一個微服務架構的應用程序比喻成搭建一個樂高機器人，那么微服務架構如下。

• 將一個完整的機器人，拆分成很多個可以獨立使用的樂高積木塊
• 積木塊之間不需要通過膠水黏合，而是使用可以隨時插拔的標準接口
• 每個積木塊都承擔獨立的功能，比如說用來組成頭部、起到連接作用等
• 任意兩塊積木都可以直接拼接，不需要一個“集成板”之類的中間組件
• 每塊積木只需要提供標準的接口即可，材料、顏色和大小等都可以各不相同

這樣一來，微服務架構的優(yōu)勢也就一目了然：任何一個服務都是可以替換的，單個服務的損壞不會導致整個系統(tǒng)的崩潰，同時整個系統(tǒng)的可擴展性也得到了大大提升，可以在不破壞系統(tǒng)運行的前提下隨時進行服務的增減和升級。

當我們系統(tǒng)中的服務數(shù)量越來越多，服務之間的組合關系越來越復雜時，如何高效地管理這些服務，以確保每個服務都在正確的“位置”運行，并且隨時替換或者升級某些“損壞”的服務呢？

這就是百度智能云CNAP（云原生微服務應用平臺）為微服務架構的運維者提供了3個錦囊妙計的初衷。

錦囊一：用路由控制流量

CNAP中的【路由】規(guī)則用于管理服務間的通信鏈路。微服務的管理其實比搭建樂高積木更復雜，因為一塊樂高積木最多與和它相鄰的幾塊積木拼接，但是一個系統(tǒng)中的服務卻可以與系統(tǒng)中任意一個其它服務產(chǎn)生通信。

通過合理配置路由，可以解決微服務架構中的兩個問題：

1、讓服務A訪問正確的服務B，就好比積木A用來組成頭部，那它就應該與組成身體的積木B拼接，而不應該錯誤拼接到組成手臂的積木C上。

2、服務間通過正確的實例互相訪問。一個服務往往會同時運行在多個實例上（實例即物理資源的單位），就像一塊樂高積木上通常會有很多個接口。那么路由規(guī)則可以指定當服務A訪問服務B時，流量應該具體從服務A的哪些實例出發(fā)，流入到服務B的哪些實例中去

如上圖所示，路由規(guī)則主要由【流量來源】和【流量目的】兩部分組成。和拼裝樂高積木一樣，我們通常會拿起一個積木A（流量目的），然后去系統(tǒng)中找另外一個需要拼接到A上面的積木B（流量來源）。

流量來源即訪問發(fā)起的服務，我們通常稱之為Consumer（服務消費者）。需要先通過服務名找到所需的Consumer，然后通過一組篩選規(guī)則來定位Consumer上產(chǎn)生流量的一組具體實例。

流量目的即接受訪問的服務，我們通常稱之為Provider（服務提供者）。Provider在一條路由規(guī)則中是不變的（就是我們先拿到手上的那塊積木），只需要通過篩選規(guī)則來定位接受流量的一組實例。由于流量最終要被分配到某個具體實例中，所以路由規(guī)則中還需要指定流量分配的策略和權重（比如可根據(jù)實例負載情況分配流量權重）。

有了路由規(guī)則，服務間就可以通過正確的方式互相訪問，“頭部”可以拼接到“身體”，“身體”可以連接到“四肢”，從而在龐大復雜的微服務架構中建立起井然有序的拓撲關系。

錦囊二：合理制定限流規(guī)則

樂高積木的拼接僅僅是物理上的連接，但是微服務之間一旦建立起路由，就意味著會有數(shù)據(jù)在服務之間流通。由于不同服務可以提供的資源和對數(shù)據(jù)流量的承載能力不盡相同，為了防止單個Consumer占用Provider過多的資源，或者突發(fā)的大流量沖擊導致Provider故障。CNAP的【限流】規(guī)則用來限定從Consumer到Provider訪問流量，起到保護Provider服務的作用。

限流規(guī)則分為【流量來源】和【限流對象】兩部分。流量來源規(guī)定了從哪些服務或者哪些實例產(chǎn)生的流量需要被限制，可以通過多個篩選條件來確認一組實例。限流對象則用來配置所選Provider中接收流量的具體實例和方法（方法在服務中用來對請求進行處理，一個方法往往用來實現(xiàn)一個具體的業(yè)務邏輯），并且限定該方法可以接收來自流量來源的請求QPS上限。

限流規(guī)則就像是城市路網(wǎng)中的交通管制，通過對不同路段不同車道限制單位時間通行車輛數(shù)，保障整個交通路網(wǎng)的健康運轉(zhuǎn)。合理地配置限流規(guī)則，可以讓服務資源能夠更加合理地分配給不同的請求者，也預防了流量波動可能引發(fā)的服務故障甚至宕機。

錦囊三：熔斷降級防止“雪崩”

在服務治理中，雖然我們可以通過限流規(guī)則盡量避免服務承受過高的流量，但是在實際生產(chǎn)中服務故障依然難以完全避免。當整個系統(tǒng)中當某些服務產(chǎn)生故障時，如果不及時采取措施，這種故障就有可能因為服務之間的互相訪問而被傳播開來，最終導致故障規(guī)模的擴大，甚至導致整個系統(tǒng)奔潰，這種現(xiàn)象我們稱之為“雪崩”。

熔斷降級其實不只是服務治理中，在金融行業(yè)也有很廣泛的應用。比如當股指的波動幅度超過規(guī)定的熔斷點時，交易所為了控制風險采取的暫停交易措施。CNAP提供了服務熔斷降級的能力，用來避免微服務架構中因為少量服務故障而引發(fā)的服務“雪崩”。

與路由和限流不同，熔斷規(guī)則是在預先選定了Consumer后，配置該Consumer在不同Provider發(fā)生故障時的熔斷策略。因此熔斷對象（即Consumer）是固定的，需要通過一組篩選條件指定該Consumer中發(fā)起請求的實例，然后選擇需要熔斷的Provider服務以及該服務提供的具體方法。

CNAP支持自動熔斷和手動熔斷，在設置自動熔斷的情況下，可以根據(jù)指定的熔斷條件觸發(fā)時（如在某個時間窗口內(nèi)異常返回超過某個比例），自動熔斷一段時間內(nèi)從Consumer到Provider之間的所有流量，從而實現(xiàn)對Consumer的保護。

熔斷機制是微服務架構中的“交通管制”，一旦高速公路上發(fā)生交通事故時立即對某個路段或車道進行封禁，從而避免事故進一步擴大。合理利用熔斷規(guī)則可以大大提升整個微服務架構的健壯性，降低系統(tǒng)性風險和可能發(fā)生的事故規(guī)模。

結束語：更多功能正在上線

路由、限流、熔斷，這三個百度智能云所提供的微服務治理錦囊你是否已經(jīng)查收了呢？其實這還只是CNAP的微服務治理能力中的冰山一角，我們還有微服務的監(jiān)控與報警、服務拓撲與鏈路查詢、異常請求分析等大量功能可以幫助你搭建更加強大的微服務架構。

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。