美團Service Mesh服務(wù)治理體系落地實踐
點擊上方藍色字體，選擇“設(shè)為星標”
美團主要的服務(wù)治理體系是圍繞Octo搭建的，隨著ServiceMesh的概念興起，美團的服務(wù)治理解決方案，也在朝著Mesh方向演進。
美團服務(wù)治理的發(fā)展史，整體分為四個階段：
?基礎(chǔ)治理的統(tǒng)一：實現(xiàn)了通信框架及注冊中心的統(tǒng)一，由統(tǒng)一的治理平臺支撐節(jié)點管理、流量管理、監(jiān)控預(yù)警等運營能力；
提升性能及易用性：qps從2w提升到10w，99分為線1ms，建立分布式鏈路追蹤、分階段耗時精細化埋點等功能；
全方位豐富治理能力：落地了全鏈路壓測平臺、性能診斷優(yōu)化平臺、穩(wěn)定性保障平臺、鑒權(quán)加密等一系列平臺，實現(xiàn)了鏈路級別的流量治理，全鏈路灰度發(fā)布等；
跨地域的容災(zāi)及擴展能力：每天數(shù)千萬訂單的單元化，實現(xiàn)了所有PaaS層組件及核心存儲系統(tǒng)的打通；
目前所面對的特點有兩個：業(yè)務(wù)發(fā)展多元化，治理需求精細化。
展開來說，比如業(yè)務(wù)和中間件強耦合，制約彼此迭代。中間件的bug會要求業(yè)務(wù)系統(tǒng)大面積的升級，整體迭代成本高。非java語言治理體系薄弱，很多主流中間件缺少相關(guān)sdk。
解決思路是，隔離出基礎(chǔ)設(shè)施層建設(shè)標準化的治理運行時，在標準之上建立體系。
在業(yè)務(wù)進程旁附屬一個Proxy進程，SDK發(fā)出及接收的流量會被附屬的Proxy進程攔截。一些標準化的服務(wù)治理能力，如：限流、路由等，會由Proxy和中心化的控制大腦完成，并由控制面對接所有治理子系統(tǒng)集成。
這種方案下SDK很輕薄、異構(gòu)語言、異構(gòu)治理體系就很容易打通，和業(yè)界的Mesh思想很像（Proxy類似數(shù)據(jù)面，中心化控制類似于控制面）。
如圖：
基于此思想，美團的整體服務(wù)治理方向，向著Mesh解決方案做遷移。
美團的數(shù)據(jù)面采用Envoy二次開發(fā)，控制面以自研為主，結(jié)合SDK協(xié)同升級方案。
多語言輕薄的SDK與Proxy通過UDS交互，主要考慮到相比于透明流量劫持，UDS性能與可運維性更好。
控制面與Proxy通過雙向流通信，控制面與治理生態(tài)的多個子系統(tǒng)交互，將計算處理后的數(shù)據(jù)與策略下發(fā)到Proxy執(zhí)行，協(xié)同配合完成路由、限流等核心治理功能。
控制面中有多個自研獨立服務(wù)：Pilot承載治理能力，與Proxy交互、Dispatcher負責屏蔽異構(gòu)子系統(tǒng)差異、集中式健康檢查節(jié)點狀態(tài)、Config Server管理Mesh體系內(nèi)相關(guān)策略、監(jiān)控巡檢系統(tǒng)負責提升穩(wěn)定性。
Meta Server實現(xiàn)了Mesh體系內(nèi)的節(jié)點注冊和尋址，通過管理控制面和數(shù)據(jù)面連接關(guān)系，實現(xiàn)按業(yè)務(wù)群的隔離與水平擴展能力。
由于美團之前的服務(wù)治理體系是基于中心化Proxy的平臺調(diào)度，遷移到Sidecar的Mesh方案下，需要做到業(yè)務(wù)無感，同時要保證較好的穩(wěn)定性。
主要做法：
與現(xiàn)有基礎(chǔ)設(shè)施及治理體系兼容，將Mesh與Octo深度打通，保障各子系統(tǒng)使用方式不變；在運行層面支持容器、虛擬機、物理機；打通運維體系，保障服務(wù)治理基礎(chǔ)設(shè)施可管理、可檢測。
協(xié)議兼容，服務(wù)間調(diào)用是多對多的關(guān)系，為實現(xiàn)Mesh與非Mesh的互通，需要在協(xié)議層面做到完全透明；對于異常處理，需要在SDK和Proxy之間達成共識，保證兼容；無法在控制面和數(shù)據(jù)面實現(xiàn)的能力，在SDK中執(zhí)行通過上下文傳遞給Proxy，保障功能完全對齊。
Mesh與非Mesh模式的無縫切換，基于UDS通信，需要業(yè)務(wù)升級一次SDK版本，可以默認不開啟Mesh狀態(tài)；在可視化平臺通過開關(guān)操作，可以無成本實現(xiàn)從Mesh模式與非Mesh模式之間的切換，并實時生效。
為解決異構(gòu)性問題，采用了標準化服務(wù)治理運行時的手段。
比如，在架構(gòu)層面由控制面實現(xiàn)統(tǒng)一的子治理系統(tǒng)對接，屏蔽了注冊中心、鑒權(quán)、限流等具體實現(xiàn)機制的異構(gòu)性問題。
將數(shù)據(jù)面+控制面定義為標準化的服務(wù)治理運行時，在標準運行時內(nèi)打通所有治理能力。
建設(shè)統(tǒng)一接入中心Dispatcher，由其屏蔽對接子系統(tǒng)的異構(gòu)性差異，從而實現(xiàn)外部系統(tǒng)的差異性對Pilot透明。
對于異構(gòu)語言、異構(gòu)體系使用增強的統(tǒng)一協(xié)議交互，實現(xiàn)互通。
如圖：
以摩拜單車流量改造對比查看：
美團的服務(wù)規(guī)模還是比較龐大的，需要對Istio做一定的改造升級，才可以支持美團規(guī)?；疢esh使用的問題。
規(guī)?；疢esh的目標：具備支撐數(shù)萬服務(wù)、百萬節(jié)點體量的系統(tǒng)能力、支持水平擴展。
面對Istio需要解決的問題：
美團的體量是Istio產(chǎn)品上限的千倍。
美團場景下，有極高的實時性與準確性要求，配置下發(fā)或丟失將引發(fā)流量異常。
問題分析：
Istio的每個控制面實例由ETCD存儲系統(tǒng)的全部數(shù)據(jù)，無法水平擴展。
每個Proxy獨立與ETCD交互，同一個服務(wù)的Proxy請求內(nèi)容相同，獨立的交互方式有大量的IO冗余。當Proxy批量發(fā)版或網(wǎng)絡(luò)抖動時，瞬時風暴會壓垮ETCD。
每個節(jié)點都會探活其他節(jié)點，10w+節(jié)點規(guī)模集群，每個檢測周期都是百億次的探活，會引發(fā)網(wǎng)絡(luò)風暴。
解決措施
橫向數(shù)據(jù)分片
對于Istio控制面實例承載的全集群數(shù)據(jù)問題，對應(yīng)的措施是通過橫向數(shù)據(jù)分片實現(xiàn)擴展性支持：
proxy啟動時，向Meta Server系統(tǒng)請求需要連接的Pilot IP，Meta Server將相同服務(wù)的Proxy盡量落到同一控制面節(jié)點，這樣數(shù)據(jù)大體是一樣的，每個Pilot實例按需加載，而不需要承載所有數(shù)據(jù)。
控制面節(jié)點異?；虬l(fā)布更新時，其所管理的Proxy會規(guī)律的遷移，恢復后，會接管其所負責的Proxy，實現(xiàn)了會話粘滯，實現(xiàn)了邏輯數(shù)據(jù)分片。
通過鏈接管理，實現(xiàn)了按事業(yè)群、按服務(wù)灰度的平臺能力，同時解決了Mesh水平擴展問題。
縱向分層訂閱
對于Istio獨立管理各Proxy鏈接的IO冗余問題，對應(yīng)的措施是通過分層訂閱減少冗余IO。
Proxy不直接與存儲系統(tǒng)對接，而是在中間經(jīng)過多步處理：
?基于快照緩存+索引機制，減少zk watcher同步。相同服務(wù)的Proxy所關(guān)注的內(nèi)容是相同的，不同服務(wù)的Proxy的關(guān)注也會存在大量的冗余。分層訂閱模式下，proxy不與注冊中心直接交互，而是通過中間層的快照緩存分層方式，確保每個Pilot實例中zk相同路徑的監(jiān)聽，最多1個watcher，獲取到watcher通知后，pilot根據(jù)內(nèi)存快照緩存+索引，向所有關(guān)注者分發(fā)，降低了冗余。
治理能力層和會話層，實現(xiàn)了類似于IO多路復用的能力，提升了并發(fā)吞吐。
基于此設(shè)計，有效的應(yīng)對了網(wǎng)絡(luò)抖動或批量發(fā)版的瞬間風暴壓力。
集中式健康檢測
對于大規(guī)模集群內(nèi)指數(shù)級膨脹的節(jié)點健康檢測次數(shù)，對應(yīng)措施是摒棄了P2P檢測模式。
當Pilot感知到Proxy異常時，會立即通知中心化健康檢測系統(tǒng)進行檢測，而不是等待檢測周期窗口的到來，可以有效提升業(yè)務(wù)調(diào)用的成功率。
對于交易屬性的業(yè)務(wù)，Mesh接入更加謹慎。
在業(yè)務(wù)接入之前，基礎(chǔ)架構(gòu)平臺建設(shè)了精細化運營體系：
基于SOA分級，將服務(wù)劃分為非核心和核心服務(wù)，對于非核心服務(wù)進行線下環(huán)境的重點突破。
在運營平臺，通過校驗SDK版本、運行時環(huán)境等信息，篩選出滿足條件的服務(wù)，服務(wù)負責同學在平臺可以實現(xiàn)開關(guān)啟關(guān)閉、節(jié)點選擇、指定Mesh流量等工作，與內(nèi)部IM聯(lián)動，提升了數(shù)據(jù)運營效率。
服務(wù)接入Mesh后，運營層面有足夠的詳細數(shù)據(jù)，基于穩(wěn)定性策略，可以在Mesh模式異常時，自動切換回非Mesh模式。
在UDS通信之外，還實現(xiàn)了增量聚合下發(fā)、序列化優(yōu)化措施，實現(xiàn)了不必要的解包，提升了通信效率。
為提升整體Mesh架構(gòu)的可用性，做了多級的流量保護：
?當proxy不可用時，流量自動fallcack到非mesh模式；支持按節(jié)點的1/1000比例的流量灰度控制。
基于FD遷移+SDK配合協(xié)議交互，實現(xiàn)Proxy無損熱重啟的能力。
控制面配置下發(fā)錯誤比停發(fā)配置更加危險，針對于此建設(shè)了應(yīng)用層面和系統(tǒng)層面的周期性巡檢，實現(xiàn)了端到端應(yīng)用視角的驗證正確性，避免因變更引發(fā)的異常。
建設(shè)限流、熔斷等對中心化控制面的服務(wù)保護，讓系統(tǒng)柔性可用，當控制面全面異常時，可以通過緩存機制實現(xiàn)一段時間的可用。