美团技术：复杂环境下落地 Service Mesh 的挑战与实践
在私有云集群環(huán)境下建設 Service Mesh ，往往需要對現(xiàn)有技術架構做較大范圍的改造，同時會面臨諸如兼容困難、規(guī)模化支撐技術挑戰(zhàn)大、推廣困境多等一系列復雜性問題。本文會系統(tǒng)性地講解在美團在落地 Service Mesh 過程中，我們面臨的一些挑戰(zhàn)及實踐經(jīng)驗，希望能對大家有所啟發(fā)或者幫助。
一、美團服務治理建設進展
1.1 服務治理發(fā)展史
首先講一下 OCTO，此前美團技術團隊博客也分享過很多相關的文章，它是美團標準化的服務治理基礎設施，現(xiàn)應用于美團所有事業(yè)線。OCTO 的治理生態(tài)非常豐富，性能及易用性表現(xiàn)也很優(yōu)異，可整體概括為 3 個特征：
屬于公司級的標準化基礎設施。技術棧高度統(tǒng)一，覆蓋了公司 90% 以上的應用，日均調用量達數(shù)萬億次。
經(jīng)歷過較大規(guī)模的技術考驗。覆蓋數(shù)萬個服務、數(shù)十萬個節(jié)點。
治理能力豐富。協(xié)同周邊治理生態(tài)，實現(xiàn)了 SET 化、鏈路級復雜路由、全鏈路壓測、鑒權加密、限流熔斷等治理能力。
回顧美團服務治理體系的發(fā)展史，歷程整體上劃分為四個階段：
第一階段是基礎治理能力統(tǒng)一。實現(xiàn)通信框架及注冊中心的統(tǒng)一，由統(tǒng)一的治理平臺支撐節(jié)點管理、流量管理、監(jiān)控預警等運營能力。
第二階段重點提升性能及易用性。4 核 4GB 環(huán)境下使用 1KB 數(shù)據(jù)進行 echo 測試，QPS 從 2 萬提升至接近 10 萬，99 分位線 1ms；也建設了分布式鏈路追蹤、分階段耗時精細埋點等功能。
第三階段是全方位豐富治理能力。落地了全鏈路壓測平臺、性能診斷優(yōu)化平臺、穩(wěn)定性保障平臺、鑒權加密等一系列平臺，也實現(xiàn)了鏈路級別的流量治理，如全鏈路灰度發(fā)布等。
第四階段是建設了跨地域的容災及擴展能力。在每天數(shù)千萬訂單量級下實現(xiàn)了單元化，也實現(xiàn)了所有 PaaS 層組件及核心存儲系統(tǒng)的打通。
1.2 服務治理體系的困境
目前，美團已具備了較完善的治理體系，但仍有較多的痛點及挑戰(zhàn)。大的背景是公司業(yè)務蓬勃發(fā)展，業(yè)務愈發(fā)多元化，治理也愈發(fā)精細化，這帶來了較多新的問題：
業(yè)務與中間件強耦合，制約彼此迭代。當中間件引入 Bug，可能成百上千、甚至數(shù)千個業(yè)務需要做配合升級，中間件的新特性也依賴業(yè)務升級后才能使用，成本很高。
中間件版本碎片化嚴重。發(fā)布出去的組件基本托管在業(yè)務側，很難統(tǒng)一進行管控，這也頻繁造成業(yè)務多類的問題。
異構體系融合難。新融入公司的技術體系往往與美團不兼容，治理體系打通的成本很高，難度也很大。此前，美團與大眾點評打通治理，不包含業(yè)務遷移，就歷時 1 年半的時間；近期，摩拜使用的 gRPC 框架也無法與系統(tǒng)進行通信，但打通迫在眉睫。
非 Java 語言治理體系能力弱，多個主流語言無官方 SDK。多元業(yè)務場景下，未來多語言也是個趨勢，比如在機器學習領域，Python 語言不太可能被其他語言完全代替。
二、服務治理體系優(yōu)化的思路與挑戰(zhàn)
2.1 優(yōu)化思路
總結來看，OCTO 在服務層實現(xiàn)了統(tǒng)一抽象來支撐業(yè)務發(fā)展，但它并未解決這層架構可以獨立演進的問題。
1.2節(jié)中問題1與問題2的本質是“耦合”，問題3與問題4的本質是“缺乏標準服務治理運行時”。在理想的架構中，異構語言、異構治理體系可以共用統(tǒng)一的標準治理運行時，僅在業(yè)務使用的 SDK 部分有輕微差異。
所以，我們整體的優(yōu)化思路分為三步：隔離解耦，在隔離出的基礎設施層建設標準化治理運行時，標準之上建體系。
上述解決方案所對應的新架構模式下，各業(yè)務進程會附屬一個 Proxy 進程，SDK 發(fā)出以及接收的流量均會被附屬的 Proxy 攔截。像限流、路由等治理功能均由 Proxy 和中心化的控制大腦完成，并由控制面對接所有治理子系統(tǒng)集成。這種模式下 SDK 很輕薄，異構的語言、異構的治理體系就很容易互通，從而實現(xiàn)了物理解耦，業(yè)界將這種模式稱為 Service Mesh（其中 Proxy 被稱為數(shù)據(jù)面、中心化控制大腦被稱為控制面）。
2.2 復雜性挑戰(zhàn)
美團在實踐中所面臨的復雜性劃主要包括以下4類：
兼容性：技術改造涉及范圍較大，一方面需要通過保證現(xiàn)有通信方式及平臺使用方式不變，從而來保障業(yè)務研發(fā)效率，另一方面也要解決運行載體多樣性、運維體系兼容等問題。
異構性：第一是多語言互通問題；第二是打通治理體系內的眾多治理子系統(tǒng)，像服務鑒權、注冊中心等系統(tǒng)的存儲及發(fā)布訂閱機制都是不同的；第三是快速打通新融入公司的異構治理體系。
大規(guī)模支撐：出于性能方面考慮，開源 Istio 等產品不宜直接應用于大規(guī)模的生產環(huán)境，美團控制面需具備百萬級鏈接下高吞吐、低延遲、高精確的系統(tǒng)能力。
重交易型業(yè)務容錯性低：交易型業(yè)務場景下，業(yè)務對 Service Mesh 的性能、穩(wěn)定性往往持懷疑態(tài)度；美團基礎架構團隊也強調在業(yè)務價值導向下，基于實際業(yè)務價值進行運營推廣，而不是采用從上至下的偏政策性推廣方式。
三、美團落地 Service Mesh 的解決方案
3.1 整體架構
美團采用數(shù)據(jù)面基于 Envoy 二次開發(fā)、控制面自研為主、SDK 協(xié)同升級的方案（內部項目名是 OCTO Mesh?）。架構簡介如下：
各語言輕薄的 SDK 與 Proxy 通過 UDS（Unix Domain Socket）交互，主要出發(fā)點是考慮到相比透明流量劫持，UDS 性能與可運維性更好。
控制面與 Proxy 通過雙向流通信，控制面與治理生態(tài)的多個子系統(tǒng)交互，并將計算處理過的治理數(shù)據(jù)及策略數(shù)據(jù)下發(fā)給 Proxy 執(zhí)行，協(xié)同配合完成路由、限流等所有核心治理功能。
控制面內部的 5 個模塊都是自研的獨立服務。
Pilot 承載核心治理能力，與 Proxy 直接交互。
Dispatcher 負責屏蔽異構子系統(tǒng)差異。
集中式健康檢查管理節(jié)點狀態(tài)。
Config Server 管理 Mesh 體系內相關的策略，并將 Pilot 有狀態(tài)的部分盡量遷移出來。
監(jiān)控及巡檢系統(tǒng)負責提升穩(wěn)定性。
自研了的 Meta Server 系統(tǒng)實現(xiàn) Mesh 體系內部的節(jié)點注冊和尋址，通過管理控制面與數(shù)據(jù)面的鏈接關系，也實現(xiàn)了按事業(yè)群隔離、水平擴展等能力。
3.2 兼容性解決方案
兼容性的目標及特征用一句話來總結就是：業(yè)務接入無感知。為此，我們做了以下三件事情：
(1) 與現(xiàn)有基礎設施及治理體系兼容
將 Service Mesh 與 OCTO 深度打通，確保各治理子系統(tǒng)的使用方式都不變。
運行載體方面，同時支持容器、虛擬機、物理機。
打通運維體系，保證服務治理基礎設施處于可管理、可監(jiān)測的狀態(tài)。
(2) 協(xié)議兼容
服務間調用往往是多對多的關系，一般調用端與服務端無法同時升級，為支持 Mesh 與非 Mesh 的互通，增強后的協(xié)議對業(yè)務完全透明。
與語義相關的所有內容（比如異常等），均在 SDK 與 Proxy 之間達成共識，保證兼容。
無法在控制面及數(shù)據(jù)面中實現(xiàn)的能力，在 SDK 中執(zhí)行并通過上下文傳遞給 Proxy，保障功能完全對齊，當然這種情況應該盡量避免的。
(3) Mesh 與非 Mesh 模式的無縫切換
基于 UDS 通信必然需要業(yè)務升級一次 SDK 版本，我們在 2020 年初時預先發(fā)布早做部署，確保當前大部分業(yè)務已經(jīng)升級到新版本，但默認仍是不開啟 Mesh 的狀態(tài)。
在可視化平臺上面通過開關操作，幾乎無成本實現(xiàn)從 Mesh 模式與非 Mesh 模式的切換，并具備實時生效的能力。
3.3 異構性解決方案
異構性的目標及特征用一句話總結就是：標準化服務治理運行時。具體可拆分為3個子目標：
標準化美團內部 6 種語言的治理體系。
架構層面由控制面統(tǒng)一對接各個治理子系統(tǒng)，屏蔽注冊中心、鑒權、限流等系統(tǒng)具體實現(xiàn)機制的異構性。
支持摩拜及未來新融入公司的異構治理體系與公司整體的快速融合。
針對上述3個子目標，我們所采取的方案如下：
將數(shù)據(jù)面 + 控制面定義為標準化的服務治理運行時，在標準運行時內打通所有治理能力。
建設統(tǒng)一接入中心系統(tǒng) Dispatcher ，并由其對接并屏蔽治理子系統(tǒng)的異構性，從而實現(xiàn)外部系統(tǒng)的差異對 Pilot 透明；下圖中 Dispatcher 與 Pilot 直接交互，Meta Server 的作用是避免廣播降低冗余。
重構或從零建設 SDK，目前使用的 6 種語言 SDK 均已落地并使用。
異構語言、異構體系均使用增強的統(tǒng)一協(xié)議交互，實現(xiàn)互通。
通過 Service Mesh 實現(xiàn)體系融合的前后對比如下：
引入 Service Mesh 前，單車向公司的流量以及公司向單車的流量，均是由中間的 adaptor 單點服務承接。除穩(wěn)定性有較大隱患外，所有交互邏輯均需要開發(fā)兩份代碼，效率較差。
引入 Service Mesh后，在一套服務治理設施內打通并直接交互，消除了中心 adaptor 帶來的穩(wěn)定性及研發(fā)效率方面的缺陷；此外整個打通在1個月內完成，異構體系融合效率很高。
通過上述方案，針對異構性方面取得了較好的效果：
標準化 6 種語言治理體系，非 Java 語言的核心治理能力基本對齊 Java；新語言也很容易融入，提供的官方 Python 語言、Golang 語言的通信框架新版本（依托于 OCTO Mesh），開發(fā)成本均控制在1個月左右。
支持異構治理子系統(tǒng)通過統(tǒng)一接入中心快速融入，架構簡潔、擴展性強。
支持異構治理體系快速融合并在單車側落地，異構治理體系打通成本也從 1.5 年降低到 1 個月。
3.4 規(guī)模化解決方案
3.4.1 開源 Istio 問題分析
規(guī)模化的目標及特征用一句話總結是：具備支撐數(shù)萬服務、百萬節(jié)點體量的系統(tǒng)能力，并支持水平擴展。挑戰(zhàn)主要有3個：
美團體量是最流行開源產品 Istio 上限的上千倍。
極高的實時性、準確性要求；配置下發(fā)錯誤或丟失會直接引發(fā)流量異常。
起步較早，業(yè)界參考信息很少。
經(jīng)過對 Istio 架構進行深入分析，我們發(fā)現(xiàn)核心問題聚焦在以下3個瓶頸點：
每個控制面實例有 ETCD 存儲系統(tǒng)的全部數(shù)據(jù)，無法水平擴展。
每個 Proxy 鏈接相當于獨立與 ETCD 交互，而同一個服務的 Proxy 請求內容都相同，獨立交互有大量的 I/O 冗余。當 Proxy 批量發(fā)版或網(wǎng)絡抖動時，瞬時風暴很容易壓垮控制面及 ETCD。
每個節(jié)點都會探活所有其他節(jié)點。10 萬節(jié)點規(guī)模的集群，1 個檢測周期有 100 億次探活，會引發(fā)網(wǎng)絡風暴。
3.4.2 措施一：橫向數(shù)據(jù)分片
針對 Istio 控制面各實例承載全集群數(shù)據(jù)的問題，對應的措施是通過橫向邏輯數(shù)據(jù)分片支持擴展性，具體方案設計如下：
Proxy 啟動時會去向 Meta Server 系統(tǒng)請求需要連接的 Pilot IP，Meta Server 將相同服務的 Proxy 盡量落到同一個控制面節(jié)點（內部策略更為復雜，還要考慮地域、負載等情況），這樣每個 Pilot 實例按需加載而不必承載所有數(shù)據(jù)。
控制面節(jié)點異常或發(fā)布更新時，其所管理的 Proxy 也會有規(guī)律的遷移，恢復后在一定時間后還會接管其負責的 Proxy，從而實現(xiàn)了會話粘滯，也就實現(xiàn)邏輯上面的數(shù)據(jù)分片。
通過管理鏈接關系實現(xiàn)了按事業(yè)群隔離、按服務灰度等平臺能力，最關鍵的還是解決了 Mesh 體系水平擴展的問題。
3.4.3 措施二：縱向分層訂閱
針對 Istio 獨立管理各 Proxy 鏈接的 I/O 冗余問題，對應的措施是通過分層訂閱減少冗余 I/O。Proxy 不直接與存儲等系統(tǒng)對接，而是在中間經(jīng)過一系列的處理，關鍵點有兩個：
關鍵點 1：基于快照緩存 + 索引的機制來減少 ZK watcher 同步。以注冊中心為例，常規(guī)實現(xiàn)方式下，如果每個 Proxy 關注 100 個節(jié)點，1 萬個節(jié)點就會注冊 100 萬個 watcher，相同服務的 Proxy 所關注內容是相同的，另外不同服務 Proxy 所關注的也有很多交集，其中包含大量的冗余。分層訂閱模式下，Proxy 不與注冊中心直接交互，通過中間的快照緩存與分層，確保每個 Pilot 實例中 ZK 相同路徑的監(jiān)聽最多只用1個 watcher，獲取到 watcher 通知后，Pilot 根據(jù)內部的快照緩存 + 索引向所有關注者分發(fā)，大大降低了冗余。
關鍵點 2：治理能力層及會話管理層實現(xiàn)了類似于 I/O 多路復用能力，通過并發(fā)提升吞吐。
結果方面有效應對了網(wǎng)絡抖動或批量發(fā)版的瞬間風暴壓力，壓測單 Pilot 實例可以承載 6 萬以上的鏈接，時延 TP99 線 < 2.3ms、數(shù)據(jù)零丟失。
3.4.4 措施三：集中式健康檢測
針對大規(guī)模集群內指數(shù)級膨脹的節(jié)點間健康監(jiān)測次數(shù)，對應的措施是摒棄了 P2P 檢測模式，我們參考并優(yōu)化了 Google 的 Traffic Drector 中心化管理的健康檢測模式。這種模式下檢測次數(shù)大大減少，一個周期內 10 萬節(jié)點集群的檢測次數(shù)，從 100 億次下降到 10 萬次。
此外，當 Pilot 感知到 Proxy 異常時，會立即通知中心化健康檢測系統(tǒng)啟動檢測，而不是等待檢測周期窗口的到來，這可以有效提升業(yè)務調用的成功率。
3.5 交易型場景困境下的解決方案
3.5.1 業(yè)務屬性分析
美團內部業(yè)務線較多，包括外賣、配送、酒店、旅游、單車、團購等，其中絕大多數(shù)業(yè)務都帶有交易屬性，交易鏈路上一個流量異常就可能影響到訂單。業(yè)務系統(tǒng)對新技術領域的探索往往比較慎重，期望在新技術充分驗證后再啟動試點，所以除小語種及亟待與公司打通的單車業(yè)務外，推廣的難度是非常大的。此外，基礎架構部秉承“以客戶為中心”的原則，研發(fā)、運維、測試人員均是我們的“客戶”，所以技術升級會重點從業(yè)務價值入手，并非簡單依靠從上至下的政策推動力。
所以，我們對外的承諾是：通信足夠快、系統(tǒng)足夠穩(wěn)定、接入足夠平滑高效。
3.5.2 精細化運營體系建設
針對推廣的困境，我們首先做了兩件事情：
尋找具備強訴求的業(yè)務試點，客觀來說，美團技術棧內這類業(yè)務數(shù)量非常有限。
尋求標桿核心業(yè)務試點，充分驗證后推廣給其他業(yè)務，但效果并不理想，與業(yè)務穩(wěn)定性的訴求并不匹配。
針對上述困境，我們進行深度思考后建立了一個精細化的運營體系：
服務接入 Mesh 前。基于 SOA 分級將服務劃分為非核心與核心兩類，先針對非核心服務以及所有服務的線下環(huán)境進行重點突破，實現(xiàn)了在廣泛的業(yè)務場景下，全面且充分的驗證系統(tǒng)能力。
服務接入 Mesh 中。運營系統(tǒng)通過校驗 SDK 版本、運行時環(huán)境等信息，自動篩選出滿足條件的服務，業(yè)務同學只需要在平臺上做（1）開啟開關、（2）選擇節(jié)點（3）指定 Mesh 流量比例三個步驟，就完成了到 Mesh 模式的切換，不需代碼改造也不需發(fā)布服務，整個過程基本在 1 分鐘左右完成；此外，通過與 IM 工具深度聯(lián)動，提升了推廣與數(shù)據(jù)運營的效率。
服務接入 Mesh 后。一方面，業(yè)務側包括架構側的運營有詳細的數(shù)據(jù)指標做對比參考；另一方面，運營系統(tǒng)支持預先設置穩(wěn)定性策略并做準實時的檢測，當某個接入服務 Mesh 模式異常時，即時自動切換回非 Mesh 模式。
運營體系具備 “接入過程無感”、“精細化流量粒度灰度”、“異常自動回滾恢復” 三個核心能力，在運營體系建設后推廣運營較為順利，目前線上接入的 600+ 服務、線下接入的 3500+ 服務中，90% 以上是依托運營平臺接入 Mesh 的。
3.5.3 通信性能優(yōu)化
在性能損耗優(yōu)化這個方向，除使用 UDS 規(guī)避網(wǎng)絡棧外，我們也通過增量聚合下發(fā)、序列化優(yōu)化兩個措施減少不必要的解包，提升了通信性能。
經(jīng)過壓測，去除非核心功能在 2 核 4G 環(huán)境用 1KB 數(shù)據(jù)做 echo 測試，QPS 在 34000 以上，一跳平均延遲 0.207ms，時延TP99 線 0.4ms 左右。
3.5.4 流量多級保護
美團落地 Service Mesh 在穩(wěn)定性保障方面建設投入較多，目前尚無 Service Mesh 引發(fā)的故障，具體包含三個方面：
首先做了流量多級保護
一方面，當 Proxy 不可用時，流量會自動 fallback 到非 Mesh 模式；另一方面，支持最精細支持按單節(jié)點的 1/1000 比例灰度。下圖是具體的交互流程，當然，這兩個特性與 Service Mesh 的最終形態(tài)是沖突的，只是作為系統(tǒng)建設初期優(yōu)先保證業(yè)務穩(wěn)定性的過渡性方案，長期來看必然是要去除的（包括美團一些核心服務已經(jīng)完全去除）。
基于 FD 遷移 + SDK 配合協(xié)議交互，實現(xiàn) Proxy 無損熱重啟的能力。
控制面下發(fā)錯誤配置比停發(fā)配置的后果更為嚴重，我們建設了應用層面及系統(tǒng)層面的周期巡檢，從端到端的應用視角驗證正確性，避免或減少因變更引發(fā)的異常。
系統(tǒng)交互方面，通過限流、熔斷對中心化控制面做服務保護；系統(tǒng)內柔性可用，當控制面全部異常時，緩存機制也能協(xié)助 Proxy 在一定時間內可用。
四、總結
本文系統(tǒng)性的介紹美團在 Service Mesh 落地進程中面臨的“兼容性”、“異構性”、“規(guī)模化”、“交易屬性業(yè)務容錯性低”這四類復雜性挑戰(zhàn)，針對上述挑戰(zhàn)，我們也詳細介紹了大規(guī)模私有云集群場景下的優(yōu)化思考及實踐方案。
基于上述實踐，目前美團線上落地服務數(shù)超過 600，線下服務數(shù)超過 3500+，初步驗證了模式的可行性。短期價值方面，我們支持了摩拜等異構治理體系的快速融合、多語言治理能力的統(tǒng)一；長期價值仍需在實踐中繼續(xù)探索與驗證，但在標準化服務治理運行時并與業(yè)務解耦、中心化管控下更豐富的治理能力輸出兩個方面，是非常值得期待的。
作者簡介
繼東、薛晨、業(yè)祥、張昀，均來自美團基礎技術部-基礎架構部。
----------? END? ----------
想要加入中生代架構群的小伙伴，請?zhí)砑尤汉匣锶?strong>大白的微信
申請備注（姓名+公司+技術方向）才能通過哦！
阿里技術精彩文章推薦
往期推薦
深度：揭秘阿里巴巴的客群畫像
多隆：從工程師到阿里巴巴合伙人
阿里技術專家楚衡：架構制圖的工具與方法論
螞蟻集團技術專家山丘：性能優(yōu)化常見壓測模型及優(yōu)缺點
阿里文娛技術專家戰(zhàn)獒: 領域驅動設計詳解之What, Why, How?
阿里專家馬飛翔：一文讀懂架構整潔之道
阿里專家常昊：新人如何上手項目管理？
螞蟻集團沈凋墨：Kubernetes-微內核的分布式操作系統(tǒng)
阿里合伙人范禹：常掛在阿里技術人嘴邊的四句土話
阿里技術專家都鐸：一文搞懂技術債
支付寶研究員兼OceanBase總架構師楊傳輝：我在數(shù)據(jù)庫夢之隊的十年成長路
阿里技術專家麒燁：修煉測試基本功
阿里計算平臺掌門人賈揚清：我對人工智能方向的一點淺見
螞蟻資深算法專家周俊：從原理到落地，支付寶如何打造保護隱私的共享智能？
阿里高級技術專家簫逸：如何畫好一張架構圖？
阿里高級技術專家張建飛：應用架構分離業(yè)務邏輯和技術細節(jié)之道
螞蟻科技 Service Mesh 落地實踐與挑戰(zhàn) | GIAC 實錄
阿里6年，我的技術蛻變之路！
螞蟻集團涵暢：再啟程，Service Mesh 前路雖長，尤可期許
阿里P9專家右軍：大話軟件質量穩(wěn)定性
阿里合伙人程立：阿里15年，我撕掉了身上兩個標簽
阿里高工流生 | 云原生時代的 DevOps 之道
阿里高級技術專家邱小俠：微服務架構的理論基礎 - 康威定律
阿里P9專家右軍：以終為始的架構設計
阿里P8架構師：淘寶技術架構從1.0到4.0的架構變遷！12頁PPT詳解
阿里技術：如何畫出一張合格的技術架構圖？
螞蟻資深技術專家王旭：開源項目是如何讓這個世界更安全的？
阿里資深技術專家崮德：8 個影響我職業(yè)生涯的重要技能
儒梟：我看技術人的成長路徑
阿里高級技術專家宋意：平凡人在阿里十年的成長之旅
阿里技術專家甘盤：淺談雙十一背后的支付寶LDC架構和其CAP分析
阿里技術專家光錐：億級長連網(wǎng)關的云原生演進之路
阿里云原生張羽辰：服務發(fā)現(xiàn)技術選型那點事兒
螞蟻研究員玉伯：做一個簡單自由有愛的技術人
阿里高級技術專家至簡: Service Mesh 在超大規(guī)模場景下的落地挑戰(zhàn)
阿里巴巴山獵：手把手教你玩轉全鏈路監(jiān)控
阿里涉江：你真的會學習嗎？從結構化思維說起
螞蟻金服資深技術專家經(jīng)國：云原生時代微服務的高可用架構設計
深入分布式緩存之EVCache探秘開局篇
? ?END ? ?? #架構師必備#點分享點點贊點在看總結
以上是生活随笔為你收集整理的美团技术：复杂环境下落地 Service Mesh 的挑战与实践的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： hdu-Calculation 2(欧拉
- 下一篇： poj-青蛙的约会（扩展欧几里得）nyo