當 Service Mesh 從概念期進入到應用期時，大家的關注重點都會轉向先鋒企業的落地實踐。為了幫助大家在實踐中“避坑”，我們採訪了多家互聯網企業的應用實踐，例如美團點評、同程藝龍以及瓜子二手車等，本文將和大家分享的是網易的 Service Mesh 實踐。今年 6 月，本文采訪嘉賓馮常健將在 QCon 全球軟件開發大會（北京站）2020 上分享題為《網易基於 Istio 的 Service Mesh 2.0 架構升級實踐》的演講，感興趣的同學可以關注一下。
2016 年，網易的部分業務嚴選、傳媒等率先開始探索使用 Service Mesh 架構支撐微服務體系建設；2017 年，網易開始落地 Service Mesh 1.0，代號 cNginx；2019 年，由於 Service Mesh 1.0 在管控能力和流量治理等方面的不足，網易開始基於定製 Istio 和擴展 Envoy 落地雲原生 Mesh 2.0，代號輕舟微服務。經過 1 年的升級改造，輕舟微服務已經在嚴選落地。
傳統微服務架構與 Service Mesh
大多數企業的 Service Mesh 實踐都不是從零開始，而是在原有微服務架構的基礎上進行改造轉型。那麼，傳統微服務架構在轉型過程中會面臨哪些問題？轉型之後，企業內部不同角色的技術人員需要做出哪些改變？
傳統的微服務框架以 RPC 通信框架為基礎，提供服務目錄、註冊發現、服務治理、流量管理、配置中心、全鏈路追蹤等核心能力，並且向外延伸到安全審計、監控告警、統計分析、知識庫等平臺化能力。
馮常健表示：“服務框架在微服務架構中佔據核心位置，因此，使用 Service Mesh 來替換正在使用的微服務框架，無異於一次‘換心手術’。”
以網易為例，他們的關注點在於如何在不中斷業務的情況下，逐步將微服務架構支撐能力下沉到 Service Mesh 架構裡。想要實現平滑過渡，除了需要在 Service Mesh 數據面和控制面組件中對服務註冊發現、RPC 協議、配置下發進行擴展之外，還要對現有的上層研發工作臺、運維效能平臺等支撐平臺進行兼容設計，避免支撐平臺等基建重複建設。
在部署架構方面，Service Mesh 比傳統微服務框架多了一層 Sidecar，且服務治理是基於流量的，因此會帶來一系列的問題和挑戰。
- Sidecar 的運維複雜性問題，微服務架構支撐能力下沉後，也把複雜性下沉到了 Sidecar。Sidecar 面臨著頻繁更新的問題，但 Kubernetes 和 Istio 只解決了部分部署的問題，因此如何在不影響業務的情況下熱更新 Sidecar 成為了新的挑戰；
- 性能問題，某些對延時比較敏感的業務會對性能問題有較多顧慮，迫切需要對服務與 Sidecar、Sidecar 與 Sidecar 之間的鏈路進行性能優化；
- 整體架構的可觀測性和排障效率問題，對業務方來說，服務註冊發現、服務通信等原本客戶端可見的過程現在都成了黑盒，在問題診斷和故障恢復方面需要更立體化的監控系統支撐。
Service Mesh 實踐會如何影響企業內部員工的工作內容呢？
傳統模式下，開發和運維會有比較清晰的邊界，開發人員負責服務運行穩定，運維人員負責服務運行的基礎設施穩定。而進入到雲原生時代，特別是容器化和 Service Mesh 落地之後，服務框架、服務治理、灰度發佈等穩定性密切相關的能力都作為基礎設施下沉了，開發和運維的邊界開始變得模糊。所以，企業 IT 人員的職責也應該相應的進行重新劃分。
- 架構師及基礎架構團隊，新的職責要求他們必須要非常理解業務，清楚地知道業務的服務依賴和服務治理規則，故障後能從業務視角進行排障和快速恢復。同時，他們還需要重新審視現有的技術架構和支撐平臺建設，從業務視角出發進行設計，避免做出來的技術平臺無法滿足業務需求，或者不好用。
- 開發人員，原先開發人員要關注很多方面，例如服務框架、服務治理、環境一致性、遙測數據、客戶端 SDK 版本升級等等，而現在，以上這些幾乎統統不用關注，只需要專注於業務本身的邏輯開發；
- 運維人員，依託於 Service Mesh 打通的服務和基礎設施邊界，以及對服務的統一抽象，能夠更好的從全局視角進行服務質量、依賴管理、容量規劃、端到端監控等來保障產品穩定性。
網易的 Service Mesh 實踐
2016 年，移動互聯網發展火熱，網易業務發展飛快。當時內部各事業部之間在服務化框架的應用方面差別非常大，Dubbo RPC 框架、Spring Cloud 微服務框架、自研微服務基礎設施都有，較少考慮微服務架構支撐能力的複用問題。
網易嚴選是 2015 年內部孵化、2016 年對外發布的新業務，沒有太多的歷史負擔，考慮到電商業務的複雜性，其在微服務架構選型方面進行了慎重的思考。
- 是否基於 RPC 框架提供服務治理？根據歷史經驗，由於業務團隊和基礎架構團隊的關注點和優先級不同，推動 RPC 框架升級效率非常低，業務團隊擔心服務穩定性受影響，基礎架構團隊擔心架構演進效率太低，矛盾比較突出。
- 如何支持多語言？微服務時代多語言是趨勢也是優勢，嚴選的核心業務是基於 Java 技術棧的，但是還是有大量前端業務和運營業務是基於 Node.js，另外還有不少業務是 Python 和 C++ 技術棧的。
- 基於開源項目還是自研？自研系統可掌控性較強，但是會面臨重複造輪子和項目生命力的問題，基於開源定製是一條更好的落地路徑。
2017 年，網易落地 Service Mesh 1.0
2017 年，網易嚴選業務首先開始落地 Service Mesh 1.0（代號：cNginx）架構。在選型方面，數據面採用了 Nginx，控制面及註冊中心採用 Consul，Nginx 和 Consul Agent 形成 Sidecar。通過 Nginx 實現了負載均衡、環境路由、熔斷降級和限流等服務東西向流量的管理，通過 Consul 實現了服務註冊發現、配置同步、指令下發等控制面流量下發。服務對外調用的流量都通過本地部署的 Nginx。
舉個例子，如果運維人員要對某服務進行流控設置，只需通過服務治理平臺將流控參數下發到 Consul Server，Consul Server 通過一致性協議將配置同步到集群所有 Consul Agent，Nginx 能 Watch 本地 Consul Agent，生成 Nginx 流控配置，作用於服務間的東西向流量。
Nginx+Consul 提供的基礎能力基本滿足了業務和基礎架構團隊對服務治理的需求。Service Mesh 1.0 最早是在網易郵箱、網易有錢和網易嚴選試點，隨著嚴選業務的快速發展，2017 年底，就基本在嚴選全面落地了，併發揮了重要作用。
- 業務不改造即可接入服務治理能力，對齊了跨團隊間對服務治理的理解，降低溝通協作成本，提升了業務團隊生產力。
- 解耦了基礎架構和業務服務化架構，使得他們能夠獨立演進。業務團隊聚焦業務開發，基礎架構團隊推動中間件和框架的升級可以做到業務無感知。原本需要三個月才能落地的 SDK 版本升級，現在只要兩週就可以通過灰度發佈完成全量更新。
- 多語言技術棧統一治理，充分發揮多語言技術棧在微服務架構中的優勢。
2019 年，網易落地 Service Mesh 2.0
Service Mesh 1.0 的落地雖然帶來一定的好處，但是隨著嚴選規模的變大和業務的複雜度，業務方對於基礎架構的訴求也發生了變化，他們需要更靈活的流量調度、更多功能的服務治理、更大範圍的基礎組件解耦、更敏捷的快速迭代，更彈性的 IT 資源…而這些，現有架構並不能滿足。
2019 年初，伴隨以 Kubernetes、Envoy、Istio 為代表的雲原生技術體系成熟，網易開始推動 Service Mesh 1.0 向雲原生 Service Mesh 2.0 架構（代號：輕舟微服務）升級。經過 1 年的升級改造，輕舟微服務已經在嚴選落地。
Service Mesh 2.0 與 1.0 有啥區別
與 Service Mesh 1.0（cNginx）相比，Service Mesh 2.0（輕舟）最大的不同在於全面擁抱雲原生技術。底座採用 Kubernetes，通過容器化和混合雲基礎設施解決快速迭代和 IT 資源彈性的問題。同時對基礎組件做了升級，數據面組件採用 Envoy，控制面組件採用 Istio。
輕舟的 Sidecar 在部署架構上採用 per-pod 模式，取代了 cNginx 的 per-node 模式，per-pod 在隔離性、安全性、擴展性、升級風險等方面更加友好。此外，cNginx 只開啟 client-sidecar，只攔截 Outbound 流量，為了充分發揮 Service Mesh 架構的優勢，輕舟啟用 both-sidecar 注入，在安全、遙測、路由、限流、故障注入、負載控制等方面能力更加完整。對於業務方最關心的請求延時問題，輕舟通過 SR-IOV 網絡增強、eBPF 短路 socket、xDS 協議優化等方式增強容器網絡和數據面性能，使延時降低 100% 以上。
Service Mesh 2.0 的技術選型
Service Mesh 2.0 是基於 Istio+Envoy 構建的，為什麼會是這樣的技術選型呢？
馮常健表示：“其實在選型之前，我們也做了很多調研工作，基於標準化、擴展能力、技術風險、研發成本等多種因素，綜合考慮了很多開源或自研方案，之所以選定 Istio+Envoy，主要是因為以下四種原因。”
- Istio 和 Envoy 都是雲原生社區開源產品。雲原生是下一個技術浪潮，面向雲原生的架構可以快速獲得社區的技術紅利，而且雲原生社區活躍度高，版本迭代快。
- Envoy 擁有不低於 Nginx 的轉發性能，但在治理能力和控制能力（UDPA）方面，卻比 Nginx 靈活得多。Istio 是 Envoy 的黃金搭檔，作為從 Kubernetes 上長出來的原生 Service Mesh 控制面框架，比較親和容器化場景。
- Envoy 支持協議和插件擴展，以滿足除 HTTP 之外的其他 L4/L7 協議，Istio 也可以通過 MCP 和 API 能方式擴展控制面對註冊中心、配置中心、CRD 的支持。這種豐富的擴展能力不僅能夠實現 Service Mesh，將來也能實現 DB Mesh、Redis Mesh 等等。
- 近幾年，Kubernetes 通過工作負載和 CRD 抽象給基礎設施系統設計帶來了巨大變革，Istio+Envoy 對微服務流量和服務治理的良好抽象，讓我們可以看到了通過 Service Mesh 來統一服務層系統設計的可能性。對集團來說，統一服務化層的技術棧，沉澱技術資產實現跨事業部的複用，能夠極大降低研發成本。
實踐 Service Mesh 還有哪些問題？
作為 Service Mesh 實踐者，對於想要實踐 Service Mesh 的企業，馮常健給出了以下三個建議：
首先，要充分認識到 Service Mesh 架構改造的必要性，想清楚當前技術架構的痛點在哪，用 Service Mesh 解決什麼問題，能為自己的業務帶來什麼樣的價值；
其次，要審視當前的組織文化。Service Mesh 作為一個統一的服務治理層，匯聚了大量原本其他技術平臺的能力，必然會涉及到對基礎技術平臺和周邊系統的改造。這時候尤其需要技術管理者制定戰略目標，為開發、架構、運維等多個團隊通力配合掃清障礙，這是預判 Service Mesh 能否落地的重要因素。
最後，關於 Service Mesh 演進路徑問題。微服務化是前提，業務系統沒有完成微服務化改造，就不存在 Service Mesh 建設的基礎。微服務化架構下，我認為先完成容器化改造和完善周邊平臺 (全鏈路監控、日誌平臺、CI/CD) 建設之後，再進行 Service Mesh 演進是一條穩妥的路徑，否則在系統運維效率和服務穩定性方面存在極大風險。當然，對於沒有能力成立基礎架構團隊的企業來說，外採雲廠商提供的成熟產品和諮詢也是一個替代方案。
從整個業界的發展趨勢來看，Service Mesh 正處於 Gartner 技術成熟曲線中的期望膨脹期。馮常健表示，目前 Service Mesh 發展呈現兩個特徵：
- 觀眾多，選手少。Service Mesh 技術在業界關注度高，當人們談論微服務架構的時候，必不可少都會談 Service Mesh，但是目前看到的落地實踐均出自互聯網頭部公司，大公司資源充足願意投資技術，IT 基礎設施完善，有技術沉澱，能應付 Service Mesh 的複雜性，而中小型公司和傳統企業基本還處於觀望狀態。
- Service Mesh 技術的商業價值還處於探索階段。幾乎所有的雲廠商都提供 Service Mesh 服務，但是目前這種雲服務同質化嚴重，缺少場景化的產品形態封裝，難以滿足用戶對於平滑演進的訴求，未來需要依靠更多貼近業務的最佳實踐來打磨產品。
Service Mesh 架構雖然通過業務和基礎平臺的解耦降低了整體服務化術棧的熵，但是卻增加了其所在的基礎平臺本身的複雜性，除了數據面性能需要持續優化之外，控制面組件的運維複雜性、可觀測性欠佳引起的排障困難、Sidecar 對中間件 Mesh 場景的支撐能力等都是 Service Mesh 未來發展需要解決的問題。
關注我並轉發此篇文章，私信我“領取資料”，即可免費獲得InfoQ價值4999元迷你書！
閱讀更多 InfoQ 的文章
