螞蟻金服在服務(wù)化上面已經(jīng)經(jīng)過多年的沉淀，支撐了每年雙十一的高峰峰值。Service Mesh 作為微服務(wù)的一個(gè)新方向，在最近兩年成為領(lǐng)域的一個(gè)大熱點(diǎn)，但是如何從經(jīng)典服務(wù)化架構(gòu)往 Service Mesh 的方向上演進(jìn)，中間可能會(huì)遇到什么樣的問題，幾乎沒有可以借鑒的經(jīng)驗(yàn)。

本文會(huì)給大家分享 Service Mesh 在螞蟻金服的演進(jìn)歷程和在2018年6月舉辦的?GIAC 全球互聯(lián)網(wǎng)架構(gòu)大會(huì)中螞蟻金服高級(jí)技術(shù)專家與現(xiàn)場(chǎng)人員關(guān)于Service Mesh的熱門QA互動(dòng)。

螞蟻金服高級(jí)技術(shù)專家，螞蟻金服分布式架構(gòu)SOFA?的開源負(fù)責(zé)人黃挺

前言

---

在過去的一段時(shí)間中螞蟻金服已經(jīng)開始采用 Service Mesh 來幫助解決一些架構(gòu)上的問題，并且在 Service Mesh 如何更好地與經(jīng)典的服務(wù)化架構(gòu)結(jié)合上有一定的經(jīng)驗(yàn)，希望借此分享和大家交流我們這部分的實(shí)踐。使大家對(duì)螞蟻金服當(dāng)前的服務(wù)化架構(gòu)有更多了解，并對(duì) Service Mesh 如何解決經(jīng)典服務(wù)化架構(gòu)中的問題以及螞蟻金服實(shí)際在落地Service Mesh 中的時(shí)候的一些設(shè)計(jì)考慮和未來展望有更進(jìn)一步的了解，也希望能與行業(yè)分享螞蟻金服服務(wù)化架構(gòu)現(xiàn)狀。

螞蟻金服從單體應(yīng)用轉(zhuǎn)移到服務(wù)化的架構(gòu)下已經(jīng)經(jīng)過了差不多 10 年的時(shí)間，在整個(gè)過程中，為了滿足螞蟻金服金融級(jí)的要求，我們也構(gòu)建了一整套地面向金融級(jí)的分布式架構(gòu)的解決方案，也就是 SOFA。

SOFA 其實(shí)包含了金融級(jí)分布式中間件，CICD 以及 PAAS 平臺(tái)。SOFA中間件部分包含的內(nèi)容包括 SOFABoot 研發(fā)框架、SOFA微服務(wù)相關(guān)的框架（RPC，服務(wù)注冊(cè)中心，批處理框架，動(dòng)態(tài)配置等等）、消息中間件、分布式事務(wù)和分布式數(shù)據(jù)訪問等等中間件。

以上的這些中間件都是基于 Java 技術(shù)棧的，目前 SOFA 在螞蟻金服內(nèi)部大概超過 90% 的系統(tǒng)在使用，除了這些系統(tǒng)之外，還有剩下的 10% 的系統(tǒng)，采用 NodeJS，C++，Python 等等技術(shù)棧研發(fā)的。這剩下的 10% 的系統(tǒng)想要融入到 SOFA 的整個(gè)體系中，一種辦法是用對(duì)應(yīng)的語言再去寫一遍 SOFA 中間件的各個(gè)部分對(duì)應(yīng)的客戶端。

事實(shí)上，之前我們正是這么干的，螞蟻金服內(nèi)部之前就有一套用 NodeJS 搞的 SOFA 各個(gè)組件的客戶端，但是最近幾年隨著 AI 等領(lǐng)域的興起，C++ 也在螞蟻金服內(nèi)部被應(yīng)用到越來越多的地方，那么我們是否也要用 C++ 再來寫一遍 SOFA 中間件的各個(gè)客戶端？如果我們繼續(xù)采用這種方式去支持 C++ 的系統(tǒng)，首先會(huì)遇到成本上的問題，每個(gè)語言一套中間件的客戶端，這些中間件的客戶端就像一個(gè)個(gè)煙囪，都需要獨(dú)立地去維護(hù)，去升級(jí)。另一方面，從穩(wěn)定性上來講，之前 Java 的客戶端踩過的一些坑，可能其他的語言又得重新再踩一遍坑。

