Service Mesh：調(diào)度千軍萬馬微服務(wù)，2.0妥妥的

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

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

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

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

并被一度當(dāng)作云原生技術(shù)棧的關(guān)鍵組件之一，人稱“新一代微服務(wù)架構(gòu)”，即2.0版本。

從邏輯出發(fā)，如果想聊透Service Mesh，還是要先談?wù)勎⒎?wù)的。

用維基百科的話說，所謂微服務(wù)，可被定義為一種軟件架構(gòu)風(fēng)格。

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

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

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

此基礎(chǔ)上，每個(gè)服務(wù)又包含多達(dá)上千個(gè)實(shí)例。

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

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

這時(shí)候Service Mesh就派上了用場(chǎng)。

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

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

作為一個(gè)專門讓服務(wù)與服務(wù)之間的通信變得安全、快速以及可靠的基礎(chǔ)設(shè)施，Service Mesh確實(shí)可以做到通過服務(wù)通訊，讓整個(gè)架構(gòu)更為先進(jìn)和Cloud Native。

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

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

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

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

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

對(duì)于服務(wù)語言沒有限制，只需和Service Mesh通信即可。

更重要的是，對(duì)應(yīng)用透明，組件可單獨(dú)升級(jí)。

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

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

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

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

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

Linkerd最初是由Buoyant團(tuán)隊(duì)在2016年打造的一個(gè)服務(wù)網(wǎng)格項(xiàng)目。

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

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

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

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

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

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

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

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

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

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

如果說Linkerd是服務(wù)網(wǎng)格的開山鼻祖，那Istio可謂是目前這個(gè)領(lǐng)域?qū)崒?shí)在在的“流量大花”。

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

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

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

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

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

可觀察性：了解服務(wù)之間的依賴關(guān)系以及它們之間流量的本質(zhì)和流向，從而提供快速識(shí)別問題的能力。

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

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

總之一句話，Istio極大的減少了應(yīng)用程序代碼，底層平臺(tái)和策略之間的耦合，使微服務(wù)更容易實(shí)現(xiàn)就對(duì)了！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

關(guān)于Service Mesh 技術(shù)，這些大企業(yè)代表都有何頻頻動(dòng)作？

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

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

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

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

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

具體來說，使用App Mesh來建模的所有微服務(wù)的連接方式，都會(huì)自動(dòng)計(jì)算并向每個(gè)微服務(wù)代理發(fā)送相應(yīng)的配置信息。

這樣就達(dá)成了跨整個(gè)應(yīng)用的程序標(biāo)準(zhǔn)化，以及易用性與流量控制等要求。

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

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

接著又推出了 Google Cloud Service Mesh。

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

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

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

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

對(duì)比Google的高調(diào)支持，微軟更聚群力，推出了Service Fabric Mesh。

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

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

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

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

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

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

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

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

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

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

“我們正試圖簡化Istio配置的復(fù)雜性。”Tetrate方面表示。

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

阿里Dubbo Mesh

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

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

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

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

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

Pilot 和 Bonder則共同承擔(dān)控制平面的角色，實(shí)現(xiàn)服務(wù)注冊(cè)、進(jìn)程拉起與保活、集群信息和配置推送等功能。

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

迄今為止，Dubbo應(yīng)該是國內(nèi)比較受到歡迎的遠(yuǎn)程服務(wù)框架，也是阿里分布式架構(gòu)相互連通的核心所在。

騰訊Tencent Service Mesh

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

TSF Mesh 整體架構(gòu)上，其核心能力與開源的 Istio 保持一致，同時(shí)對(duì) envoy、Pilot、Mixer、Pilot-agent 組件做了增強(qiáng)，并且新增組件 Apiserver 和 Mesh-dns。其外圍能力聚焦在安全性、易用性、可維護(hù)性和可觀測(cè)性。

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

Rancher2.3

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

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

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

“Rancher 嚴(yán)格來說是一個(gè)單體應(yīng)用，我們的server架構(gòu)，它是一個(gè)集中式的，其中有很多不同的服務(wù)，比方說Rancher 的UI、Rancher server的核心控制進(jìn)程、catalog、Container Engine對(duì)接基礎(chǔ)設(shè)施等。將其全部打包到一個(gè)鏡像中去再進(jìn)行統(tǒng)一運(yùn)行的話，管理升級(jí)就會(huì)變得額外簡單。”Rancher方面表示。

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

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

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

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

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

華為 Mesher 與 ASM

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

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

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

螞蟻金服SOFAMesh+SOFAMosn

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

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

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

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

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

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

預(yù)研階段：2017 年底開始調(diào)研并探索，確定方向。

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

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

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

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

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

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

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

Service Mesh用起來會(huì)面臨哪些問題？

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

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

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

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

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

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

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

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

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

此外，2020年或?qū)⒊霈F(xiàn)核心服務(wù)網(wǎng)格用例，并將成為下一批使用者實(shí)施的參照。

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

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

下一代微服務(wù)！ServiceMesh的2018年度總結(jié) | 萬字雄文

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

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

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

企業(yè)服務(wù)網(wǎng)格競(jìng)爭(zhēng)白熱化

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

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

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

騰訊云中間件團(tuán)隊(duì)在Service Mesh中的實(shí)踐與探索

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

談?wù)勅A為微服務(wù)解決方案與實(shí)踐

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

螞蟻金服 Service Mesh 深度實(shí)踐

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ù)網(wǎng)格產(chǎn)品升級(jí)，全面擁抱下一代微服務(wù)技術(shù)

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

淺談服務(wù)治理、微服務(wù)與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)化總結(jié)

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ù)網(wǎng)格：是什么和為什么

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