背景

有 外文 指出，2020 年 Service Mesh 技術將有以下三大發展：

• 快速增長的服務網格需求；
• Istio 很難被打敗，很可能成爲服務網格技術的事實標準；
• 出現更多的服務網格用例，WebAssembly 將帶來新的可能。

針對 Service Mesh 技術，ServiceMesher 社區治理委員會成員在 2020 新年伊始發表了他們各自的看法，並邀請雲原生與服務網格領域業界大牛抒發各自的見解，彙總成文，希望能給讀者們帶來一些思考和啓發。

正文

宋淨超（螞蟻金服）

雲原生的本質是讓機器取代人類，執行更多的自動化程序，就像 Kubernetes Operator 所提倡的那樣。假如說 Docker 的普及是 Kubernetes 發展的前提，那麼 Kubernetes 又成了 Service Mesh 這又一雲原生技術的發展前提，Service Mesh 從概念的提出到現在已經發展有三年了，目前總體上正處於概念普及到真正落地的階段，但是 Service Mesh 的發展遠沒有 Kubernetes 同期發展的那麼順利，越靠近應用層人類的慣性就越大，就越難被機器替代。如果有一天都可以機器自己寫程序了，那誰還管什麼 Service Mesh，什麼雲原生？

羅廣明（百度）

據瞭解，2020 年的 Kubecon EU 的提案中，很少有涉及服務網格落地場景，由此來看，服務網格技術離大規模生產落地還有很遠的路要走。當前 Istio 架構體現出來的性能問題遲遲沒有得到優化，使用原生的 Istio 大規模上生產還不太靠譜，有的公司選擇將 mixer 功能下層至自研的數據面，有的公司通過向容器注入探針解決可觀察性。總的來看，在當前服務網格部分落地場景中，大多都是基於 Istio 和 envoy，但對其或多或少都有改動，以滿足公有云/私有云的需求。

此外，在 Service Mesh 落地的過程中，現有傳統微服務應用（Spring Cloud/Dubbo 應用）如何平滑遷移到 Service Mesh，也是一個至關重要的話題。“雙模微服務”的互聯互通、共同治理有望成爲 2020 年服務網格落地的關鍵技術之一，這也是國內幾家典型雲廠商力求打造的亮點產品。

馬若飛（FreeWheel）

我個人認爲 Service Mesh 想要真正發展成熟並大規模落地還有很長的一段路要走。一方面業界基於微服務構建的一系列服務治理框架和產品相當穩定和成熟，在功能上和 Service Mesh 有很多重合的地方，使得開發者對 Service Mesh 的需求並不迫切；另一方面，目前 Service Mesh 領域產品的成熟度還有待提高，冒險遷移過於激進，也容易面臨兼容性的問題，這也制約了 Service Mesh 的落地。

從近半年廠商的動作來看，主要方向是提供託管的控制平面，並整合成熟的數據面（如 Envoy）；同時提供多環境支持（如多雲、混合雲、VM 等）。這也和目前應用複雜多樣的的部署現狀有關，廠商的目的是先讓你上雲，再 Mesh 化。這也是一個相對穩妥且折中的方案。我司作爲一個重度使用 AWS 服務的公司，選擇了 AWS App Mesh 託管服務作爲 mesh 的解決方案，使得和現有服務能更容易的整合，減少維護和遷移成本。

邱世達 (BoCloud)

目前來看，Kubernetes 已經逐步在企業中落地，服務上雲已然是大勢所趨。而隨着雲計算基礎設施層的日益完備，在可以預見的未來，應用層服務治理必然成爲新的焦點，也是在大規模微服務場景下必須要解決的問題。在 Service Mesh 領域，Istio 無疑是明星項目，除了具備一定自研能力的科技公司會定製開發自己的服務治理工具，大多數中小型企業通常會選擇以 Istio 爲代表的開源服務治理方案進行初步試水。實踐過程中遇到問題並不可怕，我認爲這反而是一種正向推動力，作爲一種良性反饋，能更加積極地促使 Service Mesh 技術趨於成熟和穩定。擁抱服務網格，擁抱雲原生，讓我們期待 Service Mesh 在新的一年取得更大的發展！

孫海洲（中國科學院計算技術研究所）

對於 Service Mesh 來說，2019 年是極不平凡的一年，也是從觀望走向生產落地的一年。在這一年裏，以 Istio 爲代表的 Service Mesh 開始加快發佈週期，可以看到社區從以優雅架構到開始追求性能。最近社區裏大家積極地參與到 Istio 文檔的本地化工作中。在業界可以看到國內各個大廠開始有所舉動，螞蟻在雙十一的成功大規模落地爲 Service Mesh 走向生產打下了堅實的基礎，同時也爲大家提供了很多寶貴的經驗，騰訊、百度、華爲等雲服務提供商也都紛紛發佈相關的產品。關於 Service Mesh 的圖書在今年也出版了幾本，社區多次組織線下的 Service Mesh Meetup 場場爆滿，可見大家對 Service Mesh 的熱情與日俱增。2020年應該可以看到會有更多的 Service Mesh 的成功落地，但是當前還有很多企業還處於過渡時期，如何更好更便捷地解決向雲原生遷移依賴值得關注。Service Mesh 社區的推廣和佈道工作依然任重而道遠，需要我們更加積極努力地投入到 Service Mesh 事業中去。

趙化冰（中興通訊）

