istio是怎么連接、管理和保護微服務2.0的

這期內容當中小編將會給大家帶來有關istio是怎么連接、管理和保護微服務2.0的，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

一、分布式計算的八個謬論

彼得多維奇多年前提出的分布式計算的八個謬論，對于開發人員來說他們往往會忽視這八條。這八條基本上都和網絡相關，例如在發起一個網絡請求時，會不斷地做一些嘗試等待，來保障消息投遞的有效性。

微服務是一個更為復雜的分布式系統，之前 SOA 或者B/S，CS 架構，它的顆粒度會更粗一點，但是如果采用微服務，它的顆粒度是更細的。在馬丁·富勒博客《微服務的先決條件是什么》一文中提到一條，你必須要成為“高個子”，想成為“高個子”其實并不簡單，很多公司，它們都是為了成為“高個子”，做了很多框架、平臺。

二、服務治理

1微服務治理的技術點

要成為“高個子”需要對微服務進行哪些改造，這里是相關服務治理的技術點，其中只是一部分，和服務網格比較相關的技術點，包含服務發現、負載均衡、請求路由、認證與授權、可觀測性，還有健康檢查、容錯等。目前主流的解決方案有眾所周知的 Spring Cloud， Dubbo 等，這些都是提供庫來把服務治理相關的內容打包，供具體的業務去調用。

2庫或框架的問題

但是庫和框架會存在一些問題：

 1、學習成本。多一個庫對于開發人員而言，意味著要多學一些東西，并且在業務開發過程中，還會受到庫或者框架的制約。

2、對業務代碼的侵入性。例如用 Spring Cloud 會在代碼里面加很多額外的內容，比如每個請求里面加一個注解來表達想引用服務治理的某些功能。

3、基礎庫的維護、升級和下線。如果是以庫的方式來提升到服務里面，庫的維護、升級、下線就會造成整個服務的維護、升級、下線。

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

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

這時候怎么去做呢？就引出了容器經典部署模式——Sidecar。

3Sidecar模式

Sidecar 模式通常是和容器一起使用，如果不和容器一起使用也沒關系，那就是兩個獨立的進程，如果和容器使用的話，就基于容器為單位。Sidecar模式是物理隔離的，并且與語言無關。因為是兩個獨立的東西，可以獨立發布，和微服務理念一樣。另外它們是部署在同一個 Host 上面，所以資源之間可以做到相互訪問，并且因為在一起所以通信延遲也不會太明顯。和業務無關的功能都可以放上去，形成多個 Sidecar。今天 Sidecar 主要是把一些服務治理相關的東西放在里面，做軟件設計上的思想就是分離關注點。

基于 Sidecar 模式做服務治理，之后形成連接的具體狀況，如圖，對于服務A來說，服務A是不知道和 Sidecar 進行通信，服務A還是向服務B發消息，照常調用通信接口，但是消息可能會被 Sidecar 捕獲到，然后通過Sidecar 進行轉發。

三、服務網格

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

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

四、Istio架構

一句話定義 Istio：一個用來連接、管理和保護微服務的開放平臺。剛才也說了 Istio 是 Google 開發的，所以 Istio 今后的趨勢肯定是會越來越火的，并且目前 K8S 已經把它集成到里面了，做成一個可選的組件。

對于連接而言，Istio 它主要包含彈性、服務發現、負載均衡，管理是流量控制、策略增強，監控也有，并且安全這塊 Istio 也是有考慮，Istio 是端到端的身份驗證和授權，等一下會詳細的介紹。

Istio的關鍵特性:

1、智能路由和負載均衡。這里的智能路由和負載均衡是屬于比較高級的，不是像傳統簡單的隨機負載均衡，而是可以基于一些數據包內部的內容來進行負載均衡。

2、跨語言和平臺的彈性。對于平臺來說 Istio 是支持各種各樣的平臺，并且能支持A/B測試，金絲雀發布，并使用藍綠部署運維上的一些高級功能。

3、全面策略執行。Istio 有一個組件是專門負責保障策略能夠通過一個組件下發到具體的數據面板。

4、遙測和上報。即具體的測量以及流量的監控等。

這個就是 Istio 整個的系統架構，如圖，上面是控制面板，下面是很多數據 Envoy，很多個代理，形成一個數據面板。后面我們會對單個進行詳細介紹。

