istio是怎么連接、管理和保護(hù)微服務(wù)2.0的

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)碛嘘P(guān)istio是怎么連接、管理和保護(hù)微服務(wù)2.0的，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

一、分布式計(jì)算的八個(gè)謬論

彼得多維奇多年前提出的分布式計(jì)算的八個(gè)謬論，對(duì)于開發(fā)人員來說他們往往會(huì)忽視這八條。這八條基本上都和網(wǎng)絡(luò)相關(guān)，例如在發(fā)起一個(gè)網(wǎng)絡(luò)請(qǐng)求時(shí)，會(huì)不斷地做一些嘗試等待，來保障消息投遞的有效性。

微服務(wù)是一個(gè)更為復(fù)雜的分布式系統(tǒng)，之前 SOA 或者B/S，CS 架構(gòu)，它的顆粒度會(huì)更粗一點(diǎn)，但是如果采用微服務(wù)，它的顆粒度是更細(xì)的。在馬丁·富勒博客《微服務(wù)的先決條件是什么》一文中提到一條，你必須要成為“高個(gè)子”，想成為“高個(gè)子”其實(shí)并不簡單，很多公司，它們都是為了成為“高個(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)、可觀測性，還有健康檢查、容錯(cuò)等。目前主流的解決方案有眾所周知的 Spring Cloud， Dubbo 等，這些都是提供庫來把服務(wù)治理相關(guān)的內(nèi)容打包，供具體的業(yè)務(wù)去調(diào)用。

2庫或框架的問題

但是庫和框架會(huì)存在一些問題：

 1、學(xué)習(xí)成本。多一個(gè)庫對(duì)于開發(fā)人員而言，意味著要多學(xué)一些東西，并且在業(yè)務(wù)開發(fā)過程中，還會(huì)受到庫或者框架的制約。

2、對(duì)業(yè)務(wù)代碼的侵入性。例如用 Spring Cloud 會(huì)在代碼里面加很多額外的內(nèi)容，比如每個(gè)請(qǐng)求里面加一個(gè)注解來表達(dá)想引用服務(wù)治理的某些功能。

3、基礎(chǔ)庫的維護(hù)、升級(jí)和下線。如果是以庫的方式來提升到服務(wù)里面，庫的維護(hù)、升級(jí)、下線就會(huì)造成整個(gè)服務(wù)的維護(hù)、升級(jí)、下線。

4、不同語言和技術(shù)棧。在提出微服務(wù)概念時(shí)，它的一個(gè)重要好處就是可以使用不同的技術(shù)棧來開發(fā)微服務(wù)，但如果受到框架制約，只能用這個(gè)語言，這是我們比較頭痛的事情，無法發(fā)揮微服務(wù)跨語言的能力。

這些問題其實(shí)是有嚴(yán)重程度的，從上往下越來越讓開發(fā)人員覺得不舒服。理想中的服務(wù)治理方案是什么？可以先暢想一下，整個(gè)服務(wù)治理相關(guān)的東西，應(yīng)該是和業(yè)務(wù)邏輯完全隔離的，并且服務(wù)和服務(wù)之間的交互是不會(huì)考慮服務(wù)治理這塊內(nèi)容，最好對(duì)于業(yè)務(wù)開發(fā)來說是不可見的。

這時(shí)候怎么去做呢？就引出了容器經(jīng)典部署模式——Sidecar。

3Sidecar模式

Sidecar 模式通常是和容器一起使用，如果不和容器一起使用也沒關(guān)系，那就是兩個(gè)獨(dú)立的進(jìn)程，如果和容器使用的話，就基于容器為單位。Sidecar模式是物理隔離的，并且與語言無關(guān)。因?yàn)槭莾蓚€(gè)獨(dú)立的東西，可以獨(dú)立發(fā)布，和微服務(wù)理念一樣。另外它們是部署在同一個(gè) Host 上面，所以資源之間可以做到相互訪問，并且因?yàn)樵谝黄鹚酝ㄐ叛舆t也不會(huì)太明顯。和業(yè)務(wù)無關(guān)的功能都可以放上去，形成多個(gè) Sidecar。今天 Sidecar 主要是把一些服務(wù)治理相關(guān)的東西放在里面，做軟件設(shè)計(jì)上的思想就是分離關(guān)注點(diǎn)。

