從集中式ESB 到 分布式ESB Service Mesh

問題提出：

很多人理解ESB企業(yè)服務(wù)總線是一種集中式服務(wù)治理的架構(gòu)，服務(wù)總線實(shí)際上是一種服務(wù)治理的架構(gòu)，并不是只有集中式ESB，還有分布式ESB。分布式的服務(wù)總線已經(jīng)出來，Service Mesh未來會(huì)成為一種新的標(biāo)準(zhǔn)。

微服務(wù)是近幾年.術(shù)社群討論很多的一種軟件架構(gòu)方式，可以說是SOA的現(xiàn)代版本、時(shí)尚版本。不過這次浪潮不是由大公司倡導(dǎo)的，而是由工程師們引領(lǐng)的。比如，它采用工程師們熟悉的RESTful接口，而不是笨重的WebService，也不需要一大堆昂貴的中間件。

?第一，目前移動(dòng)APP開發(fā)越來越重要。就算是html的客戶端，也大量采用了html5技術(shù)。在這種情況下，工程師們都習(xí)慣通過RESTful接口與后端通訊，甚至他們把職位也簡單的劃分為前端工程師和后端工程師。這導(dǎo)致REST服務(wù)成了剛需。原來的軟件可以拒絕提供Web Service接口，但現(xiàn)在的則不能不提供RESTful接口。人人都用，用量很大。這為微服務(wù)化提供了天然的契機(jī)。

第二，性能也越來越重要。為什么？只要服務(wù)一慢，APP的用戶體驗(yàn)就差呀。原來的SOA體系不怎么提性能。一方面是故意不說，你想WebService各種打包解包就要消耗多少CPU周期和網(wǎng)絡(luò)帶寬，性能肯定不是優(yōu)勢。二是如果性能不好，正好買大廠商的昂貴的服務(wù)器和lincense呀。但工程師們不吃這一套。明明很簡單就可以實(shí)現(xiàn)高性能，為什么要搞那么復(fù)雜？把微服務(wù)集群化、搞搞讀寫分離不就好了嗎？

第三，替換比利舊重要。SOA很多的應(yīng)用場景都是在對(duì)已有應(yīng)用的打通，比如你買了ERP 的軟件，又買了另一家的軟件，還有以前投資定制開發(fā)的軟件。這些軟件都很貴，要像祖宗一樣供起來的，輕易不敢改動(dòng)，改動(dòng)成本很高。所以要盡量保留，要通過SOA的方式對(duì)接在一起。而搞微服務(wù)的那些人呢？他們的理念是“Design for replacement”，設(shè)計(jì)的每個(gè)微服務(wù)都要非常容易被拋棄、被替換。擁抱不斷變化的業(yè)務(wù)，快讀迭代開發(fā)。那些舊的包袱他們壓根不想搭理，天天想的是怎么替掉它們算了。

所以，看上去我們不需要ESB了。ThoughtWorks的首席科學(xué)家Matin Fowler也不贊同在微服務(wù)架構(gòu)中繼續(xù)用ESB。他的考慮是說沒有必要把一些邏輯集中在像ESB這樣的中介結(jié)構(gòu)中，這樣與系統(tǒng)盡量解耦的初衷是背離的。

然而，事情似乎沒有那么簡單。我們在實(shí)踐中發(fā)現(xiàn)，還是有一些需求，如果用類似ESB的機(jī)制，可能更容易滿足。

沒錯(cuò)，但是一個(gè)問題來了，原來SOA架構(gòu)中推行的那些東西：ESB、BPEL、CEP，Composite service 這些都沒有用？或者是不是有替代者？

比如，ESB是解決服務(wù)消費(fèi)者和服務(wù)提供者之間的點(diǎn)對(duì)點(diǎn)連接關(guān)系的。點(diǎn)對(duì)點(diǎn)連接當(dāng)然不如大家都連到一個(gè)“總線”上，這樣就會(huì)實(shí)現(xiàn)物理位置、傳輸協(xié)議等多個(gè)方面對(duì)透明。這在微服務(wù)架構(gòu)中有用嗎？