這是在 K8S 下面 Istio 部署的示意圖，可以看到它們之間最關鍵的東西是所有服務和組件都會有一個代理，這代理是必備的，包括控制面板都會有代理。沒有畫的有兩個東西，一個是 Ingress，一個是初始化器，初始化器主要是做代理注入。它們之間相互的交互都是通過加密，由TLS協議來完成。

五、Istio組件

1數據面板Envoy

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

Envoy 的目標是透明地處理集群內服務間、從服務到外部服務之間的出入口流量。Envoy 是用C++編寫的，高并行、非阻塞。并且是可裝卸的L3/4過濾器，以及L7的過濾器，最終會形成一個過濾鏈來對流量進行管理或者控制，Envoy 是通過 xDS 動態配置來進行接口提供。

下面就是一些固有的功能，服務發現、健康檢查。Envoy 的健康檢查也做的顆粒度比較細，包含主動健康檢查和被動健康檢查。主動健康檢查像常規的健康檢查，主動地發一個健康檢查的接口調用請求，查詢一下。被動的是通過對其他服務的一些請求，從一些返回值進行健康檢查。當然還包含高級的負載均衡，監控、跟蹤這些功能。

Envoy最關鍵的三個點：

• 高性能。一直在強調的是數據面板必須要高性能，因為是要和業務服務部署在一起的。

• 可擴展。

• 可配置。具有動態配置的特性。

Envoy 是如何做到高性能的？

Envoy 的線程模型分為三類線程，如果做過C++開發，這種單進程多線程的架構是很常見的。Envoy 分為主線程、工作線程、文件刷新線程，其中主線程就是負責工作線程和文件刷新線程的管理和調度。而工作線程主要負責監聽、過濾和轉發，工作線程里面會包含一個監聽器，如果收到一個請求之后會通過剛才所介紹的過濾鏈來進行數據過濾。前面兩個都是非阻塞的，唯一一個阻塞的是這種 IO 操作的，會不斷地把內存里面一些緩存進行落盤。

服務網格所強調的另外一個功能，是動態配置不用重啟，實際上是重啟的，它會啟動一個新的進程，然后在這進程之上進行新的策略，還有一些初始化，這時候再請求監聽，之前那個進程的 socket 副本。當老的關閉鏈接以及退出之后，它才會接收新的，這時候就實現了對用戶沒有感知的重啟。

這就是它的 xDS，如圖，可以看到它的密度是非常細的，

• 終端發現服務（EDS），實際上就是服務的發現服務；

• 集群發現服務（CDS）是為了發現集群；

• 路由發現服務（RDS）是為了對路由進行一些處理；

• 監聽器（LDS）來動態地添加、更新、刪除監聽器，包括過濾鏈的一些管理、維護。

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

• 還有聚合（ADS）是對于監控指標進行聚合的接口；

• 另外一個密鑰發現（KDS）是和安全相關的。

   

首先，如果來了一個請求，會到剛才所說的工作線程里面去，工作線程會有監聽器，收到之后進行一些處理，然后要往外發，這時會調用路由的發現功能，然后再找到相應的集群，再通過這個集群找到相應的服務，一層一層的往下面調用。

2控制面板Pilot

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

Pilot 是運行時的代理配置，剛才所說的 xDS，就是用 Pilot 來進行調用，負責把相應的一些策略，失敗恢復的特性派發下去。Pilot 是負責管理所有的這些代理，代理和管理就通過 Pilot 來完成，是平臺無關的一個拓撲模型。目前主要支持的是 K8S。

Pilot 是一層抽象的獨立于底層平臺的模型，因為這里有個代理，對于多平臺或多樣性的管理架構，即適配器的架構。平臺特定的適配器負責適當填充這些規范，要通過具體平臺的適配器形成一些規范，和通用的模型結合，生成必須要往 Envoy 下發的數據，并且配置、推送都是由 Pilot 來完成的。

