Service Mesh：調度千軍萬馬微服務，2.0妥妥的

冠望 發(fā)自 凹非寺
量子位 報道 | 公眾號 QbitAI

過去一年，繼Kubernetes風靡，Service Mesh已成功上位變成當之無愧的技術網(wǎng)紅。

TA不但可以極大簡化用戶使用體驗，還將大中型企業(yè)的Kubernetes落地引向“實處”。

對于絕大多數(shù)使用容器的企業(yè)來說，似乎一夜之間，Service Mesh就成長為完善容器部署的功能擔當，不容小覷。

并被一度當作云原生技術棧的關鍵組件之一，人稱“新一代微服務架構”，即2.0版本。

從邏輯出發(fā)，如果想聊透Service Mesh，還是要先談談微服務的。

用維基百科的話說，所謂微服務，可被定義為一種軟件架構風格。

這個風格比較專注單一責任與功能的小型區(qū)塊，利用模塊化的方式組合出復雜的大型應用程序。

在此過程中，各功能區(qū)塊的使用與語言無關的API集達成相互通信。

簡單來說，在云原生微服務的模式下，哪怕是單個應用也可能由數(shù)百個服務組成。

此基礎上，每個服務又包含多達上千個實例。

如果你真想抽絲剝繭一下下，其實每個實例又很有可能被像 Kubernetes 這樣的服務調度器不斷調度，而產(chǎn)生千變萬化的形態(tài)。

盡管形態(tài)復雜多樣，但端到端通信的可靠性與性能優(yōu)勢卻始終至關重要。

這時候Service Mesh就派上了用場。

本質上就是將服務間的通信從無法發(fā)現(xiàn)與控制的基礎設施中分離出來，并達成監(jiān)控、管理與控制的目標。

顯而易見，關于Service Mesh的定義，廣泛被接受的一種，是控制應用程序不同部分彼此共享數(shù)據(jù)的方式。

作為一個專門讓服務與服務之間的通信變得安全、快速以及可靠的基礎設施，Service Mesh確實可以做到通過服務通訊，讓整個架構更為先進和Cloud Native。

在某些方面，這有點兒像網(wǎng)絡七層模型中的第四層 TCP 協(xié)議。

但與TCP不同的是， TA想要達成的目的不僅僅是正常的網(wǎng)絡通訊。

還著力為應用提供了統(tǒng)一的，可視化的以及可控制的控制平面。

如果追根溯源，Service Mesh 并不算是什么新技術；如果一定要說創(chuàng)新的話，更多則是功能所在位置的改變。

實踐證明，Service Mesh確實可高效做到屏蔽分布式系統(tǒng)通信的復雜性，只關注業(yè)務邏輯。

對于服務語言沒有限制，只需和Service Mesh通信即可。

更重要的是，對應用透明，組件可單獨升級。

止步于開源，那些鼎鼎大名的service mesh項目數(shù)一數(shù)

從2016年1月，業(yè)內第一個開源項目Linkerd發(fā)布，“Service Mesh”首次在公開場合被使用；到控制平面概念及作用被人們認可并接受以至于到今天。

我們發(fā)現(xiàn)熱鬧歸熱鬧，雖然如火如荼，但還尚未出現(xiàn)完全現(xiàn)成的商業(yè)產(chǎn)品。

大部分的Service Mesh僅僅止步于開源項目，例如現(xiàn)在比較知名的Linkerd、Istio 等。

1、2、3，那就從Linkerd說起吧！

Linkerd最初是由Buoyant團隊在2016年打造的一個服務網(wǎng)格項目。

從Twitter開發(fā)的library中分離出來并由Scala語言編寫，設計理念是支持基于主機（物理主機或者虛擬節(jié)點）的部署模式，算是開源項目中資歷比較深厚的。

有關資料顯示，Conduit，也是該領域另一位頗具影響力的選手，多年前已成功合并到Linkerd項目，并在2018年7月發(fā)布為Linkerd 2.0 版本。