Service Mesh （分布式ESB）是下一代微服務(wù)架構(gòu)核心

?Service Mesh又譯作“服務(wù)網(wǎng)格”， 也有人翻譯為”服務(wù)嚙合層”.

Service Mesh 是一個(gè)基礎(chǔ)設(shè)施層，用于處理服務(wù)間通信。云原生應(yīng)用有著復(fù)雜的服務(wù)拓?fù)洌琒ervice Mesh 保證請求可以在這些拓?fù)渲锌煽康卮┧?。在?shí)際應(yīng)用當(dāng)中，Service

Mesh 通常是由一系列輕量級(jí)的網(wǎng)絡(luò)代理組成的，它們與應(yīng)用程序部署在一起，但應(yīng)用程序不需要知道它們的存在。

下圖展示了服務(wù)網(wǎng)格的典型邊車部署方式：

圖中應(yīng)用作為服務(wù)的發(fā)起方，只需要用最簡單的方式將請求發(fā)送給本地的服務(wù)網(wǎng)格代理，然后網(wǎng)格代理會(huì)進(jìn)行后續(xù)的操作，如服務(wù)發(fā)現(xiàn)，負(fù)載均衡，最后將請求轉(zhuǎn)發(fā)給目標(biāo)服務(wù)。

In a nutshell, a?Service Mesh?is an inter-service

communication infrastructure. With a?service mesh, A given Microservice

won't directly communicate with the other microservices. Rather

all?service-to-service communications will take places on-top of a

software component called?service mesh?(or side-car proxy).

當(dāng)有大量服務(wù)相互調(diào)用時(shí)，它們之間的服務(wù)調(diào)用關(guān)系就會(huì)形成網(wǎng)格，如下圖所示

在上圖中綠色方塊為服務(wù)，藍(lán)色方塊為邊車部署的服務(wù)網(wǎng)格，藍(lán)色線條為服務(wù)間通訊。可以看到藍(lán)色的方塊和線條組成了整個(gè)網(wǎng)格，我們將這個(gè)圖片旋轉(zhuǎn)90°，就更加明顯了：服務(wù)網(wǎng)格呈現(xiàn)出一個(gè)完整的支撐態(tài)勢，將所有的服務(wù)”架”在網(wǎng)格之上

原理

Service

Mesh 基本原理

如果用一句話來解釋什么是 Service Mesh，可以將它比作是應(yīng)用程序或者說微服務(wù)間的 TCP/IP，負(fù)責(zé)服務(wù)之間的網(wǎng)絡(luò)調(diào)用、限流、熔斷和監(jiān)控。對(duì)于編寫應(yīng)用程序來說一般無須關(guān)心 TCP/IP 這一層（比如通過 HTTP 協(xié)議的 RESTful 應(yīng)用），同樣使用 Service Mesh 也就無須關(guān)系服務(wù)之間的那些原來是通過應(yīng)用程序或者其他框架實(shí)現(xiàn)的事情，比如 Spring Cloud、OSS，現(xiàn)在只要交給 Service Mesh 就可以了。

從最原始的主機(jī)之間直接使用網(wǎng)線相連

網(wǎng)絡(luò)層的出現(xiàn)

集成到應(yīng)用程序內(nèi)部的控制流

分解到應(yīng)用程序外部的控制流

應(yīng)用程序的中集成服務(wù)發(fā)現(xiàn)和斷路器

出現(xiàn)了專門用于服務(wù)發(fā)現(xiàn)和斷路器的軟件包/庫，Twitter’s Finagle和 Facebook’s

? ? Proxygen。這時(shí)候還是集成在應(yīng)用程序內(nèi)部

出現(xiàn)了專門用于服務(wù)發(fā)現(xiàn)和斷路器的開源軟件，如：NetflixOSS ecosystem

最后作為微服務(wù)的中間層Service

? ? Mesh出現(xiàn)

Service Mesh的優(yōu)點(diǎn)

[if !supportLists]1.???[endif]應(yīng)用程序間通訊的中間層；

