Categories
程式開發

落地三年,兩次架構升級,網易 Service Mesh 實踐之路


當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。

落地三年,兩次架構升級,網易 Service Mesh 實踐之路 1

舉個例子,如果運維人員要對某服務進行流控設置,只需通過服務治理平台將流控參數下發到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。

落地三年,兩次架構升級,網易 Service Mesh 實踐之路 2

輕舟的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,主要是因為以下四種原因。”

  1. Istio和Envoy都是雲原生社區開源產品。雲原生是下一個技術浪潮,面向雲原生的架構可以快速獲得社區的技術紅利,而且云原生社區活躍度高,版本迭代快。

  2. Envoy擁有不低於Nginx的轉發性能,但在治理能力和控制能力(UDPA)方面,卻比Nginx靈活得多。 Istio是Envoy的黃金搭檔,作為從Kubernetes上長出來的原生Service Mesh控制面框架,比較親和容器化場景。

  3. Envoy支持協議和插件擴展,以滿足除HTTP之外的其他L4/L7協議,Istio也可以通過MCP和API能方式擴展控制面對註冊中心、配置中心、CRD的支持。這種豐富的擴展能力不僅能夠實現Service Mesh,將來也能實現DB Mesh、Redis Mesh等等。

  4. 近幾年,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未來發展需要解決的問題。