在路上：嚴選服務治理實踐

當你面對一個由幾百上千個服務高度耦合而成的大型系統，各式各樣的問題便會不約而至，並且絕對是一個不小的挑戰。熵增原理告訴咱們——任何系統都須要治理，本文分享嚴選在多年的服務治理實踐中的一些思考、一些心得。

服務須要治理嗎？

> 固然須要，你100%會碰上各類需求，各類問題。

古代的農民耕種最關心的問題是氣候變化、按時播種、按量灌溉，而現在的現代化規模化種植時代，農民（和糧食集團）還須要去關注一系列其它問題，譬如多做物立體種植、經濟效應最大化、環保合規和生態破壞等等。只要生產方式和生產規模不是一成不變，那遲早都會有新的問題誕生。

計算機應用亦然。當服務技術架構仍是單體服務（monolithic）的年代咱們須要解決問題A、問題B和問題C，到了MVC架構/RPC架構/SOA架構盛行的時代可能會引入問題D、E、F，當業務規模持續擴張促使架構演進到微服務（microservice）階段，此時你會發現，可能老問題A、B、D、F消失不見了，但C和E依然存在，同時還引入了好幾個新問題G、H、I、J和K。

> 存在問題或可能出現問題，所以才須要治理。

IBM在2006年對服務治理的要點作過總結，「問題」能夠概括爲如下10個方面：

1. 服務定義 Service definition：關注服務的範圍、接口和邊界

2. 服務生命週期 Service deployment life cycle：從規劃到下線整個生命週期各個階段

3. 服務版本治理 Service versioning：強調兼容性，新需求催生新版本，但迭代不能中斷用戶體驗

4. 服務遷移 Service migration：啓用和退役

5. 服務註冊中心 Service registries：依賴關係

6. 服務消息模型 Service message model：規範數據模型

7. 服務監控 Service monitoring：異常發現、排障定位與恢復，強調SLA

8. 服務全部權 Service ownership：企業組織，用戶角色，對齊服務與業務關係

9. 服務測試 Service testing：充分測試和驗證，覆蓋，重複

10. 服務安全 Service security：圈定保護範圍，控制數據獲取渠道並強化

在嚴選的實踐中，咱們發現服務元數據管理（配置中心或叫CMDB）、註冊與發現、流量管理、容量管理、資源調度、可觀測性、故障定位、安全控制、平臺抽象化等方面是解決問題的重中之重。同時，要重視規範流程先行、交付效率&交付質量和治理平臺易用性。其實，這裏面每個方面都很龐大和複雜，值得深刻鑽研，它們都屬於服務治理的範疇，整個服務治理就是「企業爲了確保事情順利完成而實施的過程」（SOA governance —— Anne Thomas Manes）。

 

若是你的系統規模很小，只有十幾個服務，那治理成本是很低的，任何粗放式、人工式手段一般都能被接受。然而，當你面對一個由幾百上千個服務高度耦合而成的大型系統，各式各樣的問題便會不約而至，並且絕對是一個不小的挑戰。熵增原理告訴咱們——任何系統都須要治理，假如咱們選擇無視這些問題，則可能致使一些更加不可接受的問題，譬如維護成本劇增、規範腐化、MTTR增長、SLA降低、系統失控等等。

一句話，服務治理，勢在必行，宜早不宜遲。

服務如何治理？

> 參考答案：擁抱DevOps。

DevOps是服務治理的好夥伴。DevOps落地讓團隊得到CMDB、CI/CD、CloudNative、ServiceMesh、Monitor等多重利器，爲服務治理提供各類工具，是不可或缺的治理能力層。

嚴選DevOps工具鏈的持續建設讓產技部門在效能、性能、穩定性等方面嚐到了愈來愈多的甜頭，隨着基建愈來愈完善，服務治理情況也獲得極大改善。正所謂內功外功要兼修，在這個過程當中，咱們發現服務治理很須要一個統一的易用的門戶平臺，不然開發、測試和運維都要去接觸不少概念術語和底層系統，面臨着巨大學習成本和上手門檻（效能↓），以及不小的出錯概率（風險↑）。