[if !supportLists]2.???[endif]輕量級(jí)網(wǎng)絡(luò)代理；

[if !supportLists]3.???[endif]應(yīng)用程序無感知；

[if !supportLists]4.???[endif]解耦應(yīng)用程序的重試、超時(shí)、監(jiān)控、追蹤和服務(wù)發(fā)現(xiàn)；

不妨考慮一下貴企業(yè)在微服務(wù)方面的計(jì)劃。也許貴企業(yè)打算在Kubernetes集群中運(yùn)行10個(gè)服務(wù)、50個(gè)服務(wù)、100個(gè)服務(wù)或1000個(gè)服務(wù)。那么如何以一種高效而統(tǒng)一的方式在新的微服務(wù)和容器環(huán)境中管理所有那些服務(wù)？

你知道哪個(gè)服務(wù)在跟哪個(gè)服務(wù)聯(lián)系、是否允許它們這樣？這種通信是否安全？出現(xiàn)故障時(shí)，你如何來調(diào)試某個(gè)服務(wù)？如何在不影響所有應(yīng)用程序的情況下添加跟蹤或日志功能？你知道發(fā)布其中一個(gè)服務(wù)的新版本對(duì)上下游服務(wù)的性能或質(zhì)量有何影響嗎？

Service Mesh有助于回答那些問題。作為插入在微服務(wù)和網(wǎng)絡(luò)之間的一個(gè)透明的基礎(chǔ)設(shè)施層，它為你在應(yīng)用程序的通信路徑中提供了單一點(diǎn)，以便插入服務(wù)、收集遙測數(shù)據(jù)。你無需更改應(yīng)用程序就可以做到這一點(diǎn)。

3. 方案

目前社區(qū)Service Mesh的開源解決方案有：Buoyant 公司推出的 Linkerd 和 Google、IBM等廠商牽頭的 Istio。Linkerd 更加成熟穩(wěn)定些，Istio 功能更加豐富、設(shè)計(jì)上更為強(qiáng)大，社區(qū)相對(duì)也更加強(qiáng)大一些。所以普遍認(rèn)為Istio 的前景會(huì)更好，但是畢竟還處于項(xiàng)目的早期，問題還很多。

3.1 Istio 介紹

Istio是由Google、IBM和Lyft開源的微服務(wù)管理、保護(hù)和監(jiān)控框架。Istio為希臘語，意思是”起航“。官方中文文檔地址：https://istio.doczh.cn

Google Cloud首席技術(shù)官UrsH?lzle表示：“我的期望是，90％的Kubernetes用戶在兩年后使用Istio。它與Kubernetes所提供的非常吻合，幾乎感覺就像Kubernetes的下一次迭代。這是由同一個(gè)團(tuán)隊(duì)完成的，兩者合作得很好。Istio剛剛1.0。到目前為止，大家對(duì)它還比較陌生。今天它的用量非常少，因?yàn)橹钡奖局芩派a(chǎn)就緒?！盚?lzle還說了這么一句話：“可以說你從Istio獲得的價(jià)值會(huì)大于Kubernetes。

H?lzle認(rèn)為，Istio將加速企業(yè)對(duì)公有云的采用，因?yàn)樗梢栽趦?nèi)部部署和云之間實(shí)現(xiàn)更高的同質(zhì)性：“公司可以決定將所有內(nèi)容都移到Istio，包括他們不想重寫的舊代碼，這是非常合理的——更像是包裝而不是重寫。我們相信GKE

on-prem是許多用戶深入云計(jì)算的方式。它與現(xiàn)代云思維非常融合，但它讓用戶可以選擇何時(shí)何地遷移?！薄澳阆胧裁磿r(shí)候遷移，選擇哪個(gè)供應(yīng)商，都可以。我們希望許多公司能夠?qū)⑵渥鳛樵朴?jì)算之旅的核心，使云計(jì)算之路更加順暢?！薄耙坏┤藗兪煜ち薑ubernetes和Istio的管理和編排方式，云就不會(huì)太可怕了。

