關于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應用程序對網絡及其服務器施加了巨大的壓力，需要新的方式來擴展容量和確?？捎眯裕褂萌萜鱽聿渴饝贸绦颉貏e是那些使用微服務體系結構的應用。
在容器化環境和傳統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
