微服務(wù)架構(gòu)的演進(jìn)

作為一種架構(gòu)模式，微服務(wù)將復(fù)雜系統(tǒng)切分為數(shù)十乃至上百個(gè)小服務(wù)，每個(gè)服務(wù)負(fù)責(zé)實(shí)現(xiàn)一個(gè)獨(dú)立的業(yè)務(wù)邏輯。這些小服務(wù)易于被小型的軟件工程師團(tuán)隊(duì)所理解和修改，并帶來了語言和框架選擇靈活性，縮短應(yīng)用開發(fā)上線時(shí)間，可根據(jù)不同的工作負(fù)載和資源要求對(duì)服務(wù)進(jìn)行獨(dú)立縮擴(kuò)容等優(yōu)勢(shì)。

另一方面，當(dāng)應(yīng)用被拆分為多個(gè)微服務(wù)進(jìn)程后，進(jìn)程內(nèi)的方法調(diào)用變成了了進(jìn)程間的遠(yuǎn)程調(diào)用。引入了對(duì)大量服務(wù)的連接、管理和監(jiān)控的復(fù)雜性。

該變化帶來了分布式系統(tǒng)的一系列問題，例如：

如何找到服務(wù)的提供方？

如何保證遠(yuǎn)程方法調(diào)用的可靠性？

如何保證服務(wù)調(diào)用的安全性？

如何降低服務(wù)調(diào)用的延遲？

如何進(jìn)行端到端的調(diào)試？

另外生產(chǎn)部署中的微服務(wù)實(shí)例也增加了運(yùn)維的難度，例如：

如何收集大量微服務(wù)的性能指標(biāo)已進(jìn)行分析？

如何在不影響上線業(yè)務(wù)的情況下對(duì)微服務(wù)進(jìn)行升級(jí)？

如何測(cè)試一個(gè)微服務(wù)集群部署的容錯(cuò)和穩(wěn)定性？

這些問題涉及到成百上千個(gè)服務(wù)的通信、管理、部署、版本、安全、故障轉(zhuǎn)移、策略執(zhí)行、遙測(cè)和監(jiān)控等，要解決這些微服務(wù)架構(gòu)引入的問題并非易事。

讓我們來回顧一下微服務(wù)架構(gòu)的發(fā)展過程。在出現(xiàn)服務(wù)網(wǎng)格之前，我們最開始在微服務(wù)應(yīng)用程序內(nèi)理服務(wù)之間的通訊邏輯，包括服務(wù)發(fā)現(xiàn)、熔斷、重試、超時(shí)、加密、限流等邏輯。

在一個(gè)分布式系統(tǒng)中，這部分邏輯比較復(fù)雜，為了為微服務(wù)應(yīng)用提供一個(gè)穩(wěn)定、可靠的基礎(chǔ)設(shè)施層，避免大家重復(fù)造輪子，并減少犯錯(cuò)的可能，一般會(huì)通過對(duì)這部分負(fù)責(zé)服務(wù)通訊的邏輯進(jìn)行抽象和歸納，形成一個(gè)代碼庫供各個(gè)微服務(wù)應(yīng)用程序使用，如下圖所示：

公共的代碼庫減少了應(yīng)用程序的開發(fā)和維護(hù)工作量，降低了由應(yīng)用開發(fā)人員單獨(dú)實(shí)現(xiàn)微服務(wù)通訊邏輯出現(xiàn)錯(cuò)誤的機(jī)率，但還是存在下述問題：

微服務(wù)通訊邏輯對(duì)應(yīng)用開發(fā)人員并不透明，應(yīng)用開發(fā)人員需要理解并正確使用代碼庫，不能將其全部精力聚焦于業(yè)務(wù)邏輯。

需要針對(duì)不同的語言/框架開發(fā)不同的代碼庫，反過來會(huì)影響微服務(wù)應(yīng)用開發(fā)語言 和框架的選擇，影響技術(shù)選擇的靈活性。

隨著時(shí)間的變化，代碼庫會(huì)存在不同的版本，不同版本代碼庫的兼容性和大量運(yùn)行環(huán)境中微服務(wù)的升級(jí)將成為一個(gè)難題。