在 2019 年裏，我看到的一個有趣的現象是出現了各種各樣的開源 Service Mesh 項目，基於開源 Service Mesh 項目的初創公司，以及各大雲廠商的閉源 Service Mesh 實現。和 2018 年大部分項目圍繞 Istio 搭建生態有所不同（至少大部分項目聲稱自己兼容 Istio），2019年整個 Service Mesh 生態出現了百花齊放，百家爭鳴的趨勢。這也許和 Istio 項目的進度有一定關係。Istio 在項目最開始發佈時搭建了一個非常漂亮的架構，但實際開發的進展較慢。目前 Mixer V2 還沒有能夠正式發佈（處於 alpha 版本）， 其安全模型也在近期進行了較大的變動，導致除了流量管控之外的其他功能基本無法在生產中使用；除此之外，Istio 對於非 Kubernetes 環境的支持也非常有限。所有這些因素在一定程度上給其他 Service Mesh 項目留出了較大的發展空間。

在 Service Mesh 的不同實現紛紛湧現的情況下，要最大化利用 Service Mesh 提供了服務通信和管控能力，必須統一 Service Mesh 的標準接口。通過一個標準北向接口，對 Service Mesh 提供的流量控制，安全策略，拓撲信息、性能指標等基本能力進行組合，並加以創新，可以創建大量端到端的高附加值業務，例如支持業務平滑升級的灰度發佈，測試微服務系統健壯性的混沌測試，微服務的監控系統等等。而採用一個標準的南向接口，則可以構建一個良好的數據面代理生態，甚至可能將一些傳統的硬件代理設備納入 Service Mesh 控制面進行統一管理。

在 2020 年裏，我希望 Istio 項目在 telemetry 和 security 方面取得更多實際性的進展，並出現更多的商用案例。希望能夠制定一個 Service Mesh 的標準接口,或者出現一個足夠強大的事實標準，並看到建立在標準北向接口上的更多應用，這是 Service Mesh 的核心價值所在，也許會成爲 Service Mesh 的下一個熱點。

鍾華（騰訊雲）

還記得 2019 年初，我們對打磨半年之久的 Istio 新版本翹首以盼，大家對 Istio 的高度抽象模型褒貶不一，社區裏偶爾會看到朋友問「到底有沒有公司在生產環境落地了 Istio？」

在過去的一年裏，Istio 持續發力，核心功能迭代更加穩定，發佈了四個子版本，同時也更注重用戶體驗的優化。各大雲廠商在 2019 年陸續實現了對 Istio 的支持，業界也出現了越來越多的 Service Mesh 生產實踐，其中典型的是螞蟻雙十一大規模落地案例；筆者所在的騰訊雲 TKE Mesh 團隊，支持了數十個團隊的 Service Mesh 改造過程，其中不乏一些場景複雜、體量龐大的核心繫統。

Service Mesh 技術前景廣闊，但遠未成熟。展望 2020， 作爲 Service Mesh 頭號玩家的， Istio 還會持續快速發展，我個人很期待的一些演進： 支持 webassembly 擴展的數據面，真正生產可用的 Mixer V2，更易安裝和運維的單體控制面 istiod，更容易理解和操縱的用戶接口，以及提升 Istio 自身的可觀測性。

Service Mesh 技術本質上是各種最佳實踐的組合運用。Istio 試圖運用精巧的模型，去聯結各種平臺、觀測系統和用戶應用。未來的 Istio，一定會更加複雜，這些「複雜」的目的，是讓用戶能更「簡單」地使用 Service Mesh 領域的最佳實踐。

William Morgan

Buoyant CEO, author of Linkerd，the originator of the concept Service Mesh .

The service mesh today exists in a somewhat unfortunate state: while there is real and significant value, the marketing has outpaced the technology. Cloud vendors especially have seized upon the service mesh as a way to differentiate their container offerings, and the resulting frenetic marketing push does end users a substantial disservice.

今天的服務網格處於有點不幸的狀態：雖然有真實和重要的價值，但市場營銷已經超過了技術本身。雲供應商特別利用服務網格作爲區分他們的容器產品的一種方式，而由此產生的狂熱的市場推廣給終端用戶帶來了實質性的損害。

However, the service mesh provides some really transformative capabilities when applied correctly. From the perspective of Linkerd, the project which created the service mesh category itself, we continue to believe minimizing the cost of a service mesh, especially the long-term operational cost incurred by complexity, is paramount.

然而，如果應用正確，服務網格確實能提供一些真正變革性的功能。從 Linkerd 的角度來看，創建服務網格的項目，我們仍然認爲最小化服務網格的成本，特別是由複雜性引起的長期運營成本是最重要的。

In 2020, Linkerd will continue to focus on its goal of providing “observable security” while minimizing complexity and cost of adoption–Linkerd’s ultralight, ultrafast Rust proxies, minimalist control plane, and “do less, not more” philosophy have already paid dividends here. Most importantly, Linkerd’s commitment to open governance and home in a neutral foundation will ensure that Linkerd will continue to be a project not for customers of a particular cloud vendor, but for all engineers everywhere.

在2020年，Linkerd 將繼續專注於提供“可觀察的安全性”的目標，同時最小化複雜性和使用成本 — Linkerd 的超輕、超快 Rust 代理、極簡控制平面，以及“少做，而不是多做”的理念已經在這裏得到了鮮明的體現。最重要的是，Linkerd 對開放治理和中立基礎的承諾將確保 Linkerd 將繼續成爲一個爲所有工程師服務的項目，而不是爲某個特定雲供應商的客戶服務。

相關文章