基于 Sidecar 模式做服務(wù)治理，之后形成連接的具體狀況，如圖，對(duì)于服務(wù)A來說，服務(wù)A是不知道和 Sidecar 進(jìn)行通信，服務(wù)A還是向服務(wù)B發(fā)消息，照常調(diào)用通信接口，但是消息可能會(huì)被 Sidecar 捕獲到，然后通過Sidecar 進(jìn)行轉(zhuǎn)發(fā)。

三、服務(wù)網(wǎng)格

兩個(gè)最新的控制面板，一個(gè)是 Istio，是由 Google、IBM、Lyft 開發(fā)的，而 Conduit 是由 Buoyant 公司開發(fā)的，跟剛才所說的性能不太好的數(shù)據(jù)面板Linkerd是同一家公司，Buoyant 在 Linkerd 之后又重新開發(fā)了 Conduit，專門來解決性能上的問題，所以在性能上面來看，Conduit 的性能指標(biāo)已經(jīng)出來了，就是微秒級(jí)，并且是P99延遲。但是 Istio 的性能指標(biāo)現(xiàn)在還沒出來，還在功能開發(fā)階段。因?yàn)?Istio 需要實(shí)現(xiàn)的功能比較多，要支持各種各樣的平臺(tái)和過濾，Istio 整個(gè)架構(gòu)非常靈活，所以 Istio 整個(gè)量級(jí)是比較重量的，但是 Conduit 只支持 K8S，Conduit 的原則是怎么快怎么來。

從編程語言上來說，控制面板 Istio 和 Conduit 都是使用Go語言，但是在數(shù)據(jù)面板上 Istio 是使用C++，Conduit 使用 Rust，可以看出來這兩個(gè)語言都是那種比較高效的，在數(shù)據(jù)面板上面必須要使用高效的語言來完成。

四、Istio架構(gòu)

一句話定義 Istio：一個(gè)用來連接、管理和保護(hù)微服務(wù)的開放平臺(tái)。剛才也說了 Istio 是 Google 開發(fā)的，所以 Istio 今后的趨勢肯定是會(huì)越來越火的，并且目前 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)簡單的隨機(jī)負(fù)載均衡，而是可以基于一些數(shù)據(jù)包內(nèi)部的內(nèi)容來進(jìn)行負(fù)載均衡。

2、跨語言和平臺(tái)的彈性。對(duì)于平臺(tái)來說 Istio 是支持各種各樣的平臺(tái)，并且能支持A/B測試，金絲雀發(fā)布，并使用藍(lán)綠部署運(yùn)維上的一些高級(jí)功能。

3、全面策略執(zhí)行。Istio 有一個(gè)組件是專門負(fù)責(zé)保障策略能夠通過一個(gè)組件下發(fā)到具體的數(shù)據(jù)面板。

4、遙測和上報(bào)。即具體的測量以及流量的監(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ì)有代理。沒有畫的有兩個(gè)東西，一個(gè)是 Ingress，一個(gè)是初始化器，初始化器主要是做代理注入。它們之間相互的交互都是通過加密，由TLS協(xié)議來完成。

五、Istio組件

1數(shù)據(jù)面板Envoy

介紹一下 Istio 的核心組件，首先是 Istio 的數(shù)據(jù)面板 Envoy。