不妨設(shè)想一下，在平時(shí)理解的微服務(wù)開發(fā)過程中，在沒有Istio這樣的服務(wù)網(wǎng)格的情況下，要如何開發(fā)我們的應(yīng)用程序，才可以做到前面列出的這些豐富多彩的功能? 這數(shù)以幾十記的各種特性，如何才可以加入到應(yīng)用程序?

無外乎，找個(gè)Spring Cloud或者Dubbo的成熟框架，直接搞定服務(wù)注冊，服務(wù)發(fā)現(xiàn)，負(fù)載均衡，熔斷等基礎(chǔ)功能。然后自己開發(fā)服務(wù)路由等高級(jí)功能，接入Zipkin等Apm做全鏈路監(jiān)控，自己做加密、認(rèn)證、授權(quán)。想辦法搞定灰度方案，用Redis等實(shí)現(xiàn)限速、配額。 諸如此類，一大堆的事情， 都需要自己做，無論是找開源項(xiàng)目還是自己操刀，最后整出一個(gè)帶有一大堆功能的應(yīng)用程序，上線部署。然后給個(gè)配置說明到運(yùn)維，告訴他說如何需要灰度，要如何如何，如果要限速，配置哪里哪里。

就是transformation，routing這些和business logic相關(guān)的orchastration，放到服務(wù)自身去做。這只是去掉了ESB的業(yè)務(wù)層的轉(zhuǎn)換和路由，而而網(wǎng)絡(luò)協(xié)議的轉(zhuǎn)換調(diào)用適配，是去不掉的，而網(wǎng)絡(luò)協(xié)議的轉(zhuǎn)換調(diào)用適配，是去不掉的。而業(yè)務(wù)層無論是放在esb還是放在服務(wù)本身其實(shí)是無關(guān)緊要的，并不是說放在esb就工作量大，也并不是說放在服務(wù)本身就工作量小，所以，無論怎么樣，核心的東西是去不掉的服務(wù)發(fā)現(xiàn)，服務(wù)注冊，服務(wù)安全，熔斷，監(jiān)控，AB測試，負(fù)載均衡。。

這些工作，相信做微服務(wù)落地的公司，基本都跑不掉，需求是現(xiàn)實(shí)存在的，無非能否實(shí)現(xiàn)，以及實(shí)現(xiàn)多少的問題，但是毫無疑問的是，要做到這些，絕對(duì)不是一件容易的事情。

這里就有一個(gè)很嚴(yán)肅的問題， 給每個(gè)業(yè)務(wù)程序的開發(fā)人員: 你到底想往你的業(yè)務(wù)程序里面塞多少管理和運(yùn)維的功能? 就算你hold的住技術(shù)和時(shí)間，你有能力一個(gè)一個(gè)的滿足各種運(yùn)維和管理的需求嗎？當(dāng)你發(fā)現(xiàn)你開始疲于響應(yīng)各種非功能性的需求時(shí)，就該開始反省了: 我們開發(fā)的是業(yè)務(wù)程序，它的核心價(jià)值在業(yè)務(wù)邏輯的處理和實(shí)現(xiàn)，將如此之多的時(shí)間精力花費(fèi)在這些非業(yè)務(wù)功能上，這真的合理嗎? 而且即使是在實(shí)現(xiàn)層面，微服務(wù)實(shí)施時(shí)，最重要的是如何劃分微服務(wù)，如何制定接口協(xié)議，你該如何分配你有限的時(shí)間和資源？

Istio 超越 spring cloud和dubbo 等傳統(tǒng)開發(fā)框架之處， 就在于不僅僅帶來了遠(yuǎn)超這些框架所能提供的功能， 而且也不需要應(yīng)用程序?yàn)榇俗龃罅康母膭?dòng)， 開發(fā)人員也不必為上面的功能實(shí)現(xiàn)進(jìn)行大量的知識(shí)儲(chǔ)備。

Istio架構(gòu)圖：

Istio架構(gòu)分為控制層和數(shù)據(jù)層。

