Istio旨在成為容器化微服務的網格管道

在精彩的軟體容器世界中，當新專案湧現並解決你認為早已解決的問題時，這感覺就像地面在你的腳下不斷地移動。在許多情況下，這些問題很久以前被解決，但現在的雲原生架構正在推動著更大規模的應用程式部署，這就需要新的工具和方法。

微服務就是一個很好地例子。在此模型下，典型的應用程式或服務將被分解成可以獨立部署的功能模組，這些功能模組能彼此分開擴充套件和維護，並且連結在一起時可以提供應用或服務的全部功能。

當使用容器來開發微服務時，後一塊可能是棘手的。當它們可能散佈在伺服器節點叢集中時，並且在它們的例項不斷彈出時，隨後被更新版本替換而下線時，該如何將所有元件部分連結起來？在面向服務的架構中（ SOA ），微服務可以被視為進化的繼承者，這種任務類似於企業服務匯流排（ EBS ）所處理的任務，所以需要的是一種基於雲原生版本的 EBS 。

這是一個相對新的開源專案 Istio 旨在填補的工作。它被正式的描述為服務網格，因為它的其中一部分分佈在由容器管理的基礎架構中，並且它開始著手於滿足服務發現，負載均衡，訊息路由，遙測和監控，以及必不可少的安全等需求。

Istio 源自於谷歌和 IBM 之間的合作，實際上包含了一些現有的元件，特別是由乘車服務公司 Lyft 開發的元件。它以某一種形式存在了至少一年，最終在七月底達到 1.0 版本的里程碑，這意味著它終於被認為足夠成熟，可以作為生產的一部分基礎架構運作。

IBM 研究員兼 IBM 雲端計算技術長 Jason McGee 告訴 The Next Platform ，雲原生態系統已基本確定容器作為打包和執行的核心結構，而 Kubernetes 則作為管理容器的編排系統。但 McGee 解釋說，還有第三塊拼圖還沒有落地，這就是 Istio 的設計點。

“你如何管理在容器平臺上執行的應用程式或服務之間的互動？” McGee 問道。 “如果你正在構建微服務，或者你有一組應用程式，那麼應用程式之間的通訊會產生一大堆有趣的問題。你如何瞭解誰與誰之間進行對話，如何收集有關應用程式之間通訊的資料，如何保護控制哪些服務可以相互通訊的通訊，以及如何使應用程式安全，尤其是我們今天擁有更多種的動態或分散式架構應用程式，你在公有云的何處能安放高質量的元件？ ”

McGee 說他在 IBM 的團隊幾年前已經開始研究這個問題了，當時他遇到了谷歌的同行並發現他們正走在同一條道路上，但 IBM 主要關注流量路由，版本控制和 A/B 測試方面，谷歌則專注於安全和遙測。兩家公司決定合併各自的努力，結果就是 Istio 的產生。

Istio 由以下元件組成：

Envoy ，被描述為邊車代理，它作為代理部署在每個微服務例項旁邊 ;

Mixer ，它是一個核心元件，用於透過 Envoy 代理實施策略，並從中收集遙測指標 ;

Pilot ，負責配置代理 ;

Citadel ，是負責頒發證書的集中元件，它也有自己在每個節點的代理。

Envoy 是由 Lyft 開發的元件，被 McGee 描述為“一種非常輕量的 L4 到 L7 的智慧路由器”，它捕獲來自與其配對的微服務的所有傳入和傳出通訊，作為一種流量的控制方式，執行策略和收集遙測。 Pilot 是 IBM 提供的主要元件，可作為部署在基礎架構中的所有 Envoy 代理的控制平面。

“如果你想象在一個服務網格中，你可能有一百個微服務，如果每個都有多個例項，你可能有數百或數千個這些智慧路由器，你需要一種方法對它們進行全部程式設計，所以 Istio 引入了這個稱為 Pilot 的東西。可以把它想象成程式設計師，所有這些路由器的控制平面。所以你有一個地方可以透過它來程式設計這個服務網路，然後圍繞資料收集進行遙測，圍繞安全進行證書管理，但從根本上說你可以利用這個智慧路由層和這個控制平面來管理它。 ”McGee 解釋道。