對(duì)于多語言的問題來說，Service Mesh 其實(shí)就很好地解決了這部分的問題，通過 Service Mesh的方案，我們可以盡量把最多的功能從中間件的客戶端中移到 Sidecar 中，這樣就可以做到一次實(shí)現(xiàn)，就搞定掉所有語言，這個(gè)對(duì)于基礎(chǔ)設(shè)施團(tuán)隊(duì)來說，在成本和穩(wěn)定性上都是一個(gè)提升。

另外的一個(gè)問題其實(shí)是所有在往云原生架構(gòu)中轉(zhuǎn)型的公司都會(huì)遇到的問題，云原生看起來非常美好，但是我們?cè)趺礉u進(jìn)式的演進(jìn)到云原生的架構(gòu)下？特別是對(duì)于遺留系統(tǒng)，到底怎么做比較好。當(dāng)然，一種簡(jiǎn)單粗暴的方式就是直接用云原生的設(shè)施和架構(gòu)重新寫一套，但是這樣，投入的成本就非常高，而且重寫就意味著可能會(huì)引入 Bug，導(dǎo)致線上的穩(wěn)定性的問題。那么有沒有一種方式可以讓這些遺留系統(tǒng)非常便捷地享受到云原生帶來的好處呢？Service Mesh 其實(shí)為我們指明了一個(gè)方向，通過 Service Mesh，我們?yōu)檫z留系統(tǒng)安上一個(gè) Sidecar，少量地修改遺留系統(tǒng)的配置甚至不用修改遺留系統(tǒng)的配置就可以讓遺留系統(tǒng)享受到服務(wù)發(fā)現(xiàn)，限流熔斷，故障注入等等能力。

最后我們?cè)谖浵伣鸱姆?wù)化的過程中遇到的問題是中間件升級(jí)的問題，螞蟻金融從單體應(yīng)用演進(jìn)到服務(wù)化的架構(gòu)，再演進(jìn)到單元化的架構(gòu)，再演進(jìn)到彈性架構(gòu)，其實(shí)伴隨了大量中間件升級(jí)，每次升級(jí)，中間件不用說要出新的版本去提供新的能力，業(yè)務(wù)系統(tǒng)也需要升級(jí)依賴的中間件，這中間再出個(gè) Bug，又得重新升級(jí)一遍，不光是中間件研發(fā)同學(xué)痛苦，應(yīng)用的研發(fā)同學(xué)也非常痛苦。

我們從單體應(yīng)用演進(jìn)到了服務(wù)化的架構(gòu)，從原來好幾個(gè)團(tuán)隊(duì)維護(hù)同一個(gè)應(yīng)用，到各個(gè)團(tuán)隊(duì)去維護(hù)各自領(lǐng)域的應(yīng)用，團(tuán)隊(duì)之間通過接口去溝通，已經(jīng)將各個(gè)業(yè)務(wù)團(tuán)隊(duì)之間做到了最大程度的解耦，但是對(duì)于基礎(chǔ)設(shè)施團(tuán)隊(duì)來說，還是和每一個(gè)業(yè)務(wù)團(tuán)隊(duì)耦合在一起。

我們中間嘗試過用各種方法去解決升級(jí)過程中的耦合的問題，一種是通過我們自己研發(fā)的應(yīng)用服務(wù)器 CloudEngine 來管理所有的基礎(chǔ)類庫(kù)，盡量地去減少給用戶帶來的升級(jí)成本，不用讓用戶一個(gè)個(gè)升級(jí)依賴，一次升級(jí)就可以。

但是隨著螞蟻的業(yè)務(wù)的不斷發(fā)展，規(guī)模地不斷擴(kuò)大，團(tuán)隊(duì)的數(shù)量，業(yè)務(wù)的規(guī)模和我們交付的效率已經(jīng)成為了主要的矛盾，所以我們期望以更高的效率去研發(fā)基礎(chǔ)設(shè)施，而不希望基礎(chǔ)設(shè)施的迭代受制于這個(gè)規(guī)模。