?Envoy，在Istio中扮演的就是數(shù)據(jù)面板，而其他我們下面將要陸續(xù)介紹的Mixer、Pilot和Auth屬于控制面板。上面我給出了一個(gè)類比：Istio中Envoy (或者說數(shù)據(jù)面板)扮演的角色是底層干活的民工，而該讓這些民工如何工作，由包工頭控制面板來負(fù)責(zé)完成。

在Istio的架構(gòu)中，這兩個(gè)模塊的分工非常的清晰，體現(xiàn)在架構(gòu)上也是經(jīng)緯分明： Mixer，Pilot和Auth這三個(gè)模塊都是Go語言開發(fā)，代碼托管在Github上，三個(gè)倉庫分別是 Istio/mixer, Istio/pilot/auth。而Envoy來自Lyft，編程語言是c++ 11，代碼托管在Github但不是Istio下。從團(tuán)隊(duì)分工看，Google和IBM關(guān)注于控制面板中的Mixer，Pilot和Auth，而Lyft繼續(xù)專注于Envoy。

Istio的這個(gè)架構(gòu)設(shè)計(jì)，將底層Service Mesh的具體實(shí)現(xiàn)，和Istio核心的控制面板拆分開。從而使得Istio可以借助成熟的Envoy快速推出產(chǎn)品，未來如果有更好的Service Mesh方案也方便集成。

Pilot

流量管理

Istio最核心的功能是流量管理，前面我們看到的數(shù)據(jù)面板，由Envoy組成的服務(wù)網(wǎng)格，將整個(gè)服務(wù)間通訊和入口/出口請求都承載于其上。

使用Istio的流量管理模型，本質(zhì)上將流量和基礎(chǔ)設(shè)施擴(kuò)展解耦，讓運(yùn)維人員通過Pilot指定它們希望流量遵循什么規(guī)則，而不是哪些特定的pod/VM應(yīng)該接收流量。

對(duì)這段話的理解, 可以看下圖：假定我們原有服務(wù)B，部署在Pod1/2/3上，現(xiàn)在我們部署一個(gè)新版本在Pod4在，希望實(shí)現(xiàn)切5%的流量到新版本。

如果以基礎(chǔ)設(shè)施為基礎(chǔ)實(shí)現(xiàn)上述5%的流量切分，則需要通過某些手段將流量切5%到Pod4這個(gè)特定的部署單位，實(shí)施時(shí)就必須和ServiceB的具體部署還有ServiceA訪問ServiceB的特定方式緊密聯(lián)系在一起. 比如如果兩個(gè)服務(wù)之間是用Nginx做反向代理，則需要增加Pod4的IP作為Upstream，并調(diào)整Pod1/2/3/4的權(quán)重以實(shí)現(xiàn)流量切分。

如果使用Istio的流量管理功能, 由于Envoy組成的服務(wù)網(wǎng)絡(luò)完全在Istio的控制之下,因此要實(shí)現(xiàn)上述的流量拆分非常簡單. 假定原版本為1.0，新版本為2.0，只要通過Polit 給Envoy發(fā)送一個(gè)規(guī)則：2.0版本5%流量，剩下的給1.0。

這種情況下，我們無需關(guān)注2.0版本的部署，也無需改動(dòng)任何技術(shù)設(shè)置, 更不需要在業(yè)務(wù)代碼中為此提供任何配置支持和代碼修改。一切由 Pilot 和智能Envoy代理搞定。

我們還可以玩的更炫一點(diǎn), 比如根據(jù)請求的內(nèi)容來源將流量發(fā)送到特定版本

后面我們會(huì)介紹如何從請求中提取出User-Agent這樣的屬性來配合規(guī)則進(jìn)行流量控制。

Pilot的功能概述

我們在前面有強(qiáng)調(diào)說，Envoy在其中扮演的負(fù)責(zé)搬磚的民工角色，而指揮Envoy工作的民工頭就是Pilot模塊。

官方文檔中對(duì)Pilot的功能描述：

