摘要：敖小劍萬字解讀服務(wù)網(wǎng)格新生代添加很多新的功能以及改建，下面來談一談，讓人激動的大改進對于自定義資源和初始化器的支持，要求或更新，如果集群中啟用了特性，建議安裝初始化器，它為所有想要的管理的微服務(wù)部署注入了自動的。

關(guān)于Service Mesh，數(shù)人云之前給大家分享了敖小劍老師的《Qcon2017實錄|Service Mesh：下一代微服務(wù)》那么它對于容器相比傳統(tǒng)模式都有哪方面的優(yōu)勢呢？同作為Service Mesh的新生代，Istio v0.2都有哪些添加與改進？本文見分曉！

容器仍然是目前極度火熱的話題，一些人稱，通過容器他們正處于崛起的邊緣，成為數(shù)據(jù)中心的主宰，另外一些人則認為容器只適用于云計算，還有一些人在耐心地等待著看容器是不是應(yīng)用程序基礎(chǔ)設(shè)施的SDN，一些權(quán)威人士在極力吹捧，但其實很少在生產(chǎn)中付諸實踐。

通過一些研究和調(diào)查可以看到容器確實在吸引著人們的注意：

32%的公司每年花費50萬美元或更多的資金用于容器技術(shù)的授權(quán)和使用費（Portworx的年度容器采用率調(diào)查）

采用容器技術(shù)的公司在9個月內(nèi)將其容器數(shù)量增加5倍（Datadog 8個令人驚訝的事實，關(guān)于Docker的采用。

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

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

5%的企業(yè)希望采用容器來部署傳統(tǒng)的網(wǎng)絡(luò)托管應(yīng)用服務(wù)（F5 Networks State of Application Delivery 2017）

如大多數(shù)的基礎(chǔ)設(shè)施——無論是應(yīng)用還是網(wǎng)絡(luò)——在可預(yù)見的未來，容器都將與日常運行在大型機和Midranges Alike上的應(yīng)用程序共存，這是應(yīng)用基礎(chǔ)設(shè)施最重要的轉(zhuǎn)變，當(dāng)WEB堆棧上升到主導(dǎo)地位時，它并沒有消除Fat Client-Server應(yīng)用程序，至少在一段時間內(nèi)，它們是一同運行的。

然而，它所做的都是迫使我們改變這些應(yīng)用的規(guī)模，WEB應(yīng)用程序?qū)W(wǎng)絡(luò)及其服務(wù)器施加了巨大的壓力，需要新的方式來擴展容量和確?？捎眯裕褂萌萜鱽聿渴饝?yīng)用程序——特別是那些使用微服務(wù)體系結(jié)構(gòu)的應(yīng)用。

在容器化環(huán)境和傳統(tǒng)WEB應(yīng)用程序中使用的擴展模式之間存在著顯著的差異。

無論在云端（公有云、私有云）還是數(shù)據(jù)中心，傳統(tǒng)的模式都采用了相當(dāng)標準的模式，它使用固定的“池”資源，配置和行為最終基于端口和IP地址。

負責(zé)實際擴展應(yīng)用程序的軟件（無論部署在特定的目的硬件和是COTS上）都是在一個相當(dāng)獨立的操作前提下執(zhí)行的，從算法到可用的資源，所有的一切都是按照比例服務(wù)的。

同時也包括這些資源的狀態(tài)，在傳統(tǒng)的模式中，通常是擴展應(yīng)用，跟蹤資源的健康狀況，并在不可用的情況下進行輪轉(zhuǎn)。

傳統(tǒng)的規(guī)模模式依賴于命令式的配置模式，并且只有很少的明顯例外（如狀態(tài)）變化是由配置事件驅(qū)動的，這意味著一個操作符或外部腳本已經(jīng)發(fā)布了一個非常特定的命令——通過API、CLI或GUI——來更改配置。

當(dāng)“自動擴展”的概念出現(xiàn)時，云計算開始影響這個模式，于大多數(shù)容器化的環(huán)境中，自動伸縮是傳統(tǒng)模式和服務(wù)網(wǎng)格模式之間的一個半步，它融合了環(huán)境變化的概念，比如增加需求出發(fā)配置更改，比如添加或刪除資源，然而，模式仍然是一個“推”模式，這意味著對規(guī)模負責(zé)的系統(tǒng)仍然必須被隱式地告知需要進行的更改。

容器的管理通常由一些外部系統(tǒng)實現(xiàn)，比如Kubernetes或Mesos或Open Shift，通過一個類似于容器集群的命令和控制中心的“主”控制器，它的職責(zé)是管理容器，并將其保存到最新的目錄中。

對于給定服務(wù)（或應(yīng)用程序）可用資源的“池”是動態(tài)的，很多東西都是由一個特定容器的實際壽命所做而成，但事實是，跟它們的前輩虛擬機的幾周或者幾個月的壽命相比，可能只有幾分鐘或幾個小時。

這種速度是不可能手動進行跟蹤了，這也是為什么服務(wù)注冊中心存在的原因——為了保存一個實時列表，列出哪些資源可用，以及它們屬于什么服務(wù)。

這是服務(wù)網(wǎng)格模式避免將應(yīng)用程序和服務(wù)緊密耦合到IP地址和端口的原因之一，當(dāng)然，它們?nèi)匀槐皇褂?，但波動性（以及網(wǎng)絡(luò)屬性的重要）要求應(yīng)用程序和服務(wù)必須由其他東西來表示——比如標簽。

然后，真?zhèn)€系統(tǒng)中的所有配置和行為都是基于這些標記的，它們與FQDNs很相似。

通過DNS映射到IP地址。