后來螞蟻?zhàn)约貉邪l(fā)的數(shù)據(jù)庫(kù) OceanBase 也在用一個(gè) Proxy 的方式來屏蔽掉 OceanBase 本身的集群負(fù)載，FailOver切換等方面的邏輯，而剛好 Service Mesh 的這種 Sidecar 的模式也是這樣的一個(gè)思路，這讓我們看到將基礎(chǔ)設(shè)施的能力從應(yīng)用中下移到 Sidecar 這件事情是一個(gè)業(yè)界的整體的趨勢(shì)和方向，通過這種方式應(yīng)用和中間件的基礎(chǔ)設(shè)施從此成了兩個(gè)進(jìn)程，我們可以針對(duì)中間件的基礎(chǔ)設(shè)施進(jìn)行單獨(dú)的升級(jí)，而不用和應(yīng)用的發(fā)布升級(jí)綁定在一起，這不僅解放了應(yīng)用研發(fā)和基礎(chǔ)設(shè)施團(tuán)隊(duì)，也讓基礎(chǔ)設(shè)施團(tuán)隊(duì)的交付能力變地更強(qiáng)，以前可能需要通過半年或者一年甚至更長(zhǎng)時(shí)間的折騰，才能夠?qū)⒒A(chǔ)設(shè)施團(tuán)隊(duì)提供的新的能力鋪到所有的業(yè)務(wù)系統(tǒng)中去，現(xiàn)在我們通過一個(gè)月的時(shí)間，就可以將新能力讓所有的業(yè)務(wù)系統(tǒng)享受到。這也讓基礎(chǔ)設(shè)施團(tuán)隊(duì)的中臺(tái)能力變得更強(qiáng)了。這樣我們就可以把我們還是把一些架構(gòu)當(dāng)中非常關(guān)鍵的支撐點(diǎn)以及一些邏輯下沉到 Sidecar上面去，因?yàn)檎麄€(gè)螞蟻金服的整體架構(gòu)有非常多的邏輯和能力承載在這一套架構(gòu)上面的。這些東西我們有一個(gè)最大的職責(zé)是要支撐它快速向前演進(jìn)和靈活。

Service Mesh 的選型

---

前面講到了螞蟻金服當(dāng)前服務(wù)化架構(gòu)下遇到的問題以及我們希望能夠通過 Service Mesh 能夠去解決的一些問題，接下來就面臨一個(gè)很現(xiàn)實(shí)的問題，Service Mesh 的框架我們到底應(yīng)該怎么選，我們應(yīng)該用什么樣的標(biāo)準(zhǔn)去衡量，那接下來，我就給大家分享一下螞蟻金服在Service Mesh 的框架上的選型上的一些思考。

首先，所有的架構(gòu)的演進(jìn)都不是一蹴而就的，都是一個(gè)漸進(jìn)式地演進(jìn)的一個(gè)過程，越大的公司在架構(gòu)演進(jìn)的過程中其實(shí)越需要考慮這一點(diǎn)。所以我們?cè)谶x型的時(shí)候就需要去考慮這一點(diǎn)，考慮目標(biāo)框架能否很好地和當(dāng)前的架構(gòu)融合在一起。另一個(gè)點(diǎn)，作為一個(gè)和錢打交道的公司，我們需要特別地去關(guān)注目標(biāo)框架是否在生產(chǎn)環(huán)境經(jīng)過大規(guī)模的驗(yàn)證，在場(chǎng)景上，是否經(jīng)過了各類場(chǎng)景的驗(yàn)證。

目前，業(yè)界主流的 Service Mesh 相關(guān)的框架有三個(gè)，分別是 Google，IBM，Lyft都參與其中的 Istio，以及 Bouyant 公司下的兩個(gè)開源的 Service Mesh 的框架 Linkerd 以及 Conduit。

