蚂蚁集团涵畅：再启程，Service Mesh 前路虽长，尤可期许
本文根據涵暢在開源中國 OSC 源創會架構專場分享整理。
前言
幾乎所有人都在說 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.html
Sentinel
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 負責人。
本文歸檔在 sofastack.tech。
推薦閱讀
?
阿里P9專家右軍：大話軟件質量穩定性
?
史海峰：構建產業互聯網金融系統的正確姿勢
?
阿里合伙人程立：阿里15年，我撕掉了身上兩個標簽
?
揭秘阿里中臺！一文看懂阿里推薦業務的兩大利器 | 贈書
? ?END ? ?? #接力技術，鏈接價值# 點分享點點贊點在看總結
以上是生活随笔為你收集整理的蚂蚁集团涵畅：再启程，Service Mesh 前路虽长，尤可期许的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： hdu-3342-Legal or No
- 下一篇： 知道创宇杨冀龙：2B产品经理的自我修养