Istio 還有自己的 API ，允許使用者將其插入現有的後端系統，例如用於日誌記錄和遙測。

根據谷歌的說法， Istio 的監控功能使使用者能夠測量服務之間的實際流量，例如每秒請求數，錯誤率和延遲，還可以生成依賴關係圖，以便使用者可以看到服務之間如何相互影響。

透過其 Envoy 邊車代理， Istio 還可以在每個服務請求上使用雙向 TLS 身份驗證（ mTLS ），新增傳輸加密並使使用者能夠授權跨基礎架構的每個請求。

Istio 的目的是，它消除了開發人員擔心例項之間的能否安全通訊，解決了控制哪個例項可以與哪些例項進行通訊，以及提供執行諸如金絲雀部署之類功能等需求。如果是釋出新版本的特定微服務的程式碼，最初只更新例項的一部分，直到你對新程式碼執行可靠性感到滿意，再更新其他部分。

應該注意的是，其他服務網格平臺已經存在，例如開源端的 Linkerd 或 Conduit ，而微軟有一項服務，被稱之為 Azure Service Fabric Mesh ，目前作為其雲平臺上的技術預覽。此外，服務網格代表了網路管道上方的抽象層，因此前提是已經為每個容器例項配置了網路介面， IP 地址和其他網路屬性。這通常意味著，無論何時建立新的容器例項，部署微服務還將需要一個單獨的工具來自動配置網路。

然而， IBM 希望 Istio 將成為雲原生工具包的標準組成部分，正如 Kubernetes 那樣， Kubernetes 基於谷歌為自己的內部叢集開發的 Borg 和 Omega 技術和其上面的容器層技術。

“從社群的角度來看，我的期望是 Istio 成為架構的預設部分，就像容器和 Kubernetes 已經成為雲原生架構的預設部分一樣。” McGee 說。為此， IBM 希望將 Istio 與其公有云所提供的 Kubernetes 託管服務以及其內部部署的 IBM Cloud Private 堆疊整合在一起。

“所以，你現在可以執行 Istio ，我們支援現在平臺上執行 Istio ，但期望是在不久的將來，我們將 Istio 內嵌，所以每當使用我們的平臺時， Istio 元件就在那裡，你可以利用它，並且不必負責部署和管理 Istio 本身，只需能夠在應用程式中使用它。” McGee 說。

谷歌已經新增對了 Istio 的支援，儘管只是將其標記為 alpha 版本，作為託管服務的一部分，該服務在其雲平臺上客戶的 Google Kubernetes Engine （ GKE ）叢集中自動安裝和維護。

Istio 也獲得了業內其他公司的支援，尤其是 Red Hat ，幾年前它重新設計了 OpenShift 應用程式平臺，以 Docker 容器和 Kubernetes 為基礎。

Red Hat 的 Istio 產品經理 Brian Redbeard Harrington 表示 Red Hat 打算將服務網格整合到 OpenShift 中，但 Red Hat 希望在正式使用前能看到一些粗糙點的改進，比如支援多租戶技術。

“ Istio 現在的目標是他們所謂的軟多租戶技術，也就是說，我們希望在組織內部可以使用它，以便該組織內的兩個不同的團隊可以使用並信任它，只要沒有一個組的行為過於惡意，他們就不會影響到彼此的服務。透過我們執行 OpenShift Online 的方式，我們讓客戶執行我們從未看過的程式碼，並且必須最後安排這兩個客戶並存，這是一個非常獨特的多租戶挑戰。” Harrington 解釋道。

“我們需要對這個多租戶有更高的信心 ; 我們需要對效能和穩定性有更高的信心。 我們還沒有看到任何攪局者，但我們已經看到了可提供很多價值的領域，包括在進行規模測試和一些自動化迴歸測試方面，我們還在社群層面貢獻了一個名為 Kiali 的專案，視覺化的給出了 Istio 的內部運作，這只是我們所提供的產品的一部分。”他補充道。

換句話說， Istio 是另一種開源工具，可以為那些希望構建雲原生應用程式基礎架構的使用者新增選項選單。像 Red Hat 這樣的供應商將把它融入他們經過測試和支援的企業平臺產品中比如 OpenShift ，而其他供應商則希望自己混合搭配並構建它。