數人云|服務網格新生代Istio進化，與傳統模式相較5大特性更助容器擴展

關於Service Mesh，數人云以前給你們分享了敖小劍老師的《Qcon2017實錄|Service Mesh：下一代微服務》那麼它對於容器相比傳統模式都有哪方面的優點呢？同做爲Service Mesh的新生代，Istio v0.2都有哪些添加與改進？本文見分曉！

容器仍然是目前極度火熱的話題，一些人稱，經過容器他們正處於崛起的邊緣，成爲數據中心的主宰，另一些人則認爲容器只適用於雲計算，還有一些人在耐心地等待着看容器是否是應用程序基礎設施的SDN，一些權威人士在極力吹捧，但其實不多在生產中付諸實踐。

經過一些研究和調查能夠看到容器確實在吸引着人們的注意：

• 32%的公司每一年花費50萬美圓或更多的資金用於容器技術的受權和使用費（Portworx的年度容器採用率調查）

• 採用容器技術的公司在9個月內將其容器數量增長5倍（Datadog 8個使人驚訝的事實，關於Docker的採用。

• 容器的密度爲平均每臺主機10個容器（Sys Docker 使用報告2017）

• 2017年，Docker的使用率飆升至35%（2017年雲計算報告）

• 5%的企業但願採用容器來部署傳統的網絡託管應用服務（F5 Networks State of Application Delivery 2017）

如大多數的基礎設施——不管是應用仍是網絡——在可預見的將來，容器都將與平常運行在大型機和Midranges Alike上的應用程序共存，這是應用基礎設施最重要的轉變，當WEB堆棧上升到主導地位時，它並無消除Fat Client-Server應用程序，至少在一段時間內，它們是一同運行的。

然而，它所作的都是迫使咱們改變這些應用的規模，WEB應用程序對網絡及其服務器施加了巨大的壓力，須要新的方式來擴展容量和確保可用性，使用容器來部署應用程序——特別是那些使用微服務體系結構的應用。

在容器化環境和傳統WEB應用程序中使用的擴展模式之間存在着顯著的差別。

傳統模式

不管在雲端（公有云、私有云）仍是數據中心，傳統的模式都採用了至關標準的模式，它使用固定的「池」資源，配置和行爲最終基於端口和IP地址。

負責實際擴展應用程序的軟件（不管部署在特定的目的硬件和是COTS上）都是在一個至關獨立的操做前提下執行的，從算法到可用的資源，全部的一切都是按照比例服務的。

同時也包括這些資源的狀態，在傳統的模式中，一般是擴展應用，跟蹤資源的健康情況，並在不可用的狀況下進行輪轉。

傳統的規模模式依賴於命令式的配置模式，而且只有不多的明顯例外（如狀態）變化是由配置事件驅動的，這意味着一個操做符或外部腳本已經發布了一個很是特定的命令——經過API、CLI或GUI——來更改配置。

The Cloud Half-Step

當「自動擴展」的概念出現時，雲計算開始影響這個模式，於大多數容器化的環境中，自動伸縮是傳統模式和服務網格模式之間的一個半步，它融合了環境變化的概念，好比增長需求出發配置更改，好比添加或刪除資源，然而，模式仍然是一個「推」模式，這意味着對規模負責的系統仍然必須被隱式地告知須要進行的更改。

服務網格模式

容器的管理一般由一些外部系統實現，好比Kubernetes或Mesos或Open Shift，經過一個相似於容器集羣的命令和控制中心的「主」控制器，它的職責是管理容器，並將其保存到最新的目錄中。

對於給定服務（或應用程序）可用資源的「池」是動態的，不少東西都是由一個特定容器的實際壽命所作而成，但事實是，跟它們的前輩虛擬機的幾周或者幾個月的壽命相比，可能只有幾分鐘或幾個小時。

這種速度是不可能手動進行跟蹤了，這也是爲何服務註冊中心存在的緣由——爲了保存一個實時列表，列出哪些資源可用，以及它們屬於什麼服務。

這是服務網格模式避免將應用程序和服務緊密耦合到IP地址和端口的緣由之一，固然，它們仍然被使用，但波動性（以及網絡屬性的重要）要求應用程序和服務必須由其餘東西來表示——好比標籤。

而後，真個系統中的全部配置和行爲都是基於這些標記的，它們與FQDNs很類似。

經過DNS映射到IP地址。

全部這些都致使了須要一個更加協做的操做前提，負責擴展容器化應用和服務的軟件，與傳統的模式有很大不一樣，它們的前提是「我須要其餘服務的信息來決定，而個人目的可能在另外一個地方」。

