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

問(wèn)題提出：

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

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

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

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

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

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

然而皱埠，事情似乎沒(méi)有那么簡(jiǎn)單肮帐。我們?cè)趯?shí)踐中發(fā)現(xiàn)，還是有一些需求漱逸，如果用類似ESB的機(jī)制泪姨，可能更容易滿足。

沒(méi)錯(cuò)饰抒，但是一個(gè)問(wèn)題來(lái)了肮砾，原來(lái)SOA架構(gòu)中推行的那些東西：ESB、BPEL袋坑、CEP仗处，Composite service 這些都沒(méi)有用？或者是不是有替代者枣宫？

比如婆誓，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 保證請(qǐng)求可以在這些拓?fù)渲锌煽康卮┧蟆Ｔ趯?shí)際應(yīng)用當(dāng)中蜕提，Service

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

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

圖中應(yīng)用作為服務(wù)的發(fā)起方凛膏，只需要用最簡(jiǎn)單的方式將請(qǐng)求發(fā)送給本地的服務(wù)網(wǎng)格代理杨名，然后網(wǎng)格代理會(huì)進(jìn)行后續(xù)的操作，如服務(wù)發(fā)現(xiàn)译柏，負(fù)載均衡镣煮，最后將請(qǐng)求轉(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)勢(shì)，將所有的服務(wù)”架”在網(wǎng)格之上

原理

Service

Mesh 基本原理

如果用一句話來(lái)解釋什么是 Service Mesh寒波，可以將它比作是應(yīng)用程序或者說(shuō)微服務(wù)間的 TCP/IP乘盼，負(fù)責(zé)服務(wù)之間的網(wǎng)絡(luò)調(diào)用、限流俄烁、熔斷和監(jiān)控绸栅。對(duì)于編寫應(yīng)用程序來(lái)說(shuō)一般無(wú)須關(guān)心 TCP/IP 這一層（比如通過(guò) HTTP 協(xié)議的 RESTful 應(yīng)用），同樣使用 Service Mesh 也就無(wú)須關(guān)系服務(wù)之間的那些原來(lái)是通過(guò)應(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)和斷路器的軟件包/庫(kù)风纠，Twitter’s Finagle和 Facebook’s

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

出現(xiàn)了專門用于服務(wù)發(fā)現(xiàn)和斷路器的開(kāi)源軟件牢贸，如：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)用程序無(wú)感知潜索；

[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í)逃魄，你如何來(lái)調(diào)試某個(gè)服務(wù)？如何在不影響所有應(yīng)用程序的情況下添加跟蹤或日志功能澜搅？你知道發(fā)布其中一個(gè)服務(wù)的新版本對(duì)上下游服務(wù)的性能或質(zhì)量有何影響嗎伍俘？

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

3. 方案

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

3.1 Istio 介紹

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

Google Cloud首席技術(shù)官UrsH?lzle表示：“我的期望是宴咧，90％的Kubernetes用戶在兩年后使用Istio。它與Kubernetes所提供的非常吻合径缅，幾乎感覺(jué)就像Kubernetes的下一次迭代掺栅。這是由同一個(gè)團(tuán)隊(duì)完成的，兩者合作得很好纳猪。Istio剛剛1.0氧卧。到目前為止，大家對(duì)它還比較陌生氏堤。今天它的用量非常少沙绝，因?yàn)橹钡奖局芩派a(chǎn)就緒。”H?lzle還說(shuō)了這么一句話：“可以說(shuō)你從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í)何地遷移∩栏纾”“你想什么時(shí)候遷移剪廉，選擇哪個(gè)供應(yīng)商，都可以炕檩。我們希望許多公司能夠?qū)⑵渥鳛樵朴?jì)算之旅的核心斗蒋，使云計(jì)算之路更加順暢〉阎剩”“一旦人們熟悉了Kubernetes和Istio的管理和編排方式泉沾，云就不會(huì)太可怕了。

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

無(wú)外乎，找個(gè)Spring Cloud或者Dubbo的成熟框架肩杈，直接搞定服務(wù)注冊(cè)柴我，服務(wù)發(fā)現(xiàn)，負(fù)載均衡扩然，熔斷等基礎(chǔ)功能艘儒。然后自己開(kāi)發(fā)服務(wù)路由等高級(jí)功能，接入Zipkin等Apm做全鏈路監(jiān)控夫偶，自己做加密界睁、認(rèn)證、授權(quán)兵拢。想辦法搞定灰度方案翻斟，用Redis等實(shí)現(xiàn)限速、配額说铃。 諸如此類访惜，一大堆的事情敞斋， 都需要自己做，無(wú)論是找開(kāi)源項(xiàng)目還是自己操刀疾牲，最后整出一個(gè)帶有一大堆功能的應(yīng)用程序，上線部署衙解。然后給個(gè)配置說(shuō)明到運(yùn)維阳柔，告訴他說(shuō)如何需要灰度，要如何如何蚓峦，如果要限速舌剂，配置哪里哪里。

就是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ù)層無(wú)論是放在esb還是放在服務(wù)本身其實(shí)是無(wú)關(guān)緊要的，并不是說(shuō)放在esb就工作量大监憎，也并不是說(shuō)放在服務(wù)本身就工作量小纱意，所以，無(wú)論怎么樣鲸阔，核心的東西是去不掉的服務(wù)發(fā)現(xiàn)偷霉，服務(wù)注冊(cè)，服務(wù)安全褐筛，熔斷类少，監(jiān)控，AB測(cè)試渔扎，負(fù)載均衡瞒滴。。

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

