容器雲技術：容器化微服務，Istio佔C位出道

在精彩的軟件容器世界中，當新項目涌現並解決你認爲早已解決的問題時，這感受就像地面在你的腳下不斷地移動。在許多狀況下，這些問題好久之前被解決，但如今的雲原生架構正在推進着更大規模的應用程序部署，這就須要新的工具和方法。

微服務就是一個很好地例子。在此模型下，典型的應用程序或服務將被分解成能夠獨立部署的功能模塊，這些功能模塊能彼此分開擴展和維護，而且連接在一塊兒時能夠提供應用或服務的所有功能。

當使用容器來開發微服務時，後一塊多是棘手的。當它們可能散佈在服務器節點集羣中時，而且在它們的實例不斷彈出時，隨後被更新版本替換而下線時，該如何將全部組件部分連接起來？在面向服務的架構中（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/---------------------