可是不能指望主控制器通知每個更改的組件，這種集中式控制不考慮系統中的組件數量，記住，它不僅是容器，除了用於監控和報告業務以及操做分析所須要的遠程數據守護進程以外，還存在諸如服務和規則之類的構造，但擴展軟件仍然須要，知道何時改變（或者資源轉移）。

在服務網格模式中，更改是由其餘地方發佈的操做事件所驅動，擴展軟件的職責是拉出這些更改並對它們進行操做，而不是經過腳本或人工操做來實現特定的配置更改。

這意味着更改必須與實現無關，更改不多是特定的API調用或須要實現的命令，他們必須是「什麼」而非「如何」。這是一種聲明式的配置模式，而不是與傳統的規模模式相關的命令式模式。

這就意味着：

• 這些變化對網絡的流量產生了至關大的影響
• 傳統的模式能夠被看作是一個交通訊號燈系統

• 固定的配置
• 限定方向
• 路線預約義

另外一方面，一個服務網格模式更相似於現代的交通管理系統：

• 基於實時條件的動態
• 路徑變量
• 路線靈活

接受這個模式最困難的部分，從做者的我的經驗來看，是在一個服務的設備中有多少移動的部件，這使得很難從一端（客戶端），到另外一端（應用程序）跟蹤數據路徑，服務於主控制器和服務註冊中心的服務依賴於對路由請求的依賴，由於它們對於路由請求的重要性，就像ARP映射表在覈心網絡中路由數據包同樣重要。

服務網格模式在那些採用容器的用戶中獲取了極大的興趣和新引力，在牆的另外一邊，要了解它對網絡的影響，並準備好管理它。

Istio v0.2

Istio是Google/IBM/Lyft聯合開發的開源項目，2017年5月發佈第一個release 0.1.0， 官方定義爲:

Istio：一個鏈接，管理和保護微服務的開放平臺。

按照Isito文檔中給出的定義:

Istio提供一種簡單的方式來創建已部署的服務的網絡，具有負載均衡，服務到服務認證，監控等等功能，而不須要改動任何服務代碼。

——敖小劍《萬字解讀:Service Mesh服務網格新生代--Istio》

Istio v0.2添加不少新的功能以及改建，下面來談一談，Istio v0.2讓人激動的5大改進：

Automatic Sidecar Injection

對於自定義資源和初始化器的支持，Istio v0.2要求Kubernetes1.7.4或更新，若是集羣中啓用了I nitializer Alpha特性，建議安裝Istio初始化器，它爲全部想要的Istio管理的微服務部署注入了自動的Sidecar。IBM Bluemix容器服務集羣在1.7.4或更新時自動運行，這與Istio初始化器很好地工做，因爲仍然是Istio開發整體方案中的一個Alpha特性，因此建議謹慎使用。

Traffic Management Improvement

在Istio v0.1中，用戶可使用Ingress路由規則來制定想要經過微服務進入的流量，如今，還可使用e外出路由規則來制定想要從微服務中得到哪些類型的流量，以及服務能夠與哪些外部服務進行通訊，例如，用戶能夠輕鬆地配置服務，與IBM Cloud中的IBM Watson服務之一進行對話，從而爲用戶的服務提供人工智能功能。

Improved Telemetry

做爲Istio用戶，無需作任何事情去啓動各類度量或跟蹤，這很是簡便，用戶能夠部署微服務應用，讓Istio進行管理，而不須要任何應用程序或部署。Yaml文件，Zipkin的跟蹤爲應用提供了詳細的跟蹤信息，Zipkin的進一步追蹤讓人能夠深刻到每個請求中，以查看流量子啊服務網格中如何技術，若是用戶更喜歡Jaeger，也提供支持。

多環境支持

Istio的最初目標之一就是進行多環境的支持，在微服務體系結構中，沒法要求全部的工做負載都在Kubernetes中運行，用戶的一些應用程序可能在Kubernetes中運維，而另一些可能在Docker Swarm或者VM中運行，在Istio v0.2中，引入了早期對VM的支持，並與一些更流行的服務發現系統進行了集成，Istio已經被擴展支持到其餘運行時環境，這是讓人興奮的一件事。

在Kubernetes環境中使用Kubectl與Istio進行交互

本文做者最喜歡的一項是Istio v0.2更新了配置的模式，並使用Kubernetes的自定義資源定義，這意味着用戶如今能夠在Kubernetes環境中使用Kubectl與Istio進行交互，若是有自動的Sidecar注入，在Kuberentes環境中與Istio互動時，就無需Istioctl了，當用戶想要首都注入Sidecar或與諸如控制檯和VM等多環境交互時，Istioctl就變得有用了。

原文做者：DevCentral 原文連接：https://www.tuicool.com/articles/uE3uyyV