可以將微服務(wù)之間的通訊基礎(chǔ)設(shè)施層和TCP/IP協(xié)議棧進(jìn)行類比。TCP/IP協(xié)議棧為操作系統(tǒng)中的所有應(yīng)用提供基礎(chǔ)通信服務(wù)，但TCP/IP協(xié)議棧和應(yīng)用程序之間并沒有緊密的耦合關(guān)系，應(yīng)用只需要使用TCP/IP協(xié)議提供的底層通訊功能，并不關(guān)心TCP/IP協(xié)議的實(shí)現(xiàn)，如IP如何進(jìn)行路由，TCP如何創(chuàng)建鏈接等。

同樣地，微服務(wù)應(yīng)用也不應(yīng)該需要關(guān)注服務(wù)發(fā)現(xiàn)，Load balancing、Retries、Circuit Breaker等微服務(wù)之間通信的底層細(xì)節(jié)。如果將為微服務(wù)提供通信服務(wù)的這部分邏輯從應(yīng)用程序進(jìn)程中抽取出來，作為一個(gè)單獨(dú)的進(jìn)程進(jìn)行部署，并將其作為服務(wù)間的通信代理，可以得到如下圖所示的架構(gòu)：

因?yàn)橥ㄓ嵈磉M(jìn)程伴隨應(yīng)用進(jìn)程一起部署，因此形象地把這種部署方式稱為“Sidecar”/邊車（即三輪摩托的挎斗）。

應(yīng)用間的所有流量都需要經(jīng)過代理，由于代理以Sidecar方式和應(yīng)用部署在同一臺(tái)主機(jī)上，應(yīng)用和代理之間的通訊可以被認(rèn)為是可靠的。由代理來負(fù)責(zé)找到目的服務(wù)并負(fù)責(zé)通訊的可靠性和安全等問題。

當(dāng)服務(wù)大量部署時(shí)，隨著服務(wù)部署的Sidecar代理之間的連接形成了一個(gè)如下圖所示的網(wǎng)格，該網(wǎng)格成為了微服務(wù)的通訊基礎(chǔ)設(shè)施層，承載了微服務(wù)之間的所有流量，被稱之為Service Mesh（服務(wù)網(wǎng)格）。

服務(wù)網(wǎng)格是一個(gè)基礎(chǔ)設(shè)施層，用于處理服務(wù)間通信。云原生應(yīng)用有著復(fù)雜的服務(wù)拓?fù)洌?wù)網(wǎng)格保證請(qǐng)求可以在這些拓?fù)渲锌煽康卮┧蟆Ｔ趯?shí)際應(yīng)用當(dāng)中，服務(wù)網(wǎng)格通常是由一系列輕量級(jí)的網(wǎng)絡(luò)代理組成的，它們與應(yīng)用程序部署在一起，但應(yīng)用程序不需要知道它們的存在。?

William Morgan ,?WHAT’S A SERVICE MESH? AND WHY DO I NEED ONE?

服務(wù)網(wǎng)格中有數(shù)量眾多的Sidecar代理，如果對(duì)每個(gè)代理分別進(jìn)行設(shè)置，工作量將非常巨大。為了更方便地對(duì)服務(wù)網(wǎng)格中的代理進(jìn)行統(tǒng)一集中控制，在服務(wù)網(wǎng)格上增加了控制面組件。

這里我們可以類比SDN的概念，控制面就類似于SDN網(wǎng)管中的控制器，負(fù)責(zé)路由策略的指定和路由規(guī)則下發(fā)；數(shù)據(jù)面類似于SDN網(wǎng)絡(luò)中交換機(jī)，負(fù)責(zé)數(shù)據(jù)包的轉(zhuǎn)發(fā)。

由于微服務(wù)的所有通訊都由服務(wù)網(wǎng)格基礎(chǔ)設(shè)施層提供，通過控制面板和數(shù)據(jù)面板的配合，可以對(duì)這些通訊進(jìn)行監(jiān)控、托管和控制，以實(shí)現(xiàn)微服務(wù)灰度發(fā)布，調(diào)用分布式追蹤，故障注入模擬測(cè)試，動(dòng)態(tài)路由規(guī)則，微服務(wù)閉環(huán)控制等管控功能。

如果你們想提升自己的技術(shù)，想學(xué)習(xí)以上的技術(shù)要點(diǎn)，你們可以加群獲取，在此我向大家推薦一個(gè)交流學(xué)習(xí)群：575745314 里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識(shí)體系。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源，目前受益良多。

