近幾年，微服務(wù)架構(gòu)逐漸發(fā)展成熟憋他，從最初的星星之火到現(xiàn)在大規(guī)模的落地和實(shí)踐孩饼，幾乎已經(jīng)成為分布式環(huán)境下的首選架構(gòu)。然而軟件開(kāi)發(fā)沒(méi)有銀彈竹挡，基于微服務(wù)構(gòu)建的應(yīng)用系統(tǒng)在享受其優(yōu)勢(shì)的同時(shí)镀娶，痛點(diǎn)也越加明顯。Service Mesh 技術(shù)也因此而生此迅，受到越來(lái)越多的開(kāi)發(fā)者關(guān)注汽畴，并擁有了大批擁躉。本文會(huì)從概念介紹開(kāi)始耸序，讓大家理解 Service Mesh 技術(shù)出現(xiàn)的原因以及愿景；接著會(huì)對(duì)目前最主流的兩個(gè)產(chǎn)品 Istio 和 AWS App Mesh 進(jìn)行詳細(xì)的比較鲁猩；最后簡(jiǎn)要介紹一下我們目前在該領(lǐng)域的一些探索與實(shí)踐坎怪。
Service Mesh - 服務(wù)通信的濟(jì)世良方
Service Mesh 是什么？
Service Mesh（中文譯做服務(wù)網(wǎng)格）這一概念由 Buoyant 公司的 CEO廓握，William Morg」n 首先提出搅窿。2017 年 4 月該公司發(fā)布了第一個(gè) Service Mesh 產(chǎn)品 Linkerd，這篇同一時(shí)間發(fā)表的文章What’s a service mesh隙券？ And why do I need one?也被業(yè)界公認(rèn)是 Service Mesh 的權(quán)威定義男应。
“A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.”
其定義翻譯為：Service Mesh 是一個(gè)處理服務(wù)通訊的專(zhuān)門(mén)的基礎(chǔ)設(shè)施層。它的職責(zé)是在由云原生應(yīng)用組成服務(wù)的復(fù)雜拓?fù)浣Y(jié)構(gòu)下進(jìn)行可靠的請(qǐng)求傳送娱仔。在實(shí)踐中沐飘，它是一組和應(yīng)用服務(wù)部署在一起的輕量級(jí)的網(wǎng)絡(luò)代理，對(duì)應(yīng)用服務(wù)透明。這段話(huà)有點(diǎn)晦澀難懂耐朴，但只要抓住下面 4 個(gè)關(guān)鍵點(diǎn)就能輕松理解：
本質(zhì)：基礎(chǔ)設(shè)施層
功能：請(qǐng)求分發(fā)
部署形式：網(wǎng)絡(luò)代理
特點(diǎn)：透明
如果用一句話(huà)來(lái)總結(jié)借卧，我個(gè)人對(duì)它的定義是：Service Mesh 是一組用來(lái)處理服務(wù)間通訊的網(wǎng)絡(luò)代理。
為什么需要 Service Mesh筛峭？
上面晦澀抽象的定義很難讓你真正理解 Service Mesh 存在的意義铐刘。你可能會(huì)想，服務(wù)間通信（service-to-service communication）無(wú)非就是通過(guò) RPC影晓、HTTP 這些方式進(jìn)行镰吵，有什么可處理的？沒(méi)錯(cuò)挂签，服務(wù)間只需要遵循這些標(biāo)準(zhǔn)協(xié)議進(jìn)行交互就可以了疤祭，但是在微服務(wù)這樣的分布式環(huán)境下，分散的服務(wù)勢(shì)必帶來(lái)交互的復(fù)雜性竹握，而規(guī)模越大的系統(tǒng)其通信越加錯(cuò)綜復(fù)雜画株。分布式計(jì)算下的 8 個(gè)謬論很好的歸納了分布式環(huán)境下存在的網(wǎng)絡(luò)問(wèn)題。而為了解決這些問(wèn)題啦辐，提高系統(tǒng)的容錯(cuò)能力和可用性谓传，出現(xiàn)了服務(wù)注冊(cè)與發(fā)現(xiàn)、負(fù)載均衡芹关、熔斷续挟、降級(jí)、限流等等和通信相關(guān)的功能侥衬，而這些才是 Service Mesh 要真正處理的問(wèn)題诗祸。
Pattern：Service Mesh這篇文章詳細(xì)的講述了微服務(wù)架構(gòu)下通訊處理的演進(jìn)，由此引出 Service Mesh 出現(xiàn)的意義和核心價(jià)值轴总。下圖為服務(wù)通信演變的過(guò)程：
最初直颅，流量管理和控制能力（比如圖例中的熔斷、服務(wù)發(fā)現(xiàn)）是和業(yè)務(wù)邏輯耦合在一起怀樟，即便以引用包的方式被調(diào)用功偿，依然解決不了異構(gòu)系統(tǒng)無(wú)法重用的問(wèn)題。
流控功能和業(yè)務(wù)耦合相當(dāng)不美好往堡，于是出現(xiàn)了提供這些功能的公共庫(kù)和框架械荷。但這些庫(kù)通常比較復(fù)雜，無(wú)論是學(xué)習(xí)使用虑灰，與業(yè)務(wù)系統(tǒng)整合吨瞎、維護(hù)都會(huì)帶來(lái)很大的成本。
為避免花費(fèi)太多時(shí)間開(kāi)發(fā)和維護(hù)這些通用庫(kù)穆咐，人們希望流量控制能力可以下沉到網(wǎng)絡(luò)通訊棧的層面颤诀，但幾乎無(wú)法實(shí)現(xiàn)字旭。
于是另一種思路出現(xiàn)，就是將這些功能獨(dú)立成一個(gè)代理着绊，由它先接管業(yè)務(wù)服務(wù)的流量谐算，處理完成后再轉(zhuǎn)發(fā)給業(yè)務(wù)服務(wù)本身，這就是 Sidecar 模式归露。
為統(tǒng)一管理 Sidecar洲脂，該模式進(jìn)一步進(jìn)化，形成網(wǎng)絡(luò)拓?fù)渚绨黾恿丝刂破矫婵纸酰葑兂?Service Mesh（最后的網(wǎng)格圖中，綠色代表業(yè)務(wù)服務(wù)疆液，藍(lán)色代表 sidecar 服務(wù)）一铅。
可以說(shuō)，Service Mesh 就是 Sidecar 的網(wǎng)絡(luò)拓?fù)湫螒B(tài)堕油，Mesh 這個(gè)詞也由此而來(lái)潘飘。（關(guān)于 Sidecar 模式這里不做討論，你可以自行 Google）掉缺。
業(yè)務(wù)系統(tǒng)的核心價(jià)值應(yīng)該是業(yè)務(wù)本身卜录，而不是服務(wù)，微服務(wù)只是一種實(shí)現(xiàn)手段眶明，實(shí)現(xiàn)業(yè)務(wù)才是目標(biāo)〖瓒荆現(xiàn)有的微服務(wù)架構(gòu)下，為解決可能出現(xiàn)的網(wǎng)絡(luò)通信問(wèn)題搜囱，提升系統(tǒng)的彈性丑瞧，開(kāi)發(fā)人員不得不花費(fèi)大量時(shí)間和精力去實(shí)現(xiàn)流量控制相關(guān)的非業(yè)務(wù)需求，不能聚焦在業(yè)務(wù)本身蜀肘。而 Service Mesh 的出現(xiàn)解決了這一問(wèn)題绊汹，帶來(lái)了下面 2 個(gè)變革：
解決了微服務(wù)框架中的服務(wù)流量管理的痛點(diǎn)，使開(kāi)發(fā)人員專(zhuān)注于業(yè)務(wù)本身扮宠；
將服務(wù)通信及相關(guān)管控功能從業(yè)務(wù)程序中分離并下層到基礎(chǔ)設(shè)施層灸促，使其和業(yè)務(wù)系統(tǒng)完全解耦。
在云原生應(yīng)用中涵卵，面對(duì)數(shù)百個(gè)服務(wù)或數(shù)千個(gè)實(shí)例，單個(gè)業(yè)務(wù)鏈路的請(qǐng)求經(jīng)由服務(wù)的拓?fù)渎窂娇赡軙?huì)非常復(fù)雜荒叼，單獨(dú)處理非常必要轿偎。這就是 Service Mesh 的意義所在。
Service Mesh 的主要功能
那么 Service Mesh 到底能帶來(lái)哪些實(shí)用的功能呢被廓？可以把它們歸納為下面 4 個(gè)部分：
流量控制：流控是最主要也是最重要的功能坏晦，通過(guò) Service Mesh，我們可以為應(yīng)用提供智能路由（藍(lán)綠部署、金絲雀發(fā)布昆婿、A/B test）球碉、超時(shí)重試、熔斷仓蛆、故障注入睁冬、流量鏡像等各種控制能力；
-安全：在安全層面上看疙，授權(quán)和身份認(rèn)證也可以托管給 Service Mesh豆拨；
策略：可以為流量設(shè)置配額、黑白名單等策略能庆；
可觀察性：服務(wù)的可觀察性一般是通過(guò)指標(biāo)數(shù)據(jù)施禾、日志、追蹤三個(gè)方式展現(xiàn)的搁胆，目前的 Service Mesh 產(chǎn)品可以很容易和和主流的后端設(shè)施整合弥搞，提供給應(yīng)用系統(tǒng)完整的監(jiān)控能力。
通過(guò)上面的講述渠旁，我相信 Service Mesh 的概念大家都已經(jīng)有所了解攀例。接下來(lái)我們來(lái)介紹兩個(gè)重要的網(wǎng)格產(chǎn)品，讓大家進(jìn)一步了解 Service Mesh 的產(chǎn)品形態(tài)是什么樣的一死。
Istio vs AWS App Mesh - 開(kāi)源與閉環(huán)之爭(zhēng)
目前市面上比較成熟的開(kāi)源服務(wù)網(wǎng)格主要有下面幾個(gè)：Linkerd肛度，這是第一個(gè)出現(xiàn)在公眾視野的服務(wù)網(wǎng)格產(chǎn)品，由 Twitter 的 finagle 庫(kù)衍生而來(lái)投慈，目前由 Buoyant 公司負(fù)責(zé)開(kāi)發(fā)和維護(hù)承耿；Envoy，Lyft 開(kāi)發(fā)并且是第一個(gè)從 CNCF 孵化的服務(wù)網(wǎng)格產(chǎn)品伪煤，定位于通用的數(shù)據(jù)平面或者單獨(dú)作為 Sidecar 代理使用加袋；Istio，由 Google抱既、IBM职烧、Lyft 聯(lián)合開(kāi)發(fā)的所謂第二代服務(wù)網(wǎng)格產(chǎn)品，控制平面的加入使得服務(wù)網(wǎng)格產(chǎn)品的形態(tài)更加完整防泵。
從今年的風(fēng)向看蚀之，作為構(gòu)建云原生應(yīng)用的重要一環(huán)，Service Mesh 已經(jīng)被各大云廠商認(rèn)可捷泞，并看好它的發(fā)展前景足删。在 Istio 紅透半邊天的情況下，作為和 Google 在云服務(wù)市場(chǎng)競(jìng)爭(zhēng)的 Amazon 來(lái)說(shuō)锁右，自然不愿錯(cuò)失這塊巨大的蛋糕失受。他們?cè)诮衲?4 月份發(fā)布了自己的服務(wù)網(wǎng)格產(chǎn)品：AWS App Mesh讶泰。這一部分內(nèi)容我們會(huì)聚焦于 Istio 和 App Mesh 這兩個(gè)產(chǎn)品，通過(guò)橫向的對(duì)比分析讓大家對(duì) Service Mesh 的產(chǎn)品形態(tài)和兩大云廠商的策略有一個(gè)更深入的認(rèn)識(shí)拂到。
產(chǎn)品定位
從官方的介紹來(lái)看痪署，Istio 和 App Mesh 都明確的表示自己是一種服務(wù)網(wǎng)格產(chǎn)品。Istio 強(qiáng)調(diào)了自己在連接兄旬、安全狼犯、控制和可視化 4 個(gè)方面的能力；而 App Mesh 主要強(qiáng)調(diào)了一致的可見(jiàn)性和流量控制這兩方面能力辖试，當(dāng)然也少不了強(qiáng)調(diào)作為云平臺(tái)下的產(chǎn)品的好處：托管服務(wù)辜王，無(wú)需自己維護(hù)。
從某種程度上講罐孝，Istio 是一個(gè)相對(duì)重一點(diǎn)的解決方案呐馆，提供了不限于流量管理的各個(gè)方面的能力；而 App Mesh 是更加純粹的服務(wù)于運(yùn)行在 AWS 之上的應(yīng)用并提供流控功能莲兢。筆者認(rèn)為這和它目前的產(chǎn)品形態(tài)還不完善有關(guān)（后面會(huì)具體提到）汹来。從與 AWS 技術(shù)支持團(tuán)隊(duì)的溝通中可以感覺(jué)到，App Mesh 應(yīng)該是一盤(pán)很大的棋改艇，目前只是初期階段收班。
核心術(shù)語(yǔ)
和 AWS 里很多產(chǎn)品一樣，App Mesh 也不是獨(dú)創(chuàng)谒兄，而是基于 Envoy 開(kāi)發(fā)的摔桦。AWS 這樣的閉環(huán)生態(tài)必然要對(duì)其進(jìn)行改進(jìn)和整合。同時(shí)承疲，也為了把它封裝成一個(gè)對(duì)外的服務(wù)邻耕，提供適當(dāng)?shù)?API 接口，在 App Mesh 這個(gè)產(chǎn)品中提出了下面幾個(gè)重要的技術(shù)術(shù)語(yǔ)燕鸽，我們來(lái)一一介紹一下兄世。
服務(wù)網(wǎng)格（Service mesh）：服務(wù)間網(wǎng)絡(luò)流量的邏輯邊界。這個(gè)概念比較好理解啊研，就是為使用 App mesh 的服務(wù)圈一個(gè)虛擬的邊界御滩。
虛擬服務(wù)（Virtual services）：是真實(shí)服務(wù)的抽象。真實(shí)服務(wù)可以是部署于抽象節(jié)點(diǎn)的服務(wù)党远，也可以是間接的通過(guò)路由指向的服務(wù)削解。
虛擬節(jié)點(diǎn)（Virtual nodes）：虛擬節(jié)點(diǎn)是指向特殊工作組（task group）的邏輯指針。例如 AWS 的 ECS 服務(wù)沟娱，或者 Kubernetes 的 Deployment钠绍。可以簡(jiǎn)單的把它理解為是物理節(jié)點(diǎn)或邏輯節(jié)點(diǎn)的抽象花沉。
Envoy：AWS 改造后的 Envoy（未來(lái)會(huì)合并到 Envoy 的官方版本）柳爽，作為 App Mesh 里的數(shù)據(jù)平面，Sidecar 代理碱屁。
虛擬路由器（Virtual routers）：用來(lái)處理來(lái)自虛擬服務(wù)的流量磷脯。可以理解為它是一組路由規(guī)則的封裝娩脾。
路由（Routes）：就是路由規(guī)則赵誓，用來(lái)根據(jù)這個(gè)規(guī)則分發(fā)請(qǐng)求。
上面的圖展示了這幾個(gè)概念的關(guān)系：當(dāng)用戶(hù)請(qǐng)求一個(gè)虛擬服務(wù)時(shí)柿赊，服務(wù)配置的路由器根據(jù)路由策略將請(qǐng)求指向?qū)?yīng)的虛擬節(jié)點(diǎn)俩功，這些節(jié)點(diǎn)最終會(huì)與集群中某個(gè)對(duì)外提供服務(wù)的 DNS 或者服務(wù)名一一對(duì)應(yīng)。
那么這些 App Mesh 自創(chuàng)的術(shù)語(yǔ)是否能在 Istio 中找到相似甚至相同的對(duì)象呢碰声？我歸納了下面的表格來(lái)做一個(gè)對(duì)比：
App MeshIstio
服務(wù)網(wǎng)格（Service mesh）Istio并未顯示的定義這一概念诡蜓，我們可以認(rèn)為在一個(gè)集群中，由Istio管理的服務(wù)集合胰挑，它們組成的網(wǎng)絡(luò)拓?fù)浼词欠?wù)網(wǎng)格蔓罚。
虛擬服務(wù)（Virtual services）Istio中也存在虛擬服務(wù)的概念。它的主要功能是定義路由規(guī)則瞻颂，使請(qǐng)求可以根據(jù)這些規(guī)則被分發(fā)到對(duì)應(yīng)的服務(wù)豺谈。從這一點(diǎn)來(lái)說(shuō)，它和App Mesh的虛擬服務(wù)的概念基本上是一致的贡这。
虛擬節(jié)點(diǎn)（Virtual nodes）Istio沒(méi)有虛擬節(jié)點(diǎn)的概念茬末，可以認(rèn)為類(lèi)似Kubernetes里的Deployment。
虛擬路由器（Virtual routers）Istio也沒(méi)有虛擬路由器的概念盖矫。
路由（Routes）Istio中的目標(biāo)規(guī)則（DestinationRule）和路由的概念類(lèi)似丽惭，為路由設(shè)置一些策略。從配置層面講炼彪，其中的子集（subset）和App Mesh路由里選擇的目標(biāo)即虛擬節(jié)點(diǎn)對(duì)應(yīng)吐根。但I(xiàn)stio的目標(biāo)規(guī)則更加靈活，也支持更多的路由策略辐马。
從上面的對(duì)比看出拷橘，App Mesh 目前基本上實(shí)現(xiàn)了最主要的流量控制（路由）的功能，但像超時(shí)重試喜爷、熔斷冗疮、流量復(fù)制等高級(jí)一些的功能還沒(méi)有提供，有待進(jìn)一步完善檩帐。
架構(gòu)
AWS App Mesh 是一個(gè)商業(yè)產(chǎn)品术幔，目前還沒(méi)有找到架構(gòu)上的技術(shù)細(xì)節(jié)，不過(guò)我們依然可以從現(xiàn)有的湃密、公開(kāi)的文檔或介紹中發(fā)現(xiàn)一些有用的信息诅挑。
從這張官網(wǎng)的結(jié)構(gòu)圖中可以看出四敞，每個(gè)服務(wù)的橙色部分就是 Sidecar 代理：Envoy。而中間的 AWS App Mesh 其實(shí)就是控制平面拔妥，用來(lái)控制服務(wù)間的交互忿危。那么這個(gè)控制平面具體的功能是什么呢？我們可以從今年的 AWS Summit 的一篇 PPT 中看到這樣的字樣：
控制平面用來(lái)把邏輯意圖轉(zhuǎn)換成代理配置没龙，并進(jìn)行分發(fā)铺厨。
熟悉 Istio 架構(gòu)的朋友有沒(méi)有覺(jué)得似曾相識(shí)？沒(méi)錯(cuò)硬纤，這個(gè)控制平面的職責(zé)和 Pilot 基本一致解滓。由此可見(jiàn)，不管什么產(chǎn)品的控制平面筝家，也必須具備這些核心的功能洼裤。
那么在平臺(tái)的支持方面呢？下面這張圖展示了 App Mesh 可以被運(yùn)行在如下的基礎(chǔ)設(shè)施中肛鹏，包括 EKS逸邦、ECS、EC2 等等在扰。當(dāng)然缕减，這些都必須存在于 AWS 這個(gè)閉環(huán)生態(tài)中。
而 Istio 這方面就相對(duì)弱一些芒珠。盡管 Istio 宣稱(chēng)是支持多平臺(tái)的桥狡，但目前來(lái)看和 Kubernetes 還是強(qiáng)依賴(lài)。不過(guò)它并不受限于單一的云平臺(tái)皱卓，這一點(diǎn)有較大的優(yōu)勢(shì)裹芝。
Istio 的架構(gòu)大家都比較熟悉，數(shù)據(jù)平面由 Envoy sidecar 代理組成娜汁，控制平面包括了 Pilot嫂易、Mixer、Citadel掐禁、Galley 等控件怜械。它們的具體功能這里就不再贅述了，感興趣的同學(xué)可以直接去官網(wǎng)查看詳細(xì)信息傅事。
功能與實(shí)現(xiàn)方式
部署
無(wú)論是 Istio 還是 App Mesh 都使用了控制平面+數(shù)據(jù)平面的模式缕允，且 Sidecar 都使用了 Envoy 代理。Istio 的控制平面組件較多蹭越，功能也更復(fù)雜障本，1.0.x 版本完整安裝后的 CRD 有 50 個(gè)左右。架構(gòu)修改后 Mixer 的一些 adapter 被獨(dú)立出去，crd 有所降低驾霜。下面是最新的 1.4 版本案训，安裝后仍然有 24 個(gè) crd。
而 App Mesh 就簡(jiǎn)單得多寄悯，只針對(duì)核心概念添加了如下 3 個(gè) crd萤衰，用一個(gè) controller 進(jìn)行管理。
盡管 Istio 更多的 crd 在一定程度上代表了更加豐富的功能猜旬，但同時(shí)也為維護(hù)和 troubleshooting 增加了困難。
流量控制
盡管兩者的數(shù)據(jù)平面都基于 Envoy倦卖，但它們提供的流量控制能力目前還是有比較大的差距的洒擦。在路由的設(shè)置方面，App Mesh 提供了相對(duì)比較豐富的匹配策略怕膛，基本能滿(mǎn)足大部分使用場(chǎng)景熟嫩。下面是 App Mesh 控制臺(tái)里的路由配置截圖，可以看出褐捻，除了基本的 URI 前綴掸茅、HTTP Method 和 Scheme 外，也支持請(qǐng)求頭的匹配柠逞。
Istio 的匹配策略更加完善昧狮，除了上面提到的，還包括 HTTP Authority板壮，端口匹配逗鸣，請(qǐng)求參數(shù)匹配等，具體信息可以從官方文檔的虛擬服務(wù)設(shè)置查看绰精。下面兩段 yaml 分別展示了兩個(gè)產(chǎn)品在虛擬服務(wù)配置上的差異撒璧。
App Mesh 配置：
Istio 配置：
另外一個(gè)比較大的不同是，App Mesh 需要你對(duì)不同版本的服務(wù)分開(kāi)定義（即定義成不同的虛擬服務(wù)）笨使，而 Istio 是通過(guò)目標(biāo)規(guī)則 DestinationRule 里的子集 subsets 和路由配置做的關(guān)聯(lián)卿樱。本質(zhì)上它們沒(méi)有太大區(qū)別。
除了路由功能外硫椰，App Mesh 就顯得捉襟見(jiàn)肘了繁调。就在筆者撰寫(xiě)本文時(shí)，AWS 剛剛添加了重試功能最爬。而 Istio 借助于強(qiáng)大的 Envoy涉馁，提供了全面的流量控制能力，如超時(shí)重試爱致、故障注入烤送、熔斷、流量鏡像等糠悯。
安全
在安全方面帮坚，兩者的實(shí)現(xiàn)方式具有較大區(qū)別妻往。默認(rèn)情況下，一個(gè)用戶(hù)不能直接訪問(wèn) App Mesh 的資源试和，需要通過(guò) AWS 的 IAM 策略給用戶(hù)授權(quán)讯泣。比如下面的配置是容許用戶(hù)用任意行為去操作網(wǎng)格內(nèi)的任意資源：
因此，App Mesh 的授權(quán)和認(rèn)證都是基于 AWS 自身的 IAM 策略阅悍。
Istio 提供了兩種認(rèn)證方式好渠，基于 mTLS 的傳輸認(rèn)證，和 基于 JWT 的身份認(rèn)證节视。而 Istio 的授權(quán)是通過(guò) RBAC 實(shí)現(xiàn)的拳锚，可以提供基于命名空間、服務(wù)和 HTTP 方法級(jí)別的訪問(wèn)控制寻行。這里就不具體展示了霍掺，大家可以通過(guò)官網(wǎng)文檔來(lái)查看。
可觀察性
一般來(lái)說(shuō)拌蜘，可以通過(guò)三種方式來(lái)觀察你的應(yīng)用：指標(biāo)數(shù)據(jù)杆烁、分布式追蹤、日志简卧。Istio 在這三個(gè)方面都有比較完整的支持兔魂。指標(biāo)方面，可以通過(guò) Envoy 獲取請(qǐng)求相關(guān)的數(shù)據(jù)贞滨，同時(shí)還提供了服務(wù)級(jí)別的指標(biāo)入热，以及控制平面的指標(biāo)來(lái)檢測(cè)各個(gè)組件的運(yùn)行情況。通過(guò)內(nèi)置的 Prometheus 來(lái)收集指標(biāo)晓铆，并使用 Grafana 展示出來(lái)勺良。分布式追蹤也支持各種主流的 OpenTracing 工具，如 Jaeger骄噪、Zipkin 等尚困。訪問(wèn)日志一般都通過(guò) ELK 去完成收集、分析和展示链蕊。另外事甜，Istio 還擁有 Kiali 這樣的可視化工具，給你提供整個(gè)網(wǎng)格以及微服務(wù)應(yīng)用的拓?fù)湟晥D滔韵÷咔總體來(lái)說(shuō)，Istio 在可觀察方面的能力是非常強(qiáng)大的陪蜻，這主要是因?yàn)?Mixer 組件的插件特性帶來(lái)了巨大的靈活性邦马。
App Mesh 在這方面做的也不錯(cuò)。從最新發(fā)布的官方 repo中，App Mesh 已經(jīng)提供了集成主流監(jiān)控工具的 helm chart滋将，包括 Prometheus邻悬、Grafana、Jaeger 等随闽。同時(shí)父丰，AWS 又一次發(fā)揮了自己閉環(huán)生態(tài)的優(yōu)勢(shì)，提供了與自家的監(jiān)控工具 CloudWatch掘宪、X-Ray 的整合蛾扇。總的來(lái)說(shuō)魏滚，App Mesh 在對(duì)服務(wù)的可觀察性上也不落下風(fēng)屁桑。
Amazon 與 Google 的棋局
AWS App Mesh 作為一個(gè) 2019 年 4 月份才發(fā)布的產(chǎn)品（GA），在功能的完整性上和 Istio 有差距也是情有可原的栏赴。從 App Mesh 的 Roadmap 可以看出，很多重要的功能靖秩，比如熔斷已經(jīng)在開(kāi)發(fā)計(jì)劃中须眷。從筆者與 AWS 的支持團(tuán)隊(duì)了解的信息來(lái)看，他們相當(dāng)重視這個(gè)產(chǎn)品沟突，優(yōu)先級(jí)很高花颗，進(jìn)度也比較快，之前還在預(yù)覽階段的重試功能在上個(gè)月也正式發(fā)布了惠拭。另外扩劝，App Mesh 是可以免費(fèi)使用的，用戶(hù)只需要對(duì)其中的實(shí)例資源付費(fèi)即可职辅，沒(méi)有額外費(fèi)用棒呛。對(duì) AWS 來(lái)說(shuō)，該產(chǎn)品的開(kāi)發(fā)重點(diǎn)是和現(xiàn)有產(chǎn)品的整合域携，比如 Roadmap 列出的使用 AWS Gateway 作為 App Mesh 的 Ingress簇秒。借助著自己的生態(tài)優(yōu)勢(shì)，這種整合即方便快捷的完善了 App Mesh秀鞭，同時(shí)又讓生態(tài)內(nèi)的產(chǎn)品結(jié)合的更緊密趋观，使得閉環(huán)更加的牢固，不得不說(shuō)是一步好棋锋边。
和 App Mesh 目前只強(qiáng)調(diào)流控能力不同皱坛，Istio 更多的是把自己打造成一個(gè)更加完善的、全面的服務(wù)網(wǎng)格系統(tǒng)豆巨。架構(gòu)優(yōu)雅剩辟，功能強(qiáng)大，但性能上受到質(zhì)疑。在產(chǎn)品的更迭上貌似也做的不盡如人意（不過(guò)近期接連發(fā)布了 1.3 到 1.4 版本抹沪，讓我們對(duì)它的未來(lái)發(fā)展又有了期待）刻肄。Istio 的優(yōu)勢(shì)在于 3 大頂級(jí)技術(shù)公司加持的強(qiáng)大資源，加上開(kāi)源社區(qū)的反哺融欧，利用好的話(huà)容易形成可持續(xù)發(fā)展的局面敏弃，并成為下一個(gè)明星級(jí)產(chǎn)品。然而 Google 目前對(duì) Istio 的態(tài)度有一些若即若離噪馏，一方面很早就在自家的云服務(wù) gcloud 里提供了 Istio 的默認(rèn)安裝選項(xiàng)麦到，但同時(shí)又發(fā)布了和 Istio 有競(jìng)爭(zhēng)關(guān)系的 Traffic director 這個(gè)托管的控制平面。筆者的猜測(cè)是 Google 也意識(shí)到 Istio 的成熟不可能一蹴而就欠肾，鑒于網(wǎng)格技術(shù)托管需求的越發(fā)強(qiáng)烈瓶颠，先提供一個(gè)輕量化的產(chǎn)品以占領(lǐng)市場(chǎng)。
目前各大廠商都意識(shí)到了網(wǎng)格技術(shù)的重要性并陸續(xù)推出了自己的產(chǎn)品（包括 AWS App Mesh刺桃，Kong 的 Kuma粹淋，國(guó)內(nèi)的螞蟻金服、騰訊云等）瑟慈，競(jìng)爭(zhēng)也會(huì)逐漸激烈桃移。未來(lái)是三分天下還是一統(tǒng)山河，讓我們拭目以待葛碧。
我們的實(shí)踐 - 從 Service Mesh 邁向云原生
最后這部分給大家簡(jiǎn)要介紹一下我們（FreeWheel）在 Service Mesh 領(lǐng)域的實(shí)踐借杰。希望通過(guò)一些前瞻性的探索，總結(jié)出最佳實(shí)踐进泼，為我們將來(lái)的微服務(wù)應(yīng)用全面擁抱云原生提供一定的經(jīng)驗(yàn)和指導(dǎo)蔗衡。目前我們已經(jīng)開(kāi)發(fā)完成的 Data service 項(xiàng)目就整合了 AWS App Mesh，即將上線(xiàn)乳绕，并使用網(wǎng)格的能力進(jìn)行智能路由和發(fā)布绞惦。
Data service 項(xiàng)目只包含兩個(gè)服務(wù)：Forecast service 和 Query service，前者作為業(yè)務(wù)服務(wù)通過(guò) Query service 查詢(xún)來(lái)自持久層（ClickHouse）的數(shù)據(jù)刷袍；后者作為數(shù)據(jù)訪問(wèn)代理翩隧，從持久層獲取數(shù)據(jù)并進(jìn)行對(duì)象化的封裝。這個(gè) mini 的微服務(wù)系統(tǒng)非常適合作為一個(gè)先行者為我們探索網(wǎng)格的功能呻纹、性能堆生、易用性等方面的能力，且范圍足夠小雷酪，不會(huì)影響到其他業(yè)務(wù)系統(tǒng)淑仆。
選擇 AWS App Mesh 作為該項(xiàng)目的網(wǎng)格產(chǎn)品主要原因如下：
FreeWheel 是一個(gè)重度使用 AWS 各項(xiàng)服務(wù)的公司，未來(lái)所有的服務(wù)也都會(huì)全部托管的 AWS 上哥力。作為一個(gè)閉環(huán)生態(tài)蔗怠，App Mesh 可以和現(xiàn)有服務(wù)無(wú)縫整合墩弯，提高易用性；
相比 Istio 這樣還不太成熟的開(kāi)源產(chǎn)品寞射，我們可以得到 AWS 技術(shù)團(tuán)隊(duì)的全力支持渔工；
數(shù)據(jù)平面基于成熟高效的 Envoy，控制平面不存在 Istio 中的性能問(wèn)題桥温；
完全免費(fèi)
下圖是該項(xiàng)目的部署視圖引矩。前端請(qǐng)求從我們的業(yè)務(wù)系統(tǒng) UIF 發(fā)送到 Forecast service，它作為 App Mesh 的一個(gè)虛擬節(jié)點(diǎn)侵浸，調(diào)用 Data service 進(jìn)行數(shù)據(jù)查詢(xún)旺韭。Data service 作為數(shù)據(jù)平面，會(huì)注入 App Mesh 的 sidecar 代理掏觉。這兩個(gè)服務(wù)組成了一個(gè) Mesh 網(wǎng)格区端，并無(wú)縫整合在 AWS 的 EKS 中。
下圖是網(wǎng)格內(nèi)部的邏輯視圖澳腹，展示了如何利用 App Mesh 進(jìn)行智能路由织盼。Forecast service 作為調(diào)用者被定義為虛擬節(jié)點(diǎn)，Data service 作為虛擬服務(wù)酱塔，掛載著虛擬路由悔政，內(nèi)部根據(jù)需要可以設(shè)定若干路由規(guī)則。用 App Mesh 實(shí)現(xiàn)一個(gè)金絲雀發(fā)布的過(guò)程非常簡(jiǎn)單：假設(shè)在 Data service 的新版本（V2）發(fā)布前延旧，流量都被指向 V1 版本；此時(shí)我們?cè)?App Mesh 里配置好一個(gè)新的路由規(guī)則槽地，將 10%的流量指向新的 V2 版本迁沫；只需要將新的規(guī)則通過(guò) kubectl apply -f new-rule.yaml 應(yīng)用到集群中，金絲雀發(fā)布就可以完成捌蚊，且無(wú)縫切換集畅，對(duì)用戶(hù)透明。
在后續(xù)的工作中缅糟，我們會(huì)先驗(yàn)證 App Mesh 的性能和可靠性挺智，然后逐漸的將更多的流量控制（如超時(shí)重試、熔斷等）功能添加進(jìn)來(lái)窗宦，并總結(jié)出一整套可行的實(shí)施方案赦颇，供大家參考。也歡迎對(duì) Service Mesh 感興趣的同學(xué)加入到我們的團(tuán)隊(duì)中赴涵，一起學(xué)習(xí)媒怯，共同進(jìn)步。
總結(jié)
解耦是軟件開(kāi)發(fā)中永恒的主題髓窜，開(kāi)發(fā)人員對(duì)消除重復(fù)的偏執(zhí)是推動(dòng)軟件扇苞、以及架構(gòu)模式演進(jìn)的主要?jiǎng)恿ζ鄣睢６?Service Mesh 的核心價(jià)值就是將服務(wù)通信功能從業(yè)務(wù)邏輯中解耦，并下沉為基礎(chǔ)設(shè)施鳖敷，由控制平面統(tǒng)一管理脖苏。有人將 Service Mesh、Kubernetes 和 Serverless 技術(shù)稱(chēng)為云原生應(yīng)用開(kāi)發(fā)的三駕馬車(chē)定踱。Kubernetes 是云應(yīng)用實(shí)際意義上的操作系統(tǒng)棍潘；Service Mesh 將服務(wù)通信功能剝離，實(shí)現(xiàn)了與業(yè)務(wù)的解耦屋吨；Serverless 讓你不用關(guān)心應(yīng)用的服務(wù)器蜒谤。這三項(xiàng)技術(shù)讓我們有能力實(shí)現(xiàn)應(yīng)用開(kāi)發(fā)的終極目標(biāo)，那就是：只關(guān)注業(yè)務(wù)本身至扰。而它們鳍徽，也會(huì)引領(lǐng)我們通向未來(lái)云原生應(yīng)用的詩(shī)和遠(yuǎn)方。