首先我們來看下 Istio，Istio 應(yīng)該是目前被關(guān)注最高的一個(gè) ServiceMesh 框架，本身又有頂尖公司的光環(huán)加持，比如 Google，IBM 等等，他也完整地包含了一個(gè) Data Plane 以及 Control Plane，但是Istio 一直以來被挑戰(zhàn)的地方其實(shí)在于他的 Control Plane 的 Mixer 的部分，Istio 的 Mixer 承擔(dān)了服務(wù)鑒權(quán)，Quota 控制，Tracing，Metrics等等能力，它是一個(gè)中央的節(jié)點(diǎn)，如果不開啟緩存的情況下，所有的調(diào)用都需要從 Mixer 中過去，即使開啟了緩存的情況，也不可避免的有請(qǐng)求一定要從 Mixer 中過去，而在全螞蟻，有20000 多的服務(wù)，服務(wù)之間的調(diào)用是非常頻繁的，如果都需要過 Mixer，那 Mixer 就成了一個(gè)單點(diǎn)，這個(gè)單點(diǎn)的運(yùn)維和高可用又成了一個(gè)問題。

另外，Istio 的性能是我們一直以來比較擔(dān)心的問題，雖然 Istio 每個(gè)版本的發(fā)布，性能都有了一定程度的提升。但是我們來看下 Istio 的性能數(shù)據(jù)，0.5.1 的時(shí)候是 700 的 TPS，0.6.0 的時(shí)候是 1000 個(gè) TPS，0.7.1 的時(shí)候是 1700 個(gè) TPS，相對(duì)于一般的RPC 通信框架，最低最低都是萬級(jí)別的 TPS，Istio 的這個(gè)性能數(shù)據(jù)的確是有點(diǎn)兒慘淡，完全無法滿足螞蟻這邊的性能要求。

接下來我們來看 Linkerd，Linkerd 算是業(yè)界幾個(gè) Service Mesh的框架里面最成熟的一個(gè)了，但是他也有一個(gè)問題，首先就是他脫胎于 Twitter 的 Finagle，架構(gòu)上其實(shí)不夠開放，沒法很好的適配到螞蟻的環(huán)境里面去，另外Linkerd 也沒有 Control Plane 這一層，只有 Sidecar，再者 Linkerd 的路由規(guī)則 DTab 其實(shí)是挺難理解的。最后，其實(shí)也是我們當(dāng)時(shí)選型的時(shí)候最關(guān)心的一個(gè)問題，Linkerd是用 Scala 寫的，跑在 JVM 上面，我從 Linkerd 的一篇博客上摘錄出了一張圖片，這篇博客主要講的是如何優(yōu)化 JVM 的內(nèi)存使用，這種文章一般上是的確有這個(gè)問題，才會(huì)去寫這樣的文章，從這張圖片中我們可以看到 Linkerd 所需要的內(nèi)存至少都需要 100M，這也是 Bouyant 官方不推薦 Linkerd 和應(yīng)用做一對(duì)一的部署，而是采用 DaemonSet 的方式進(jìn)行部署。而我們期望的一個(gè)部署方式是和應(yīng)用做一對(duì)一的部署，這樣的內(nèi)存占用對(duì)于我們來說成本太過，我們期望將 Sidecar 的內(nèi)存占用控制在 10M 左右。

最后，我們來看下 Conduit，首先 Conduit 也是 Linkerd 不久之前推出的一個(gè)Service Mesh 的框架，其實(shí)不太成熟，其次，Conduit 選擇的語言是 Rust，我們來看下 Rust 在 Tiobe 上的排名，Java 長(zhǎng)時(shí)間高居第一位，C++在第三位，Golang 經(jīng)過這幾年云基礎(chǔ)設(shè)施的蓬勃發(fā)展，到了 14 位，而 Rust，和一眾語言的占用率沒有太大的差別，排在了 50 位往后。

所以，我們最后選擇了自研 Service Mesh，一方面當(dāng)然是我們基于前面的兩個(gè)準(zhǔn)則去衡量目前業(yè)界流行的Service Mesh 框架，沒有能夠完全滿足我們的要求的，另一方面螞蟻金服服務(wù)化上有長(zhǎng)期以及深厚的積累，這部分的一些經(jīng)驗(yàn)也可以支持我們能夠更好地去自研我們自己的Service Mesh 的框架。

當(dāng)然，我們也不是說完全從零開始搞 Service Mesh 框架，對(duì)于業(yè)界的Service Mesh 的框架中的優(yōu)秀理念，我們是希望能夠吸收過來的，另一方面，我們也希望能夠盡量地去 Follow Service Mesh 目前社區(qū)中的一些規(guī)范。

??