關于Conduit的研發(fā)初衷，很多人總結為是由于最初版本的內存占用問題廣受詬病，所以Conduit確實表現(xiàn)更加輕量級，為Kubernetes定制，用Rust和Go語言編寫，但與當下廣泛提及的Istio相比，依舊不在一個數(shù)量級別上。

但更多人認為，Buoyant 是意識到繼續(xù)同時支撐 Linkerd1.x 和 Conduit 兩條產(chǎn)品線已經(jīng)不合時宜，此外Linkerd1.x無論是在數(shù)據(jù)平面還是控制平面上表現(xiàn)都很堪憂。

所以，合并產(chǎn)品線并保持品牌效力更關鍵。

可喜的是，從1到2，我們發(fā)現(xiàn)Linkerd 2.x 主要基于Kubernetes，而Linkerd 1.x 則可以基于節(jié)點模式部署，當面臨復雜環(huán)境的場景時，開發(fā)者完全有更靈活的選擇方向，對部署更是恰到好處。

就在2018 年 12 月，Linkerd 2.1 也順勢被發(fā)布，推出了路由級的遙測能力。

更重要的是，此次發(fā)布率先提出了 Service Profile 概念，以服務為中心，將服務相關的大量 CRD 聚合統(tǒng)一，這對服務網(wǎng)格的管理助力不小。

伴隨發(fā)展，2017 年 1 月，開源的 Service Mesh 軟件 Linkerd 就正式加入了云原生基金會，成為云原生基金會的官方項目并至今影響深遠。

但從近些年掌握的發(fā)展情況來看，面對出身豪門的網(wǎng)紅 Istio 以及在數(shù)據(jù)平面上表現(xiàn)優(yōu)越的Envoy，Linkerd更多是力不從心，想要改變其現(xiàn)狀，恐怕還需在戰(zhàn)略敏感度以及技術升級上做做功課。

如果說Linkerd是服務網(wǎng)格的開山鼻祖，那Istio可謂是目前這個領域實實在在的“流量大花”。

由Lyft、IBM與google聯(lián)合開發(fā)的Istio，相比 Linkerd、Envoy這些典型的服務網(wǎng)格，提供了一個更加完整的解決方案，包括行為洞察以及操作控制在內，主要用來滿足微服務應用程序的多樣化需求。

所以，Istio是一個服務網(wǎng)格沒錯，但又不僅僅是服務網(wǎng)格那么簡單。

具體來說，TA可以做到在不修改微服務源代碼的前提下，輕松為其添加負載均衡、身份驗證等強功能，并通過控制Envoy等代理服務來控制所有流量，其中Istio基于Envoy代理并以之為數(shù)據(jù)層（data plane）。

另外，Istio還提供了容錯、金絲雀部署、A/B測試、監(jiān)控等功能，甚至可以支持自定義的組件和集成，對此官方有云：

流量管理：控制服務之間的流量和API調用的流向，使得調用更可靠，并使網(wǎng)絡在惡劣情況下更加健壯。

可觀察性：了解服務之間的依賴關系以及它們之間流量的本質和流向，從而提供快速識別問題的能力。

策略執(zhí)行：將組織策略應用于服務之間的互動，確保訪問策略得以執(zhí)行，資源在消費者之間良好分配。策略的更改是通過配置網(wǎng)格而不是修改應用程序代碼。

服務身份和安全：為網(wǎng)格中的服務提供可驗證身份，并提供保護服務流量的能力，使其可以在不同可信度的網(wǎng)絡上流轉。

總之一句話，Istio極大的減少了應用程序代碼，底層平臺和策略之間的耦合，使微服務更容易實現(xiàn)就對了！

作為各種技術前沿會議中備受矚目的創(chuàng)新技術，世界范圍各主流云平臺都對Istio伸出了橄欖枝，比方說IBM Cloud Kubernetes Service以及Red Hat 創(chuàng)建了一個名為 Maistra 的社區(qū)項目等。

但不難發(fā)現(xiàn)的一點，雖說Istio是如今最炙手可熱的服務網(wǎng)格，但實際落地的生產(chǎn)場景并不多，更多是選擇在測試環(huán)境中試用，其應用價值確實受到某種限制。

