關系圖 需要 技術分享 實例 產品 中一 企業 部署 遇到

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

微服務就是一個很好地例子。在此模型下，典型的應用程序或服務將被分解成可以獨立部署的功能模塊，這些功能模塊能彼此分開擴展和維護，並且鏈接在一起時可以提供應用或服務的全部功能。
當使用容器來開發微服務時，後一塊可能是棘手的。當它們可能散布在服務器節點集群中時，並且在它們的實例不斷彈出時，隨後被更新版本替換而下線時，該如何將所有組件部分鏈接起來？在面向服務的架構中（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，而其他供應商則希望自己混合搭配並構建它。

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