因而，一個嚴選服務治理門戶便水到渠成地誕生了，項目代號是服務鳥巢Service Nest，內部平常簡稱爲SNest。前面提到服務治理要解決10個方面的問題，這些問題在背後會由不一樣的系統在提供解決方案（如CMDB、Consul、Istio、KVM、K8S等），這些統統能夠視爲能力層，而SNest最大的使命就是包裝所有能力層並統一暴露出來，做爲服務治理的整合平臺和用戶端門戶系統。

下面舉幾個例子。

服務元數據管理

服務類型、所屬產品、不一樣環境的實例信息（IP、端口）、JVM配置、Tomcat參數、操做系統特殊需求、服務的負責人/研發人員/測試人員列表等等，這些均可以視爲服務的元數據，它們很是重要。

之前：散落在各地（開發和運維手上各自維護一部分，可能記錄在一些內部零散系統或者wiki、甚至靠腦子記憶），有變動靠人工交流、手動執行，系統之間也無打通關聯。可想而知，溝通成本巨大，並且，時間久了就意味着文檔老化和數據變髒。

現狀&規劃：基礎配置項（Configuration Item，CI）維護在嚴選CMDB，服務級別的配置項（也是CI）則維護在嚴選SNest，核心配置的修改由流程控制（嚴選工單），配置變動後觸發通知（嚴選事件消息中心），再結合SNest提供的豐富OpenAPI，使得嚴選全服務的元數據得以平臺化（入口收斂，規範落地於此）、流程化（變動審批和事件推送）、自動化（工單自動執行）和數據打通（系統間聯動，通傳通識）。對未來來講，擁有完善的服務元數據對單元化和服務定義（Application Definition）等進階項目都有極大幫助。

服務容量與資源調度

服務實例必須運行在必定資源之上，服務A可能須要4臺8core/16G mem/150G HDD規格的虛擬機，服務B可能須要10臺Dell R740物理機，服務A但願不要與服務BCD共處同一臺物理宿主機（這4個服務容易存在資源搶佔，嚴選內部常稱之爲互斥），服務E但願優先被調度到能提供SRIOV高性能網絡的機器（雲計算建德機房，特殊網卡+內核參數）上運行。與此同時，嚴選當前正處於上雲過程當中，雲內和雲外兩地機房的IaaS資源層實現是不一樣的，雲外機房跑的是物理機和KVM虛擬機，而云內機房跑的是雲計算輕舟提供的K8S容器。

之前：僅提供少數幾個規格備選，粒度粗，存在浪費（服務一般會偏大選擇，主機利用率低），支持最簡單的調度算法。主機利用率抓得不嚴，容量趨勢預估多爲人工，規格選擇也是依靠申請人經驗。

現狀&規劃：SNest提供多種豐富的細粒度規格，以及規格智能推薦、規格/副本數環境限制等策略，而且支持用戶表達資源調度傾向性：雲外使用WebKvm新算法和新表達式，雲內則藉助K8s Lable/NodeSelector/Toleration等對象來組合親和性表達式。藉助主機利用率統計和資源密集型定性，能夠支持錯峯調度，錯開資源密集型調度，進一步提升總體利用率和降本。

服務註冊發現與流量調配

服務註冊發現與流量調配，這是ServiceMesh關鍵落腳點，包括一個服務在各個環境有哪些實例，運行在何處（IP：Port），處於什麼狀態（健康檢測），但願受理多少流量（流控頻控），是否須要劫持流量作一些校驗甚至篡改等等。嚴選的ServiceMesh架構一直在演進，雲外機房使用的解決方案是Consul+Consul-Nginx，而云內機房則使用K8S+Istio雲原生定製加強方案。

之前：服務註冊走工單人工執行，平常可以使用一個老舊平臺去維護實例狀態，用戶直接打Consul weight標籤來控制每一個實例的流量（此時需人工覈算每一個實例的weight值，容易算錯），嚴選上雲初期服務要切一部分流量進去雲內很麻煩，必須找運維人工修改Consul配置和網關配置。

