在精彩的軟體容器世界中，當新專案湧現並解決你認為早已解決的問題時，這感覺就像地面在你的腳下不斷地移動。在許多情況下，這些問題很久以前被解決，但現在的雲原生架構正在推動著更大規模的應用程式部署，這就需要新的工具和方法。
微服務就是一個很好地例子。在此模型下，典型的應用程式或服務將被分解成可以獨立部署的功能模組，這些功能模組能彼此分開擴充套件和維護，並且連結在一起時可以提供應用或服務的全部功能。
當使用容器來開發微服務時，後一塊可能是棘手的。當它們可能散佈在伺服器節點叢集中時，並且在它們的例項不斷彈出時，隨後被更新版本替換而下線時，該如何將所有元件部分連結起來？在面向服務的架構中（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的監控功能使使用者能夠測量服務之間的實際流量，例如每秒請求數，錯誤率和延遲，還可以生成依賴關係圖，以便使用者可以看到服務之間如何相互影響。
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，而其他供應商則希望自己混合搭配並構建它。
原文地址：
https://www.nextplatform.com/2018/08/15/istio-aims-to-be-the-mesh-plumbing-for-containerized-microservices/