微服務(wù)之后什么最火？毫無(wú)疑問(wèn)ServiceMesh。 目前各個(gè)大廠都在Mesh化，Mesh的前身是Side Car模式，隨著互聯(lián)網(wǎng)時(shí)代/移動(dòng)互聯(lián)網(wǎng)時(shí)代以及未來(lái)IOT時(shí)代發(fā)展，互聯(lián)網(wǎng)架構(gòu)在數(shù)據(jù)量，高并發(fā)，高可用場(chǎng)景會(huì)面臨幾何倍數(shù)的增長(zhǎng)，同時(shí)對(duì)于我們的系統(tǒng)也是幾何倍數(shù)的挑戰(zhàn)，我們需要在這個(gè)時(shí)間點(diǎn)到來(lái)之前將我們的系統(tǒng)提前進(jìn)化，于是CNNF，Service Mesh成為了服務(wù)化的未來(lái)。

系統(tǒng)服務(wù)化之后，服務(wù)間通信需要關(guān)注什么：

服務(wù)發(fā)現(xiàn)

負(fù)載均衡

路由

流控

通信可靠性

彈性

安全

監(jiān)控，日志

API 網(wǎng)關(guān)

API網(wǎng)關(guān)可以集中式的管理這些功能，但是會(huì)出現(xiàn)單點(diǎn)故障，并且實(shí)現(xiàn)起來(lái)網(wǎng)關(guān)會(huì)變得越來(lái)越臃腫。 并且網(wǎng)關(guān)是一個(gè)集中式的處理，Service Mesh是網(wǎng)絡(luò)通信基礎(chǔ)設(shè)施，可以將網(wǎng)絡(luò)功能從代碼中剝離出來(lái)。 通過(guò)Service Mesh不用在服務(wù)代碼中實(shí)現(xiàn)用于可靠性通信的模式或斷路，超時(shí)等控制。

Service Mesh是一個(gè)專門的軟件基礎(chǔ)設(shè)施層，和主進(jìn)程獨(dú)立，通過(guò)（HTTP，GRPC）進(jìn)行代理通信，用于控制和監(jiān)控微服務(wù)應(yīng)用程序中服務(wù)到服務(wù)的內(nèi)部通信，讓服務(wù)到服務(wù)通信變得快速，安全，可靠。

通常分為：數(shù)據(jù)層和控制層。

服務(wù)開發(fā)者不會(huì)意識(shí)到Service Mesh的存在，平臺(tái)工程師則通過(guò)這套新的工具，以確?？煽啃裕踩院涂梢娦?。

我們可以將Service Mesh看成路由器和交換機(jī)互聯(lián)的設(shè)備組成的（第七層）網(wǎng)絡(luò)。

通常我們采用代理方式，攔截所有出入的流量來(lái)進(jìn)行請(qǐng)求的安全，可靠，及時(shí)的處理。

Service Mesh架構(gòu)中代理使用的是邊車模式實(shí)現(xiàn)的。

邊車模式：是附屬在主應(yīng)用程序，提供平臺(tái)功能用以補(bǔ)充該主應(yīng)用程序功能，比如路由，負(fù)載均衡，彈性，深度探測(cè)和訪問(wèn)控制。

Service Mesh不僅擴(kuò)展了主應(yīng)用的能力，還要監(jiān)控和保護(hù)應(yīng)用程序，是插在微服務(wù)和網(wǎng)絡(luò)之間的一個(gè)透明的基礎(chǔ)設(shè)施層，以便對(duì)服務(wù)進(jìn)行插入，收集檢測(cè)數(shù)據(jù)，而無(wú)需修改應(yīng)用程序。

以Linkerd為例

當(dāng)一個(gè)請(qǐng)求經(jīng)過(guò)Linkerd時(shí)，會(huì)發(fā)生以下事件。

Linkerd根據(jù)動(dòng)態(tài)路由規(guī)則確定請(qǐng)求是發(fā)送給哪個(gè)服務(wù)的，比如是發(fā)送給生產(chǎn)環(huán)境的還是staging環(huán)境的服務(wù)？ 是發(fā)給本地?cái)?shù)據(jù)中心的還是云端數(shù)據(jù)中心的服務(wù)？ 是發(fā)送給新版的還是舊版的服務(wù)？這些路由規(guī)則是可以動(dòng)態(tài)配置的，可以應(yīng)用在全局的流量上，也可以應(yīng)用在部分流量上。

在確定了請(qǐng)求的目標(biāo)服務(wù)后，Linkerd從服務(wù)發(fā)現(xiàn)端點(diǎn)獲取相應(yīng)的服務(wù)實(shí)例。如果服務(wù)實(shí)例信息出現(xiàn)了偏差，Linkerd需要決定從哪個(gè)信息的來(lái)源更值得信任。

Linkerd根據(jù)某些因子，比如最近處理請(qǐng)求的延遲情況，選擇更優(yōu)秀的實(shí)例。

Linkerd向選中的實(shí)例發(fā)送請(qǐng)求，并把延遲情況和響應(yīng)信息記錄下來(lái)。

如果選中的實(shí)例發(fā)生宕機(jī)，無(wú)法響應(yīng)請(qǐng)求，Linkerd會(huì)把請(qǐng)求轉(zhuǎn)發(fā)給其他實(shí)例，當(dāng)然服務(wù)實(shí)例需要做成冪等的。

如果一個(gè)實(shí)例持續(xù)返回錯(cuò)誤，Linkerd就會(huì)將其從負(fù)載均衡池移除，并在稍后定時(shí)重試，重試成功重新放入負(fù)載均衡池。

如果請(qǐng)求超時(shí)，則不進(jìn)行重試，進(jìn)行記錄，最終一致性。

Linkerd以度量指標(biāo)和分布式日志的方式記錄上述行為，然后將度量指標(biāo)發(fā)送中心度量指標(biāo)系統(tǒng)。

Service Mesh

大規(guī)模分布式系統(tǒng)又一個(gè)共性：局部故障累積到一定程度會(huì)造成系統(tǒng)層面的災(zāi)難。

Service Mesh作用是在底層系統(tǒng)的負(fù)載達(dá)到上限之前，通過(guò)流量分散和快速實(shí)效來(lái)防止這些故障破壞整個(gè)系統(tǒng)。

云原生應(yīng)用的前身：應(yīng)用層被拆分成多個(gè)服務(wù)，也就是微服務(wù)，這樣的系統(tǒng)需要一個(gè)通信層，以客戶端SDK的方式存在。

云原生應(yīng)用在之前微服務(wù)模型中加入了兩個(gè)額外的元素：容器和服務(wù)編排層。容器提供了資源隔離和依賴管理，服務(wù)編排層對(duì)底層的硬件進(jìn)行抽象池化。

邊車SDK，容器，服務(wù)編排框架讓應(yīng)用程序在云環(huán)境中具備了伸縮能力和處理故障的能力。但隨著服務(wù)實(shí)例的數(shù)量增長(zhǎng)，服務(wù)編排需要無(wú)時(shí)無(wú)刻的調(diào)度實(shí)例，請(qǐng)求在服務(wù)拓?fù)渲g穿梭的軌跡變得越來(lái)越復(fù)雜，再加上不用語(yǔ)言開發(fā)的服務(wù)實(shí)例很多，之前的“胖客戶端”方式行不通了。

于是催生了服務(wù)間通信層的出現(xiàn)，這個(gè)層不會(huì)與應(yīng)用程序的代碼耦合，又能捕獲底層環(huán)境的高度動(dòng)態(tài)的特點(diǎn)，就是Service Mesh。