網易雲原生架構實踐之服務治理

時間 2019-11-18

標籤網易原生架構實踐服務治理欄目系統架構简体版

原文原文鏈接

本文由網易雲發佈。html

雲原生（Cloud Native）的高階實踐是分佈式服務化架構。一個良好的服務化架構，須要良好的服務發現、服務治理、服務編排等核心能力。本文爲讀者解析網易雲的服務治理策略及其典型實踐。算法

網易雲微服務架構

在優化了版本控制策略，研發並集成了自動化構建和發佈工具，實現「項目工程化」以後，網易雲開始了分佈式服務化架構的探索，但願解決支撐海量用戶及產品高速迭代需求下的軟件研發成本高、測試部署維護代價大、擴展性差等問題。安全

業務模塊的獨立，天然而然造成了基於 Docker 容器的微服務架構。網易雲簡化的微服務架構如圖 1 所示，包括服務註冊與發現、分佈式配置管理、負載均衡、服務網關、斷路器等模塊。網絡

圖 1 微服務架構架構

一個產品一般由多個應用組成，容器只是提供一個應用服務的能力，須要把多個應用組合編排起來才能提供服務。在服務編排上，網易雲選擇開源的 Kubernetes 。Kubernetes 是自動化編排容器應用的開源平臺，這些操做不只包括部署、調度和節點集羣間擴展，還包括服務發現和配置服務等架構支持的基礎能力。Kubernetes 對應用層面的關注、對微服務、雲原生的支持及其生態，正是網易雲所須要的。併發

網易雲服務治理策略

在微服務架構下，隨着業務逐漸複雜，服務數量愈來愈多，引入的問題也愈來愈複雜。如何在業務發展的同時保障服務的 SLA 和最大化利用機器資源，是擺在網易雲面前一個很大的挑戰。咱們須要一個統一的服務治理機制對全部服務進行統一管控，保障服務正常運行。負載均衡

服務治理範圍覆蓋了服務的整個生命週期，從服務建模開始，到開發、測試、審批、發佈、運行時管理，以及最後的下線。咱們一般說的服務治理主要是指服務運行時的治理，一個好的服務治理框架要遵循「在線治理，實時生效」原則，只有這樣才能真正保障服務總體質量。下面介紹服務治理策略在服務運行時的應用。框架

服務愈來愈多，配置項愈來愈多，利用統一註冊中心解決服務發現和配置管理問題。
服務之間存在多級依賴，靠人工已經沒法理清，還要避免潛在的循環依賴問題，咱們須要依賴管理機制，支持導出依賴關係圖。
服務的性能數據和健康狀態數據是服務治理的重要依據，好比訪問量、響應時間、併發數等，所以須要有監控、健康檢查和統計服務。
當一個服務的訪問量愈來愈大，須要對服務進行擴容，而後在客戶端進行流量引導和優先級調度。
面對突發流量，已經沒法經過擴容解決問題時，要啓用流量控制，甚至服務降級。
隨着業務持續發展，要提早進行容量規劃，結合服務監控數據，以確認當前系統容量可否支撐更高水位的壓力。
等愈來愈多的微服務上線以後，從安全角度看，咱們須要實施明確的權限控制策略和服務上下線流程。
經過一系列的服務治理策略，最終經過數據證實系統對外承諾的 SLA。

網易雲典型服務治理實踐

彈性擴縮容

基於負載均衡的應用彈性伸縮方案，只要將應用系統設計成無狀態，在須要伸縮的時候修改負載均衡代理配置，就能夠方便地水平擴容應用系統，提升系統承載能力。分佈式

在雲原生應用架構裏，咱們其實有更多的選擇。對於無狀態服務，配合雲平臺提供的 AutoScaling 能力，可以快速彈性擴容，實施 DevOps。在這裏，彈性擴縮容是一種重要的服務治理手段。網易雲選擇基於 Kubernetes 的 AutoScaling 機制實現彈性伸縮。微服務

網易雲採用 Kubernetes 實現應用管理，而 Kubernetes 的 Horizontal Pod Autoscaler （HPA）組件專門設計用於應用彈性擴容的控制器，它經過按期輪詢 Pod 的狀態（CPU、內存、磁盤、網絡，或者自定義的應用指標），當 Pod 的狀態連續達到提早設置的閾值時，就會觸發副本控制器，修改其應用副本數量，使得 Pod 的負載從新迴歸到正常範圍以內。如圖 2 所示。

圖 2 基於 Kubernetes 的彈性擴縮容

