極客們，請收下2021 微軟 x 英特爾黑客松大賽英雄帖！>>>
導讀：服務網格（ Servicemesh ）于 2018 年夏天随着 Istio1.0 的正式釋出席卷全球，國内各大公司也遍地開花，其所帶來的理念逐漸為各方所接受并風靡。愛番番基于自身的痛點和 ToB 行業的特點，攜手公司基礎架構，于 2020 年 8 月底正式啟動了 Servicemesh 項目，僅用 3 個月就快速完成了 Java 業務應用的全切，成為百度第一個将商用生産系統完全基于原生 Kubernetes + Istio 運作的産品。
全文6492字，預計閱讀時間12分鐘。
一、緣起：沉浸式治理
愛番番作為一站式智能營銷和銷售的加速器，旨在助力企業實作業務增長。在溝通、營銷、銷售、洞察等領域持續發力，在 ToB SaaS 行業中面臨着激烈的競争，這就意味着在技術上對系統穩定性和研發人效有着非常高的要求。而回頭來看，當下愛番番在業務上面臨着諸多挑戰：
1.多語言治理難。存在着 Java、Golang、Nodejs、Python 等語言，在服務治理上主要支撐 Java 的需求，其餘語言的治理或自成一套，或基本缺失。其将帶來很大的治理成本和系統風險。
2.業務耦合。目前采用 Smart Client 的服務治理架構，推動疊代更新困難。服務治理的周期平均在三個月以上，帶來極大的運維更新成本。
3.能力缺失。目前采用的服務治理架構缺乏足夠的治理手段，如限流熔斷、混沌、金絲雀、服務分組、流量錄制回放、動态配置等能力的支援。
4.人肉配置。目前服務治理架構将治理粒度全部降到方法級，其直接導緻過于大量（ 2k+ 方法）的人肉配置要求帶來的事實上的不可配置。直接導緻愛番番服務治理平台處于事實上的無人使用狀态。也正是以出過一些嚴重的線上問題。
因而服務治理的現狀即：治理邊際成本無法下降，反而呈指數上升趨勢，治理由于成本過高隻能基于問題驅動進行。這也是業内很多公司服務治理的現狀。最終在效能、穩定性、能力三方面，都面臨着很大的挑戰。同時，由于居高不下的治理成本，我們業務上要進行「 多雲/私有化部署 」的售賣目标看起來将會遙遙無期。
筆者稱這種治理為：沉沒式治理。看着永遠在治理，其實永遠在沉沒。
二、抉擇：下一代的服務治理體系
為了解決以上問題，扭轉沉沒式治理的困境，我們展開了一次艱難而不得不進行的選擇。是否能夠有辦法，既可解決 Smart Client 帶來的多語言&業務耦合的難題，又可以具備功能豐富而治理粒度适宜的服務治理能力？而且考慮到有限的資源，能夠以拿來主義的務實态度去進行問題的解決？
經過層層篩選和論述，擺在我們眼前的答案逐漸清晰了起來：服務網格（Servicemesh）。我們選擇了目前的事實上的雲原生标準服務網格設施：Istio。
服務網格（ Servicemesh，以下簡稱 Mesh ）概念于 2017 年春正式提出，并與2018年夏随着Google、IBM、Lyft 共建的 Istio1.0 的正式釋出席卷全球。其出現主要在于解決 Smart Client 帶來的一大難題 —— 「 如何解決服務治理與業務代碼強耦合以及跨語言場景治理效率低下 」的問題。Mesh 給出的解決方案即：倡導将服務治理能力進行就近下沉，統一由 Sidecar 進行接管南北東西流量。這樣最直接的好處即可以實作解耦，應用自身 “黑盒化”，整體服務治理進一步實作标準化，達到營運效率提升。在此之上，快速進行各種服務治理能力的增強，“一處開發，處處具備” ，徹底解放生産力，如下圖所示：
Istio 從邏輯上可以分為資料平面和控制平面，如下圖：
資料平面主要由一系列的智能代理（預設為 Envoy）組成，管理微服務之間的網絡通信以及收集和報告所有 mesh 中的遙測資料。
控制平面負責管理和配置代理來路由流量。
服務網格是一個新的概念，但本身并不是一個新奇的架構設計，早在十多年前，Airbnb 就已經在其治理架構 Smartstack 中進行了實踐，攜程的 OSP ，以及充斥在各種雲（mesos/marathon、k8s）裡面的服務治了解決方案都早已是類似的 Local Agent 架構。但此時，業内并未形成統一的标準，而其運維的複雜度也讓諸多人望而卻步。而随着 k8s 重新定義了基礎設施，服務網格則應運而生重新定義了 Local Agent。
随着服務網格的大放異彩，對應的問題也随之而來。不少人對于 Mesh 理念延伸出的問題如性能、穩定性和資源開銷表現出不同程度的擔憂和質疑，其也直接導緻了最具盛名的 Linkerd 的折戟，以及 Istio 架構上的曲折前進。Istio在經曆了控制平面性能漫長的質疑期後，終于不破不立移除了 Mixer，引入了 WASM 機制在資料面上進行插件化能力增強。這是很艱難而勇敢的一步，但也同樣會面臨新的風險。
時至今日，是否要用 Mesh，什麼時候使用 Mesh，如何用好 Mesh，Mesh 的定位和未來仍然為大家所津津樂道。這也正是其的魅力所在。而從整體上看，Istio 開源社群表現出了積極開放的心态，我們有理由相信，Istio 在成為服務網格的事實标準之後，能夠不斷釋放更大能量。
縱觀目前業内 Mesh 的落地情況：
1.騰訊雲基于 Istio 推出了 TCM，支援進行叢集托管或者自建，可對多地域流量管控；
2.螞蟻 Sofa-Mosn 另辟蹊徑，以 Golang 語言重寫 Mesh 并進行獨立演化，在國内大放異彩；
3.美團點評也正在大力推進 OCTO2.0 服務治理體系，進行基于 Envoy+ 自研控制台的Mesh 轉型；
4.百度内部有 BMesh 和天合Mesh 兩款 Mesh 産品；
5.頭條、快手正在進行對應的建設，網易輕舟進行了 Mesh化，陌陌建構了Java 版 Mesh；
6.Azure、AWS、Google Cloud 都推出了Mesh産品；
7. ......
整體情況如下圖不完全列舉所示：
我們可以進一步歸納看到：
1.Envoy（ Istio 預設使用了 Envoy ）已成為事實标準；
2.Istio 項目還在快速疊代演進并趨于生産穩定；
3.全球主流雲廠商和國内大量公司都已落地 Mesh；
4.目前主流做法采用（二次開發）Envoy + 自研控制台；
5.業内正在嘗試通過中間件下沉享有 Mesh 紅利。
我們的選擇：
1.從 ROI 來說，我們并不希望自己從 0-1 去自建 Mesh，我們希望集中更多資源投入業務疊代中，是以我們抱定「 滿足 80% 的能力，剩餘的 20% 可以妥協可以增強 」的思路來進行下一步的選擇。
2.從語言棧來說，由于 Mesh 本質是「 寄生 」在應用機器上的程序，是以資源控制本身尤其重要。因而現階段選擇 Java 語言來進行 Sidecar 的開發并不明智，也這是 Linkerd1.0 失敗的主要原因。是以我們并不打算引入 Java 技術棧的 Mesh。
3.從開源生态來說，Istio 經曆幾年的錘煉，雖然還有諸多不完美的地方，但其以強大的能力、巨頭的背書、以及生态的活躍等方面來說，已經成為業内事實上的 Mesh 标準。是以我們希望基于 Istio 建構愛番番的 Mesh 體系。
4.與百度基礎架構的協作上，關于是否直接複用廠内的 Mesh 産品這一問題，我們與基礎架構雲原生的同學進行了多輪溝通，由于「 私有化 / 多雲部署 」這一前提，愛番番本身希望盡量以不改變開源元件原有結構的方式進行輕量部署，如盡量不與廠内獨有基礎設施進行耦合、如按照完全原生的方式落地等。
于是愛番番和基礎架構雙方商定最終方案為：暫時不直接采用基礎架構的 Mesh，而改由基礎架構為我們運維 k8s 叢集以及搭建 calico 網絡，并采用百度天合産品進行叢集的管控。愛番番在此基礎上選擇 Istio1.7 原生元件進行落地。
在 ToC 場景，性能往往會被高優考慮，Mesh 目前的性能（RT & OPS）并不出衆，官方方案會帶來幾毫秒~十毫秒不等的延時。業内自研/二次開發方案做得較好的約在 0.5~2ms 之間不等。在 toc 高流量場景下，Mesh 的落地會有一定的阻礙。在性能問題解決之後，才可能會去考慮是不是能很好遷移之類的問題。
而在 ToB SaaS 場景，核心點即【可移植】，能夠很好地支撐私有化、多雲部署，産品需要具備良好的可遷移性和可維護性。相比之下，Mesh絕對的性能要求在中前期并不是需要最高優考量的點。而在中後期，随着中間件能力的下沉，更高的性能要求才會逐漸提上議程。
即二者差異性：
ToC場景：【性能】早于【可移植】考慮
ToB場景：【可移植】早于【性能】考慮
而愛番番，則是典型的 ToB 場景。Mesh 在做開箱即用上，能夠很好地起到作用。
三、實踐：平滑遷移與賦能業務
愛番番目前擁有華北、華南、華東3個 IDC，300+ 的 k8s node，300+ 的應用，3k+ 的服務點，8k+ 的pod。日均 10+ 億pv。主業務産品大多部署在華東叢集上，因而本次遷移主要針對華東叢集。
我們選擇了 Istio1.7 版本，以愛番番的實際使用場景作為基準進行 POC 的性能測試後，發現單機性能暫時可以滿足愛番番目前需求，在單機 100 QPS 左右，引入 Istio 的性能損耗在 1%以下。并且基于 Istio 的核心能力進行了驗證。
遷移的大原則有如下幾個：
1.監控先行；
2.業務方低感覺；
3.盡可能無損。
基于大原則，産出的遷移方案整體架構如下：
總體方案簡述：以 calico 為網絡設施建構一套新的 Mesh 容器網絡叢集，以入口網關進行灰階。兩個叢集之間采用 Istio-Gateway 進行通信，并在多環節進行容錯處理。以 Istio 作為服務治理的核心重構基礎設施。整個過程中，對于灰階遷移過程，以及新叢集的表現進行可視化觀察。整體遷移過程通過 CICD 以及 SDK 兩個層面來最大化實作對業務方的細節屏蔽。
我們在實施過程中，碰到的主要難點：
無法進行流量閉環假設。複雜的分布式拓撲中，遷移時候極難挑選出完全閉環的子拓撲進行先行遷移驗證。而一旦在沒有任何準備的情況下，将服務遷移上容器網絡叢集，這時候調用鍊中的某一環仍然留在主機網絡叢集上，則極容易引起線上事故。為了解決這個問題：
1.通過 Skywalking 進行鍊路拓撲的觀察，在遷移前期驗證階段時，盡量讓流量不至過于分散；
2.借助老注冊中心和灰階名單，實作容器網絡叢集中的服務在通路非灰階應用的時候，可直連調回主機。通過這種方式，即可放心地進行服務遷移而無需關注是否進行流量閉環。
容器網絡環境初期不穩定。在最開始遷移的初期，新叢集偶爾會出現 Node、API Server等基礎設施的不穩定，如果不進行任何幹預和快速應對，則可能會導緻嚴重的業務問題。為了解決這一問題，我們在多個環節進行了可用性的保障，包括：
1.在基礎設施層面，針對于 api server、etcd 等的抖動迅速止損和優化，并制定相應穩定性保障的 SOP；
2.在網關入口層面，基于任意産品線、任意灰階比例進行灰階和回切操作；
3.對于幂等的請求，提供失敗時自動 fallback 的機制；
4.對于失敗的請求，提供自動熔斷和恢複的能力；
5.對于常見容易遺漏的定時任務和異步 MQ 消費者程序，進行辨別後，一鍵回切時可進行自動縮容；
6.Mesh 容器叢集裡進行調用時，在調用方會進行連接配接/讀取逾時&重試的能力支援。
大規模的遷移較難對業務方屏蔽影響。基本涉及所有300+的業務應用的遷移，在高速疊代的業務場景之下，如何盡量降低業務方的成本，來實作快速的切換工作。針對這一問題，我們主要有三方面的舉措：
1.SDK 預設盡量向前相容。避免業務方進行大面積改造；
2在 CICD層面，屏蔽了新老叢集的部署細節，并可以按産品線進行按批次灰階，用一套模闆來管控兩套叢集配置，通過這些方式實作在CICD環節對業務方的完全透明；
3.對于大規模遷移過程中發現的緊急問題，通過鳳巢商業平台團隊提供的launcher熱加載機制，實作自動替換注入更新包來完成新功能的零侵入替換和快速驗證。
對于 Istio 的引入帶來的治理挑戰。Istio 的引入，對于以 Smart Client 理念去構築的原服務治理架構帶來了颠覆性的改變，這塊也會帶來對應的适應和切換的成本，我們如下進行應對：
1.理念轉變：整體理念即服務治理理念和模型全面向Istio靠齊，逐漸放棄全部基于 ServiceID（方法級）進行治理的思路；
2.配置優化：引入Istio後，會在整個調用鍊路上加入兩跳，針對這兩跳，重新審視連接配接/讀取逾時重試、tcp backlogsize 等核心配置的關系，避免引起不必要的穩定性故障；
3.入口收斂：Istio 引入後絕大部分的治理能力都通過 CRD 進行互動。我們将其治理入口暫時內建在 CD 系統上，禁止在kiali等其他地方進行核心配置變更，通過入口收斂來杜絕無序混亂的線上管理；
4.妥協增強：Istio 本身功能非常強大，但部分能力還需要進一步增強，比如限流熔斷、混沌工程等，于是我們也是在 tradeoff 之後進行取舍，對于部分功能做閹割妥協（如短暫放棄叢集限流），對于部分功能做補齊（如引入 chaosmesh 增強混沌）。通過這種方式，達到能夠快速享受 Istio 紅利的目的。
Mesh 項目于20年8月底正式啟動，9月初完成 POC 驗證，9月底完成 MVP 傳遞，并切換愛番番 17% 的應用，在10月之後，進行逐漸擴量，并不斷增強新叢集穩定性，同時開始釋放 Istio能力，最終在20年11月底完成華東主叢集業務應用的全量切換。整體投入5人力，僅曆時3個月完成從驗證到切換的過程，成為百度第一個将商用生産系統完全基于原生 Kubernetes+Istio運作的産品。
在完成 istio 的主體切換後，我們并沒有停下腳步，而是緊接着開始進行了業務上的賦能以最大化發揮出 mesh 的價值點。我們基于 mesh 這一标準化的底座，傳遞了近 20個 功能點，幫助我們的業務實作了效能、穩定性、功能、成本上的全面提升。
以一個 case 為例，愛番番的「全鍊路灰階釋出」平台，基于istio通過同構底層「分組多元路由」的架構設計，在解決業内主流 flagger/helm 方案弊端的同時，完成了一套架構對 ABTest、金絲雀、容量評估、多路複用、Set化 在内的多個核心能力的支撐（部分能力研發進行中），對分組節點的全生命周期和流量進行了集中管控。針對于服務端場景，通過 FGR Operator 協調 k8s 以及 istio vs/dr 資源，并打通監控報警與 CICD。針對于端上場景，與對應的前端資源打包和擷取的流程整合，進行使用者級的打标和路由分發。這在傳統解決方案中，需要付出大量的研發成本才能實作，而依托于 istio ，我們的整體資源投入得到了大幅的縮減。
Istio 具備豐富的治理能力，在服務連接配接、服務發現、服務保護、服務可觀察等方面都有豐富的能力進行支撐。目前，愛番番對 Istio 的使用包括但不限于：
服務連接配接
1.通訊：基于 Http1 的原協定長連；基于 K8s service 的服務發現；
2.負載均衡：預設 RR，對于特殊的應用需求（如愛番番的資料庫中間件 dataio ）采用一緻性哈希；
3.路由分組：金絲雀能力、測試環境多路複用、網關入口流量路由、abtest、開發機直連、灰階鍊路等。
服務保護
1.授權：敏感接口調用權限管控（如擷取使用者手機号）；
2.限流熔斷：基于連接配接數的單機限流，基于慢調用/異常數/率的熔斷；
3.故障注入：東西流量的故障模拟，其餘由 chaosmesh/chaosblade 支援。
服務營運
1.服務管控：并未使用開源 kiali 管理端，而将對應的節點資訊呈現在愛番番一站式平台上，并提供基礎的一站式管理能力，如限流熔斷、配置管控、服務遷移等；
2.APM：Istio 本身的 APM 中，Logging 基于 EFK架構 進行采集、Metrics 基于Prometheus 進行采集，通過 Grafana 進行一站式管理。業務應用的 APM 暫時維持現狀，仍然采用無 Mesh 的 Skywalking + EFK + Prometheus + Grafana 進行管控。
通過切換 Mesh，标志着愛番番雲原生又一核心裡程碑的達成，愛番番對自身業務的服務治理進行了底層解構并初步重塑，初步改變了沉沒式治理的現狀。之前的多語言治理難、業務耦合、能力缺失、人肉配置困境得到較大的緩解，在功能上，快速補充了超過 10+ 個之前缺失的核心治理能力，在效能上，将服務治理的生命周期從數月直線拉低到分鐘級，CI pipeline 時間節省 20%，解放了業務方和架構方的效能，測試環境多路複用能力更是可以颠覆現有開發模式，實作并行開發測試，并同時節省 30%以上 的測試聯調等待時間；在穩定性上，提供了限流熔斷和混沌工程的能力，為業務提供了堅實的自我保護手段。通過金絲雀釋出，更是可以實作上線流量的無損的同時，讓研發人員告别深夜釋出的局面；依托于 istio 建構的穩定性保障體系更是讓愛番番整體穩定性得到了飛躍式的提升。這僅是現在就能帶來的收益，而其未來的收益遠不止此。
四、結篇：星辰大海
當下，着眼于務實的角度，愛番番的服務治理仍然面臨着不小的挑戰需要去一一攻克，以最大化發揮出 Istio 的核心紅利。另一邊，我們其實并不滿足于将 Servicemesh 定義為南北東西向流量的管控上，面對效能難題，Servicemesh 的紅利其實能夠更大的釋放，解決更大範圍的痛點，沉沒式的治理不僅存在于分布式服務架構中，也會長期存在于所有的中間件裡。我們也關注到業内包括 Istio 自己本身也有一些對應的探索，我們也堅信這在未來必将成為「多語言微服務架構」背景下的主流趨勢，愛番番也基于自身痛點開始主導 apm mesh — Apache Skywalking Satellite 的孵化并成功 Release。我們更希望愛番番的 Servicemesh 體系，能夠真正意義上成為「下一代的中間件治理核心」。相信這會在不久的未來和公司其他部門的攜手合作下達成，徹底告别沉沒式治理，加速傳遞客戶價值點。
本期作者 | 橙子，百度愛番番業務部首席架構師，騰訊雲最具價值專家，QCon出品人，ArchSummit明星講師， Apache Commiter，曆任多家公司平台&基礎架構&運維負責人。
招聘資訊
無論你是後端，前端 ，大資料還是算法，這裡有若幹職位在等你，歡迎投遞履歷，關注同名公衆号百度Geek說，輸入内推即可，愛番番業務部期待你的加入！
閱讀原文
百度愛番番與Servicemesh不得不說的故事
---------- END ----------
百度Geek說
百度官方技術公衆号上線啦！
技術幹貨 · 行業資訊 · 線上沙龍 · 行業大會
招聘資訊 · 内推資訊 · 技術書籍 · 百度周邊
歡迎各位同學關注