Istio服務(wù)網(wǎng)格

Istio是一個(gè)Service Mesh開源項(xiàng)目，是Google繼Kubernetes之后的又一力作，主要參與的公司包括Google，IBM和Lyft。

憑借Kubernetes良好的架構(gòu)設(shè)計(jì)及其強(qiáng)大的擴(kuò)展性，Google圍繞Kubernetes打造一個(gè)生態(tài)系統(tǒng)。Kubernetes用于微服務(wù)的編排（編排是英文Orchestration的直譯，用大白話說就是描述一組微服務(wù)之間的關(guān)聯(lián)關(guān)系，并負(fù)責(zé)微服務(wù)的部署、終止、升級(jí)、縮擴(kuò)容等）。其向下用CNI（容器網(wǎng)絡(luò)接口），CRI（容器運(yùn)行時(shí)接口）標(biāo)準(zhǔn)接口可以對(duì)接不同的網(wǎng)絡(luò)和容器運(yùn)行時(shí)實(shí)現(xiàn)，提供微服務(wù)運(yùn)行的基礎(chǔ)設(shè)施。向上則用Istio提供了微服務(wù)治理功能。

由下圖可見，Istio補(bǔ)充了Kubernetes生態(tài)圈的重要一環(huán)，是Google的微服務(wù)版圖里一個(gè)里程碑式的擴(kuò)張。

Google借Istio的力量推動(dòng)微服務(wù)治理的事實(shí)標(biāo)準(zhǔn)，對(duì)Google自身的產(chǎn)品Google Cloud有極其重大的意義。其他的云服務(wù)廠商，如Redhat、Pivotal、Nginx、Buoyant等看到大勢(shì)所趨，也紛紛跟進(jìn)，宣布自身產(chǎn)品和Istio進(jìn)行集成，以避免自己被落下，丟失其中的市場(chǎng)機(jī)會(huì)。

可以預(yù)見不久的將來，對(duì)于云原生應(yīng)用而言，采用Kubernetes進(jìn)行服務(wù)部署和集群管理，采用Istio處理服務(wù)通訊和治理，將成為微服務(wù)應(yīng)用的標(biāo)準(zhǔn)配置。

Istio服務(wù)包括網(wǎng)格由數(shù)據(jù)面和控制面兩部分。

數(shù)據(jù)面由一組智能代理（Envoy）組成，代理部署為邊車，調(diào)解和控制微服務(wù)之間所有的網(wǎng)絡(luò)通信。

控制面負(fù)責(zé)管理和配置代理來路由流量，以及在運(yùn)行時(shí)執(zhí)行策略。

Istio控制面

Istio控制面板包括3個(gè)組件：Pilot、Mixer和Istio-Auth。

Pilot

Pilot維護(hù)了網(wǎng)格中的服務(wù)的標(biāo)準(zhǔn)模型，這個(gè)標(biāo)準(zhǔn)模型是獨(dú)立于各種底層平臺(tái)的。Pilot通過適配器和各底層平臺(tái)對(duì)接，以填充此標(biāo)準(zhǔn)模型。

例如Pilot中的Kubernetes適配器通過Kubernetes API服務(wù)器得到Kubernetes中Pod注冊(cè)信息的更改，入口資源以及存儲(chǔ)流量管理規(guī)則等信息，然后將該數(shù)據(jù)被翻譯為標(biāo)準(zhǔn)模型提供給Pilot使用。通過適配器模式，Pilot還可以從Mesos、Cloud Foundry、Consul中獲取服務(wù)信息，也可以開發(fā)適配器將其他提供服務(wù)發(fā)現(xiàn)的組件集成到Pilot中。

除此以外，Pilo還定義了一套和數(shù)據(jù)面通信的標(biāo)準(zhǔn)API，API提供的接口內(nèi)容包括服務(wù)發(fā)現(xiàn) 、負(fù)載均衡池和路由表的動(dòng)態(tài)更新。通過該標(biāo)準(zhǔn)API將控制面和數(shù)據(jù)面進(jìn)行了解耦，簡(jiǎn)化了設(shè)計(jì)并提升了跨平臺(tái)的可移植性。基于該標(biāo)準(zhǔn)API已經(jīng)實(shí)現(xiàn)了多種Sidecar代理和Istio的集成，除Istio目前集成的Envoy外，還可以和Linkerd、Nginmesh等第三方通信代理進(jìn)行集成，也可以基于該API自己編寫Sidecar實(shí)現(xiàn)。

