前言
幾乎所有人都在說 Service Mesh；貌似沒人知道怎麼落地 Service Mesh；但是大家都覺得其他人在大力做 Service Mesh；是以大家都宣稱自己在做 Service Mesh。
上面隻是開一個玩笑，但是從某種程度反映了一些實際情況：Service Mesh 是一種設計思想和理念，而不是具體的架構或者實作方式，雖然 Istio+Envoy 的配置似乎已經成了事實标準，當我們環顧四周，卻發現理想太豐滿，現實太骨感，因為各企業目前切實原因，導緻各種形态的 Service Mesh 百花齊放。
螞蟻金服的 Service Mesh 就屬于上面提到的百花齊放中的一員，我們已經渡過探索期，全面進入生産應用。去年的雙十一完成了交易支付核心鍊路，幾十萬容器規模的生産級驗證。但是業界對于 Service Mesh 仍然有很多種不同的聲音，一方面是衆星捧月式的支援，另一方面是困惑和質疑，包括對價值、架構以及性能的質疑。那麼我們對此是什麼态度？雙十一深度實踐之後螞蟻金服的 Service Mesh 路又在何方？Service Mesh 架構是終點嗎？
本文将結合螞蟻金服内部實際場景以及思考，講述繼 2019 雙十一之後，螞蟻金服在 Service Mesh 路上的規劃和持續演進。
螞蟻金服 Service Mesh 實踐回顧
上圖是 2019 年螞蟻金服雙十一的實踐架構，雲原生網絡代理 MOSN（
https://github.com/mosn）作為螞蟻金服自研資料面産品，承載了 Mesh 架構的東西向流量。對于控制平面，基于務實的前提我們探索出一套目前階段切實可行的方案，基于傳統服務發現體系落地了 Service Mesh 架構。
這裡是資料化的落地總結，在滿足業務的同時，我們真正做到了對業務的低侵入：極低的資源消耗以及快速疊代能力，業務和基礎技術都享受到雲原生 Mesh 化所帶來的紅利。
Service Mesh 前路漫漫
我們再來看看 InfoQ 釋出的 2020 年 4 月份 Software Architecture and Design 趨勢報告，Service Mesh 目前處于 Early Adoption 代，在雲原生技術圈仍處于大熱階段，各種技術論壇我們都能見到 Mesh 架構的專場，本篇文章我們不過多讨論 Service Mesh 的選型、使用場景、合理性等等問題，需要的同學可以參考一下文末曆史文章，有很多螞蟻金服對 Service Mesh 的思考。
對于我們來說，既然在深度思考後選擇了這條路，并且在去年雙十一進行了深度實踐，那麼棋到中盤，下一步應該如何落子，除了務實落地之外，我們還要仰望星空，必須知道離詩和遠方還有哪些 Gap：
非全面雲原生
前面提到我們落地 Service Mesh 時，仍然采用了傳統微服務體系，雖然整體架構基于 K8s，但在控制面上并沒有采用社群的方案，當然這些是有考慮的，但是随着整體架構的演進，非全面雲原生化勢必會成為我們持續享受雲原生紅利的最大障礙。
平台能力不足
Service Mesh 的定位是解耦基礎設施與業務，但是目前看來，不管是社群 Istio+Envoy 的組合，還是螞蟻金服傳統微服務+MOSN 的實踐，均是把東西流量的治理作為了重點，離詩和遠方還有很長的路。目前還有大量的基礎設施邏輯作為 SDK 鑲嵌在業務系統中，我們仍然要面臨基礎設施更新對業務帶來的影響。
邊界流量覆寫不全
随着雲原生在資料中心内部愈演愈烈，但是對于資料中心邊界以及邊緣網絡，七層應用網絡流量仍然沒有形成一個全局體系，由于體系的缺失我們不得不在邊界網關與 Mesh 網絡兩者之間各自分裂發展，均有獨立的流量排程體系以及安全可信體系。
生态融合度低
傳統服務體系發展了這麼多年，積累了大量寶貴的财富，Service Mesh 作為新貴出現，從兩個方面來說：Service Mesh 需要傳統服務體系的融入支撐，才能使現有業務遷移到 Mesh 體系；同時傳統服務體系的元件也需要有和 Mesh 體系融合的能力才能持續保持競争力。
性能
性能是一個老生常談的問題，Mesh 架構中質疑性能的聲音也層出不窮 ，包括 Mixer 控制面，還有引入 Sidecar 造成的額外網絡消耗、編解碼消耗等等。不過我們可以看到社群一直在解決這些問題，包括對 Mixer 架構的重構，引入 ebpf 來加速流量劫持等等。
綜上所述，我們在 Service Mesh 上任重道遠。
将 Service Mesh 進行到底
今年我們的目标是 Mesh 全面覆寫主要業務，這将面臨非常大的挑戰：
- 金融級安全可信的要求，需要我們做到全鍊路加密與服務鑒權；
- 統一 Sidecar 與 Ingress Web Server；
- 雲原生控制面的落地；
- 透明劫持能力；
- 需要承載更多的中間件能力下沉；
上面分析了目前存在的各種問題，同時結合螞蟻金服自身的業務發展需求，那麼我們可以很清晰的對症下藥了，我們将上述問題抽象成三類，并進行專項攻堅：
- 以開源生态建設，來應對生态融合問題；
- 通過雲原生标準演進，來解決非全面雲原生問題；
- 最後通過基礎核心能力增強，來治理平台能力，覆寫場景以及性能的不足的問題；
開源生态建設
我們再來回顧一下雙十一之後我們做的第一個動作：在 2019 年 12 月 28 日由螞蟻金服主辦的第九期 Service Mesh Meetup 上，我們對外宣布了 MOSN 完成在 SOFAStack 的孵化，開始獨立營運，以更加開放的姿态尋求合作共建夥伴：
我們認為，未來會更多地屬于那些告别大教堂、擁抱集市的人們。《大教堂與集市》
在宣布獨立營運的同時，我們也做了一系列措施：
- 獨立的項目域名：mosn.io
- 項目位址：github.com/mosn/mosn
- 社群組織：MOSN Community Organization
- 項目管理條例：PMC、Committer 選舉晉升機制等等
接下來，開源社群我們也持續做了非常多的事情，包括專題 Working Group的建立，例如 Isito WG， Dubbo WG 等等。
同時也尋求了非常多的外部合作，超過一半的 contributor 均來自外部，接受了第一個來自 BOSS 直聘的 Committer 等等，針對生态融合，我們同Skywalking，Sentinel和Dubbo-go社群進行了深度合作。
Skywalking
調用依賴以及服務與服務之間的調用狀态，是微服務管理中一個重要名額。Skywalking 是該領域非常優秀的一款 APM 軟體，MOSN 與 Skywalking 社群展開了合作，進行了兩個系統的深度整合工作，目前支援：
- 調用鍊路拓撲展示；
- QPS 監控；
- 細粒度 RT 展示；
在今年五月份，SkyWalking 8.0 版本進行了一次全面更新，采用新的探針協定和分析邏輯，探針将更具互感覺能力，更好的在 Service Mesh 下使用探針進行監控。同時，SkyWalking 将開放之前僅存在于核心中的 Metrics 名額分析體系。Prmoetheus、Spring Cloud Sleuth、Zabbix 等常用的 Metrics 監控方式，都會被統一的接入進來，進行分析。此外，SkyWalking 與 MOSN 社群将繼續合作：支援追蹤 Dubbo 和
SOFARPC，同時适配 Sidecar 模式下的鍊路追蹤。
更詳細的資訊參考：
http://skywalking.apache.org/zh/blog/2020-04-28-skywalking-and-mosn.htmlSentinel
Sentinel 是由阿裡巴巴開源，面向微服務的輕量級流量控制架構，從流量控制、熔斷降級、系統負載保護等多個次元保護服務的穩定性。MOSN 目前僅有簡單的限流功能，是以我們與 Sentinel 社群進行合作，将多種不同的限流能力融入 MOSN，進一步提高 MOSN 的流量管理能力，同時大幅降低業務限流接入及配置成本。
對于長期規劃方面，後面會提到，我們将以此作為切入點，提出新的基于 UDPA 的統一限流标準。
Dubbo
對于支援 Dubbo ，我們主要是基于以下背景：
- Dubbo 是服務實作架構，Service Mesh 是架構理念，Dubbo 也需要享受 Service Mesh 帶來的紅利，企業适配、擴充需求客觀存在，Dubbo 社群同樣有這樣的使用者需求；
- 很多使用者和企業無法一步到位雲原生，需要漸進落地；
- 目前開源方案無法支援 Dubbo 服務發現；
此前我們基于 MOSN 的 xprotocol 架構支援了 Dubbo 協定，但是并沒有整體實作基于 Dubbo 的服務體系，這次我們設計了兩個方案來滿足使用者對 Dubbo 的需求，也同樣是雙模微服務架構：左邊是基于傳統的 Dubbo 注冊中心，內建 Dubbo-go SDK 來滿足在傳統架構下的 Mesh 化：
- MOSN 提供 Subscribe、Unsubscribe、Publish、Unpublish 的 HTTP 服務；
- SDK 發送請求到 MOSN 提供的這些服務，讓 MOSN 代為與真正的注冊中心互動；
- MOSN 通過 Dubbo-go直接和注冊中心連接配接；
右圖是直接通過 Istio 擴充，以雲原生的方式進行 Mesh 支援，該方案是社群合作夥伴多點生活進行了能力貢獻，詳細的技術方案和使用方式可以閱讀
《多點生活在 Service Mesh 上的實踐 -- Istio + Mosn 在 Dubbo 場景下的探索之路》。
雲原生标準演進
在前面我們提過無論是螞蟻金服，還是其他公司，雖然生産級實踐了 Mesh，但是均是以傳統方式進行的落地，當然這也是基于各個公司目前現狀的選擇。随着技術的探索，雲原生服務治理系統 Istio 的可運維性和架構的合理性也逐漸迎來積極的變化，其功能的完善、性能的提升、部署和運維的複雜性等問題将得到解決，同時随着雲原生的全面深度規模化演進，非雲原生的架構勢必阻礙我們的前進。是以我們通過與 Istio 社群的緊密合作建設一個全局的 Service Mesh 控制平面，同時與雲原生網絡代理 MOSN 緊密協作推動我們從傳統向雲原生 Mesh 化的演進，為此我們進行了以下方面的工作：
- 雲原生标準 Sidecar 的打造；
- 标準化參與和建設；
針對第一點，MOSN 持續在進行 Istio 能力的對齊工作，包括 Istio 側多 Sidecar 支援以及 MOSN 側功能對齊 Istio，控制面方面支援注入 MOSN Sidecar、Pilot-agent 的适配以及 Istio 編譯建構的适配、負載均衡算法、流量管理體系、流量檢測、服務治理、Gzip等，整個 Milestone：
- 2020年4月完成相關需求任務拆解，可在 Istio-1.4.x 版運作 Bookinfo；
- 2020年6月完成 HTTP 系強依賴功能開發，相容新架構下的 Istio-1.5.x；
- 2020年8月 HTTP 系功能對齊 Istio；
- 2020年9月支援 Istio 版本預釋出；
标準化方面，我們參與了 UDPA 相關規範讨論，并提出限流通用 API 規範
讨論，社群會議讨論組織中。
另外 MOSN 一直積極地在與 Istio 社群進行溝通以及尋求合作，我們的目标是希望能成為 Istio 官方推薦的 Sidecar 産品，對此我們在 Istio github 上提了相關 ISSUE，引發了比較大的關注，也非常高興官方 Member 成員對此問題進行了非常詳細的回答和探讨。
他們對此提出了一些問題和顧慮，并在 Istio 的例會上進行了專項讨論。
讨論記錄詳見：
https://github.com/istio/istio/issues/23753有過此次溝通後，我們得到了官方對此的想法和建議，讓我們也有了非常明确的目标和動力。另一方面針對 Istio 提出的幾點問題，我們也有了相應的想法和 Action：
- 對于測試用例覆寫成本，可以通過解耦 Istio 中測試用例和 Envoy 的綁定，或者制定資料面測試集标準套件來降低維護成本；
- 另外 MOSN 社群的同學可以一起加入來進行維護，進而降低維護成本；
我們會持續投入資源專注在自身能力的打造上，同時保持與社群的協作關系，相信在今後時機成熟時，雙方會進行深度的合作。
基礎核心能力增強
Service Mesh 未來路在何方，會發展到何種形态？MOSN 應該具備什麼能力才能支撐 Service Mesh 的持續演進？前文中我們通過開源生态建設，雲原生标準演進去解決非全面雲原生、生态融合度低的問題。那麼對于其他問題，再結合螞蟻金服自身場景的需要，我們做了非常多的能力建設：
- 靈活便捷的多協定擴充支援；
- 多形态的可擴充能力；
- 消息與 P2P 通信模型；
- OpenSSL 支援；
協定擴充
阿喀琉斯之踵
我用了阿喀琉斯之踵來形容對協定擴充的痛之切，足以見在這塊踩過的坑吃過的苦。不管是“遠古時代”的 Apache httpd、“中古時代”的 Nginx、還是“現代化”的 Envoy，都是針對 HTTP 或者其他通用協定設計的架構，雖然很多延伸産品做了非常多的擴充，但是對于私有協定擴充仍然比較困難，除了協定本身的轉發支援，無法做到通用的架構治理。是以我們需要對每一種協定行為做獨立的體系支援，架構需要了解整個請求生命周期、連接配接複用、路由政策等等，研發成本非常大。基于這些實踐痛點，我們設計了 MOSN 多協定架構，希望可以降低私有協定的接入成本，加快普及 ServiceMesh 架構的落地推進，更詳細的内容可以看看當時的視訊分享：《
雲原生網絡代理 MOSN 的多協定機制解析》
MOSN 多協定架構
可擴充子產品化能力
随着業務的發展以及我們對Service Mesh的規劃，MOSN需要承載越來越多的基礎能力下沉，隻有提供靈活高效且穩定的可擴充機制，才能保持其競争力以及長久生命力。
MOSN 在設計初期就借鑒了 Nginx 和 Envoy 的優秀設計，提供了基于 Filter 的可擴充機制，通過 Network Filter 可以建立自定義的 Proxy 邏輯，通過 Stream Filter 可以提供限流、認證鑒權、注入等等功能，通過 Listener Filter 可以支援透明劫持的能力。
但是這裡會發現一個問題，就是有時候我們需要的擴充能力已經有現成可用的實作了，那麼我們是否可以做簡單的改造就讓 MOSN 可以擷取對應的能力，哪怕目前可用的實作不是 Go 語言的實作，比如現成的限流能力的實作、注入能力的實作等；又或者對于某些特定的能力，它需要有更嚴格的控制，更高的标準，比如安全相關的能力。
類似這樣的場景，我們引入了 MOSN 的 Plugin 機制，它支援我們可以對 MOSN 需要的能力進行獨立開發或者我們對現有的程式進行适當的改造以後，就可以将它們引入到 MOSN 當中來。
MOSN 的 Plugin 機制包含了兩部分内容：
- 一是 MOSN 自定義的 Plugin 架構，它支援通過在 MOSN 中實作 agent 與一個獨立的程序進行互動來完成 MOSN 擴充能力的實作；
- 二是基于 Golang 的 Plugin 架構，通過動态庫（SO）加載的方式，實作 MOSN 的擴充。其中動态庫加載的方式目前還存在一些局限性，還處于 beta 階段；
另外目前大熱的 WebAssembly 也是未來發展的方向，在很多場景已經有了比較成熟的支援，Golang 官方目前也有了 WASM 的分支，相信在不久的将來我們也能享受到 WASM 的紅利。
消息通信模式
随着 Service Mesh 襲來以及實踐的浪潮愈發猛烈，除了傳統的服務通信 RPC 外，DB、cache 等形态的 Mesh 需求也日益浮出水面，但好在這些通信模式與 RPC 類似，我們不需要對 Sidecar 進行太多的改造就能支援。但是對于消息通信就不一樣了：
- 有狀态網絡模型；
- 消息順序性；
- Partitions 為負載原子；
這使得消息 SDK 無法使用 Partitions 順序消息，導緻 Mesh 化後的消息無法保證正常發送和接受。消息的 Pull/Push Consumer 中 Partitions 是負載均衡的基本機關，原生的 Consumer 中其實是要感覺與自己處于同一 ConsumerGroup 下消費同一 Partitions 的 Consumer 數目的，每個 Consumer 根據自己的位置來選擇相應的 Partitions 來進行消費，這使得消息中的負載均衡政策已經不再适用于 Service Mesh 體系。
OpenSSL 支援
在今年的規劃裡，我們将基于 Service Mesh 全面實施東西向流量加密，提供更強的傳輸流量加密保護。同時還會引入國密算法提升安全合規能力，基于安全硬體實作全方位的可信能力。這一切的基石都是需要有一個高效強大且穩定的密碼基礎設施，MOSN 的原生 Go-TLS 有很多問題：
- 安全能力弱：尚未有任何軟/硬體的密鑰安全機制；
- 疊代周期長：Go-TLS 到版本 1.15+ 才完全支援 TLS1.3 的安全特性；
- 套件支援差：僅支援典型的 ECDHE、RSA、ECDSA 等算法；
- 性能弱：典型如 RSA、Go 版本性能不到 C 版本的 1/5；
OpenSSL 作為密碼基礎設施的老大哥，成為了我們的不二選擇。OpenSSL 有廣泛的使用、豐富的硬體加速引擎、專職的社群人員維護、大而全的套件支援以及高度優化的算法性能。當然對于如何支援 OpenSSL 我們也做了充分的測試和思考，如果使用傳統 Cgo 接管所有 TLS 流程，雖然我們享受到了一次內建，終身受用的便捷，但是 Cgo 帶來的性能損耗我們無法接受，是以最終我們采用的方案是混合使用，實作特定的安全能力。
透明劫持
雖然社群提供了無侵入接入 Service Mesh 方案，但是原生社群方案帶來的性能損失和運維成本都非常大，是以我們在實踐中其實并沒有做到無侵入地接入。但是随着業務的更大範圍的鋪開，無侵入式能力迫在眉睫，我們需要要解決多環境适配、可運維性以及性能問題。我們仍然是基于 Iptables 作為資料面來實作流量的劫持，但是針對不同情況作了優化：
- Tproxy 替代 DNAT 解決 Conntrak 連接配接跟蹤問題；
- Hook Connet 系統調用解決 outbond 流量兩次穿越協定棧帶來的性能損失；
- 模糊比對黑白名單降低整體規則的管理成本；
流量劫持技術的發展與 Service Mesh 的落地密切相關，後續我們将圍繞環境适配性、低延遲時間、低管理成本等方面持續演進，建構由 DNAT、TProxy、TC redirect、Sockmap 等技術組成的多模單體底座，在不同核心環境、不同性能要求、不同管理成本的場景中自适應選取最合适的劫持技術，不斷降低 Service Mesh 的接入成本。
Service Mesh 尤可期許
以上便是我們去年雙十一之後，在 MOSN 以及 Service Mesh 下的持續探索，整體的 Milestone 如下：
在我看來，Service Mesh架構對于雲原生架構，就像高鐵之于國民經濟。我們經曆了雲計算的十年，在這個過程中，看似牢固的行業和技術壁壘被不斷打破，經典的理念也經常受到質疑和挑戰，那麼Service Mesh在未來一定也有大的變革。小劍老師其實對此做了深入的分析
《Mecha：将Mesh進行到底》。這裡我就不再重複，主要說說我個人的一些見解。首先我們在發展趨勢中，業務與基礎技術持續解耦、協同；中間件持續下沉，業務基礎層下沉；基礎業務需更好的與 Mesh 架構整合，形成生态，有非常高度的一緻。同時我認為随着雲原生網絡的邊界擴大，勢必帶來規模化效應，我們需要解決性能、資源消耗、延遲等各種基礎問題，是以需要通過 Kernel Bypaas，Sidecar as Node，引入硬體優化等手段解決以上問題。同時我們相信在雲原生的演進中，容器網絡将與 Service Mesh 融合，網絡從面向 IP 到面向 Identity 與服務，可以将 Sidecar 向下沉澱為系統基礎設施，成為安全容器網絡棧，智能硬體裝置基本網絡單元。
當 Sidecar 下沉作為系統的一部分後，開始從架構往平台發展，提供分布式原語抽象像 Dapr 一樣提供遠端 API 的方式對外提供服務是一種實作，另外我們正在嘗試基于共享記憶體的接口通信方案，最後業務會發展為面向 Mesh 程式設計，Mesh 架構最終形成分布式微服務 OS。
但是 No Silver Bullet，分布式系統雖然已經成為新型業務的主流形态，但在很多傳統領域，集中式架構仍然存在于許多核心系統中。這種系統最重要的就是運維效率，高可用等穩定性訴求。這正是成熟的集中式架構的強項。而業務中前台，更多的挑戰是如何應對市場的快速變化，進行快速疊代，搶占市場。分布式架構，特别是微服務架構正是幫助使用者能夠進行快速疊代，推出業務能力而生的，Service Mesh 目前來看将成為這種架構的助推器。
作者簡介
肖涵，花名涵暢，2011年加入螞蟻金服，一直從事四/七層網絡負載均衡，高性能代理伺服器以及網絡協定相關的研發工作。目前是螞蟻金服可信原生技術部應用網絡組負責人，螞蟻金服開源項目雲原生網絡代理 MOSN 負責人。