對此專業(yè)人士持這樣的觀點：原本使用像Istio這樣的服務網(wǎng)格是為了希望能夠降低微服務管理或者治理復雜度，更好觀測運行狀況，更容易完成熔斷限流，進行灰度發(fā)布等。

但在實際操作中，我們會發(fā)現(xiàn)非但沒有降低微服務的復雜度，反而是引入了一個同樣復雜的技術。

是否應該將一些主線變成單體應用去做統(tǒng)一部署，從而降低service mesh管理控制平面本身的使用和維護的復雜度呢？

事實上，最近數(shù)月Istio接連發(fā)布了1.5和1.6版本。

相比2018年-2019年度的頻繁更新，大多只涉及到錯誤修復和性能改善，未帶來新的特性的情況，目前的1.5版本算是重大變革之一。

該版本似乎回應了社區(qū)里關于Istio性能和易用性的詬病，重建了新架構即回歸單體。

具體來說，由原來更分散的微服務架構、控制平面做了一些收縮與整合，變?yōu)橐粋€更加集中的方式。

將過去一些過于復雜的分散式組件，集中到了Istio核心的控制平面中，從而降低了使用管理的難度系數(shù)。

另外，以前的mxier組件，在1.5版本中被移除，該能力通過其他方式來實現(xiàn)，組件刪減之后也對性能方面帶來顯著提升。

總體來說，就是提升性能并降低復雜度，從而讓用戶能夠更容易去采納這樣的新技術。

回顧Istio的一路走來，如何打破叫好不叫座的局面，真正實現(xiàn)生產(chǎn)環(huán)境落地的意義，可能是未來很長時間都需要證明自己的事兒。

相比Istio的任重道遠，作為Istio中的Sidecar官方標配，Envoy也有很吸睛的表現(xiàn)。

Envoy，由Lyft創(chuàng)建，為了直擊完整的ServiceMesh功能，它牢牢占據(jù)了“數(shù)據(jù)平面”的部分，與其進行匹配。

作為一個面向服務架構的高性能網(wǎng)絡代理，Envoy由C++語言實現(xiàn)，擁有較為強大的定制化能力。

主要通過其提供的Filter機制，基本可以對請求轉發(fā)過程中超過50%的流程做定制化，在性能方面由于其實現(xiàn)參考了Nginx，也處于主流水平。

其作為Sidecar其提供的核心功能可以被簡單總結：對業(yè)務透明的請求攔截；對攔截請求基于一定規(guī)則做校驗、認證、統(tǒng)計、流量調度、路由等。

其中對于請求校驗規(guī)則的多與少、遙測數(shù)據(jù)的采集精細度、數(shù)據(jù)統(tǒng)計的維度多樣性等算是復雜性需求的展現(xiàn)。

因此最有可能提升Sidecar性能的技術方向，就是對請求的攔截與Sidecar之間通訊協(xié)議的高效性。

目前Envoy被越來越多企業(yè)使用，不但穩(wěn)穩(wěn)占據(jù)了 Istio 官配 Sidecar 的位置，還在網(wǎng)絡代理、負載均衡器上展露鋒芒。

甚至廣泛被 Istio 之外的多家企業(yè) Service Mesh 框架項目采用，明顯有成為 Service Mesh 的數(shù)據(jù)平面“風向標”的傾向。

2017 年 9 月，Envoy 加入 CNCF，成為 CNCF 的第二個 Service Mesh 項目；2018 年 11 月 ，CNCF 宣布 Envoy 畢業(yè)，成為繼 Kubernetes 和 Prometheus 后，第三個孵化成熟的 CNCF 項目，前景樂觀。

當然，除了這些傳統(tǒng)的開源項目外，Service Mesh 競爭版圖中也陸陸續(xù)續(xù)迎來了各種企業(yè)級的參與者，例如Nginmesh。

來自名聲在外的nginx，作為2017 年 9 月對外宣布的一款產(chǎn)品，適用于 Istio 的方案，本質上就是使用 NGINX 作為 sidecar 來替換 Envoy。

