共計(jì) 5828 個(gè)字符，預(yù)計(jì)需要花費(fèi) 15 分鐘才能閱讀完成。
這期內(nèi)容當(dāng)中丸趣 TV 小編將會(huì)給大家?guī)?lái)有關(guān) istio 是怎么連接、管理和保護(hù)微服務(wù) 2.0 的，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
一、分布式計(jì)算的八個(gè)謬論
彼得多維奇多年前提出的分布式計(jì)算的八個(gè)謬論，對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)他們往往會(huì)忽視這八條。這八條基本上都和網(wǎng)絡(luò)相關(guān)，例如在發(fā)起一個(gè)網(wǎng)絡(luò)請(qǐng)求時(shí)，會(huì)不斷地做一些嘗試等待，來(lái)保障消息投遞的有效性。
微服務(wù)是一個(gè)更為復(fù)雜的分布式系統(tǒng)，之前 SOA 或者 B /S，CS 架構(gòu)，它的顆粒度會(huì)更粗一點(diǎn)，但是如果采用微服務(wù)，它的顆粒度是更細(xì)的。在馬丁·富勒博客《微服務(wù)的先決條件是什么》一文中提到一條，你必須要成為“高個(gè)子”，想成為“高個(gè)子”其實(shí)并不簡(jiǎn)單，很多公司，它們都是為了成為“高個(gè)子”，做了很多框架、平臺(tái)。
二、服務(wù)治理
1 微服務(wù)治理的技術(shù)點(diǎn)
要成為“高個(gè)子”需要對(duì)微服務(wù)進(jìn)行哪些改造，這里是相關(guān)服務(wù)治理的技術(shù)點(diǎn)，其中只是一部分，和服務(wù)網(wǎng)格比較相關(guān)的技術(shù)點(diǎn)，包含服務(wù)發(fā)現(xiàn)、負(fù)載均衡、請(qǐng)求路由、認(rèn)證與授權(quán)、可觀測(cè)性，還有健康檢查、容錯(cuò)等。目前主流的解決方案有眾所周知的 Spring Cloud， Dubbo 等，這些都是提供庫(kù)來(lái)把服務(wù)治理相關(guān)的內(nèi)容打包，供具體的業(yè)務(wù)去調(diào)用。
2 庫(kù)或框架的問(wèn)題
但是庫(kù)和框架會(huì)存在一些問(wèn)題：
1、學(xué)習(xí)成本。多一個(gè)庫(kù)對(duì)于開(kāi)發(fā)人員而言，意味著要多學(xué)一些東西，并且在業(yè)務(wù)開(kāi)發(fā)過(guò)程中，還會(huì)受到庫(kù)或者框架的制約。
2、對(duì)業(yè)務(wù)代碼的侵入性。例如用 Spring Cloud 會(huì)在代碼里面加很多額外的內(nèi)容，比如每個(gè)請(qǐng)求里面加一個(gè)注解來(lái)表達(dá)想引用服務(wù)治理的某些功能。
3、基礎(chǔ)庫(kù)的維護(hù)、升級(jí)和下線。如果是以庫(kù)的方式來(lái)提升到服務(wù)里面，庫(kù)的維護(hù)、升級(jí)、下線就會(huì)造成整個(gè)服務(wù)的維護(hù)、升級(jí)、下線。
4、不同語(yǔ)言和技術(shù)棧。在提出微服務(wù)概念時(shí)，它的一個(gè)重要好處就是可以使用不同的技術(shù)棧來(lái)開(kāi)發(fā)微服務(wù)，但如果受到框架制約，只能用這個(gè)語(yǔ)言，這是我們比較頭痛的事情，無(wú)法發(fā)揮微服務(wù)跨語(yǔ)言的能力。
這些問(wèn)題其實(shí)是有嚴(yán)重程度的，從上往下越來(lái)越讓開(kāi)發(fā)人員覺(jué)得不舒服。理想中的服務(wù)治理方案是什么？可以先暢想一下，整個(gè)服務(wù)治理相關(guān)的東西，應(yīng)該是和業(yè)務(wù)邏輯完全隔離的，并且服務(wù)和服務(wù)之間的交互是不會(huì)考慮服務(wù)治理這塊內(nèi)容，最好對(duì)于業(yè)務(wù)開(kāi)發(fā)來(lái)說(shuō)是不可見(jiàn)的。
這時(shí)候怎么去做呢？就引出了容器經(jīng)典部署模式——Sidecar。
3Sidecar 模式
Sidecar 模式通常是和容器一起使用，如果不和容器一起使用也沒(méi)關(guān)系，那就是兩個(gè)獨(dú)立的進(jìn)程，如果和容器使用的話，就基于容器為單位。Sidecar 模式是物理隔離的，并且與語(yǔ)言無(wú)關(guān)。因?yàn)槭莾蓚€(gè)獨(dú)立的東西，可以獨(dú)立發(fā)布，和微服務(wù)理念一樣。另外它們是部署在同一個(gè) Host 上面，所以資源之間可以做到相互訪問(wèn)，并且因?yàn)樵谝黄鹚酝ㄐ叛舆t也不會(huì)太明顯。和業(yè)務(wù)無(wú)關(guān)的功能都可以放上去，形成多個(gè) Sidecar。今天 Sidecar 主要是把一些服務(wù)治理相關(guān)的東西放在里面，做軟件設(shè)計(jì)上的思想就是分離關(guān)注點(diǎn)。
基于 Sidecar 模式做服務(wù)治理，之后形成連接的具體狀況，如圖，對(duì)于服務(wù) A 來(lái)說(shuō)，服務(wù) A 是不知道和 Sidecar 進(jìn)行通信，服務(wù) A 還是向服務(wù) B 發(fā)消息，照常調(diào)用通信接口，但是消息可能會(huì)被 Sidecar 捕獲到，然后通過(guò) Sidecar 進(jìn)行轉(zhuǎn)發(fā)。
三、服務(wù)網(wǎng)格
兩個(gè)最新的控制面板，一個(gè)是 Istio，是由 Google、IBM、Lyft 開(kāi)發(fā)的，而 Conduit 是由 Buoyant 公司開(kāi)發(fā)的，跟剛才所說(shuō)的性能不太好的數(shù)據(jù)面板 Linkerd 是同一家公司，Buoyant 在 Linkerd 之后又重新開(kāi)發(fā)了 Conduit，專門(mén)來(lái)解決性能上的問(wèn)題，所以在性能上面來(lái)看，Conduit 的性能指標(biāo)已經(jīng)出來(lái)了，就是微秒級(jí)，并且是 P99 延遲。但是 Istio 的性能指標(biāo)現(xiàn)在還沒(méi)出來(lái)，還在功能開(kāi)發(fā)階段。因?yàn)?Istio 需要實(shí)現(xiàn)的功能比較多，要支持各種各樣的平臺(tái)和過(guò)濾，Istio 整個(gè)架構(gòu)非常靈活，所以 Istio 整個(gè)量級(jí)是比較重量的，但是 Conduit 只支持 K8S，Conduit 的原則是怎么快怎么來(lái)。
從編程語(yǔ)言上來(lái)說(shuō)，控制面板 Istio 和 Conduit 都是使用 Go 語(yǔ)言，但是在數(shù)據(jù)面板上 Istio 是使用 C ++，Conduit 使用 Rust，可以看出來(lái)這兩個(gè)語(yǔ)言都是那種比較高效的，在數(shù)據(jù)面板上面必須要使用高效的語(yǔ)言來(lái)完成。
四、Istio 架構(gòu)
一句話定義 Istio：一個(gè)用來(lái)連接、管理和保護(hù)微服務(wù)的開(kāi)放平臺(tái)。剛才也說(shuō)了 Istio 是 Google 開(kāi)發(fā)的，所以 Istio 今后的趨勢(shì)肯定是會(huì)越來(lái)越火的，并且目前 K8S 已經(jīng)把它集成到里面了，做成一個(gè)可選的組件。
對(duì)于連接而言，Istio 它主要包含彈性、服務(wù)發(fā)現(xiàn)、負(fù)載均衡，管理是流量控制、策略增強(qiáng)，監(jiān)控也有，并且安全這塊 Istio 也是有考慮，Istio 是端到端的身份驗(yàn)證和授權(quán)，等一下會(huì)詳細(xì)的介紹。
Istio 的關(guān)鍵特性:
1、智能路由和負(fù)載均衡。這里的智能路由和負(fù)載均衡是屬于比較高級(jí)的，不是像傳統(tǒng)簡(jiǎn)單的隨機(jī)負(fù)載均衡，而是可以基于一些數(shù)據(jù)包內(nèi)部的內(nèi)容來(lái)進(jìn)行負(fù)載均衡。
2、跨語(yǔ)言和平臺(tái)的彈性。對(duì)于平臺(tái)來(lái)說(shuō) Istio 是支持各種各樣的平臺(tái)，并且能支持 A / B 測(cè)試，金絲雀發(fā)布，并使用藍(lán)綠部署運(yùn)維上的一些高級(jí)功能。
3、全面策略執(zhí)行。Istio 有一個(gè)組件是專門(mén)負(fù)責(zé)保障策略能夠通過(guò)一個(gè)組件下發(fā)到具體的數(shù)據(jù)面板。
4、遙測(cè)和上報(bào)。即具體的測(cè)量以及流量的監(jiān)控等。
這個(gè)就是 Istio 整個(gè)的系統(tǒng)架構(gòu)，如圖，上面是控制面板，下面是很多數(shù)據(jù) Envoy，很多個(gè)代理，形成一個(gè)數(shù)據(jù)面板。后面我們會(huì)對(duì)單個(gè)進(jìn)行詳細(xì)介紹。
這是在 K8S 下面 Istio 部署的示意圖，可以看到它們之間最關(guān)鍵的東西是所有服務(wù)和組件都會(huì)有一個(gè)代理，這代理是必備的，包括控制面板都會(huì)有代理。沒(méi)有畫(huà)的有兩個(gè)東西，一個(gè)是 Ingress，一個(gè)是初始化器，初始化器主要是做代理注入。它們之間相互的交互都是通過(guò)加密，由 TLS 協(xié)議來(lái)完成。
五、Istio 組件
1 數(shù)據(jù)面板 Envoy
介紹一下 Istio 的核心組件，首先是 Istio 的數(shù)據(jù)面板 Envoy。
Envoy 的目標(biāo)是透明地處理集群內(nèi)服務(wù)間、從服務(wù)到外部服務(wù)之間的出入口流量。Envoy 是用 C ++ 編寫(xiě)的，高并行、非阻塞。并且是可裝卸的 L3/ 4 過(guò)濾器，以及 L7 的過(guò)濾器，最終會(huì)形成一個(gè)過(guò)濾鏈來(lái)對(duì)流量進(jìn)行管理或者控制，Envoy 是通過(guò) xDS 動(dòng)態(tài)配置來(lái)進(jìn)行接口提供。
下面就是一些固有的功能，服務(wù)發(fā)現(xiàn)、健康檢查。Envoy 的健康檢查也做的顆粒度比較細(xì)，包含主動(dòng)健康檢查和被動(dòng)健康檢查。主動(dòng)健康檢查像常規(guī)的健康檢查，主動(dòng)地發(fā)一個(gè)健康檢查的接口調(diào)用請(qǐng)求，查詢一下。被動(dòng)的是通過(guò)對(duì)其他服務(wù)的一些請(qǐng)求，從一些返回值進(jìn)行健康檢查。當(dāng)然還包含高級(jí)的負(fù)載均衡，監(jiān)控、跟蹤這些功能。
Envoy 最關(guān)鍵的三個(gè)點(diǎn)：
高性能。一直在強(qiáng)調(diào)的是數(shù)據(jù)面板必須要高性能，因?yàn)槭且蜆I(yè)務(wù)服務(wù)部署在一起的。
可擴(kuò)展。
可配置。具有動(dòng)態(tài)配置的特性。
Envoy 是如何做到高性能的？
Envoy 的線程模型分為三類線程，如果做過(guò) C ++ 開(kāi)發(fā)，這種單進(jìn)程多線程的架構(gòu)是很常見(jiàn)的。Envoy 分為主線程、工作線程、文件刷新線程，其中主線程就是負(fù)責(zé)工作線程和文件刷新線程的管理和調(diào)度。而工作線程主要負(fù)責(zé)監(jiān)聽(tīng)、過(guò)濾和轉(zhuǎn)發(fā)，工作線程里面會(huì)包含一個(gè)監(jiān)聽(tīng)器，如果收到一個(gè)請(qǐng)求之后會(huì)通過(guò)剛才所介紹的過(guò)濾鏈來(lái)進(jìn)行數(shù)據(jù)過(guò)濾。前面兩個(gè)都是非阻塞的，唯一一個(gè)阻塞的是這種 IO 操作的，會(huì)不斷地把內(nèi)存里面一些緩存進(jìn)行落盤(pán)。
服務(wù)網(wǎng)格所強(qiáng)調(diào)的另外一個(gè)功能，是動(dòng)態(tài)配置不用重啟，實(shí)際上是重啟的，它會(huì)啟動(dòng)一個(gè)新的進(jìn)程，然后在這進(jìn)程之上進(jìn)行新的策略，還有一些初始化，這時(shí)候再請(qǐng)求監(jiān)聽(tīng)，之前那個(gè)進(jìn)程的 socket 副本。當(dāng)老的關(guān)閉鏈接以及退出之后，它才會(huì)接收新的，這時(shí)候就實(shí)現(xiàn)了對(duì)用戶沒(méi)有感知的重啟。
這就是它的 xDS，如圖，可以看到它的密度是非常細(xì)的，
終端發(fā)現(xiàn)服務(wù)（EDS），實(shí)際上就是服務(wù)的發(fā)現(xiàn)服務(wù)；
集群發(fā)現(xiàn)服務(wù)（CDS）是為了發(fā)現(xiàn)集群；
路由發(fā)現(xiàn)服務(wù)（RDS）是為了對(duì)路由進(jìn)行一些處理；
監(jiān)聽(tīng)器（LDS）來(lái)動(dòng)態(tài)地添加、更新、刪除監(jiān)聽(tīng)器，包括過(guò)濾鏈的一些管理、維護(hù)。
另外還有剛才說(shuō)到的健康檢查（HDS），
還有聚合（ADS）是對(duì)于監(jiān)控指標(biāo)進(jìn)行聚合的接口；
另外一個(gè)密鑰發(fā)現(xiàn)（KDS）是和安全相關(guān)的。
首先，如果來(lái)了一個(gè)請(qǐng)求，會(huì)到剛才所說(shuō)的工作線程里面去，工作線程會(huì)有監(jiān)聽(tīng)器，收到之后進(jìn)行一些處理，然后要往外發(fā)，這時(shí)會(huì)調(diào)用路由的發(fā)現(xiàn)功能，然后再找到相應(yīng)的集群，再通過(guò)這個(gè)集群找到相應(yīng)的服務(wù)，一層一層的往下面調(diào)用。
2 控制面板 Pilot
接下來(lái)介紹的是控制面板的三大組件，第一個(gè)就是 Pilot。
Pilot 是運(yùn)行時(shí)的代理配置，剛才所說(shuō)的 xDS，就是用 Pilot 來(lái)進(jìn)行調(diào)用，負(fù)責(zé)把相應(yīng)的一些策略，失敗恢復(fù)的特性派發(fā)下去。Pilot 是負(fù)責(zé)管理所有的這些代理，代理和管理就通過(guò) Pilot 來(lái)完成，是平臺(tái)無(wú)關(guān)的一個(gè)拓?fù)淠Ｐ汀Ｄ壳爸饕С值氖?K8S。
Pilot 是一層抽象的獨(dú)立于底層平臺(tái)的模型，因?yàn)檫@里有個(gè)代理，對(duì)于多平臺(tái)或多樣性的管理架構(gòu)，即適配器的架構(gòu)。平臺(tái)特定的適配器負(fù)責(zé)適當(dāng)填充這些規(guī)范，要通過(guò)具體平臺(tái)的適配器形成一些規(guī)范，和通用的模型結(jié)合，生成必須要往 Envoy 下發(fā)的數(shù)據(jù)，并且配置、推送都是由 Pilot 來(lái)完成的。
Pilot 的整個(gè)服務(wù)發(fā)現(xiàn)和負(fù)載均衡，如圖，Pilot 是 Kubernetes DNS 提供的域名進(jìn)行訪問(wèn)，首先調(diào)用 Service B 的 url，這時(shí)候 Envoy 會(huì)進(jìn)行截獲并處理，處理完之后會(huì)找到相應(yīng)的負(fù)載均衡的池子挑選一個(gè)進(jìn)行流量下發(fā)。Pilot 目前支持的這種負(fù)載均衡的方法，規(guī)劃了很多種。但目前只實(shí)現(xiàn)了三種，前兩種還是隨機(jī)和輪循，多了一個(gè)最小請(qǐng)求的負(fù)載均衡算法。它能找到這些 Pilot 里面哪個(gè)被調(diào)用的最少，然后進(jìn)行調(diào)用。
Pilot 的一些規(guī)則配置，可以看到基本是負(fù)責(zé)規(guī)則的管理以及下發(fā)。
路由規(guī)則。
目的地策略。主要包含負(fù)載均衡的算法，以及對(duì)于負(fù)載均衡算法抽象的策略預(yù)演。
出站規(guī)則。
把這些規(guī)則分了三類，好處是對(duì)這三類都會(huì)生成一些模板。
流量的拆分可以看到是基于標(biāo)簽的流量拆分，這里配置的如版本，環(huán)境，環(huán)境類型，它根據(jù)這個(gè)規(guī)則來(lái)進(jìn)行流量的派發(fā)。比如說(shuō) 99% 都發(fā)給之前版本，新版本先 1% 先測(cè)一下，類似于 A / B 測(cè)試。
另外一個(gè)比較高級(jí)的是基于內(nèi)容，因?yàn)樗?L7 的這種過(guò)濾，可以基于內(nèi)容來(lái)過(guò)濾，并且支持表達(dá)式，這種將 iPhone 的流量全部導(dǎo)到新的服務(wù)里面去，并且有標(biāo)簽，版本必須得是金絲雀版本。
3 混合器 Mixer
Mixer 是在應(yīng)用代碼和基礎(chǔ)架構(gòu)之間提供一個(gè)中間層，來(lái)隔離 Enovy 和后臺(tái)基礎(chǔ)設(shè)施，這里的后臺(tái)是指 Promethus，ELK 這些。
Mixer 有三個(gè)核心特性：
先決條件檢查。負(fù)責(zé)白名單以及 ACL 檢測(cè)；
配額管理。負(fù)責(zé)這種使用頻率上的控制；
遙測(cè)報(bào)告。
總共分為兩類，在生成配置模板的時(shí)候它是有兩類的，第一類就是負(fù)責(zé)檢查 check，第二類就是負(fù)責(zé)報(bào)告 reporter。
Mixer 是采用通用的插件模型以實(shí)現(xiàn)高擴(kuò)展性，插件被稱為適配器。運(yùn)維人員下發(fā)一些配置到這里面，這些模板又是由模板開(kāi)發(fā)人員進(jìn)行開(kāi)發(fā)的，Istio 提供了很多通用性的模板，上面簡(jiǎn)單地改造一下就能做出一個(gè)模板來(lái)。適配器也有很多種，各種后臺(tái)、平臺(tái)的都有。
Mixer 是抽象了不同后端的策略，遙測(cè)系統(tǒng)的細(xì)節(jié)，它就對(duì)這兩個(gè)東西進(jìn)行了抽象，形成了一套抽象的東西。
剛才介紹過(guò)適配器，再來(lái)介紹一下處理器，它是配置好的適配器，由運(yùn)維人員進(jìn)行配置，之后形成最終的處理器，負(fù)責(zé)真正往后臺(tái)發(fā)東西。
它封裝了與后端接口所需的邏輯，指定了配置規(guī)格，以及適配器。如果要在后臺(tái)進(jìn)行消息交互的話，所需要的操作參數(shù)在這里也會(huì)定義。而右邊就是兩個(gè)模板，第一個(gè)模板是 Prometheus，它是一個(gè)處理器，下面是它的一些指標(biāo)。另外一個(gè)是白名單檢查的模板，提供 URL，以及它請(qǐng)求的接口返回值。
剛才介紹了整個(gè)通路是怎么打通的，包括適配器和處理器都是為了干這個(gè)事情，這個(gè)通路怎么建立？接下來(lái)要介紹的是這個(gè)參數(shù)怎么生成，它是請(qǐng)求屬性到一個(gè)模板的映射結(jié)果。
Mixer 會(huì)收到 Envoy 發(fā)過(guò)來(lái)的很多屬性（請(qǐng)求），請(qǐng)求里面包含的數(shù)據(jù)都稱之為屬性。通過(guò)它的模板來(lái)生成相應(yīng)的具體參數(shù)，這邊也是剛才兩個(gè)例子里面對(duì)應(yīng)的模板。上面是度量指標(biāo)采集用的，下面是白名單。
這里有個(gè)遙測(cè)報(bào)告的示例，當(dāng)收到一個(gè)請(qǐng)求之后會(huì)發(fā)生什么。它會(huì)以屬性的形式，這邊有個(gè) Zipk，就直接上報(bào)了，這是因?yàn)?Envoy 原生的就支持 Zipk。Envoy 支持后端監(jiān)控的東西，就是 Zipk，所以它可以直接發(fā)給它。其他的需要通過(guò) Mixer 來(lái)進(jìn)行轉(zhuǎn)發(fā)。
首先它收到這個(gè)屬性之后，會(huì)把這個(gè)屬性生成具體的實(shí)例。根據(jù)運(yùn)維人員提供的配置，Mixer 將生成的數(shù)據(jù)分發(fā)到一組適配器，適配器要根據(jù)運(yùn)維人員的配置來(lái)生成具體的數(shù)據(jù)，之后就可以把剛才所生成的實(shí)例往下發(fā)了。發(fā)到后端后可以進(jìn)行進(jìn)一步的分析和處理。
4 密鑰管理
最后要介紹的就是安全相關(guān)的，Certificate Authority 這塊，這是整個(gè)密鑰管理的示意圖，可以看到服務(wù)和 Envoy 是通過(guò) TCP 進(jìn)行交互的，但是 Envoy 和 Envoy 之間是通過(guò) MTIS 進(jìn)行加密，是雙向的 TIS 加密。它的好處是，會(huì)在內(nèi)部的每一個(gè)服務(wù)節(jié)點(diǎn)之間做加密，當(dāng)然這是可選的，根據(jù)性能的需求來(lái)進(jìn)行選擇。
密鑰管理分為四個(gè)步驟，這四步就是四個(gè)特性，第一，通過(guò)服務(wù)帳戶生成的密鑰和證書(shū)，然后再將密鑰和證書(shū)部署到 Envoy 上，它還支持周期性的對(duì)這證書(shū)進(jìn)行更新，另外還支持撤銷的功能。
這是它的兩種部署方式，一種 K8S 的部署方式，另外如果是虛擬機(jī)，它會(huì)單獨(dú)有一個(gè)節(jié)點(diǎn)代理，通過(guò)節(jié)點(diǎn)代理來(lái)發(fā)出簽名請(qǐng)求給 CA，CA 再生成密鑰和證書(shū)給代理，代理再來(lái)負(fù)責(zé)部署到 Envoy 上。
具體的運(yùn)行時(shí)它們都有各自的證書(shū)，開(kāi)始進(jìn)行雙向的 TIS，這時(shí)候會(huì)到名字信息里面去查詢，后端有沒(méi)有權(quán)限訪問(wèn)，如果有的話就往下，沒(méi)有就結(jié)束了。
第三步，如果收到一個(gè)客戶端的請(qǐng)求，會(huì)去 Mixer 里面判斷一下，它是白名單上的一個(gè)判斷或者是不是黑名單上的一個(gè)判斷，會(huì)影響“握手”的成功與否。最終它們就形成了安全交互的通道。
上述就是丸趣 TV 小編為大家分享的 istio 是怎么連接、管理和保護(hù)微服務(wù) 2.0 的了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道。
