關于Service Mesh迎罗，數(shù)人云之前給大家分享了敖小劍老師的《Qcon2017實錄|Service Mesh：下一代微服務》那么它對于容器相比傳統(tǒng)模式都有哪方面的優(yōu)勢呢？同作為Service Mesh的新生代句伶，Istio v0.2都有哪些添加與改進劲蜻？本文見分曉！
容器仍然是目前極度火熱的話題考余，一些人稱先嬉，通過容器他們正處于崛起的邊緣，成為數(shù)據(jù)中心的主宰楚堤，另外一些人則認為容器只適用于云計算疫蔓，還有一些人在耐心地等待著看容器是不是應用程序基礎設施的SDN，一些權威人士在極力吹捧身冬，但其實很少在生產(chǎn)中付諸實踐衅胀。
通過一些研究和調查可以看到容器確實在吸引著人們的注意：
32%的公司每年花費50萬美元或更多的資金用于容器技術的授權和使用費（Portworx的年度容器采用率調查）
采用容器技術的公司在9個月內將其容器數(shù)量增加5倍（Datadog 8個令人驚訝的事實，關于Docker的采用酥筝。
容器的密度為平均每臺主機10個容器（Sys Docker 使用報告2017）
2017年滚躯，Docker的使用率飆升至35%（2017年云計算報告）
5%的企業(yè)希望采用容器來部署傳統(tǒng)的網(wǎng)絡托管應用服務（F5 Networks State of Application Delivery 2017）
如大多數(shù)的基礎設施——無論是應用還是網(wǎng)絡——在可預見的未來，容器都將與日常運行在大型機和Midranges Alike上的應用程序共存嘿歌，這是應用基礎設施最重要的轉變掸掏，當WEB堆棧上升到主導地位時，它并沒有消除Fat Client-Server應用程序宙帝，至少在一段時間內丧凤，它們是一同運行的。
然而茄唐，它所做的都是迫使我們改變這些應用的規(guī)模息裸，WEB應用程序對網(wǎng)絡及其服務器施加了巨大的壓力蝇更，需要新的方式來擴展容量和確保可用性呼盆，使用容器來部署應用程序——特別是那些使用微服務體系結構的應用年扩。
在容器化環(huán)境和傳統(tǒng)WEB應用程序中使用的擴展模式之間存在著顯著的差異。
傳統(tǒng)模式
無論在云端（公有云访圃、私有云）還是數(shù)據(jù)中心厨幻，傳統(tǒng)的模式都采用了相當標準的模式，它使用固定的“池”資源腿时，配置和行為最終基于端口和IP地址况脆。
負責實際擴展應用程序的軟件（無論部署在特定的目的硬件和是COTS上）都是在一個相當獨立的操作前提下執(zhí)行的，從算法到可用的資源批糟，所有的一切都是按照比例服務的格了。
同時也包括這些資源的狀態(tài)，在傳統(tǒng)的模式中徽鼎，通常是擴展應用盛末，跟蹤資源的健康狀況，并在不可用的情況下進行輪轉否淤。
傳統(tǒng)的規(guī)模模式依賴于命令式的配置模式悄但，并且只有很少的明顯例外（如狀態(tài)）變化是由配置事件驅動的，這意味著一個操作符或外部腳本已經(jīng)發(fā)布了一個非常特定的命令——通過API石抡、CLI或GUI——來更改配置檐嚣。
The Cloud Half-Step
當“自動擴展”的概念出現(xiàn)時，云計算開始影響這個模式啰扛，于大多數(shù)容器化的環(huán)境中嚎京，自動伸縮是傳統(tǒng)模式和服務網(wǎng)格模式之間的一個半步，它融合了環(huán)境變化的概念侠讯，比如增加需求出發(fā)配置更改挖藏，比如添加或刪除資源，然而厢漩，模式仍然是一個“推”模式膜眠，這意味著對規(guī)模負責的系統(tǒng)仍然必須被隱式地告知需要進行的更改。
服務網(wǎng)格模式
容器的管理通常由一些外部系統(tǒng)實現(xiàn)溜嗜，比如Kubernetes或Mesos或Open Shift宵膨，通過一個類似于容器集群的命令和控制中心的“主”控制器，它的職責是管理容器炸宵，并將其保存到最新的目錄中辟躏。
對于給定服務（或應用程序）可用資源的“池”是動態(tài)的，很多東西都是由一個特定容器的實際壽命所做而成土全，但事實是捎琐，跟它們的前輩虛擬機的幾周或者幾個月的壽命相比会涎，可能只有幾分鐘或幾個小時。
這種速度是不可能手動進行跟蹤了瑞凑，這也是為什么服務注冊中心存在的原因——為了保存一個實時列表末秃，列出哪些資源可用，以及它們屬于什么服務籽御。
這是服務網(wǎng)格模式避免將應用程序和服務緊密耦合到IP地址和端口的原因之一练慕，當然，它們仍然被使用技掏，但波動性（以及網(wǎng)絡屬性的重要）要求應用程序和服務必須由其他東西來表示——比如標簽铃将。
然后，真?zhèn)€系統(tǒng)中的所有配置和行為都是基于這些標記的哑梳，它們與FQDNs很相似劲阎。
通過DNS映射到IP地址。
所有這些都導致了需要一個更加協(xié)作的操作前提涧衙，負責擴展容器化應用和服務的軟件哪工，與傳統(tǒng)的模式有很大不同奥此，它們的前提是“我需要其他服務的信息來決定弧哎，而我的目的可能在另一個地方”。
但是不能期望主控制器通知每一個更改的組件稚虎，這種集中式控制不考慮系統(tǒng)中的組件數(shù)量撤嫩，記住，它不只是容器蠢终，除了用于監(jiān)控和報告業(yè)務以及操作分析所需要的遠程數(shù)據(jù)守護進程之外序攘，還存在諸如服務和規(guī)則之類的構造，但擴展軟件仍然需要寻拂，知道什么時候改變（或者資源轉移）程奠。
在服務網(wǎng)格模式中，更改是由其他地方發(fā)布的操作事件所驅動祭钉，擴展軟件的職責是拉出這些更改并對它們進行操作瞄沙，而不是通過腳本或人工操作來實現(xiàn)特定的配置更改。
這意味著更改必須與實現(xiàn)無關慌核，更改不可能是特定的API調用或需要實現(xiàn)的命令距境，他們必須是“什么”而非“如何”。這是一種聲明式的配置模式垮卓，而不是與傳統(tǒng)的規(guī)模模式相關的命令式模式垫桂。
這就意味著：
- 這些變化對網(wǎng)絡的流量產(chǎn)生了相當大的影響
- 傳統(tǒng)的模式可以被看做是一個交通信號燈系統(tǒng)
- 固定的配置
- 限定方向
- 路線預定義
另一方面，一個服務網(wǎng)格模式更類似于現(xiàn)代的交通管理系統(tǒng)：
- 基于實時條件的動態(tài)
- 路徑變量
- 路線靈活
接受這個模式最困難的部分粟按，從作者的個人經(jīng)驗來看诬滩，是在一個服務的設備中有多少移動的部件霹粥，這使得很難從一端（客戶端），到另一端（應用程序）跟蹤數(shù)據(jù)路徑疼鸟，服務于主控制器和服務注冊中心的服務依賴于對路由請求的依賴蒙挑，因為它們對于路由請求的重要性，就像ARP映射表在核心網(wǎng)絡中路由數(shù)據(jù)包一樣重要愚臀。
服務網(wǎng)格模式在那些采用容器的用戶中獲取了極大的興趣和新引力忆蚀，在墻的另一邊，要了解它對網(wǎng)絡的影響姑裂，并準備好管理它馋袜。
Istio v0.2
Istio是Google/IBM/Lyft聯(lián)合開發(fā)的開源項目，2017年5月發(fā)布第一個release 0.1.0舶斧， 官方定義為:
Istio：一個連接欣鳖，管理和保護微服務的開放平臺。
按照Isito文檔中給出的定義:
Istio提供一種簡單的方式來建立已部署的服務的網(wǎng)絡茴厉，具備負載均衡泽台，服務到服務認證，監(jiān)控等等功能矾缓，而不需要改動任何服務代碼怀酷。
——敖小劍《萬字解讀:Service Mesh服務網(wǎng)格新生代--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開發(fā)總體方案中的一個Alpha特性，所以建議謹慎使用束倍。
Traffic Management Improvement
在Istio v0.1中被丧，用戶可以使用Ingress路由規(guī)則來制定想要通過微服務進入的流量，現(xiàn)在肌幽，還可以使用e外出路由規(guī)則來制定想要從微服務中獲得哪些類型的流量晚碾，以及服務可以與哪些外部服務進行通信，例如喂急，用戶可以輕松地配置服務格嘁，與IBM Cloud中的IBM Watson服務之一進行對話，從而為用戶的服務提供人工智能功能廊移。
Improved Telemetry
作為Istio用戶糕簿，無需做任何事情去啟動各種度量或跟蹤探入，這非常簡便，用戶可以部署微服務應用懂诗，讓Istio進行管理蜂嗽，而不需要任何應用程序或部署。Yaml文件殃恒，Zipkin的跟蹤為應用提供了詳細的跟蹤信息植旧，Zipkin的進一步追蹤讓人可以深入到每一個請求中，以查看流量子啊服務網(wǎng)格中如何技術离唐，如果用戶更喜歡Jaeger病附，也提供支持。
多環(huán)境支持
Istio的最初目標之一就是進行多環(huán)境的支持亥鬓，在微服務體系結構中完沪，無法要求所有的工作負載都在Kubernetes中運行，用戶的一些應用程序可能在Kubernetes中運維嵌戈，而另外一些可能在Docker Swarm或者VM中運行覆积，在Istio v0.2中，引入了早期對VM的支持熟呛，并與一些更流行的服務發(fā)現(xiàn)系統(tǒng)進行了集成宽档，Istio已經(jīng)被擴展支持到其他運行時環(huán)境，這是讓人興奮的一件事惰拱。
在Kubernetes環(huán)境中使用Kubectl與Istio進行交互
本文作者最喜歡的一項是Istio v0.2更新了配置的模式雌贱，并使用Kubernetes的自定義資源定義，這意味著用戶現(xiàn)在可以在Kubernetes環(huán)境中使用Kubectl與Istio進行交互偿短，如果有自動的Sidecar注入，在Kuberentes環(huán)境中與Istio互動時馋没，就無需Istioctl了昔逗，當用戶想要首都注入Sidecar或與諸如控制臺和VM等多環(huán)境交互時，Istioctl就變得有用了篷朵。
原文作者：DevCentral
原文鏈接：https://www.tuicool.com/articles/uE3uyyV