例如促銷活動服務的應用層是一個無狀態應用，當前有兩個副本，咱們把彈性擴容的 CPU 使用率閾值設置爲 50%。可是促銷當天涌入的流量遠遠超過預期，使得兩個副本的 CPU 使用率分別達到了 80%以上，HPA 控制器監控到這種變化，因而通知副本控制器將促銷活動服務的副本數量升到 4 個。當流量峯值事後，4 個副本的 CPU 使用率慢慢降到 10% 如下，HPA 控制器計算得出兩個副本便可知足負載要求，因而通知副本控制器將應用副本數量變爲 2。

HPA控制器的副本伸縮算法能夠參考Kubernetes文檔。

熔斷機制

微服務架構中，各服務經過服務發現的方式互相依賴，雖然從單個服務看來能得到很是好的隔離性，不會由於某個進程或者服務宕掉對其餘服務形成直接影響，可是從業務角度來看，單個服務實例故障仍是可能形成業務訪問出現問題，輕則影響服務調用方出現延遲和負載上升，重則形成業務總體異常。

好比，一個簡單的電商場景，用戶經過網站下單購買一件商品，首先將調用訂單服務生成一個訂單，調用支付網關完成支付，最後調用庫存服務將庫存量減去。在這一系列服務調用過程當中，任何一個子服務由於網絡故障或者服務自己異常等狀況出現，都會致使用戶購物車服務線程阻塞，不只影響到用戶此次購物行爲失敗，若是此時有大量用戶同時訪問，還會形成後續請求的失敗。這是微服務調用中很容易出現的級聯失敗。針對這個問題，網易雲引入了服務治理中的熔斷機制，或者叫斷路器模式，斷路器在系統架構中的應用如圖2所示。

圖3 斷路器在系統架構中的應用

斷路器是一個開關，本意是指電路系統上的一種保護線路電流過載的一種裝置，當線路中電流太大或者發生短路時，斷路器開關打開，電路切斷，防止引發更加嚴重的後果。引伸到微服務治理策略中，斷路器的做用就是避免故障或者異常在微服務調用鏈中蔓延。它的工做機制如圖4 所示。

圖4 服務治理中的熔斷機制

服務調用方在嘗試調用遠端服務時，同時提供一個 fallback 方法，就是當遠端服務出現故障時，調用 fallback 方法，快速返回結果，避免級聯效應，使故障隔離。同時，斷路器應該須要提供一個閾值開關，當遠端服務的調用連續失敗次數超過某個閾值時，服務調用方直接調用 fallback 方法，再也不請求遠端服務。等遠端服務恢復後，再恢復正常調用流程。

在一些場景下，網易雲藉助 Netflix OSS 的 Hystrix 實現斷路器。Hystrix 是 Netflix 開源的庫，主要提供分佈式服務間交互的延時容忍與容錯機制，隔離了服務間的訪問入口，防止整個鏈路上某服務調用不通致使系統雪崩，提供 fallback（降級）機制以便加強系統彈性。另外，還提供了服務治理與監控功能。

Hystrix 主要提供如下幾個功能。

爲服務提供保護，控制延遲和故障。
避免複雜系統的級聯故障。
快速失敗與高效恢復。
實時監控、報警與操做控制。

代碼示例以下。

@Component
public class ShoppingService {
@HystrixCommand(fallbackMethod = "payFail")
public Object pay(Map parameters) {
//遠程調用支付服務
return;
}
public Object payFail(Map parameters) { 
//支付失敗，訂單狀態改成未支付
return;
}
}

購物服務調用 ShoppingService 的 pay()方法實現支付，支付成功則訂單狀態置爲待發貨，若支付過程當中支付網關服務出現異常，致使 pay()方法調用失敗，ShoppingService 的斷路器會調用 payFail()方法實現失敗處理，將訂單狀態改成未支付狀態，後續用戶能夠經過界面選擇訂單繼續支付。若是支付網關服務較長時間沒法恢復，當 pay()連續失敗次數超過閾值，熔斷機制開啓，斷路器打開，每次對 ShoppingService 的 pay()方法的調用退化爲對payFail()方法的調用，直至支付網關服務恢復正常。熔斷機制在服務治理中的做用主要體如今對故障的隔離上，避免調用出現鏈式雪崩。

服務降級

服務降級也是服務治理策略中重要的一環。當業務出現流量峯值，或者系統中某個組成部分出現故障，保證系統總體功能仍然可用，咱們可能須要停掉一些不過重要的周邊系統，從而保證核心服務的 SLA。好比電商系統在進行大促時，每每會棄車保帥，優先選擇中止「猜你喜歡」、「評論」等不那麼重要的系統，保障購物車、支付系統可用。在微服務架構裏，每一個服務不管是服務提供方仍是服務調用方，都應該圍繞 SLA 制定不一樣的降級策略。按降級粒度粗細咱們能夠制定接口降級、功能降級、服務降級。