Pilot還定義了一套DSL（Domain Specific Language）語言，DSL語言提供了面向業(yè)務(wù)的高層抽象，可以被運(yùn)維人員理解和使用。運(yùn)維人員使用該DSL定義流量規(guī)則并下發(fā)到Pilot，這些規(guī)則被Pilot翻譯成數(shù)據(jù)面的配置，再通過標(biāo)準(zhǔn)API分發(fā)到Envoy實(shí)例，可以在運(yùn)行期對(duì)微服務(wù)的流量進(jìn)行控制和調(diào)整。

Mixer

在微服務(wù)應(yīng)用中，通常需要部署一些基礎(chǔ)的后端公共服務(wù)以用于支撐業(yè)務(wù)功能。這些基礎(chǔ)設(shè)施包括策略類如訪問控制，配額管理；以及遙測(cè)報(bào)告如APM、日志等。微服務(wù)應(yīng)用和這些后端支撐系統(tǒng)之間一般是直接集成的，這導(dǎo)致了應(yīng)用和基礎(chǔ)設(shè)置之間的緊密耦合，如果因?yàn)檫\(yùn)維原因需要對(duì)基礎(chǔ)設(shè)置進(jìn)行升級(jí)或者改動(dòng)，則需要修改各個(gè)微服務(wù)的應(yīng)用代碼，反之亦然。

為了解決該問題，Mixer在應(yīng)用程序代碼和基礎(chǔ)架構(gòu)后端之間引入了一個(gè)通用中間層。該中間層解耦了應(yīng)用和后端基礎(chǔ)設(shè)施，應(yīng)用程序代碼不再將應(yīng)用程序代碼與特定后端集成在一起，而是與Mixer進(jìn)行相當(dāng)簡(jiǎn)單的集成，然后Mixer負(fù)責(zé)與后端系統(tǒng)連接。

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

前提條件檢查。允許服務(wù)在響應(yīng)來自服務(wù)消費(fèi)者的傳入請(qǐng)求之前驗(yàn)證一些前提條件。前提條件可以包括服務(wù)使用者是否被正確認(rèn)證，是否在服務(wù)的白名單上，是否通過ACL檢查等等。

配額管理。 使服務(wù)能夠在分配和釋放多個(gè)維度上的配額，配額這一簡(jiǎn)單的資源管理工具可以在服務(wù)消費(fèi)者對(duì)有限資源發(fā)生爭(zhēng)用時(shí)，提供相對(duì)公平的（競(jìng)爭(zhēng)手段）。Rate Limiting就是配額的一個(gè)例子。

遙測(cè)報(bào)告。使服務(wù)能夠上報(bào)日志和監(jiān)控。在未來，它還將啟用針對(duì)服務(wù)運(yùn)營(yíng)商以及服務(wù)消費(fèi)者的跟蹤和計(jì)費(fèi)流。

Mixer的架構(gòu)如圖所示：

首先，Sidecar會(huì)從每一次請(qǐng)求中收集相關(guān)信息，如請(qǐng)求的路徑，時(shí)間，源IP，目地服務(wù)，tracing頭，日志等，并請(qǐng)這些屬性上報(bào)給Mixer。Mixer和后端服務(wù)之間是通過適配器進(jìn)行連接的，Mixer將Sidecar上報(bào)的內(nèi)容通過適配器發(fā)送給后端服務(wù)。

由于Sidecar只和Mixer進(jìn)行對(duì)接，和后端服務(wù)之間并沒有耦合，因此使用Mixer適配器機(jī)制可以接入不同的后端服務(wù)，而不需要修改應(yīng)用的代碼，例如通過不同的Mixer適配器，可以把Metrics收集到Prometheus或者InfluxDB，甚至可以在不停止應(yīng)用服務(wù)的情況下動(dòng)態(tài)切換后臺(tái)服務(wù)。