Envoy 的目標(biāo)是透明地處理集群內(nèi)服務(wù)間、從服務(wù)到外部服務(wù)之間的出入口流量。Envoy 是用C++編寫的，高并行、非阻塞。并且是可裝卸的L3/4過濾器，以及L7的過濾器，最終會(huì)形成一個(gè)過濾鏈來對(duì)流量進(jìn)行管理或者控制，Envoy 是通過 xDS 動(dòng)態(tà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)的是通過對(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 的線程模型分為三類線程，如果做過C++開發(fā)，這種單進(jìn)程多線程的架構(gòu)是很常見的。Envoy 分為主線程、工作線程、文件刷新線程，其中主線程就是負(fù)責(zé)工作線程和文件刷新線程的管理和調(diào)度。而工作線程主要負(fù)責(zé)監(jiān)聽、過濾和轉(zhuǎn)發(fā)，工作線程里面會(huì)包含一個(gè)監(jiān)聽器，如果收到一個(gè)請(qǐng)求之后會(huì)通過剛才所介紹的過濾鏈來進(jìn)行數(shù)據(jù)過濾。前面兩個(gè)都是非阻塞的，唯一一個(gè)阻塞的是這種 IO 操作的，會(huì)不斷地把內(nèi)存里面一些緩存進(jì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)聽，之前那個(gè)進(jìn)程的 socket 副本。當(dāng)老的關(guān)閉鏈接以及退出之后，它才會(huì)接收新的，這時(shí)候就實(shí)現(xiàn)了對(duì)用戶沒有感知的重啟。

這就是它的 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)聽器（LDS）來動(dòng)態(tài)地添加、更新、刪除監(jiān)聽器，包括過濾鏈的一些管理、維護(hù)。

• 另外還有剛才說到的健康檢查（HDS），

• 還有聚合（ADS）是對(duì)于監(jiān)控指標(biāo)進(jìn)行聚合的接口；

• 另外一個(gè)密鑰發(fā)現(xiàn)（KDS）是和安全相關(guān)的。

   

首先，如果來了一個(gè)請(qǐng)求，會(huì)到剛才所說的工作線程里面去，工作線程會(huì)有監(jiān)聽器，收到之后進(jìn)行一些處理，然后要往外發(fā)，這時(shí)會(huì)調(diào)用路由的發(fā)現(xiàn)功能，然后再找到相應(yīng)的集群，再通過這個(gè)集群找到相應(yīng)的服務(wù)，一層一層的往下面調(diào)用。

2控制面板Pilot

接下來介紹的是控制面板的三大組件，第一個(gè)就是 Pilot。

Pilot 是運(yùn)行時(shí)的代理配置，剛才所說的 xDS，就是用 Pilot 來進(jìn)行調(diào)用，負(fù)責(zé)把相應(yīng)的一些策略，失敗恢復(fù)的特性派發(fā)下去。Pilot 是負(fù)責(zé)管理所有的這些代理，代理和管理就通過 Pilot 來完成，是平臺(tái)無關(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ī)范，要通過具體平臺(tái)的適配器形成一些規(guī)范，和通用的模型結(jié)合，生成必須要往 Envoy 下發(fā)的數(shù)據(jù)，并且配置、推送都是由 Pilot 來完成的。

Pilot 的整個(gè)服務(wù)發(fā)現(xiàn)和負(fù)載均衡，如圖，Pilot 是Kubernetes DNS提供的域名進(jì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ī)則來進(jìn)行流量的派發(fā)。比如說99%都發(fā)給之前版本，新版本先1%先測一下，類似于A/B測試。

另外一個(gè)比較高級(jí)的是基于內(nèi)容，因?yàn)樗荓7的這種過濾，可以基于內(nèi)容來過濾，并且支持表達(dá)式，這種將iPhone的流量全部導(dǎo)到新的服務(wù)里面去，并且有標(biāo)簽，版本必須得是金絲雀版本。

3混合器Mixer

Mixer 是在應(yīng)用代碼和基礎(chǔ)架構(gòu)之間提供一個(gè)中間層，來隔離 Enovy 和后臺(tái)基礎(chǔ)設(shè)施，這里的后臺(tái)是指 Promethus，ELK 這些。

Mixer 有三個(gè)核心特性：

• 先決條件檢查。負(fù)責(zé)白名單以及 ACL檢測；

• 配額管理。負(fù)責(zé)這種使用頻率上的控制；

• 遙測報(bào)告。

總共分為兩類，在生成配置模板的時(shí)候它是有兩類的，第一類就是負(fù)責(zé)檢查check，第二類就是負(fù)責(zé)報(bào)告reporter。

