導讀：關於服務治理，業界的討論比較多，但尚未一個統一的解釋。從實踐角度，不少從業者會把服務治理和Service Mesh綁定起來。而百度搜索引擎和推薦引擎的微服務治理，有着本身的特色和定義。Geek大咖說第二期，咱們再次邀請到MEG推薦技術架構部的傳玉老師，跟你們聊聊咱們本身的微服務治理是怎麼落地的，效果如何。後端
全文3864字，預計閱讀時間7分鐘。性能優化
嘉賓簡介 ：傳玉架構
推薦技術架構部技術專家。2012年起專一於搜索引擎與推薦引擎方向；2016年開始負責自有的資源調度和容器編排系統的研發工做；2019年開始負責部分通用基礎組件的研發工做，並開始在MEG用戶產品內部全面推動雲原生架構改造。app
Q1：您怎麼定義服務治理？框架
以前爲了方便在內部去推服務治理，咱們給了一個比較明確的定義：咱們指望的服務治理是讓咱們全部的微服務都保持在一個合理的運行狀態。所謂合理的運行狀態，就包括：less
-
全部託管服務的容量是合理的，冗餘既不會過多，也不會過少；微服務
-
全部託管服務是健康的，可以容忍局部的短時間異常，同時不會有長時間的故障，在生命週期內能提供高質量的服務；性能
-
整個系統是可觀測的，它的流量拓撲和主要的技術指標，都是透明、可觀測、可監控的。優化
Q2：咱們從何時開始着手服務治理？搜索引擎
推薦系統是16年末17年初開始作的。起初跟其餘業務起步階段差很少，咱們搭了一個快餐系統就直接就上了。最開始的重點是支持業務的高速發展，對巨型服務、資源利用，可觀測性這些方面的問題，只要不影響業務的發展，可能就沒有那麼關注。例若有些服務上線作了一些嘗試，發現效果不理想，而後又下線後，但作這些嘗試的資源可能就沒有及時回收，浪費掉了，這種狀態一直持續到2018年。
以後，業務發展到必定規模之後，就無法維持這種超高速的增加，進入精細優化的階段了，這時候咱們就須要開始關注如何去讓這些服務的資源利用更合理，該還「技術債」了。
可是，咱們不但願僅僅經過人工去運動式地清理這些技術債，而是但願經過一種可持續發展的模式，經過系統自動化的去解決這個問題，而後把「技術債務」的清理從「運動式」的操做變成一個常規操做，決定開始全面推行對微服務治理工做。
Q3：服務治理，治理的是什麼？
隨着服務愈來愈多，後端系統面臨2個重點問題，意識如何合理分配各服務資源，二是如何保障服務高效、健康的運行。目前，咱們的微服務治理體系包括三個層面：容量治理，流量治理，穩定性工程。
容量治理，是但願利用自動擴縮容機制保障線上服務對資源的合理利用。
這就須要監控線上服務的負載狀態，對服務的資源進行自動化調整，來保證冗餘不會太高或太低。更精細化的措施是對線上服務作實時壓測，根據容忍上限來分配冗餘，咱們不要求全部的服務都作到高標準，但會設置一個基線來避免浪費。
流量治理，有2個目標：一是流量要可觀測、可監控、可控制，二是管理要自動化。
舉個例子，以前咱們作機房遷移時，有不到5%的流量不知道來源，因此不敢妄動，由於不知道會不會形成沒法挽回的損失。所以咱們須要找OP和RD一塊兒去追這部分流量來源，時間可能會很長。這種狀況帶來的問題是，咱們整個線上的流量狀態實際上是不透明的，各服務間須要可觀測、可監控、可控制。
另外，微服務改造後線上的鏈接關係變得複雜，模塊數成倍增長，之間的鏈接關係也沒法靠人力維護，面臨的最大的問題是一旦服務出現問題，就要臨時作一些降級和屏蔽，咱們不知道這個影響範圍有多大，有多少重要的服務把它看成必選依賴了。所以，這方面的管理要實現自動化。
穩定性工程，就是創建一個穩定性監控和預警機制。
微服務改造讓咱們的迭代效率變快了，資源效率變高了，但同時也讓系統總體架構變得更復雜，咱們對系統可靠性的掌控隨之變弱了。你愈來愈不清楚哪裏會出問題，出了問題會有什麼影響，上次新增的預案此次還有沒有用……
半年前咱們出現過這個問題，一次線上故障之後，新增了一個干預接口，作了一個預案，當模塊出問題的時候調用這個接口止損，當時也演練過，這個問題算close了。但半年後一樣的故障再出現時再執行預案調用這個接口，發現這接口在某次迭代之後已經失效了。
所以咱們須要一個更系統化的機制來檢測和驗證系統的穩定性風險和咱們的預案有效性。
Q4：服務是隨着系統規模增加的，怎樣的容量治理框架才能知足咱們的需求？
在容量治理方面，咱們引入了全自動化的應用層的管理系統ALM（Application Lifecycle Management），這個平臺上有一套比較完整的軟件生命週期管理模塊。咱們經過壓測來自動構建每個app的容量模型，依此肯定合理的資源利用冗餘。
2020年，咱們經過這種方式回收再利用的機器數量大概有1萬多臺。今年，咱們聯合INF讓負載反饋更實時，進而提高容量調整的實時性，與Serverless更近了。
Q5：流量治理方面咱們也是經過Service Mesh來解決可觀測的問題嗎？
是，也不徹底是。
一方面，與業界類似，咱們嘗試經過Service Mesh來解決流量的管理和可觀測的問題。
咱們引入了開源產品lstio + envoy，而後作二次開發來適配廠內的生態，以及大量的性能優化來知足在線服務的延遲要求。此外，咱們還基於lstio+envoy作了統一的Load Balance策略以及流量干預能力，好比流量熔斷、流量黑洞、流量複製等。
如此一來，不少穩定性的預案執行，就不須要每一個模塊單獨去開發，而是經過mesh的標準化接口來執行，能最大程度地避免預案退化等問題。
另外一方面，咱們正在構造一個線上服務的Service Graph，也就是全局流量拓撲。
緣由是搜索和推薦的後端服務對延遲很是敏感，致使Service Mesh在咱們內部的覆蓋率很難作到百分之百。所以，咱們把全局的服務鏈接關係單獨抽出來，從Service Mesh和brpc框架獲取和彙總服務鏈接關係和一些流量指標，實現對架構的總體可觀測性。
咱們在brpc框架和數據代理層都按統一的標準格式存儲了大量的、通用的「黃金指標」，包括延遲、負載狀況等，用於觀察整個系統全鏈路的流量健康狀態。此外，咱們也在嘗試應用Service Mesh的proxyless模式，把流量熔斷、流量黑洞、流量複製等基礎能力嵌入到brpc框架中，經過Service Mesh的控制指令下發渠道去控制。
如此一來，不管服務是否把流量託管到mesh中，在干預能力上的baseline都是一致的，這就是用一種標準化的方式去應對線上的異常，避免由於服務迭代致使的局部退化。
Service Graph 的一個直接的價值，就是提高了機房建設效率。
機房建設一般比較複雜，每一個服務都須要管理本身的下游鏈接關係，沒有全局視圖。所以在搭建新機房過程當中很難從幾百個服務裏發現個別配置錯誤，debug也須要好久。但有了Service Graph後，咱們對流量和鏈接關係就有了一個全局視圖，發現問題就變得簡單了。
Q6：穩定性主要是防患於未然，咱們怎麼提早找到系統的「隱患」？
咱們在穩定性工程方面的建設，主要是自動化管理和混動工程。
穩定性工做一般都須要頗有經驗的工程師來負責，但這在以前倒是一件隱性工做，缺乏度量機制，工做作得好時得不到正反饋，一旦出現問題就是你們都知道的事故，也沒辦法事前規避。咱們引入混沌工程主要解決兩個問題，一是經過在線上注入隨機故障的方式來發現系統中的穩定性隱患，二是嘗試用混用工程的方法來量化穩定性工做。
在故障注入方面，咱們有從容器到整機、交換機、IDC、從局部到全局的故障注入能力，並聯合OP開發外網故障和針對一些通用的複雜系統的定製化的故障。在線上，咱們有計劃地隨機注入故障，經過觀察系統的表現，就能發現一些潛在的問題。
在度量機制上，咱們設置了「韌性指數」，來衡量線上系統對於穩定性問題的容忍能力。
好比對單機故障的容忍能力，能夠經過混沌工程實驗在線上掛掉一臺機器，若是你的系統掛了，就說明不能容忍單機故障，這一項實驗就是0分。
混沌工程的實驗一輪作十幾個或幾十個，完成後打分，分值越高就能推斷該系統越穩定。在分數設置上，越是常見的故障，分值越高，疑難複雜的故障反而分數較低。這是爲了鼓勵你們，重視常見故障而非劍走偏鋒，把精力放在不常見卻疑難複雜的問題上。
Q7：在自動化方面，咱們面臨着怎樣的挑戰呢？
我以爲有三方面，第一是用於作決策的數據怎麼獲取，第二是標準化的操做接口怎麼設計，第三個就是如何基於數據去作操做決策。
在數據方面，咱們制定的黃金指標以及一些通用的負載相關的指標已經有了積累，在不斷推動覆蓋面。但一些相似服務等級、服務質量方面的指標，不一樣業務可能有不一樣的標準，若是須要業務以標準化的方式提供，就比較複雜了。如何制定統一的規範，是一個比較大的挑戰。
標準化接口如今有兩個：一個是雲上實例的控制接口，也就是容量接口，能夠經過ALM與底層PaaS系統對接；流量接口是經過Service Mesh控制面板來解決，目前還在推動覆蓋。
一旦有了標準化的數據，和標準化的操做接口，中間的策略就不是一個特別難以實現問題。一般用簡單的規則就能覆蓋絕大多數場景。但這裏的挑戰可能更可能是在策略自身的決策靈敏度和準確率的平衡，可能在一些場景下，自動化操做的靈敏度太高，準確率就會降低，引發系統抖動。但靈敏度太低又會讓問題得不到及時的解決，須要根據不一樣的場景來設定不一樣的策略。
Q8：聊聊對您感觸最大的、思惟上的重塑
我以爲不能只靠流程和規範來解決問題，要重視系統化，把流程、規範、經驗沉澱到代碼裏，經過強化系統的可觀測性，經過自動化的機制來控制和管理系統，去解決一些原來須要人工才能解決的問題。一方面，只有流程規範，人員的經驗會隨着我的的流失而丟失，咱們會反覆犯一些歷史上犯過的錯誤；另外一方面若是要開發新產品，還要再從頭培養一批很是專業的維護者，成本過高了。
之前有個老的說法，是把OP作進架構裏，其實幹的就是這件事。
招聘信息
若是你對微服務感興趣，請你聯繫我，咱們當面聊聊將來的N種可能性，另外，若是你想加入咱們，關注同名公衆號百度Geek說，輸入內推便可，期待你的加入！
推薦閱讀
---------- END ----------
百度Geek說
百度官方技術公衆號上線啦！
技術乾貨 · 行業資訊 · 線上沙龍 · 行業大會
招聘信息 · 內推信息 · 技術書籍 · 百度周邊
歡迎各位同窗關注