本文由 網易雲 發布。
雲原生（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
public object payfail(map parameters)
}
其中，功能降級和服務降級可以通過熔斷機制和斷路器實現。
本文節選自網易雲基礎服務架構團隊所著《雲原生應用架構實踐》，有改動。
了解 網易雲 ：
網易雲官網：
新使用者大禮包：gift
網易雲社群：
雲原生思想 雲原生的微服務架構
不同微服務之間可能存在一些異構，為了讓每乙個團隊在微服務體系下發揮最大效能，我們允許不同團隊採用不同的程式語言，甚至不同的執行環境來去執行這些微服務。因此，我們在運維和管理微服務時，最初其實並沒有一套統一的標準去處理的異構環境，這也是為什麼後來容器技術變得流行起來，它的乙個重要作用就是通過一層標準的...
網易雲容器服務研發實踐分享
3月25日，網易雲技術布道系列第三期 對話架構師上海站的活動中，網易雲基礎設施技術總監張曉龍帶來了題為 網易雲容器服務研發實踐分享 的乾貨演講。網易從2012年春開始雲計算研發，陸續上線私有雲iaas paas服務，並實現網易95 以上的網際網路業務遷移上雲。本次活動中，張曉龍分享了網易雲基礎服務團...
API閘道器實踐 網易雲輕舟微服務
微服務最佳實踐中，我們需要通過統一的 api 閘道器進行服務能力的共享，api 閘道器為使用者提供發布 管理 保護和監控 api的能力，幫助使用者在自己的多個系統之間，或者內部系統與合作夥伴以及第三方的系統之間實現跨系統 跨協議的服務能力互通。api閘道器應用場景 api閘道器有三種典型的應用場景 ...