Pilot 的整個服務發現和負載均衡，如圖，Pilot 是Kubernetes DNS提供的域名進行訪問，首先調用 Service B 的url，這時候 Envoy 會進行截獲并處理，處理完之后會找到相應的負載均衡的池子挑選一個進行流量下發。Pilot 目前支持的這種負載均衡的方法，規劃了很多種。但目前只實現了三種，前兩種還是隨機和輪循，多了一個最小請求的負載均衡算法。它能找到這些 Pilot 里面哪個被調用的最少，然后進行調用。

Pilot 的一些規則配置，可以看到基本是負責規則的管理以及下發。

• 路由規則。

• 目的地策略。主要包含負載均衡的算法，以及對于負載均衡算法抽象的策略預演。

• 出站規則。

把這些規則分了三類，好處是對這三類都會生成一些模板。

流量的拆分可以看到是基于標簽的流量拆分，這里配置的如版本，環境，環境類型，它根據這個規則來進行流量的派發。比如說99%都發給之前版本，新版本先1%先測一下，類似于A/B測試。

另外一個比較高級的是基于內容，因為它是L7的這種過濾，可以基于內容來過濾，并且支持表達式，這種將iPhone的流量全部導到新的服務里面去，并且有標簽，版本必須得是金絲雀版本。

3混合器Mixer

Mixer 是在應用代碼和基礎架構之間提供一個中間層，來隔離 Enovy 和后臺基礎設施，這里的后臺是指 Promethus，ELK 這些。

Mixer 有三個核心特性：

• 先決條件檢查。負責白名單以及 ACL檢測；

• 配額管理。負責這種使用頻率上的控制；

• 遙測報告。

總共分為兩類，在生成配置模板的時候它是有兩類的，第一類就是負責檢查check，第二類就是負責報告reporter。

Mixer 是采用通用的插件模型以實現高擴展性，插件被稱為適配器。運維人員下發一些配置到這里面，這些模板又是由模板開發人員進行開發的，Istio提供了很多通用性的模板，上面簡單地改造一下就能做出一個模板來。適配器也有很多種，各種后臺、平臺的都有。

Mixer 是抽象了不同后端的策略，遙測系統的細節，它就對這兩個東西進行了抽象，形成了一套抽象的東西。

剛才介紹過適配器，再來介紹一下處理器，它是配置好的適配器，由運維人員進行配置，之后形成最終的處理器，負責真正往后臺發東西。

它封裝了與后端接口所需的邏輯，指定了配置規格，以及適配器。如果要在后臺進行消息交互的話，所需要的操作參數在這里也會定義。而右邊就是兩個模板，第一個模板是 Prometheus，它是一個處理器，下面是它的一些指標。另外一個是白名單檢查的模板，提供URL，以及它請求的接口返回值。

剛才介紹了整個通路是怎么打通的，包括適配器和處理器都是為了干這個事情，這個通路怎么建立？接下來要介紹的是這個參數怎么生成，它是請求屬性到一個模板的映射結果。

Mixer 會收到 Envoy 發過來的很多屬性（請求），請求里面包含的數據都稱之為屬性。通過它的模板來生成相應的具體參數，這邊也是剛才兩個例子里面對應的模板。上面是度量指標采集用的，下面是白名單。

這里有個遙測報告的示例，當收到一個請求之后會發生什么。它會以屬性的形式，這邊有個 Zipk，就直接上報了，這是因為 Envoy 原生的就支持Zipk。Envoy 支持后端監控的東西，就是 Zipk，所以它可以直接發給它。其他的需要通過 Mixer 來進行轉發。

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

4密鑰管理

最后要介紹的就是安全相關的，Certificate Authority 這塊，這是整個密鑰管理的示意圖，可以看到服務和 Envoy 是通過 TCP 進行交互的，但是Envoy 和 Envoy 之間是通過 MTIS 進行加密，是雙向的 TIS 加密。它的好處是，會在內部的每一個服務節點之間做加密，當然這是可選的，根據性能的需求來進行選擇。

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

這是它的兩種部署方式，一種 K8S 的部署方式，另外如果是虛擬機，它會單獨有一個節點代理，通過節點代理來發出簽名請求給CA，CA再生成密鑰和證書給代理，代理再來負責部署到 Envoy上。

具體的運行時它們都有各自的證書，開始進行雙向的 TIS，這時候會到名字信息里面去查詢，后端有沒有權限訪問，如果有的話就往下，沒有就結束了。

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

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