現狀&規劃：SNest抽象掉兩地機房底層不一樣的ServiceMesh解決方案並統一封裝成接口，再以一個的簡單易用的交互界面暴露出來，開發/測試/運維能夠無需關心Consul/Consul-Nginx/k8s svc/ingress/egress/Istio RR,DR等專業術語有什麼特性、何時用、何時不要用、有什麼易踩的坑。用戶在申請資源時SNest會自動完成服務註冊（不管雲內雲外），平常管控時能夠傻瓜式一鍵調配流量（控制各個機房分別受理多少比例的流量，或者每一個實例受理多少）。因爲Istio能力很強大（它劫持了所有進&出調用），那麼實現限流熔斷、黑白名單、故障注入等也都是垂手可得，對應用無侵入。

嚴選的治理心得

嚴選的服務治理方興未艾，諸多規劃點都處於持續建設的狀態，儘管距離終點還有很長一段路，但多年的實踐經驗仍是給了咱們一些思考、一些心得。

能力層要夯實

• 萬丈高樓起於壘土，積基樹本；

• 不管是CMDB層、MetaData層、IaaS層、ServiceMesh層、Monitor層等，它們都是服務治理必須依賴的基礎能力，務必規劃先行，規範先行，能力先行。這些能力層缺一不可，並且無一不重要，怎麼樣作好都不過度。

平臺層要統一

• 能力層位於底層，並且多是異構的（不一樣數據中心有不一樣的實現方案），服務治理必須封裝一個平臺層：把底層抽象掉，爲上層管控提供接口；

• 平臺層能夠實現收口，同時落地規範。從此能力層有進化，規範有調整，只須要迭代平臺層便可；

• 也可讓能力和規範都彙集起來，再也不散落，再也不失控。

交互層要友好

• 關鍵詞是「友好」二字；

• 服務治理解決方案在面向用戶（研發/測試/運維等技術人員）時必定要提供足夠友好的交互門戶，包括但不限於頁面UI、工單流、消息通知機制等等；

• 越友好，越全面，越直觀，越精細，越智能，這樣的門戶不只能夠提升生產效率，還能下降上手門檻和出錯機率。

演進要果敢

• 業務在發展，會提出更多新需求和新問題；

• 社區在演進，會提供更多新工具和新創意；

• 銀彈是不存在的，當你察覺到治理現狀對新需求和新問題已經顯得捉襟見肘、無能爲力時，你就應該果斷啓動新方案的研發和試點。業務那邊不用太擔憂，當前版本還在繼續跑着，只需無感式地迭代你的「能力層/平臺層/交互層」並適時推出新版本便可。至於老系統和老版本，該退役的就勿過於留念。從1到1.1也是創新。

小結

服務治理要解決十大類問題，仍是那句話，每一類問題單拎出來都是一個大型課題，都須要充分實踐，並且沒有一成不變的最佳實踐。本文是嚴選在服務治理歷程上的一些心得總結，權當拋磚引玉，望你們不吝勘正，發表評論和文章分享本身的經驗。

路漫漫其修遠兮，吾將上下而求索。

 

做者簡介

書技， 網易嚴選運維SRE負責人，專一系統容量與穩定、DevOps效能、服務治理、線上質量等體系的搭建和發展。

 

招聘信息

嚴選基礎技術團隊正在招聘資深Java研發工程師、資深網絡研發工程師、資深測試開發工程師。歡迎各位小夥伴加入，一塊兒探索業務中臺、服務網格、DevOps等技術方向，共同面對產品質量、系統穩定性、效率瓶頸等挑戰，助力業務快速創新迭代和研發效能升級。

👇點擊左下「閱讀原文」，查看團隊詳細招聘信息。

 

本文由做者受權嚴選技術產品團隊發佈

 

 

 

本文分享自微信公衆號 - 嚴選技術產品團隊（YanxuanTechProd）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。