另外，Consul 來自 HashiCorp 公司，主要功能是服務注冊和服務發(fā)現(xiàn)，以及作為一個從 API 網(wǎng)關演變而來的 service mesh 產(chǎn)品，名叫Kong等。

關于Service Mesh 技術，這些大企業(yè)代表都有何頻頻動作？

如上文所言，Service Mesh確已席卷全球，過去一年時間中，已有多家公司競相推出自己的 Service Mesh 產(chǎn)品和方案，例如AWS，就是引人注目的一家。

去年4月，AWS 震撼宣布了 App Mesh GA。

App Mesh 作為 AWS 推出的 AWS 原生服務網(wǎng)格，與 AWS 完全集成，主要組件包括：網(wǎng)絡（AWS cloud map）；計算（Amazon EC2 和 AWS Fargate）以及編排工具（AWS EKS，Amazon ECS 和 EC2 上客戶管理的 k8s）。

值得提及的一點，App Mesh的數(shù)據(jù)平面采用 Envoy，產(chǎn)品同時支持VM和容器并支持多種產(chǎn)品形態(tài)。

適用于Amazon ECS、Amazon EKS和Kubernetes on EC2，另外還支持開源Envoy代理，本質上幫助開發(fā)人員監(jiān)控以及控制跨微服務的通信。

具體來說，使用App Mesh來建模的所有微服務的連接方式，都會自動計算并向每個微服務代理發(fā)送相應的配置信息。

這樣就達成了跨整個應用的程序標準化，以及易用性與流量控制等要求。

相比AWS青睞 Envoy，Google的打法則是圍繞 Istio 。

最初，Google在2018年底推出了 Istio on GKE，并提供遙測、日志、負載均衡、路由等能力。

接著又推出了 Google Cloud Service Mesh。

作為Istio的完全托管版本，不僅僅提供開源版本的完整特性，還集成了 Google Cloud上的重要產(chǎn)品 Stackdriver 。

旨在解決企業(yè)中增長最快的成本問題之一，即跨混合環(huán)境的管理復雜性。

隨后，Google拿出了 Traffic Director 的 beta 測試版本，被定義為完全托管的服務網(wǎng)格流量控制平面。

不但支持全局負載均衡，適用于虛擬機和容器，還提供混合云和多云支持、集中式健康檢查和流量控制；此外還有一個非常特別的特性，支持基于流量的自動伸縮。

對比Google的高調支持，微軟更聚群力，推出了Service Fabric Mesh。

據(jù)了解，Azure Service Fabric 是Microsoft的微服務框架，最初設計用于公共云，內部部署以及混合與多云架構。

而 Service Fabric Mesh 是 Azure 完全托管的產(chǎn)品，于2018年8月推出預覽版。

此外微軟還在 KubeConf 上推出 Service Mesh Interface，作為在 Kubernetes 上運行服務網(wǎng)格的規(guī)范。

SMI 定義了由各種供應商實現(xiàn)的通用標準，使最終用戶的標準化與創(chuàng)新可以做到兼顧，預期為Service Mesh 帶來了靈活性和互通性。

據(jù)悉SMI 作為一個開放項目，由微軟、Linkerd、HashiCorp、Solo、Kinvolk 和 Weaveworks 聯(lián)合啟動。

并同時得到了 Aspen Mesh、Canonical、Docker、Pivotal、Rancher、Red Hat 和 VMware 等多家的大力支持。

相比之前幾家的聲勢浩大與首屈一指的知名度，服務網(wǎng)格領域另一家值得提及的供應商是Tetrate。

作為一家總部位于舊金山的創(chuàng)業(yè)公司，TA與Google淵源頗深，是由Google Istio項目的一些主要工程師組成。

據(jù)了解，很長一段時間內他們正在著力開發(fā)一個獨立的企業(yè)級 服務網(wǎng)格，主要為了減輕在混合或者大規(guī)模復雜環(huán)境中運行微服務帶來的管理復雜性。

Tetrate曾承諾將Istio和Envoy的開源產(chǎn)品與企業(yè)級功能相結合，允許在復雜的企業(yè)環(huán)境中運行數(shù)據(jù)和控制平面，這意味著“企業(yè)級可擴展性、可伸縮性和性能”。