Mixer 是采用通用的插件模型以實(shí)現(xiàn)高擴(kuò)展性，插件被稱為適配器。運(yùn)維人員下發(fā)一些配置到這里面，這些模板又是由模板開發(fā)人員進(jìn)行開發(fā)的，Istio提供了很多通用性的模板，上面簡單地改造一下就能做出一個(gè)模板來。適配器也有很多種，各種后臺(tái)、平臺(tái)的都有。

Mixer 是抽象了不同后端的策略，遙測系統(tǒng)的細(xì)節(jié)，它就對(duì)這兩個(gè)東西進(jìn)行了抽象，形成了一套抽象的東西。

剛才介紹過適配器，再來介紹一下處理器，它是配置好的適配器，由運(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è)通路怎么建立？接下來要介紹的是這個(gè)參數(shù)怎么生成，它是請(qǐng)求屬性到一個(gè)模板的映射結(jié)果。

Mixer 會(huì)收到 Envoy 發(fā)過來的很多屬性（請(qǐng)求），請(qǐng)求里面包含的數(shù)據(jù)都稱之為屬性。通過它的模板來生成相應(yīng)的具體參數(shù)，這邊也是剛才兩個(gè)例子里面對(duì)應(yīng)的模板。上面是度量指標(biāo)采集用的，下面是白名單。

這里有個(gè)遙測報(bào)告的示例，當(dāng)收到一個(gè)請(qǐng)求之后會(huì)發(fā)生什么。它會(huì)以屬性的形式，這邊有個(gè) Zipk，就直接上報(bào)了，這是因?yàn)?Envoy 原生的就支持Zipk。Envoy 支持后端監(jiān)控的東西，就是 Zipk，所以它可以直接發(fā)給它。其他的需要通過 Mixer 來進(jìn)行轉(zhuǎn)發(fā)。

首先它收到這個(gè)屬性之后，會(huì)把這個(gè)屬性生成具體的實(shí)例。根據(jù)運(yùn)維人員提供的配置，Mixer 將生成的數(shù)據(jù)分發(fā)到一組適配器，適配器要根據(jù)運(yùn)維人員的配置來生成具體的數(shù)據(jù)，之后就可以把剛才所生成的實(shí)例往下發(fā)了。發(fā)到后端后可以進(jìn)行進(jìn)一步的分析和處理。

4密鑰管理

最后要介紹的就是安全相關(guān)的，Certificate Authority 這塊，這是整個(gè)密鑰管理的示意圖，可以看到服務(wù)和 Envoy 是通過 TCP 進(jìn)行交互的，但是Envoy 和 Envoy 之間是通過 MTIS 進(jìn)行加密，是雙向的 TIS 加密。它的好處是，會(huì)在內(nèi)部的每一個(gè)服務(wù)節(jié)點(diǎn)之間做加密，當(dāng)然這是可選的，根據(jù)性能的需求來進(jìn)行選擇。

密鑰管理分為四個(gè)步驟，這四步就是四個(gè)特性，第一，通過服務(wù)帳戶生成的密鑰和證書，然后再將密鑰和證書部署到 Envoy上，它還支持周期性的對(duì)這證書進(jìn)行更新，另外還支持撤銷的功能。

這是它的兩種部署方式，一種 K8S 的部署方式，另外如果是虛擬機(jī)，它會(huì)單獨(dú)有一個(gè)節(jié)點(diǎn)代理，通過節(jié)點(diǎn)代理來發(fā)出簽名請(qǐng)求給CA，CA再生成密鑰和證書給代理，代理再來負(fù)責(zé)部署到 Envoy上。

具體的運(yùn)行時(shí)它們都有各自的證書，開始進(jìn)行雙向的 TIS，這時(shí)候會(huì)到名字信息里面去查詢，后端有沒有權(quán)限訪問，如果有的話就往下，沒有就結(jié)束了。

第三步，如果收到一個(gè)客戶端的請(qǐng)求，會(huì)去 Mixer 里面判斷一下，它是白名單上的一個(gè)判斷或者是不是黑名單上的一個(gè)判斷，會(huì)影響“握手”的成功與否。最終它們就形成了安全交互的通道。

上述就是小編為大家分享的istio是怎么連接、管理和保護(hù)微服務(wù)2.0的了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。