SOFA Mesh 的設(shè)計(jì)

---

首先，SOFA Mesh 其實(shí)直接采用了 Istio 的 Control Plane 的Pilot 和 Auth，因?yàn)槲覀冇X得 Istio 在這塊上沒有太大的問題甚至里面也有一些非常不錯(cuò)的設(shè)計(jì)，比如Pilot 這部分的 Universal Data API 就是非常不錯(cuò)的設(shè)計(jì)。Istio 的 Auth 這部分也充分地利用了 Kubernetes 的安全機(jī)制。

而Mixer 這部分，其實(shí)我之前就提到我們是覺得有設(shè)計(jì)上問題的，所以我們的想法是直接把 Mixer 搬到 Sidecar 中實(shí)現(xiàn)。

再者，大家都知道 Istio 的 Sidecar 是 Envoy，它是一個(gè)用 C++ 寫的，那么我們?cè)趺窗袽ixer 移入到 Sidecar 中去呢，其實(shí)我們的 SOFA Mesh 的 Sidecar 是采用了 Golang 來寫的，所以才給把 Mixer 移入Sidecar 提供了可能性，當(dāng)然，我們選擇用 Golang 來研發(fā) Sidecar 不僅僅是為了把 Mixer 移入到 Sidecar 而已，其實(shí)也有其他的考慮，一方面，在云計(jì)算的時(shí)代，Golang已經(jīng)成為構(gòu)建基礎(chǔ)設(shè)施的首選語言，我們看到大量的基礎(chǔ)設(shè)施都是用 Golang 寫的，包括 Docker，Kubernetes 等等，選擇 Golang，其實(shí)也是希望能夠更好地和云原生時(shí)代的這些基礎(chǔ)設(shè)施貼合。

另外，相比于 Envoy 采用的 C++，Golang 顯然更加容易上手，也更加容易找到這方面的人才，另外，Golang相對(duì)于 JVM 來說，Memory Footprint 低了非常多，我們用 Golang 寫的 Sidecar，目前的峰值? TPS 下的內(nèi)存占用在 11M，雖然還有一定的優(yōu)化空間，但是相比于 JVM 來說，已經(jīng)降低了10 倍。

另外，雖然我們采用了 Istio 的 Pilot，但是在內(nèi)部使用的時(shí)候，直接使用Pilot 并不能滿足我們的訴求。首先，Pilot 在 Kubernetes 上是直接對(duì)接到 Kubernetes 的服務(wù)發(fā)現(xiàn)機(jī)制上的，無論是 SOFARPC，還是微博的Motan 等等國(guó)內(nèi)的服務(wù)框架，其實(shí)都是單個(gè)應(yīng)用多個(gè)服務(wù)這樣的模型，而 Kubernetes 的服務(wù)發(fā)現(xiàn)機(jī)制實(shí)際上針對(duì)的是單個(gè)應(yīng)用單個(gè)服務(wù)的模型，在模型上就不太一致。另外，SOFA的服務(wù)注冊(cè)中心 SOFARegistry 在螞蟻金服內(nèi)部經(jīng)過了多年的實(shí)踐，面對(duì)內(nèi)部大規(guī)模的服務(wù)化的場(chǎng)景，SOFARegistry 的擴(kuò)展能力以及可靠性已經(jīng)經(jīng)過了大量的實(shí)踐證明，這里說一下SOFARegistry 上的一些數(shù)據(jù)，上面大約注冊(cè)了 2W 多個(gè)服務(wù)，一個(gè)機(jī)房里面的 Pub 和 Sub 的加起來在千萬級(jí)別。基于以上的考慮，我們選擇了用Pilot 上增加 SOFARegistry 的 Adapter，使之能夠拿到 SOFARegistry 上的服務(wù)注冊(cè)信息。

然后，Pilot 還有一個(gè)問題，就是原來 Pilot 會(huì)把所有的服務(wù)注冊(cè)相關(guān)的數(shù)據(jù)都同步到Pilot 上，這個(gè)對(duì)于 Pilot 的集群的壓力是非常大的，所以我們選擇了只同步必要的數(shù)據(jù)到一個(gè) Pilot 的節(jié)點(diǎn)上，減少 Pilot 本身的內(nèi)存壓力。