“我們正試圖簡化Istio配置的復雜性?！盩etrate方面表示。

當然，如果放眼國內企業(yè)，包括阿里Dubbo Mesh、騰訊的Tencent Service Mesh，華為 Mesher 與 ASM、Rancher 2.3 Preview2版本上開始支持Istio以及網(wǎng)易云輕舟微服務基于開源Istio推出服務網(wǎng)格（Service Mesh）平臺等在內的多家企業(yè)也分別針對Service Mesh有了個性化的技術嘗試。

阿里Dubbo Mesh

Dubbo作為阿里巴巴內部SOA服務化治理方案的核心框架，在2012年時已經(jīng)每天為2000+個服務提供3,000,000,000+次訪問量支持，并被廣泛應用于各成員站點。

甚至自2011年開源后，已被許多非阿里系公司使用，最后帶來服務治理和SOA的設計理念開始逐漸在國內軟件行業(yè)中落地并被廣泛應用的大風潮，可謂影響深遠。

簡單理解Dubbo Mesh，就是service mesh作為云原生組織定義的微服務架構解決理念，Dubbo則是實現(xiàn)框架的意思。

有資料顯示，目前 Dubbo Mesh 主要包含 Bonder、Pilot、Envoy 三個進程，以及被輕量化的 Thin SDK。

具體來說Envoy 承擔了數(shù)據(jù)平面的角色，所有流量將由它完成服務發(fā)現(xiàn)與路由而中轉。

Pilot 和 Bonder則共同承擔控制平面的角色，實現(xiàn)服務注冊、進程拉起與?；?、集群信息和配置推送等功能。

Thin SDK 是 Fat SDK 經(jīng)過裁剪后只保留了對 Dubbo 協(xié)議進行編解碼的能力。

迄今為止，Dubbo應該是國內比較受到歡迎的遠程服務框架，也是阿里分布式架構相互連通的核心所在。

騰訊Tencent Service Mesh

TSF Mesh 作為騰訊微服務平臺 （TSF） 的 Service Mesh 解決方案，從 2018 年 8 月推出首個版本以來，已經(jīng)陸續(xù)在金融、新零售、工業(yè)互聯(lián)網(wǎng)以及公司內部等生產(chǎn)環(huán)境落地。

TSF Mesh 整體架構上，其核心能力與開源的 Istio 保持一致，同時對 envoy、Pilot、Mixer、Pilot-agent 組件做了增強，并且新增組件 Apiserver 和 Mesh-dns。其外圍能力聚焦在安全性、易用性、可維護性和可觀測性。

TSF Mesh 擁抱開源協(xié)同，努力跟進 Service Mesh 的技術發(fā)展趨勢，但就技術發(fā)展趨勢而言，比如控制面單體化，UDPA（通用數(shù)據(jù)平面API）的標準化演進，wasm 在 envoy 中扮演的角色以及mixer 下沉，協(xié)議擴展，性能優(yōu)化等都是未來亟待探討的技術關鍵。

Rancher2.3

Rancher的理念是Run Kubernetes Everywhere，其中關于Istio的支持創(chuàng)新也正是讓該理念實現(xiàn)又大步向前了一個階段。

據(jù)悉，Rancher 2.3 Preview2版本上開始支持Istio，用戶可以直接在UI界面中啟動Istio并且可以為每個命名空間注入自動sidecar。具體來說，

Rancher內置了一個支持Kiali的儀表盤，簡化Istio的安裝和配置，這一切讓部署和管理Istio變得簡單而快速。

“Rancher 嚴格來說是一個單體應用，我們的server架構，它是一個集中式的，其中有很多不同的服務，比方說Rancher 的UI、Rancher server的核心控制進程、catalog、Container Engine對接基礎設施等。將其全部打包到一個鏡像中去再進行統(tǒng)一運行的話，管理升級就會變得額外簡單?！盧ancher方面表示。

網(wǎng)易云輕舟微服務推出的服務網(wǎng)格平臺