Pilot負(fù)責(zé)收集和驗(yàn)證配置并將其傳播到各種Istio組件。它從Mixer和Envoy中抽取環(huán)境特定的實(shí)現(xiàn)細(xì)節(jié)，為他們提供獨(dú)立于底層平臺(tái)的用戶服務(wù)的抽象表示。此外，流量管理規(guī)則（即通用4層規(guī)則和7層HTTP/gRPC路由規(guī)則）可以在運(yùn)行時(shí)通過Pilot進(jìn)行編程。

每個(gè)Envoy實(shí)例根據(jù)其從Pilot獲得的信息以及其負(fù)載均衡池中的其他實(shí)例的定期健康檢查來維護(hù)負(fù)載均衡信息，從而允許其在目標(biāo)實(shí)例之間智能分配流量，同時(shí)遵循其指定的路由規(guī)則。

Pilot負(fù)責(zé)在Istio服務(wù)網(wǎng)格中部署的Envoy實(shí)例的生命周期。

Pilot的架構(gòu)

下圖是Pilot的架構(gòu)圖：

?

Envoy API負(fù)責(zé)和Envoy的通訊, 主要是發(fā)送服務(wù)發(fā)現(xiàn)信息和流量控制規(guī)則給Envoy

Envoy提供服務(wù)發(fā)現(xiàn)，負(fù)載均衡池和路由表的動(dòng)態(tài)更新的API。這些API將Istio和Envoy的實(shí)現(xiàn)解耦。(另外，也使得Linkerd之類的其他服務(wù)網(wǎng)絡(luò)實(shí)現(xiàn)得以平滑接管Envoy)

Polit定了一個(gè)抽象模型，以從特定平臺(tái)細(xì)節(jié)中解耦，為跨平臺(tái)提供基礎(chǔ)

Platform

? ? Adapter則是這個(gè)抽象模型的現(xiàn)實(shí)實(shí)現(xiàn)版本, 用于對(duì)接外部的不同平臺(tái)

最后是 Rules

? ? API，提供接口給外部調(diào)用以管理Pilot，包括命令行工具Istioctl以及未來可能出現(xiàn)的第三方管理界面

服務(wù)規(guī)范和實(shí)現(xiàn)

Pilot架構(gòu)中, 最重要的是Abstract

Model和Platform Adapter，我們詳細(xì)介紹。

Abstract

? ? Model：是對(duì)服務(wù)網(wǎng)格中”服務(wù)”的規(guī)范表示, 即定義在istio中什么是服務(wù)，這個(gè)規(guī)范獨(dú)立于底層平臺(tái)。

Platform Adapter：這里有各種平臺(tái)的實(shí)現(xiàn)，目前主要是Kubernetes，另外最新的0.2版本的代碼中出現(xiàn)了Consul和Eureka。

?Pilot功能

基于上述的架構(gòu)設(shè)計(jì)，Pilot提供以下重要功能：

請求路由

服務(wù)發(fā)現(xiàn)和負(fù)載均衡

故障處理

故障注入

規(guī)則配置

Mixer

Mixer翻譯成中文是混音器, 下面是它的圖標(biāo)：

功能概括：Mixer負(fù)責(zé)在服務(wù)網(wǎng)格上執(zhí)行訪問控制和使用策略，并收集Envoy代理和其他服務(wù)的遙測數(shù)據(jù)。

Mixer的設(shè)計(jì)背景

我們的系統(tǒng)通常會(huì)基于大量的基礎(chǔ)設(shè)施而構(gòu)建，這些基礎(chǔ)設(shè)施的后端服務(wù)為業(yè)務(wù)服務(wù)提供各種支持功能。包括訪問控制系統(tǒng)，遙測捕獲系統(tǒng)，配額執(zhí)行系統(tǒng)，計(jì)費(fèi)系統(tǒng)等。在傳統(tǒng)設(shè)計(jì)中, 服務(wù)直接與這些后端系統(tǒng)集成，容易產(chǎn)生硬耦合。在Istio中，為了避免應(yīng)用程序的微服務(wù)和基礎(chǔ)設(shè)施的后端服務(wù)之間的耦合，提供了 Mixer 作為兩者的通用中介層：