最后，我再分享一個(gè)螞蟻金服的場(chǎng)景，在螞蟻金服，因?yàn)槭聵I(yè)部眾多以及監(jiān)管的問題，不用的事業(yè)部之間的一些機(jī)器可能是網(wǎng)絡(luò)不通的，那么他們要做服務(wù)訪問，就必須有一個(gè)角色來做跨環(huán)境之間的服務(wù)訪問，所以我們基于 Sidecar 的概念，提出了 EdgeSidecar 的角色，他在技術(shù)的實(shí)現(xiàn)細(xì)節(jié)上其實(shí)和和應(yīng)用部署在一起的 Sidecar 是非常類似的，只是這個(gè) Sidecar 作為一個(gè)“邊緣”的角色，來負(fù)責(zé)跨環(huán)境的服務(wù)通信問題。

所以，SOFA Mesh 在整體的大圖上大概是這樣的，我們自研了一個(gè) Golang 的Sidecar，并且把 Mixer 納入到 Sidecar 中，來防止出現(xiàn)類似于 Istio 那樣的性能問題，在 Pilot 和 Auth 這兩個(gè)角色了，我們選擇直接使用Istio 的，然后在上面做一定程度的適配，適配到螞蟻內(nèi)部的環(huán)境中，然后我們?cè)谡麄€(gè)部署上，新增了一個(gè) EdgeSidecar 的角色，來解決跨環(huán)境的服務(wù)調(diào)用的問題。?

我知道大家一定對(duì) SOFA Mesh 在螞蟻內(nèi)部的落地情況非常感興趣，目前我們已經(jīng)落地的場(chǎng)景主要是多語言的場(chǎng)景，解決其他的語言和 SOFA 的通信問題，大約上了二三十個(gè)系統(tǒng)。然后我們正在嘗試用 SOFA Mesh 去更好地解決服務(wù)間調(diào)用的安全，以及藍(lán)綠發(fā)布的問題，在異構(gòu)系統(tǒng)通信的這件事情上，我們也在不久的將來會(huì)嘗試用 SOFA Mesh 去解決。

當(dāng)然，SOFA Mesh 在螞蟻內(nèi)部的落地其實(shí)離不開開源社區(qū)，所以在未來的兩三個(gè)月內(nèi)，我們也會(huì)將 SOFA Mesh 開源出來，將螞蟻內(nèi)部實(shí)踐 Service Mesh 的成果開源出來，給大家更多在這方面的參考。

對(duì)于未來，其實(shí)我覺得中間件作為基礎(chǔ)設(shè)施未來和云平臺(tái)融合是一個(gè)不可阻擋地趨勢(shì)，除了 Service Mesh，未來還可能會(huì)出現(xiàn) Message Mesh，DB Mesh 等等產(chǎn)品，我知道業(yè)界有些同學(xué)已經(jīng)開始做這方面的努力了。最后總結(jié)一下我今天演講的內(nèi)容，一個(gè)是 Service Mesh 給螞蟻金服解決的問題，包括多語言，遺留系統(tǒng)以及基礎(chǔ)設(shè)施團(tuán)隊(duì)和業(yè)務(wù)團(tuán)隊(duì)耦合的問題。在 ServiceMesh 的選型上，我們主要考量和當(dāng)前架構(gòu)的可融合性，以及框架的高可用，穩(wěn)定性。未來除了 ServiceMesh，可能還會(huì)出現(xiàn)其他的 Mesh，中間件和底層云平臺(tái)進(jìn)一步融合的趨勢(shì)不可擋。多謝大家！

下面帶來的是GIAC大會(huì)中螞蟻金服高級(jí)技術(shù)專家與現(xiàn)場(chǎng)參會(huì)人員進(jìn)行關(guān)于Service Mesh的問答互動(dòng)，我們精選了幾個(gè)比較熱門的問答分享給大家。

一、Mesh的高可用和安全，能否詳細(xì)說明一下？

答：我們最近正在做安全這件事情，安全涉及到兩個(gè)方面，一個(gè)方面是 RPC 的整個(gè)服務(wù)調(diào)用健全的問題，這個(gè)是可以直接在 Mesh 中去做的，可以直接利用 Istio 的 RBAC 來實(shí)現(xiàn)，另外是 Mesh 和 Mesh 之間的 TLS雙向認(rèn)證的事情。這個(gè)其實(shí) Istio 里面會(huì)有一些現(xiàn)成的方案，它與 K8S 融合的也非常好，這些東西是可以直接拿過來去用的。