其次，Sidecar在進(jìn)行每次請(qǐng)求處理時(shí)會(huì)通過Mixer進(jìn)行策略判斷，并根據(jù)Mixer返回的結(jié)果決定是否繼續(xù)處理該次調(diào)用。通過該方式，Mixer將策略決策移出應(yīng)用層，使運(yùn)維人員可以在運(yùn)行期對(duì)策略進(jìn)行配置，動(dòng)態(tài)控制應(yīng)用的行為，提高了策略控制的靈活性。例如可以配置每個(gè)微服務(wù)應(yīng)用的訪問白名單，不同客戶端的Rate limiting，等等。

邏輯上微服務(wù)之間的每一次請(qǐng)求調(diào)用都會(huì)經(jīng)過兩次Mixer的處理：調(diào)用前進(jìn)行策略判斷，調(diào)用后進(jìn)行遙測(cè)數(shù)據(jù)收集。Istio采用了一些機(jī)制來避免Mixer的處理影響Envoy的轉(zhuǎn)發(fā)效率。

從上圖可以看到，Istio在Envoy中增加了一個(gè)Mixer Filter，該Filter和控制面的Mixer組件進(jìn)行通訊，完成策略控制和遙測(cè)數(shù)據(jù)收集功能。Mixer Filter中保存有策略判斷所需的數(shù)據(jù)緩存，因此大部分策略判斷在Envoy中就處理了，不需要發(fā)送請(qǐng)求到Mixer。另外Envoy收集到的遙測(cè)數(shù)據(jù)會(huì)先保存在Envoy的緩存中，每隔一段時(shí)間再通過批量的方式上報(bào)到Mixer。

Auth

Istio支持雙向SSL認(rèn)證（Mutual SSL Authentication）和基于角色的訪問控制（RBAC），以提供端到端的安全解決方案。

認(rèn)證

Istio提供了一個(gè)內(nèi)部的CA（證書機(jī)構(gòu)），該CA為每個(gè)服務(wù)頒發(fā)證書，提供服務(wù)間訪問的雙向SSL身份認(rèn)證，并進(jìn)行通信加密，其架構(gòu)如下圖所示：

其工作機(jī)制如下：

部署時(shí)：

CA監(jiān)聽Kubernetes API Server，為集群中的每一個(gè)Service Account創(chuàng)建一對(duì)密鑰和證書，并發(fā)送給Kubernetes API Server。注意這里不是為每個(gè)服務(wù)生成一個(gè)證書，而是為每個(gè)Service Account生成一個(gè)證書。Service Account和Kubernetes中部署的服務(wù)可以是一對(duì)多的關(guān)系。Service Account被保存在證書的SAN（Subject Alternative Name）字段中。

當(dāng)Pod創(chuàng)建時(shí)，Kubernetes根據(jù)該P(yáng)od關(guān)聯(lián)的Service Account將密鑰和證書以Kubernetes Secrets資源的方式加載為Pod的Volume，以供Envoy使用。

Pilot生成數(shù)據(jù)面的配置，包括Envoy需使用的密鑰和證書信息，以及哪個(gè)Service Account可以允許運(yùn)行哪些服務(wù)，下發(fā)到Envoy。

備注：如果是虛機(jī)環(huán)境，則采用一個(gè)Node Agent生成密鑰，向Istio CA申請(qǐng)證書，然后將證書傳遞給Envoy。

運(yùn)行時(shí)：

服務(wù)客戶端的出站請(qǐng)求被Envoy接管。

客戶端的Envoy和服務(wù)端的Envoy開始雙向SSL握手。在握手階段，客戶端Envoy會(huì)驗(yàn)證服務(wù)端Envoy證書中的Service Account有沒有權(quán)限運(yùn)行該請(qǐng)求的服務(wù)，如沒有權(quán)限，則認(rèn)為服務(wù)端不可信，不能創(chuàng)建鏈接。

當(dāng)加密TSL鏈接創(chuàng)建好后，請(qǐng)求數(shù)據(jù)被發(fā)送到服務(wù)端的Envoy，然后被Envoy通過一個(gè)本地的TCP鏈接發(fā)送到服務(wù)中。

鑒權(quán)

Istio“基于角色的訪問控制”（RBAC）提供了命名空間、服務(wù)、方法三個(gè)不同大小粒度的服務(wù)訪問權(quán)限控制。其架構(gòu)如下圖所示：

管理人員可以定制訪問控制的安全策略，這些安全策略保存在Istio Config Store中。 Istio RBAC Engine從Config Store中獲取安全策略，根據(jù)安全策略對(duì)客戶端發(fā)起的請(qǐng)求進(jìn)行判斷，并返回鑒權(quán)結(jié)果（允許或者禁止）。