Mixer 設(shè)計(jì)將策略決策從應(yīng)用層移出并用配置替代，并在運(yùn)維人員控制下。應(yīng)用程序代碼不再將應(yīng)用程序代碼與特定后端集成在一起，而是與Mixer進(jìn)行相當(dāng)簡單的集成，然后 Mixer 負(fù)責(zé)與后端系統(tǒng)連接。

特別提醒: Mixer不是為了在基礎(chǔ)設(shè)施后端之上創(chuàng)建一個(gè)抽象層或者可移植性層。也不是試圖定義一個(gè)通用的Logging API，通用的Metric API，通用的計(jì)費(fèi)API等等。

Mixer的設(shè)計(jì)目標(biāo)是減少業(yè)務(wù)系統(tǒng)的復(fù)雜性，將策略邏輯從業(yè)務(wù)的微服務(wù)的代碼轉(zhuǎn)移到Mixer中, 并且改為讓運(yùn)維人員控制。

Mixer的功能

Mixer 提供三個(gè)核心功能：

前提條件檢查。允許服務(wù)在響應(yīng)來自服務(wù)消費(fèi)者的傳入請求之前驗(yàn)證一些前提條件。前提條件包括認(rèn)證，黑白名單，ACL檢查等等。

配額管理。使服務(wù)能夠在多個(gè)維度上分配和釋放配額。典型例子如限速。

遙測報(bào)告。使服務(wù)能夠上報(bào)日志和監(jiān)控。

在Istio內(nèi)，Envoy重度依賴Mixer。

Mixer的適配器

Mixer是高度模塊化和可擴(kuò)展的組件。其中一個(gè)關(guān)鍵功能是抽象出不同策略和遙測后端系統(tǒng)的細(xì)節(jié)，允許Envoy和基于Istio的服務(wù)與這些后端無關(guān)，從而保持他們的可移植。

Mixer在處理不同基礎(chǔ)設(shè)施后端的靈活性是通過使用通用插件模型實(shí)現(xiàn)的。單個(gè)的插件被稱為適配器，它們允許Mixer與不同的基礎(chǔ)設(shè)施后端連接，這些后臺(tái)可提供核心功能，例如日志，監(jiān)控，配額，ACL檢查等。適配器使Mixer能夠暴露一致的API，與使用的后端無關(guān)。在運(yùn)行時(shí)通過配置確定確切的適配器套件，并且可以輕松指向新的或定制的基礎(chǔ)設(shè)施后端。

Istio-Auth

Istio-Auth提供強(qiáng)大的服務(wù)到服務(wù)和終端用戶認(rèn)證，使用交互TLS，內(nèi)置身份和憑據(jù)管理。它可用于升級(jí)服務(wù)網(wǎng)格中的未加密流量，并為運(yùn)維人員提供基于服務(wù)身份而不是網(wǎng)絡(luò)控制實(shí)施策略的能力。

Istio的未來版本將增加細(xì)粒度的訪問控制和審計(jì)，以使用各種訪問控制機(jī)制（包括基于屬性和角色的訪問控制以及授權(quán)鉤子）來控制和監(jiān)視訪問您的服務(wù)，API或資源的人員。

結(jié)論：

?不是ESB過時(shí)，而是你的集中式ESB過時(shí)了，分布式ESB

Service Mesh 開啟一個(gè)微服務(wù)的一個(gè)新的架構(gòu)實(shí)現(xiàn)模式。Istio 可以充當(dāng)一個(gè)ESB的地位。Istio 超越 spring cloud和dubbo 等傳統(tǒng)開發(fā)框架之處，就在于不僅僅帶來了遠(yuǎn)超這些框架所能提供的功能，而且也不需要應(yīng)用程序?yàn)榇俗龃罅康母膭?dòng)，開發(fā)人員也不必為上面的功能實(shí)現(xiàn)進(jìn)行大量的知識(shí)儲(chǔ)備。