?

二、如何解決服務(wù)的多版本路由和數(shù)據(jù)單元的多版本路由的問題？

答：ServiceMesh 主要關(guān)注的是服務(wù)調(diào)用這一塊，我來解釋一下多版本的路由，其實(shí)我們?cè)趦?nèi)部的話，服務(wù)版本這件事情用得會(huì)比較少，用得更多的是同一服務(wù)不同的實(shí)現(xiàn)。但是其實(shí)多版本路由這一塊，如果說大家知道 K8S 的 Label 的話，可以把它的這種設(shè)計(jì)來借鑒到整個(gè)Mesh當(dāng)中，然后通過不同的標(biāo)簽來做區(qū)分，后面也會(huì)有一些這方面的分享出來。

???

三、Service Mesh 主要是解決了請(qǐng)求的可靠傳輸和服務(wù)治理的問題嗎？

答：應(yīng)該是說Service Mesh提出了更好的方式去解決請(qǐng)求的可靠傳輸和服務(wù)治理的問題。其實(shí)想像一下，如果說你要上一整套的服務(wù)治理的架構(gòu)的話，在原來的方式下可能需要你們所有的上層業(yè)務(wù)系統(tǒng)都接入你們對(duì)應(yīng)的服務(wù)治理的組件，現(xiàn)在的話，只要有一個(gè)Service Mesh，在這個(gè) Sidecar 當(dāng)中就可以把服務(wù)治理的這件事情做掉。它沒有去解決新的問題，只是把一些老的問題用更好的方式去解決。

?

四、為什么Control Plane對(duì)于Mesh來說很重要？

答：其實(shí)這個(gè)就涉及到整個(gè)云平臺(tái)和我們整個(gè)服務(wù)化體系的融合的問題。其實(shí)目前大家可以看到，Pilot 這部分的東西，在原來 Istio 設(shè)計(jì)當(dāng)中是非常強(qiáng)的和 K8S 這個(gè)東西融合在一起的，如果說你沒有這套東西存在的話，對(duì)于 Mesh 來說還是一個(gè)非常上層的中間件這樣的東西。當(dāng)然你可以說不用 Control Plane 這一層，只有 Sidecar，對(duì)接到原來的一整套的服務(wù)治理體系當(dāng)中去，這樣做也是可以的，沒有太大的問題。但是有了 Control Plane 這一層?xùn)|西，它定義了非常通用的 API，本身這個(gè)架構(gòu)又是和云平臺(tái)整個(gè)架構(gòu)是綁定得比較緊的，有更好的融合度。所以我們覺得整個(gè)Control Plane這一層是非常重要的。

?

另外，Istio 提出 Control Plane，其實(shí)是在往微服務(wù)標(biāo)準(zhǔn)化方面邁進(jìn)了很大一層。它里面有非常多的服務(wù)發(fā)現(xiàn)的標(biāo)準(zhǔn)，治理的標(biāo)準(zhǔn)，雖然說他大膽提出了這樣的概念和假設(shè)，我們也看到了它的一些不足，所以我們希望和社區(qū)一起推進(jìn)這一層的標(biāo)準(zhǔn)化。就像我一開始分享的，基礎(chǔ)設(shè)施一層一層的向上包。像我們覺得越來越多的中間件的部分，其實(shí)是會(huì)被沉淀到基礎(chǔ)設(shè)施當(dāng)中的。現(xiàn)在也有云原生語言，我們編譯了一下，發(fā)現(xiàn)很慢，問題也很多，但是我們覺得這是一個(gè)方向。大家在寫的時(shí)候，可能就用這樣的語言去寫，很多能力就提升上去了。我們希望把基礎(chǔ)設(shè)施向上再推一下，去扮演這樣一個(gè)角色。這也是我們認(rèn)為 Control Plane 的最大的價(jià)值。

總結(jié)

以上是生活随笔為你收集整理的蚂蚁金服的 Service Mesh 演进之道？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。