Istio RBAC Engine目前被實(shí)現(xiàn)為一個(gè)Mixer Adapter，因此其可以從Mixer傳遞過來的上下文中獲取到訪問請(qǐng)求者的身份（Subject）和操作請(qǐng)求（Action），并通過Mixer對(duì)訪問請(qǐng)求進(jìn)行策略控制，允許或者禁止某一次請(qǐng)求。

Istio Policy中包含兩個(gè)基本概念：

ServiceRole，定義一個(gè)角色，并為該角色指定對(duì)網(wǎng)格中服務(wù)的訪問權(quán)限。指定角色訪問權(quán)限時(shí)可以在命名空間，服務(wù)，方法的不同粒度進(jìn)行設(shè)置。

ServiceRoleBinding，將角色綁定到一個(gè)Subject，可以是一個(gè)用戶，一組用戶或者一個(gè)服務(wù)。

Istio數(shù)據(jù)面

Istio數(shù)據(jù)面以“邊車”（Sidecar）的方式和微服務(wù)一起部署，為微服務(wù)提供安全、快速、可靠的服務(wù)間通訊。由于Istio的控制面和數(shù)據(jù)面以標(biāo)準(zhǔn)接口進(jìn)行交互，因此數(shù)據(jù)可以有多種實(shí)現(xiàn)，Istio缺省使用了Envoy代理的擴(kuò)展版本。

Envoy是以C++開發(fā)的高性能代理，用于調(diào)解服務(wù)網(wǎng)格中所有服務(wù)的所有入站和出站流量。Envoy的許多內(nèi)置功能被Istio發(fā)揚(yáng)光大，例如動(dòng)態(tài)服務(wù)發(fā)現(xiàn)、負(fù)載均衡、TLS加密、HTTP/2 & gRPC代理、熔斷器、路由規(guī)則、故障注入和遙測(cè)等。

Istio數(shù)據(jù)面支持的特性如下：

備注：Outbound特性是指服務(wù)請(qǐng)求側(cè)的Sidecar提供的功能特性，而Inbound特性是指服務(wù)提供側(cè)Sidecar提供的功能特性。一些特性如遙測(cè)和分布式跟蹤需要兩側(cè)的Sidecar都提供支持；而另一些特性則只需要在一側(cè)提供，例如鑒權(quán)只需要在服務(wù)提供側(cè)提供，重試只需要在請(qǐng)求側(cè)提供。

典型應(yīng)用場(chǎng)景

Istio服務(wù)管控包括下列的典型應(yīng)用場(chǎng)景：

分布式調(diào)用追蹤

在微服務(wù)架構(gòu)中，業(yè)務(wù)的調(diào)用鏈非常復(fù)雜，一個(gè)來自用戶的請(qǐng)求可能涉及到幾十個(gè)服務(wù)的協(xié)同處理。因此需要一個(gè)跟蹤系統(tǒng)來記錄和分析同一次請(qǐng)求在整個(gè)調(diào)用鏈上的相關(guān)事件，從而幫助研發(fā)和運(yùn)維人員分析系統(tǒng)瓶頸，快速定位異常和優(yōu)化調(diào)用鏈路。

Istio通過在Envoy代理上收集調(diào)用相關(guān)數(shù)據(jù)，實(shí)現(xiàn)了對(duì)應(yīng)用無侵入的分布式調(diào)用跟蹤分析。 Istio實(shí)現(xiàn)分布式調(diào)用追蹤的原理如下圖所示：

Envoy收集一個(gè)端到端調(diào)用中的各個(gè)分段的數(shù)據(jù)，并將這些調(diào)用追蹤信息發(fā)送給Mixer，Mixer Adapter將追蹤信息發(fā)送給相應(yīng)的服務(wù)后端進(jìn)行處理。整個(gè)調(diào)用追蹤信息的生成流程不需要應(yīng)用程序介入，因此不需要將分布式跟蹤相關(guān)代碼注入到應(yīng)用程序中。

注意：應(yīng)用仍需要在進(jìn)行出口調(diào)用時(shí)將收到的入口請(qǐng)求中tracing相關(guān)的header轉(zhuǎn)發(fā)出去，傳遞給調(diào)用鏈中下一個(gè)邊車進(jìn)行處理。