輕舟微服務基于開源Istio推出服務網(wǎng)格（Service Mesh）平臺 ，可以提供完整的微服務生命周期管理、流量管理和非侵入式的服務治理解決方案。

支持熔斷、降級、流控、負載均衡、容錯、高級路由等服務治理功能，同時擺脫服務開發(fā)框架和開發(fā)語言的束縛。

具體來說，平臺可以通過統(tǒng)一的微服務模型，幫助將現(xiàn)有的微服務架構平滑遷移到服務網(wǎng)格，并針對數(shù)據(jù)面引入Sidecar導致延時增加的問題，持續(xù)優(yōu)化數(shù)據(jù)面，相比開源方案服務延時降低100%以上。

支持無侵入的監(jiān)控數(shù)據(jù)采集，實時獲取健康狀態(tài)；支持容器化和非容器化的部署，打破服務網(wǎng)格開源版本“偏科”容器的限制。

華為 Mesher 與 ASM

ServiceComb 是一個 java 與 go 語言的微服務編程框架，而華為Mesher則是基于華為開源的 ServiceComb。

從發(fā)展目標來看，Mesher 并不只支持 Kubernetes， 而是支持任意的基礎設施，包括容器，虛擬機等，這一點類似于網(wǎng)易云的服務網(wǎng)格嘗試。

此外，華為云 Istio 團隊在生態(tài)上投入了很大力量，并基于 Istio 發(fā)布了自己的 ASM（Application Service Mesh）， 深度集成華為云容器服務 CCE(Cloud Container Engine)，提供非侵入的智能流量治理解決方案。

螞蟻金服SOFAMesh+SOFAMosn

螞蟻金服的 Service Mesh 解決方案主要包括SOFAMesh 以及SOFAMosn。

其中SOFAMesh 是螞蟻金服推出的 Service Mesh 開源產(chǎn)品，可以簡單理解為是 Istio 的落地增強版本。

作為螞蟻金服 Service Mesh 的控制平面，跟隨社區(qū)保持同步更新，還提供了多租戶的支持。

SOFAMosn，被稱為螞蟻金服新型基礎設施和中間件的底層網(wǎng)絡通用解決方案，具備多種產(chǎn)品形態(tài)，基于 Golang 開發(fā)。

在螞蟻金服 Service Mesh 中承擔數(shù)據(jù)平面的角色，和 SOFAMesh 項目配合使用，兼容 Istio 體系。

Service Mesh 技術在螞蟻金服的落地，其實先后經(jīng)歷過幾個階段：

預研階段：2017 年底開始調研并探索，確定方向。

探索階段：2018 年初，開始用 Golang 開發(fā) Sidecar SOFAMosn，年中開源基于 Istio 的 SOFAMesh。

小規(guī)模落地階段：2018 年開始內部落地，替代 Java 語言之外的其他語言的客戶端 SDK，之后開始內部小范圍試點。

規(guī)模落地階段：2019 年上半年，作為螞蟻金融級云原生架構升級的主要內容之一，逐漸拓展到螞蟻金服內部的業(yè)務應用并平穩(wěn)支撐大促。

全面大規(guī)模落地階段：2019 年下半年，全面鋪開并落地規(guī)模龐大。

分析各家的DIY情況，我們發(fā)現(xiàn)在數(shù)據(jù)平面上，大多數(shù)選擇了Envoy；在控制平面上除了自行開發(fā)之外，很大程度上依舊依賴Istio 進行擴展和訂制。

總體上，國內 Service Mesh 的發(fā)展情況呈現(xiàn)出“多方參與，多種落地與探索，都有符合自身特點的 Service Mesh 產(chǎn)品出爐，技術社區(qū)反響熱烈”等態(tài)勢。

但從技術層面上，Service Mesh目前也面臨不少的問題與挑戰(zhàn)。

Service Mesh用起來會面臨哪些問題？

首先服務網(wǎng)格是一個平臺解決方案，十分排他。

這意味著需要在服從方式與業(yè)務考量上進行艱難取舍，前期成本消耗會十分昂貴。

