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

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

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

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

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

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

容器的密度為平均每臺(tái)主機(jī)10個(gè)容器（Sys Docker 使用報(bào)告2017）

2017年，Docker的使用率飆升至35%（2017年云計(jì)算報(bào)告）

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ù)見的未來，容器都將與日常運(yùn)行在大型機(jī)和Midranges Alike上的應(yīng)用程序共存，這是應(yīng)用基礎(chǔ)設(shè)施最重要的轉(zhuǎn)變，當(dāng)WEB堆棧上升到主導(dǎo)地位時(shí)，它并沒有消除Fat Client-Server應(yīng)用程序，至少在一段時(shí)間內(nèi)，它們是一同運(yùn)行的。

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

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

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

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

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

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

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

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

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

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

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

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

通過DNS映射到IP地址。

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

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

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

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

這就意味著：

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

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

固定的配置

限定方向

路線預(yù)定義

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

基于實(shí)時(shí)條件的動(dòng)態(tài)

路徑變量

路線靈活

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

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

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

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

Istio v0.2添加很多新的功能以及改建，下面來談一談，Istio v0.2讓人激動(dòng)的5大改進(jìn)：

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

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

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

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

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

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