這里就有一個(gè)很嚴(yán)肅的問(wèn)題， 給每個(gè)業(yè)務(wù)程序的開(kāi)發(fā)人員: 你到底想往你的業(yè)務(wù)程序里面塞多少管理和運(yùn)維的功能? 就算你hold的住技術(shù)和時(shí)間酬凳，你有能力一個(gè)一個(gè)的滿足各種運(yùn)維和管理的需求嗎惠况？當(dāng)你發(fā)現(xiàn)你開(kāi)始疲于響應(yīng)各種非功能性的需求時(shí)，就該開(kāi)始反省了: 我們開(kāi)發(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)開(kāi)發(fā)框架之處， 就在于不僅僅帶來(lái)了遠(yuǎn)超這些框架所能提供的功能呐粘， 而且也不需要應(yīng)用程序?yàn)榇俗龃罅康母膭?dòng)满俗， 開(kāi)發(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 (或者說(shuō)數(shù)據(jù)面板)扮演的角色是底層干活的民工，而該讓這些民工如何工作谤辜，由包工頭控制面板來(lái)負(fù)責(zé)完成蓄坏。

在Istio的架構(gòu)中，這兩個(gè)模塊的分工非常的清晰丑念，體現(xiàn)在架構(gòu)上也是經(jīng)緯分明： Mixer涡戳，Pilot和Auth這三個(gè)模塊都是Go語(yǔ)言開(kāi)發(fā)，代碼托管在Github上脯倚，三個(gè)倉(cāng)庫(kù)分別是 Istio/mixer, Istio/pilot/auth渔彰。而Envoy來(lái)自Lyft，編程語(yǔ)言是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核心的控制面板拆分開(kāi)淤堵。從而使得Istio可以借助成熟的Envoy快速推出產(chǎn)品，未來(lái)如果有更好的Service Mesh方案也方便集成顷扩。

Pilot

流量管理

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

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

對(duì)這段話的理解, 可以看下圖：假定我們?cè)蟹?wù)B雕擂，部署在Pod1/2/3上，現(xiàn)在我們部署一個(gè)新版本在Pod4在贱勃，希望實(shí)現(xiàn)切5%的流量到新版本井赌。

如果以基礎(chǔ)設(shè)施為基礎(chǔ)實(shí)現(xiàn)上述5%的流量切分，則需要通過(guò)某些手段將流量切5%到Pod4這個(gè)特定的部署單位贵扰，實(shí)施時(shí)就必須和ServiceB的具體部署還有ServiceA訪問(wèn)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)上述的流量拆分非常簡(jiǎn)單. 假定原版本為1.0纹坐，新版本為2.0，只要通過(guò)Polit 給Envoy發(fā)送一個(gè)規(guī)則：2.0版本5%流量舞丛，剩下的給1.0耘子。

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

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

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

Pilot的功能概述

我們?cè)谇懊嬗袕?qiáng)調(diào)說(shuō)捍歪，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í)通過(guò)Pilot進(jìn)行編程。

每個(gè)Envoy實(shí)例根據(jù)其從Pilot獲得的信息以及其負(fù)載均衡池中的其他實(shí)例的定期健康檢查來(lái)維護(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以及未來(lái)可能出現(xiàn)的第三方管理界面

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

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

Model和Platform Adapter，我們?cè)敿?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提供以下重要功能：

請(qǐng)求路由

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

故障處理

故障注入

規(guī)則配置

Mixer

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

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

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

我們的系統(tǒng)通常會(huì)基于大量的基礎(chǔ)設(shè)施而構(gòu)建蚌斩，這些基礎(chǔ)設(shè)施的后端服務(wù)為業(yè)務(wù)服務(wù)提供各種支持功能铆惑。包括訪問(wèn)控制系統(tǒng)，遙測(cè)捕獲系統(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)簡(jiǎn)單的集成魄眉，然后 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)來(lái)自服務(wù)消費(fèi)者的傳入請(qǐng)求之前驗(yàn)證一些前提條件宫屠。前提條件包括認(rèn)證列疗，黑白名單，ACL檢查等等浪蹂。

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

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

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

Mixer的適配器

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

Mixer在處理不同基礎(chǔ)設(shè)施后端的靈活性是通過(guò)使用通用插件模型實(shí)現(xiàn)的蹬挤。單個(gè)的插件被稱為適配器，它們?cè)试SMixer與不同的基礎(chǔ)設(shè)施后端連接棘幸，這些后臺(tái)可提供核心功能焰扳，例如日志，監(jiān)控误续，配額吨悍，ACL檢查等。適配器使Mixer能夠暴露一致的API蹋嵌，與使用的后端無(wú)關(guān)育瓜。在運(yùn)行時(shí)通過(guò)配置確定確切的適配器套件，并且可以輕松指向新的或定制的基礎(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的未來(lái)版本將增加細(xì)粒度的訪問(wèn)控制和審計(jì)怀喉，以使用各種訪問(wèn)控制機(jī)制（包括基于屬性和角色的訪問(wèn)控制以及授權(quán)鉤子）來(lái)控制和監(jiān)視訪問(wèn)您的服務(wù)书妻，API或資源的人員。

結(jié)論：

?不是ESB過(guò)時(shí)躬拢，而是你的集中式ESB過(guò)時(shí)了躲履，分布式ESB

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