除了在理念上的矛盾之外，服務網(wǎng)格的部署將架構引入不小的復雜性，過程中需要與現(xiàn)有的環(huán)境進行整合并反復配置。

例如Service Mesh組件以代理模式計算并轉發(fā)請求，一定程度上會降低通信系統(tǒng)性能并增加資源開銷。

隨著網(wǎng)格的擴張和路由表的膨脹，通過一系列代理進行的路由通信將慢的痛苦異常。

此外，由于組件接管了網(wǎng)絡流量，因此服務的整體穩(wěn)定性都會大概率依賴于Service Mesh，額外引入的Service Mesh服務實例，其運維和管理也是挑戰(zhàn)之一。

盡管應用艱難且挑戰(zhàn)重重，但人們對將服務網(wǎng)格作為基礎設施的關鍵部分，所激發(fā)出的興趣和亟待采用計劃，正在迅速趕上甚至超越容器。

無論企業(yè)體量大小，未來服務網(wǎng)格的使用迫切度都會顯著增長。

在此基礎上，Istio之于服務網(wǎng)格會類似于K8S之于容器的地位，一騎絕塵，畢竟縱觀生態(tài)系統(tǒng)的成熟度，Istio還是非常有競爭力的。

此外，2020年或將出現(xiàn)核心服務網(wǎng)格用例，并將成為下一批使用者實施的參照。

可想而知，如果正在使用服務網(wǎng)格，其價值會越發(fā)顯現(xiàn)；如果已經(jīng)考慮入局其中，未來的機會頗多也是意料之中的事兒。

附：文章參考多家平臺內容并撰寫，包括知乎以及CSDN社區(qū)等，主要資源列表如下：

下一代微服務！ServiceMesh的2018年度總結 | 萬字雄文

https://mp.weixin.qq.com/s/5j-1B5U8q2kE7f_DvPrBaw

KubeCon上海 | 云原生服務網(wǎng)格（Istio）企業(yè)峰會

https://mp.weixin.qq.com/s/_Ss3HrokTalRgs6R8sR-hA

企業(yè)服務網(wǎng)格競爭白熱化

https://mp.weixin.qq.com/s/WRlbxt–b81pa1QA5cjipg

Dubbo Mesh 在閑魚生產(chǎn)環(huán)境中的落地實踐

https://www.cnblogs.com/yunqishequ/p/10530705.html

騰訊云中間件團隊在Service Mesh中的實踐與探索

https://mp.weixin.qq.com/s/20UJMs4U5YEUfxV6dS3oJg

談談華為微服務解決方案與實踐

https://bbs.huaweicloud.com/blogs/110537

螞蟻金服 Service Mesh 深度實踐

https://blog.csdn.net/weixin_44326589/article/details/102928587?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522159237475219724846408250%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=159237475219724846408250&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_ecpm_v1~rank_ctr_v3-4-102928587.ecpm_v1_rank_ctr_v3&utm_term=%E8%9A%82%E8%9A%81%E9%87%91%E6%9C%8D+SOFAMosn

Dubbo在Service Mesh下的思考和方案

https://zhuanlan.zhihu.com/p/98562980

網(wǎng)易輕舟服務網(wǎng)格產(chǎn)品升級，全面擁抱下一代微服務技術

http://www.soxunwang.com/kjrd/2020/0421/66443.html

淺談服務治理、微服務與Service Mesh（一）：Dubbo的前世今生

https://blog.csdn.net/M2l0ZgSsVc7r69eFdTj/article/details/79160126?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522159232931919195265939573%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=159232931919195265939573&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_ecpm_v1~rank_ctr_v3-3-79160126.ecpm_v1_rank_ctr_v3&utm_term=Dubbo+Mesh

dubboMesh優(yōu)化總結

https://blog.csdn.net/weishiym/article/details/84922381?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522159232931919195265939573%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=159232931919195265939573&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_ecpm_v1~rank_ctr_v3-2-84922381.ecpm_v1_rank_ctr_v3&utm_term=Dubbo+Mesh

Service Mesh服務網(wǎng)格：是什么和為什么

https://blog.csdn.net/zyqduron/article/details/80433995