度量收集

Istio 實(shí)現(xiàn)度量收集的原理如下圖所示：

Envoy收集指標(biāo)相關(guān)的原始數(shù)據(jù)，如請(qǐng)求的服務(wù)、HTTP狀態(tài)碼、調(diào)用時(shí)延等，這些收集到的指標(biāo)數(shù)據(jù)被送到Mixer，通過Mixer Adapters將指標(biāo)信息轉(zhuǎn)換后發(fā)送到后端的監(jiān)控系統(tǒng)中。由于Mixer使用了插件機(jī)制，后端監(jiān)控系統(tǒng)可以根據(jù)需要在運(yùn)行期進(jìn)行動(dòng)態(tài)切換。

如果你們想提升自己的技術(shù)，想學(xué)習(xí)以上的技術(shù)要點(diǎn)，你們可以加群獲取，在此我向大家推薦一個(gè)交流學(xué)習(xí)群：575745314 里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識(shí)體系。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源，目前受益良多。

灰度發(fā)布

當(dāng)應(yīng)用上線以后，運(yùn)維面臨的一大挑戰(zhàn)是如何能夠在不影響已上線業(yè)務(wù)的情況下進(jìn)行升級(jí)。無論進(jìn)行了多么完善的測(cè)試，都無法保證線下測(cè)試時(shí)發(fā)現(xiàn)所有潛在故障。在無法百分百避免版本升級(jí)故障的情況下，需要通過一種方式進(jìn)行可控的版本發(fā)布，把故障影響控制在可以接受的范圍內(nèi)，并可以快速回退。

可以通過灰度發(fā)布（又名金絲雀發(fā)布）來實(shí)現(xiàn)業(yè)務(wù)從老版本到新版本的平滑過渡，并避免升級(jí)過程中出現(xiàn)的問題對(duì)用戶造成的影響。

Istio通過高度的抽象和良好的設(shè)計(jì)采用一致的方式實(shí)現(xiàn)了灰度發(fā)布。在發(fā)布新版本后，運(yùn)維人員可以通過定制路由規(guī)則將特定的流量（如具有指定特征的測(cè)試用戶）導(dǎo)入新版本服務(wù)中以進(jìn)行測(cè)試。通過漸進(jìn)受控地向新版本導(dǎo)入生產(chǎn)流量，可以最小化升級(jí)中出現(xiàn)的故障對(duì)用戶的影響。

采用Istio進(jìn)行灰度發(fā)布的流程如下圖所示：

首先，通過部署新版本的服務(wù)，并將通過路由規(guī)則將金絲雀用戶的流量導(dǎo)入到新版本服務(wù)中。

測(cè)試穩(wěn)定后，使用路由規(guī)則將生產(chǎn)流量逐漸導(dǎo)入到新版本系統(tǒng)中，如按5%、10%、50%、80%逐漸導(dǎo)入。

如果新版本工作正常，則最后將所有流量導(dǎo)入到新版本服務(wù)中，并將老版本服務(wù)下線；如中間出現(xiàn)問題，則可以將流量重新導(dǎo)回老版本，在新版本中修復(fù)故障后采用該流程重新發(fā)布。

斷路器

在微服務(wù)架構(gòu)中，存在著許許多多的服務(wù)單元，若一個(gè)服務(wù)出現(xiàn)故障，就會(huì)因依賴關(guān)系形成故障蔓延，最終導(dǎo)致整個(gè)系統(tǒng)的癱瘓，這樣的架構(gòu)相較傳統(tǒng)架構(gòu)就更加的不穩(wěn)定。為了解決這樣的問題，因此產(chǎn)生了斷路器模式。

斷路器模式指，在某個(gè)服務(wù)發(fā)生故障時(shí)，斷路器的故障監(jiān)控向調(diào)用放返回一個(gè)及時(shí)的錯(cuò)誤響應(yīng)，而不是長(zhǎng)時(shí)間的等待。這樣就不會(huì)使得調(diào)用線程因調(diào)用故障被長(zhǎng)時(shí)間占用，從而避免了故障在整個(gè)系統(tǒng)中的蔓延。

Istio實(shí)現(xiàn)斷路器的原理如下圖所示：