所有這些都導(dǎo)致了需要一個更加協(xié)作的操作前提，負責(zé)擴展容器化應(yīng)用和服務(wù)的軟件，與傳統(tǒng)的模式有很大不同，它們的前提是“我需要其他服務(wù)的信息來決定，而我的目的可能在另一個地方”。

但是不能期望主控制器通知每一個更改的組件，這種集中式控制不考慮系統(tǒng)中的組件數(shù)量，記住，它不只是容器，除了用于監(jiān)控和報告業(yè)務(wù)以及操作分析所需要的遠程數(shù)據(jù)守護進程之外，還存在諸如服務(wù)和規(guī)則之類的構(gòu)造，但擴展軟件仍然需要，知道什么時候改變（或者資源轉(zhuǎn)移）。

在服務(wù)網(wǎng)格模式中，更改是由其他地方發(fā)布的操作事件所驅(qū)動，擴展軟件的職責(zé)是拉出這些更改并對它們進行操作，而不是通過腳本或人工操作來實現(xiàn)特定的配置更改。

這意味著更改必須與實現(xiàn)無關(guān)，更改不可能是特定的API調(diào)用或需要實現(xiàn)的命令，他們必須是“什么”而非“如何”。這是一種聲明式的配置模式，而不是與傳統(tǒng)的規(guī)模模式相關(guān)的命令式模式。

這就意味著：

這些變化對網(wǎng)絡(luò)的流量產(chǎn)生了相當(dāng)大的影響

傳統(tǒng)的模式可以被看做是一個交通信號燈系統(tǒng)

固定的配置

限定方向

路線預(yù)定義

另一方面，一個服務(wù)網(wǎng)格模式更類似于現(xiàn)代的交通管理系統(tǒng)：

基于實時條件的動態(tài)

路徑變量

路線靈活

接受這個模式最困難的部分，從作者的個人經(jīng)驗來看，是在一個服務(wù)的設(shè)備中有多少移動的部件，這使得很難從一端（客戶端），到另一端（應(yīng)用程序）跟蹤數(shù)據(jù)路徑，服務(wù)于主控制器和服務(wù)注冊中心的服務(wù)依賴于對路由請求的依賴，因為它們對于路由請求的重要性，就像ARP映射表在核心網(wǎng)絡(luò)中路由數(shù)據(jù)包一樣重要。

服務(wù)網(wǎng)格模式在那些采用容器的用戶中獲取了極大的興趣和新引力，在墻的另一邊，要了解它對網(wǎng)絡(luò)的影響，并準備好管理它。

Istio是Google/IBM/Lyft聯(lián)合開發(fā)的開源項目，2017年5月發(fā)布第一個release 0.1.0， 官方定義為:
Istio：一個連接，管理和保護微服務(wù)的開放平臺。
按照Isito文檔中給出的定義:
Istio提供一種簡單的方式來建立已部署的服務(wù)的網(wǎng)絡(luò)，具備負載均衡，服務(wù)到服務(wù)認證，監(jiān)控等等功能，而不需要改動任何服務(wù)代碼。

——敖小劍《萬字解讀:Service Mesh服務(wù)網(wǎng)格新生代--Istio》

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

對于自定義資源和初始化器的支持，Istio v0.2要求Kubernetes1.7.4或更新，如果集群中啟用了I nitializer Alpha特性，建議安裝Istio初始化器，它為所有想要的Istio管理的微服務(wù)部署注入了自動的Sidecar。IBM Bluemix容器服務(wù)集群在1.7.4或更新時自動運行，這與Istio初始化器很好地工作，由于仍然是Istio開發(fā)總體方案中的一個Alpha特性，所以建議謹慎使用。

在Istio v0.1中，用戶可以使用Ingress路由規(guī)則來制定想要通過微服務(wù)進入的流量，現(xiàn)在，還可以使用e外出路由規(guī)則來制定想要從微服務(wù)中獲得哪些類型的流量，以及服務(wù)可以與哪些外部服務(wù)進行通信，例如，用戶可以輕松地配置服務(wù)，與IBM Cloud中的IBM Watson服務(wù)之一進行對話，從而為用戶的服務(wù)提供人工智能功能。

作為Istio用戶，無需做任何事情去啟動各種度量或跟蹤，這非常簡便，用戶可以部署微服務(wù)應(yīng)用，讓Istio進行管理，而不需要任何應(yīng)用程序或部署。Yaml文件，Zipkin的跟蹤為應(yīng)用提供了詳細的跟蹤信息，Zipkin的進一步追蹤讓人可以深入到每一個請求中，以查看流量子啊服務(wù)網(wǎng)格中如何技術(shù)，如果用戶更喜歡Jaeger，也提供支持。

Istio的最初目標之一就是進行多環(huán)境的支持，在微服務(wù)體系結(jié)構(gòu)中，無法要求所有的工作負載都在Kubernetes中運行，用戶的一些應(yīng)用程序可能在Kubernetes中運維，而另外一些可能在Docker Swarm或者VM中運行，在Istio v0.2中，引入了早期對VM的支持，并與一些更流行的服務(wù)發(fā)現(xiàn)系統(tǒng)進行了集成，Istio已經(jīng)被擴展支持到其他運行時環(huán)境，這是讓人興奮的一件事。

本文作者最喜歡的一項是Istio v0.2更新了配置的模式，并使用Kubernetes的自定義資源定義，這意味著用戶現(xiàn)在可以在Kubernetes環(huán)境中使用Kubectl與Istio進行交互，如果有自動的Sidecar注入，在Kuberentes環(huán)境中與Istio互動時，就無需Istioctl了，當(dāng)用戶想要首都注入Sidecar或與諸如控制臺和VM等多環(huán)境交互時，Istioctl就變得有用了。

原文作者：DevCentral
原文鏈接：https://www.tuicool.com/artic...