管理員通過destination policy設(shè)置斷路觸發(fā)條件，斷路時(shí)間等參數(shù)。例如設(shè)置服務(wù)B發(fā)生10次5XX錯(cuò)誤后斷路15分鐘。則當(dāng)服務(wù)B的某一實(shí)例滿足斷路條件后，就會(huì)被從LB池中移除15分鐘。在這段時(shí)間內(nèi)，Envoy將不再把客戶端的請(qǐng)求轉(zhuǎn)發(fā)到該服務(wù)實(shí)例。

Istio的斷路器還支持配置最大鏈接數(shù)，最大待處理請(qǐng)求數(shù)，最大請(qǐng)求數(shù)，每鏈接最大請(qǐng)求數(shù)，重試次數(shù)等參數(shù)。當(dāng)達(dá)到設(shè)置的最大請(qǐng)求數(shù)后，新發(fā)起的請(qǐng)求會(huì)被Envoy直接拒絕。

故障注入

對(duì)于一個(gè)大型微服務(wù)應(yīng)用而言，系統(tǒng)的健壯性非常重要。在微服務(wù)系統(tǒng)中存在大量的服務(wù)實(shí)例，當(dāng)部分服務(wù)實(shí)例出現(xiàn)問題時(shí)，微服務(wù)應(yīng)用需要具有較高的容錯(cuò)性，通過重試、斷路、自愈等手段保證系統(tǒng)能夠繼續(xù)對(duì)外正常提供服務(wù)。因此在應(yīng)用發(fā)布到生產(chǎn)系統(tǒng)強(qiáng)需要對(duì)系統(tǒng)進(jìn)行充分的健壯性測(cè)試。

對(duì)微服務(wù)應(yīng)用進(jìn)行健壯性測(cè)試的一個(gè)最大的困難是如何對(duì)系統(tǒng)故障進(jìn)行模擬。在一個(gè)部署了成百上千微服務(wù)的測(cè)試環(huán)境中，如果想通過對(duì)應(yīng)用，主機(jī)或者交換機(jī)進(jìn)行設(shè)置來模擬微服務(wù)之間的通信故障是非常困難的。

Istio通過服務(wù)網(wǎng)格承載了微服務(wù)之間的通信流量，因此可以在網(wǎng)格中通過規(guī)則進(jìn)行故障注入，模擬部分微服務(wù)出現(xiàn)故障的情況，對(duì)整個(gè)應(yīng)用的健壯性進(jìn)行測(cè)試。

故障注入的原理如下圖所示：

測(cè)試人員通過Pilot向Envoy注入了一個(gè)規(guī)則，為發(fā)向服務(wù)MS-B的請(qǐng)求加入了指定時(shí)間的延遲。當(dāng)客戶端請(qǐng)求發(fā)向MSB-B時(shí)，Envoy會(huì)根據(jù)該規(guī)則為該請(qǐng)求加入時(shí)延，引起客戶的請(qǐng)求超時(shí)。通過設(shè)置規(guī)則注入故障的方式，測(cè)試人員可以很方便地模擬微服務(wù)之間的各種通信故障，對(duì)微服務(wù)應(yīng)用的健壯性進(jìn)行較為完整的模擬測(cè)試。

總結(jié)

服務(wù)網(wǎng)格為微服務(wù)提供了一個(gè)對(duì)應(yīng)用程序透明的安全、可靠的通信基礎(chǔ)設(shè)施層。采用服務(wù)網(wǎng)格后，微服務(wù)應(yīng)用開發(fā)人員可以專注于解決業(yè)務(wù)領(lǐng)域問題，將一些通用問題交給服務(wù)網(wǎng)格處理。采用服務(wù)網(wǎng)格后，避免了代碼庫帶來的依賴，可以充分發(fā)揮微服務(wù)的異構(gòu)優(yōu)勢(shì)，開發(fā)團(tuán)隊(duì)可以根據(jù)業(yè)務(wù)需求和開發(fā)人員能力自由選擇技術(shù)棧。

Istio具有良好的架構(gòu)設(shè)計(jì)，提供了強(qiáng)大的二次開發(fā)擴(kuò)展性和用戶定制能力。雖然Istio目前還處于beta階段，但已經(jīng)獲得眾多知名公司和產(chǎn)品的支持，是一個(gè)非常具有前景的開源服務(wù)網(wǎng)格開源項(xiàng)目。