Service Mesh新秀卸夕，初出茅廬便聲勢浩蕩逝慧，前有Google衬浑，IBM和Lyft傾情奉獻捌浩，后有業(yè)界大佬俯首膜拜，這就是今天將要介紹的主角工秩，扛起Service Mesh大旗尸饺，掀起新一輪微服務開發(fā)浪潮的Istio！

講師簡介：

敖小劍助币，十五年軟件開發(fā)經(jīng)驗浪听，微服務專家，專注于基礎(chǔ)架構(gòu)眉菱，cloud native擁護者迹栓，敏捷實踐者。曾在亞信俭缓，愛立信克伊，唯品會和ppmoney任職, 現(xiàn)任數(shù)人云資深架構(gòu)師。

以下內(nèi)容為敖小劍在9月21號晚上進行的線上分享實錄华坦。

今天的主角名叫 Istio愿吹，估計很多同學在此之前可能完全沒有聽過這個名字。請不必介意惜姐，沒聽過很正常犁跪，因為Istio的確是一個非常新的東西椿息，出世也才四個月而已。

今天的內(nèi)容將會分成三個部分:

• 介紹： 讓大家了解Istio是什么坷衍，以及有什么好處寝优，以及Istio背后的開發(fā)團隊
• 架構(gòu)： 介紹Istio的整體架構(gòu)和四個主要功能模塊的具體功能，這塊內(nèi)容會比較偏技術(shù)
• 展望： 介紹Istio的后續(xù)開發(fā)計劃枫耳，探討未來的發(fā)展預期

介紹

Istio是什么：

Istio是Google/IBM/Lyft聯(lián)合開發(fā)的開源項目乏矾，2017年5月發(fā)布第一個release 0.1.0， 官方定義為:

Istio：一個連接嘉涌，管理和保護微服務的開放平臺妻熊。

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

Istio提供一種簡單的方式來建立已部署的服務的網(wǎng)絡，具備負載均衡仑最，服務到服務認證扔役，監(jiān)控等等功能，而不需要改動任何服務代碼警医。

簡單的說亿胸，有了Istio，你的服務就不再需要任何微服務開發(fā)框架（典型如Spring Cloud预皇，Dubbo）侈玄，也不再需要自己動手實現(xiàn)各種復雜的服務治理的功能（很多是Spring Cloud和Dubbo也不能提供的，需要自己動手）吟温。只要服務的客戶端和服務器可以進行簡單的直接網(wǎng)絡訪問序仙，就可以通過將網(wǎng)絡層委托給Istio，從而獲得一系列的完備功能鲁豪。

可以近似的理解為：

Istio = 微服務框架 + 服務治理

名字和圖標：

Istio來自希臘語潘悼，英文意思是”Sail”， 翻譯為中文是“啟航”爬橡。它的圖標如下:

Markdown

可以類比Google的另外一個相關(guān)產(chǎn)品：Kubernetes治唤，名字也是同樣起源于古希臘，是船長或者駕駛員的意思糙申。下圖是Kubernetes的圖標：

Markdown

后面會看到宾添，Istio和Kubernetes的關(guān)系，就像它們的名字和圖標一樣柜裸， 可謂”一脈相傳”缕陕。

主要特性：

Istio的關(guān)鍵功能:

• HTTP/1.1，HTTP/2疙挺，gRPC和TCP流量的自動區(qū)域感知負載平衡和故障切換榄檬。
• 通過豐富的路由規(guī)則，容錯和故障注入衔统，對流行為的細粒度控制。
• 支持訪問控制，速率限制和配額的可插拔策略層和配置API锦爵。
• 集群內(nèi)所有流量的自動量度舱殿，日志和跟蹤，包括集群入口和出口险掀。
• 安全的服務到服務身份驗證沪袭，在集群中的服務之間具有強大的身份標識。
• 這些特性在稍后的架構(gòu)章節(jié)時會有介紹樟氢。

為什么要使用Istio

在深入Istio細節(jié)之前冈绊，先來看看，為什么要使用Istio埠啃？它可以幫我們解決什么問題?

微服務的兩面性

最近兩三年來微服務方興未艾死宣， 可以看到越來越多的公司和開發(fā)人員陸陸續(xù)續(xù)投身到微服務架構(gòu)， 讓一個一個的微服務項目落地碴开。

但是毅该，在這一片叫好的喧鬧中， 我們還是發(fā)覺一些普遍存在的問題：雖然微服務對開發(fā)進行了簡化潦牛，通過將復雜系統(tǒng)切分為若干個微服務來分解和降低復雜度眶掌，使得這些微服務易于被小型的開發(fā)團隊所理解和維護。但是巴碗，復雜度并非從此消失朴爬。微服務拆分之后，單個微服務的復雜度大幅降低橡淆，但是由于系統(tǒng)被從一個單體拆分為幾十甚至更多的微服務召噩， 就帶來了另外一個復雜度：微服務的連接、管理和監(jiān)控明垢。

Markdown

試想蚣常， 對于一個大型系統(tǒng)， 需要對多達上百個甚至上千個微服務的管理痊银、部署抵蚊、版本控制、安全溯革、故障轉(zhuǎn)移贞绳、策略執(zhí)行、遙測和監(jiān)控等致稀，談何容易冈闭。更不要說更復雜的運維需求，例如A/B測試抖单，金絲雀發(fā)布萎攒，限流遇八，訪問控制和端到端認證。

開發(fā)人員和運維人員在單體應用程序向分布式微服務架構(gòu)的轉(zhuǎn)型中耍休， 不得不面臨上述挑戰(zhàn)刃永。

服務網(wǎng)格

Service Mesh，服務網(wǎng)格羊精，也有人翻譯為”服務嚙合層”.

這貌似是今年才出來的新名詞斯够？在2017年之前沒有聽過，雖然類似的產(chǎn)品已經(jīng)存在挺長時間喧锦。

什么是Service Mesh（服務網(wǎng)格）读规？

Service Mesh是專用的基礎(chǔ)設(shè)施層。
輕量級高性能網(wǎng)絡代理燃少。
提供安全的束亏、快速的、可靠地服務間通訊供汛。
與實際應用部署一起枪汪，但對應用透明。
為了幫助理解怔昨， 下圖展示了服務網(wǎng)格的典型邊車部署方式：

Markdown

圖中應用作為服務的發(fā)起方雀久，只需要用最簡單的方式將請求發(fā)送給本地的服務網(wǎng)格代理，然后網(wǎng)格代理會進行后續(xù)的操作趁舀，如服務發(fā)現(xiàn)赖捌，負載均衡，最后將請求轉(zhuǎn)發(fā)給目標服務矮烹。

當有大量服務相互調(diào)用時越庇，它們之間的服務調(diào)用關(guān)系就會形成網(wǎng)格，如下圖所示：

Markdown

在上圖中綠色方塊為服務卤唉，藍色方塊為邊車部署的服務網(wǎng)格仁期，藍色線條為服務間通訊□说埃可以看到藍色的方塊和線條組成了整個網(wǎng)格赊级，我們將這個圖片旋轉(zhuǎn)90°押框，就更加明顯了：服務網(wǎng)格呈現(xiàn)出一個完整的支撐態(tài)勢，將所有的服務”架”在網(wǎng)格之上：

Markdown

服務網(wǎng)格的細節(jié)我們今天不詳細展開橡伞， 詳細內(nèi)容大家可以參考網(wǎng)上資料骑歹〉烂模或者稍后我將會推出一個服務網(wǎng)格的專題最域，單獨深入介紹服務網(wǎng)格镀脂。

Istio也可以視為是一種服務網(wǎng)格薄翅， 在Istio網(wǎng)站上詳細解釋了這一概念：

如果我們可以在架構(gòu)中的服務和網(wǎng)絡間透明地注入一層翘魄，那么該層將賦予運維人員對所需功能的控制暑竟，同時將開發(fā)人員從編碼實現(xiàn)分布式系統(tǒng)問題中解放出來。通常將這個統(tǒng)一的架構(gòu)層與服務部署在一起腹躁，統(tǒng)稱為“服務嚙合層”纺非。由于微服務有助于分離各個功能團隊铐炫，因此服務嚙合層有助于將運維人員從應用特性開發(fā)和發(fā)布過程中分離出來倒信。通過系統(tǒng)地注入代理到微服務間的網(wǎng)絡路徑中鳖悠，Istio將迥異的微服務轉(zhuǎn)變成一個集成的服務嚙合層憎账。

Istio能做什么?

Istio力圖解決前面列出的微服務實施后需要面對的問題胞皱。

Istio 首先是一個服務網(wǎng)絡反砌，但是Istio又不僅僅是服務網(wǎng)格: 在 Linkerd宴树， Envoy 這樣的典型服務網(wǎng)格之上酒贬，Istio提供了一個完整的解決方案，為整個服務網(wǎng)格提供行為洞察和操作控制耐齐，以滿足微服務應用程序的多樣化需求埠况。

Istio在服務網(wǎng)絡中統(tǒng)一提供了許多關(guān)鍵功能(以下內(nèi)容來自官方文檔)：

• 流量管理：控制服務之間的流量和API調(diào)用的流向辕翰，使得調(diào)用更可靠喜命，并使網(wǎng)絡在惡劣情況下更加健壯。

• 可觀察性：了解服務之間的依賴關(guān)系牌里，以及它們之間流量的本質(zhì)和流向牡辽，從而提供快速識別問題的能力态辛。

• 策略執(zhí)行：將組織策略應用于服務之間的互動炊邦，確保訪問策略得以執(zhí)行铣耘，資源在消費者之間良好分配。策略的更改是通過配置網(wǎng)格而不是修改應用程序代碼怒详。

• 服務身份和安全：為網(wǎng)格中的服務提供可驗證身份，并提供保護服務流量的能力静尼，使其可以在不同可信度的網(wǎng)絡上流轉(zhuǎn)鼠渺。

除此之外拦盹，Istio針對可擴展性進行了設(shè)計，以滿足不同的部署需要：

• 平臺支持：Istio旨在在各種環(huán)境中運行沼侣，包括跨云蛾洛， 預置揭厚，Kubernetes筛圆，Mesos等太援。最初專注于Kubernetes提岔，但很快將支持其他環(huán)境。

• 集成和定制：策略執(zhí)行組件可以擴展和定制赛惩，以便與現(xiàn)有的ACL喷兼，日志，監(jiān)控勉抓，配額琳状，審核等解決方案集成。

這些功能極大的減少了應用程序代碼翎承，底層平臺和策略之間的耦合叨咖，使微服務更容易實現(xiàn)垛贤。

Istio的真正價值

上面摘抄了Istio官方的大段文檔說明聘惦，洋洋灑灑的列出了Istio的大把大把高大上的功能善绎。但是這些都不是重點！理論上說剂跟，任何微服務框架，只要愿意往上面堆功能，早晚都可以實現(xiàn)這些抖仅。

那撤卢，關(guān)鍵在哪里放吩？

不妨設(shè)想一下，在平時理解的微服務開發(fā)過程中惕澎，在沒有Istio這樣的服務網(wǎng)格的情況下唧喉，要如何開發(fā)我們的應用程序董朝，才可以做到前面列出的這些豐富多彩的功能? 這數(shù)以幾十記的各種特性子姜，如何才可以加入到應用程序?

無外乎，找個Spring Cloud或者Dubbo的成熟框架扭弧，直接搞定服務注冊，服務發(fā)現(xiàn)御蒲，負載均衡厚满，熔斷等基礎(chǔ)功能。然后自己開發(fā)服務路由等高級功能屁魏， 接入Zipkin等Apm做全鏈路監(jiān)控职辨，自己做加密姆涩、認證亏栈、授權(quán)绒北。 想辦法搞定灰度方案，用Redis等實現(xiàn)限速脐往、配額。 諸如此類梅尤，一大堆的事情， 都需要自己做缰揪，無論是找開源項目還是自己操刀，最后整出一個帶有一大堆功能的應用程序，上線部署坑傅。然后給個配置說明到運維，告訴他說如何需要灰度，要如何如何近零， 如果要限速窖杀，配置哪里哪里入客。

這些工作，相信做微服務落地的公司铆隘，基本都跑不掉，需求是現(xiàn)實存在的，無非能否實現(xiàn)睦刃，以及實現(xiàn)多少的問題，但是毫無疑問的是兴泥，要做到這些，絕對不是一件容易的事情。

問題是稀轨，即使費力做到這些事情到這里還沒有完：運維跑來提了點要求瓦侮，在他看來很合理的要求，比如說：簡單點的加個黑名單须喂， 復雜點的要做個特殊的灰度：將來自iPhone的用戶流量導1%到Stagging環(huán)境的2.0新版本……

Markdown

這里就有一個很嚴肅的問題掷伙， 給每個業(yè)務程序的開發(fā)人員: 你到底想往你的業(yè)務程序里面塞多少管理和運維的功能? 就算你hold的住技術(shù)和時間卒废，你有能力一個一個的滿足各種運維和管理的需求嗎摔认？ 當你發(fā)現(xiàn)你開始疲于響應各種非功能性的需求時，就該開始反省了: 我們開發(fā)的是業(yè)務程序抹蚀，它的核心價值在業(yè)務邏輯的處理和實現(xiàn)钞诡，將如此之多的時間精力花費在這些非業(yè)務功能上臭增， 這真的合理嗎? 而且即使是在實現(xiàn)層面誊抛，微服務實施時，最重要的是如何劃分微服務整陌，如何制定接口協(xié)議拗窃，你該如何分配你有限的時間和資源瞎领？

Istio 超越 spring cloud和dubbo 等傳統(tǒng)開發(fā)框架之處， 就在于不僅僅帶來了遠超這些框架所能提供的功能九默， 而且也不需要應用程序為此做大量的改動， 開發(fā)人員也不必為上面的功能實現(xiàn)進行大量的知識儲備宾毒。

Markdown

總結(jié):

Istio 大幅降低微服務架構(gòu)下應用程序的開發(fā)難度驼修，勢必極大的推動微服務的普及。

個人樂觀估計诈铛，隨著isito的成熟乙各，微服務開發(fā)領(lǐng)域?qū)⒂瓉硪淮晤嵏残缘淖兏铩?/p>

后面我們在介紹Istio的架構(gòu)和功能模塊時, 大家可以了解到Istio是如何做到這些的。

開發(fā)團隊

在開始介紹Istio的架構(gòu)之前, 我們再詳細介紹一下Istio的開發(fā)團隊, 看看背后的大佬幢竹。

首先耳峦，Istio的開發(fā)團隊主要來自 Google， IBM和Lyft焕毫，摘抄一段官方八股：

基于我們?yōu)閮?nèi)部和企業(yè)客戶構(gòu)建和運營大規(guī)模微服務的常見經(jīng)驗蹲坷，Google，IBM和Lyft聯(lián)手創(chuàng)建Istio邑飒，希望為微服務開發(fā)和維護提供可靠的基礎(chǔ)循签。

Google和IBM相信不需要介紹了, 在Istio項目中這兩個公司是絕對主力幸乒，舉個例子,下圖是 Istio Working Group的成員列表：

Markdown

數(shù)一下, 總共18人懦底，10個google，8個IBM罕扎。注意這里沒有Lyft出現(xiàn)聚唐，因為Lyft的貢獻主要集中在Envoy。

Google

Istio來自鼎鼎大名的GCP/Google Cloud Platform, 這里誕生了同樣大名鼎鼎的 App Engine, Cloud Engine等重量級產(chǎn)品腔召。

Google為Istio帶來了Kubernetes和gRPC, 還有和Envoy相關(guān)的特性如安全杆查，性能和擴展性。

八卦: 負責Istio的GCP產(chǎn)品經(jīng)理Varun Talwar臀蛛， 同時也負責gRPC項目, 所以關(guān)注gRPC的同學（比如我自己）可以不用擔心：Istio對gRPC的支持必然是沒有問題的亲桦。

IBM

IBM的團隊同來來自IBM云平臺, IBM的貢獻是:

除了開發(fā)Istio控制面板之外, 還有和Envoy相關(guān)的其他特性如跨服務版本的流量切分, 分布式請求追蹤(Zipkin)和失敗注入。

Lyft

Lyft的貢獻主要集中在Envoy代理浊仆，這是Lyft開源的服務網(wǎng)格客峭，基于C++。據(jù)說Envoy在Lyft可以管理超過100個服務抡柿，跨越10000個虛擬機舔琅，每秒處理2百萬請求。本周最新消息洲劣，Envoy剛剛加入CNCF备蚓，成為該基金會的第十一個項目课蔬。

最后， 在Isito的介紹完成之后, 我們開始下一節(jié)內(nèi)容郊尝，Istio的架構(gòu)二跋。

架構(gòu)

整體架構(gòu)

Istio服務網(wǎng)格邏輯上分為數(shù)據(jù)面板和控制面板。

• 數(shù)據(jù)面板由一組智能代理（Envoy）組成流昏，代理部署為邊車扎即，調(diào)解和控制微服務之間所有的網(wǎng)絡通信。

• 控制面板負責管理和配置代理來路由流量横缔，以及在運行時執(zhí)行策略铺遂。

下圖為Istio的架構(gòu)詳細分解圖：

Markdown

這是宏觀視圖，可以更形象的展示Istio兩個面板的功能和合作：

Markdown

以下分別介紹 Istio 中的主要模塊 Envoy/Mixer/Pilot/Auth茎刚。

Envory

以下介紹內(nèi)容來自Istio官方文檔：

Istio 使用Envoy代理的擴展版本襟锐，Envoy是以C++開發(fā)的高性能代理，用于調(diào)解服務網(wǎng)格中所有服務的所有入站和出站流量膛锭。

Istio利用了Envoy的許多內(nèi)置功能粮坞，例如動態(tài)服務發(fā)現(xiàn)，負載均衡初狰，TLS termination莫杈，HTTP/2&gRPC代理，熔斷器奢入，健康檢查筝闹，基于百分比流量拆分的分段推出，故障注入和豐富的metrics腥光。

Envoy實現(xiàn)了過濾和路由关顷、服務發(fā)現(xiàn)、健康檢查武福，提供了具有彈性的負載均衡议双。它在安全上支持TLS，在通信方面支持gRPC捉片。

概括說平痰，Envoy提供的是服務間網(wǎng)絡通訊的能力，包括(以下均可支持TLS)：

• HTTP／1.1

• HTTP/2

• gRPC

• TCP
  以及網(wǎng)絡通訊直接相關(guān)的功能：

• 服務發(fā)現(xiàn)：從Pilot得到服務發(fā)現(xiàn)信息

• 過濾

• 負載均衡

• 健康檢查

• 執(zhí)行路由規(guī)則(Rule): 規(guī)則來自Polit,包括路由和目的地策略

• 加密和認證: TLS certs來自 Istio-Auth
  此外, Envoy 也吐出各種數(shù)據(jù)給Mixer:

• Metrics

• Logging

• Distribution Trace: 目前支持 Zipkin

總結(jié): Envoy是Istio中負責”干活”的模塊,如果將整個Istio體系比喻為一個施工隊,那么 Envoy 就是最底層負責搬磚的民工伍纫，所有體力活都由Envoy完成宗雇。所有需要控制，決策莹规，管理的功能都是其他模塊來負責赔蒲，然后配置給Envoy。

Istio架構(gòu)回顧

在繼續(xù)介紹Istio其他的模塊之前，我們來回顧一下Istio的架構(gòu)嘹履，前面我們提到, Istio服務網(wǎng)格分為兩大塊：數(shù)據(jù)面板和控制面板。

Markdown

剛剛介紹的Envoy债热，在Istio中扮演的就是數(shù)據(jù)面板砾嫉，而其他我們下面將要陸續(xù)介紹的Mixer、Pilot和Auth屬于控制面板窒篱。上面我給出了一個類比：Istio中Envoy (或者說數(shù)據(jù)面板)扮演的角色是底層干活的民工焕刮，而該讓這些民工如何工作，由包工頭控制面板來負責完成墙杯。

在Istio的架構(gòu)中配并，這兩個模塊的分工非常的清晰，體現(xiàn)在架構(gòu)上也是經(jīng)緯分明： Mixer高镐，Pilot和Auth這三個模塊都是Go語言開發(fā)溉旋，代碼托管在Github上，三個倉庫分別是 Istio/mixer, Istio/pilot/auth嫉髓。而Envoy來自Lyft观腊，編程語言是c++ 11，代碼托管在Github但不是Istio下算行。從團隊分工看梧油，Google和IBM關(guān)注于控制面板中的Mixer，Pilot和Auth州邢，而Lyft繼續(xù)專注于Envoy儡陨。

Istio的這個架構(gòu)設(shè)計，將底層Service Mesh的具體實現(xiàn)量淌，和Istio核心的控制面板拆分開骗村。從而使得Istio可以借助成熟的Envoy快速推出產(chǎn)品，未來如果有更好的Service Mesh方案也方便集成类少。

Envoy的競爭者

談到這里叙身，聊一下目前市面上Envoy之外的另外一個Service Mesh成熟產(chǎn)品：基于Scala的Linkerd。 Linkerd的功能和定位和Envoy非常相似硫狞，而且就在今年上半年成功進入CNCF信轿。而在 Istio 推出之后，Linkerd做了一個很有意思的動作：Istio推出了和Istio的集成残吩，實際為替換Envoy作為Istio的數(shù)據(jù)面板财忽，和Istio的控制面板對接。

回到Istio的架構(gòu)圖泣侮，將這幅圖中的Envoy字樣替換為Linkerd即可即彪。另外還有不在圖中表示的Linkerd Ingress / Linkerd Egress用于替代Envoy實現(xiàn) k8s的Ingress/Egress。

本周最新消息： Nginx推出了自己的服務網(wǎng)格產(chǎn)品Nginmesh，功能類似隶校，比較有意思的地方是Ngxinmesh一出來就直接宣布要和Istio集成漏益，替換Envoy。

繼續(xù)八卦：一出小三上位原配出局的狗血劇情貌似正在醞釀中深胳。 結(jié)局如何我等不妨拭目以待绰疤，還是那句話: 沒有挖不倒的墻角，只有不努力的小三! Linkerd舞终，Nginmesh轻庆，加油！

下面開始介紹 Istio 中最核心的控制面板敛劝。

Pilot

• 流量管理

Istio最核心的功能是流量管理余爆，前面我們看到的數(shù)據(jù)面板，由Envoy組成的服務網(wǎng)格夸盟，將整個服務間通訊和入口/出口請求都承載于其上蛾方。

使用Istio的流量管理模型，本質(zhì)上將流量和基礎(chǔ)設(shè)施擴展解耦上陕，讓運維人員通過Pilot指定它們希望流量遵循什么規(guī)則转捕，而不是哪些特定的pod/VM應該接收流量。

對這段話的理解, 可以看下圖：假定我們原有服務B唆垃，部署在Pod1/2/3上五芝，現(xiàn)在我們部署一個新版本在Pod4在，希望實現(xiàn)切5%的流量到新版本辕万。

Markdown

如果以基礎(chǔ)設(shè)施為基礎(chǔ)實現(xiàn)上述5%的流量切分枢步，則需要通過某些手段將流量切5%到Pod4這個特定的部署單位，實施時就必須和ServiceB的具體部署還有ServiceA訪問ServiceB的特定方式緊密聯(lián)系在一起. 比如如果兩個服務之間是用Nginx做反向代理渐尿，則需要增加Pod4的IP作為Upstream醉途，并調(diào)整Pod1/2/3/4的權(quán)重以實現(xiàn)流量切分。

如果使用Istio的流量管理功能, 由于Envoy組成的服務網(wǎng)絡完全在Istio的控制之下,因此要實現(xiàn)上述的流量拆分非常簡單. 假定原版本為1.0砖茸，新版本為2.0隘擎，只要通過Polit 給Envoy發(fā)送一個規(guī)則：2.0版本5%流量，剩下的給1.0凉夯。

這種情況下货葬，我們無需關(guān)注2.0版本的部署，也無需改動任何技術(shù)設(shè)置, 更不需要在業(yè)務代碼中為此提供任何配置支持和代碼修改劲够。一切由 Pilot 和智能Envoy代理搞定震桶。

我們還可以玩的更炫一點, 比如根據(jù)請求的內(nèi)容來源將流量發(fā)送到特定版本：

Markdown

后面我們會介紹如何從請求中提取出User-Agent這樣的屬性來配合規(guī)則進行流量控制。

• Pilot的功能概述

我們在前面有強調(diào)說征绎，Envoy在其中扮演的負責搬磚的民工角色蹲姐，而指揮Envoy工作的民工頭就是Pilot模塊。

官方文檔中對Pilot的功能描述：

Pilot負責收集和驗證配置并將其傳播到各種Istio組件。它從Mixer和Envoy中抽取環(huán)境特定的實現(xiàn)細節(jié)柴墩，為他們提供獨立于底層平臺的用戶服務的抽象表示忙厌。此外，流量管理規(guī)則（即通用4層規(guī)則和7層HTTP/gRPC路由規(guī)則）可以在運行時通過Pilot進行編程江咳。

每個Envoy實例根據(jù)其從Pilot獲得的信息以及其負載均衡池中的其他實例的定期健康檢查來維護 負載均衡信息慰毅，從而允許其在目標實例之間智能分配流量，同時遵循其指定的路由規(guī)則扎阶。

Pilot負責在Istio服務網(wǎng)格中部署的Envoy實例的生命周期。

• Pilot的架構(gòu)

下圖是Pilot的架構(gòu)圖：

Markdown

1. Envoy API負責和Envoy的通訊, 主要是發(fā)送服務發(fā)現(xiàn)信息和流量控制規(guī)則給Envoy
2. Envoy提供服務發(fā)現(xiàn)婶芭，負載均衡池和路由表的動態(tài)更新的API东臀。這些API將Istio和Envoy的實現(xiàn)解耦。(另外犀农，也使得Linkerd之類的其他服務網(wǎng)絡實現(xiàn)得以平滑接管Envoy)
3. Polit定了一個抽象模型惰赋，以從特定平臺細節(jié)中解耦，為跨平臺提供基礎(chǔ)
4. Platform Adapter則是這個抽象模型的現(xiàn)實實現(xiàn)版本, 用于對接外部的不同平臺
5. 最后是 Rules API呵哨，提供接口給外部調(diào)用以管理Pilot赁濒，包括命令行工具Istioctl以及未來可能出現(xiàn)的第三方管理界面

• 服務規(guī)范和實現(xiàn)

Pilot架構(gòu)中, 最重要的是Abstract Model和Platform Adapter，我們詳細介紹孟害。

• Abstract Model：是對服務網(wǎng)格中”服務”的規(guī)范表示, 即定義在istio中什么是服務拒炎，這個規(guī)范獨立于底層平臺。
• Platform Adapter：這里有各種平臺的實現(xiàn)挨务，目前主要是Kubernetes击你，另外最新的0.2版本的代碼中出現(xiàn)了Consul和Eureka。

來看一下Pilot 0.2的代碼谎柄，pilot/platform 目錄下:

Markdown

瞄一眼platform.go：

Markdown

服務規(guī)范的定義在modle/service.go中:

Markdown

由于篇幅有限丁侄，代碼部分這里不深入, 只是通過上面的兩段代碼來展示Pilot中對服務的規(guī)范定義和目前的幾個實現(xiàn)。

暫時而言(當前版本是0.1.6, 0.2版本尚未正式發(fā)布)朝巫，目前 Istio 只支持K8s一種服務發(fā)現(xiàn)機制鸿摇。

備注: Consul的實現(xiàn)據(jù)說主要是為了支持后面將要支持的Cloud Foundry，Eureka沒有找到資料劈猿。Etcd3 的支持還在Issue列表中拙吉，看Issue記錄爭執(zhí)中。

• Pilot功能

基于上述的架構(gòu)設(shè)計揪荣，Pilot提供以下重要功能：

• 請求路由
• 服務發(fā)現(xiàn)和負載均衡
• 故障處理
• 故障注入
• 規(guī)則配置

由于篇幅限制庐镐，今天不逐個展開詳細介紹每個功能的詳情。大家通過名字就大概可以知道是什么变逃，如果希望了解詳情可以關(guān)注之后的分享必逆。或者查閱官方文檔的介紹。

Mixer

Mixer翻譯成中文是混音器, 下面是它的圖標：

Markdown

功能概括：Mixer負責在服務網(wǎng)格上執(zhí)行訪問控制和使用策略名眉，并收集Envoy代理和其他服務的遙測數(shù)據(jù)粟矿。

• Mixer的設(shè)計背景

我們的系統(tǒng)通常會基于大量的基礎(chǔ)設(shè)施而構(gòu)建，這些基礎(chǔ)設(shè)施的后端服務為業(yè)務服務提供各種支持功能损拢。包括訪問控制系統(tǒng)陌粹，遙測捕獲系統(tǒng)，配額執(zhí)行系統(tǒng)福压，計費系統(tǒng)等掏秩。在傳統(tǒng)設(shè)計中, 服務直接與這些后端系統(tǒng)集成，容易產(chǎn)生硬耦合荆姆。

在Istio中蒙幻，為了避免應用程序的微服務和基礎(chǔ)設(shè)施的后端服務之間的耦合，提供了 Mixer 作為兩者的通用中介層：

Markdown

Mixer 設(shè)計將策略決策從應用層移出并用配置替代胆筒，并在運維人員控制下邮破。應用程序代碼不再將應用程序代碼與特定后端集成在一起，而是與Mixer進行相當簡單的集成仆救，然后 Mixer 負責與后端系統(tǒng)連接抒和。

特別提醒: Mixer不是為了在基礎(chǔ)設(shè)施后端之上創(chuàng)建一個抽象層或者可移植性層。也不是試圖定義一個通用的Logging API彤蔽，通用的Metric API摧莽，通用的計費API等等。

Mixer的設(shè)計目標是減少業(yè)務系統(tǒng)的復雜性顿痪，將策略邏輯從業(yè)務的微服務的代碼轉(zhuǎn)移到Mixer中, 并且改為讓運維人員控制范嘱。

• Mixer的功能

Mixer 提供三個核心功能：

• 前提條件檢查。允許服務在響應來自服務消費者的傳入請求之前驗證一些前提條件员魏。前提條件包括認證丑蛤，黑白名單，ACL檢查等等撕阎。

• 配額管理受裹。使服務能夠在多個維度上分配和釋放配額。典型例子如限速虏束。

• 遙測報告棉饶。使服務能夠上報日志和監(jiān)控。

在Istio內(nèi)镇匀，Envoy重度依賴Mixer照藻。

• Mixer的適配器

Mixer是高度模塊化和可擴展的組件。其中一個關(guān)鍵功能是抽象出不同策略和遙測后端系統(tǒng)的細節(jié)汗侵，允許Envoy和基于Istio的服務與這些后端無關(guān)幸缕，從而保持他們的可移植群发。

Mixer在處理不同基礎(chǔ)設(shè)施后端的靈活性是通過使用通用插件模型實現(xiàn)的。單個的插件被稱為適配器发乔，它們允許Mixer與不同的基礎(chǔ)設(shè)施后端連接熟妓，這些后臺可提供核心功能，例如日志栏尚，監(jiān)控起愈，配額，ACL檢查等译仗。適配器使Mixer能夠暴露一致的API抬虽，與使用的后端無關(guān)。在運行時通過配置確定確切的適配器套件纵菌，并且可以輕松指向新的或定制的基礎(chǔ)設(shè)施后端阐污。

Markdown

這個圖是官網(wǎng)給的，列出的功能不多产艾，我從Github的代碼中抓個圖給大家展示一下目前已有的Mixer Adapter：

Markdown

• Mixer的工作方式

Istio使用屬性來控制在服務網(wǎng)格中運行的服務的運行時行為。屬性是描述入口和出口流量的有名稱和類型的元數(shù)據(jù)片段滑绒，以及此流量發(fā)生的環(huán)境闷堡。Istio屬性攜帶特定信息片段，例如：

Markdown

請求處理過程中疑故，屬性由Envoy收集并發(fā)送給Mixer杠览，Mixer中根據(jù)運維人員設(shè)置的配置來處理屬性∽菔疲基于這些屬性踱阿，Mixer會產(chǎn)生對各種基礎(chǔ)設(shè)施后端的調(diào)用。

Markdown

Mixer設(shè)計有一套強大(也很復雜, 堪稱Istio中最復雜的一個部分)的配置模型來配置適配器的工作方式钦铁，設(shè)計有適配器软舌、切面、屬性表達式牛曹，選擇器佛点、描述符，manifests 等一堆概念.

由于篇幅所限黎比，今天不展開這塊內(nèi)容超营，這里給出兩個簡單的例子讓大家對Mixer的配置有個感性的認識:

1. 這是一個IP地址檢查的Adapter，實現(xiàn)類似黑名單或者白名單的功能：

Markdown

2. metrics的適配器,將數(shù)據(jù)報告給Prometheus系統(tǒng)

Markdown

3.定義切面, 使用前面定義的 myListChecker 這個adapter 對屬性 source.ip 進行黑名單檢查阅虫。

Markdown

Istio-Auth

Istio-Auth提供強大的服務到服務和終端用戶認證演闭，使用交互TLS，內(nèi)置身份和憑據(jù)管理颓帝。它可用于升級服務網(wǎng)格中的未加密流量米碰，并為運維人員提供基于服務身份而不是網(wǎng)絡控制實施策略的能力窝革。

Istio的未來版本將增加細粒度的訪問控制和審計，以使用各種訪問控制機制（包括基于屬性和角色的訪問控制以及授權(quán)鉤子）來控制和監(jiān)視訪問您的服務见间，API或資源的人員聊闯。

Markdown

• Auth的架構(gòu)

下圖展示Istio Auth架構(gòu)，其中包括三個組件：身份米诉，密鑰管理和通信安全菱蔬。

在這個例子中, 服務A以服務帳戶“foo”運行, 服務B以服務帳戶“bar”運行, 他們之間的通訊原來是沒有加密的. 但是Istio在不修改代碼的情況, 依托Envoy形成的服務網(wǎng)格, 直接在客戶端Envoy和服務器端Envoy之間進行通訊加密。

目前在Kubernetes上運行的 Istio史侣，使用Kubernetes service account/服務帳戶來識別運行該服務的人員拴泌。

• 未來將推出的功能

Auth在目前的Istio版本(0.1.6和即將發(fā)布的0.2)中，功能還不是很全惊橱，未來則規(guī)劃有非常多的特性：

• 細粒度授權(quán)和審核
• 安全Istio組件（Mixer, Pilot等）
• 集群間服務到服務認證
• 使用JWT/OAuth2/OpenID_Connect終端到服務的認證
• 支持GCP服務帳戶和AWS服務帳戶
• 非http流量（MySql蚪腐，Redis等）支持
• Unix域套接字，用于服務和Envoy之間的本地通信
• 中間代理支持
• 可插拔密鑰管理組件
• 需要提醒的是：這些功能都是不改動業(yè)務應用代碼的前提下實現(xiàn)的税朴。

回到我們前面的曾經(jīng)討論的問題回季，如果自己來做，完成這些功能大家覺得需要多少工作量正林？要把所有的業(yè)務模塊都遷移到具備這些功能的框架和體系中泡一，需要改動多少？而Istio觅廓，未來就會直接將這些東西擺上我們的餐桌鼻忠。

未來

前面我們介紹了Istio的基本情況，還有Istio的架構(gòu)和主要組件杈绸。相信大家對Istio應該有了一個初步的認識帖蔓。

需要提醒的是，Istio是一個今年5月才發(fā)布 0.1.0 版本的新鮮出爐的開源項目瞳脓，目前該項目也才發(fā)布到0.1.6正式版本和 0.2.2 pre release版本. 很多地方還不完善塑娇，希望大家可以理解，有點類似于最早期階段的Kubernetes劫侧。

在接下來的時間钝吮，我們將簡單介紹一下Istio后面的一些開發(fā)計劃和發(fā)展預期。

運行環(huán)境支持

Istio目前只支持Kubernetes, 這是令人比較遺憾的一點. 不過 istio 給出的解釋是istio未來會支持在各種環(huán)境中運行板辽，只是目前在 0.1/0.2 這樣的初始階段暫時專注于Kubernetes奇瘦，但很快會支持其他環(huán)境。

注意: Kubernetes平臺劲弦，除了原生Kubernetes, 還有諸如 IBM Bluemix Container Service和RedHat OpenShift這樣的商業(yè)平臺耳标。 以及google自家的 Google Container Engine。這是自家的東西, 而且現(xiàn)在k8s/istio/gRPC都已經(jīng)被劃歸到 Google cloud platform部門, 自然會優(yōu)先支持.

另外isito所說的其他環(huán)境指的是:

• Mesos: 這個估計是大多人非K8s的Docker使用者最關(guān)心的了, 暫時從Github上的代碼中未見到有開工跡象, 但是Istio的文檔和官方聲明都明顯說會支持, 估計還是希望很大的.
  Cloud foundry: 這個東東我們國內(nèi)除了私有云外玩的不多, Istio對它的支持似乎已經(jīng)啟動. 比如我看到代碼中已經(jīng)有了Consul這個服務注冊的支持, 從Issue討論上看到是說為上Cloud foundry做準備, 因為Cloud foundry沒有k8s那樣的原生服務注冊機制邑跪。
• VM: 這塊沒有看到介紹, 但是有看到Istio的討論中提到會支持容器和非容器的混合(Hybrid)支持
  值得特別指出的是次坡，目前我還沒有看到Istio有對Docker家的Swarm有支持的計劃或者討論, 目前我找到的任何Istio的資料中都不存在Swarm這個東東呼猪。我只能不負責任的解讀為：有人的地方就有江湖，有江湖就自然會有江湖恩怨砸琅。

路線圖

按照Istio的說法宋距，他們計劃每3個月發(fā)布一次新版本，我們看一下目前得到的一些信息：

• 0.1 版本2017年5月發(fā)布,只支持Kubernetes
• 0.2 即將發(fā)布,當前是0.2.1 pre-release, 也只支持Kubernetes
• 0.3 roadmap上說要支持k8s之外的平臺, “Support for Istio meshes without Kubernetes.”, 但是具體哪些特性會放在0.3中,還在討論中
• 1.0 版本預計今年年底發(fā)布

注: 1.0版本的發(fā)布時間官方?jīng)]有明確給出症脂，我只是看到官網(wǎng)資料里面有信息透露如下:

“we invite the community to join us in shaping the project as we work toward a 1.0 release later this year.”

按照上面給的信息谚赎，簡單推算：應該是9月發(fā)0.2, 然后12月發(fā)0.3, 但是這就已經(jīng)是年底了, 所以不排除1.0推遲發(fā)布的可能，或者0.3直接當成 1.0 發(fā)布诱篷。

社區(qū)支持

雖然Istio初出江湖壶唤，乳臭未干，但是憑借google和IBM的金字招牌棕所，還有Istio前衛(wèi)而實際的設(shè)計理念闸盔，目前已經(jīng)有很多公司在開始提供對Istio的支持或者集成，這是Istio官方頁面有記載的：

• Red Hat：Openshift and OpenShift Application Runtimes
• Pivotal：Cloud Foundry
• Weaveworks：Weave Cloud and Weave Net 2.0
• Tigera：Project Calico Network Policy Engine
• Datawire：Ambassador project

然后一些其他外圍支持, 從代碼中看到的:

• eureka
• consul
• etcd v3: 這個還在爭執(zhí)中,作為etcd的堅定擁護者, 我對此保持密切關(guān)注

存在問題

Istio畢竟目前才是0.2.2 pre release版本琳省，畢竟才出來四個月迎吵，因此還是存在大量的問題，集中表現(xiàn)為：

1. 只支持k8s针贬，而且要求k8s 1.7.4+击费，因為使用到k8s的 CustomResourceDefinitions
2. 性能較低，從目前的測試情況看坚踩，0.1版本很糟糕荡灾，0.2版本有改善
3. 很多功能尚未完成
   給大家的建議：可以密切關(guān)注Istio的動向瓤狐，提前做好技術(shù)儲備瞬铸。但是，最起碼在年底的1.0版本出來之前础锐，別急著上生產(chǎn)環(huán)境嗓节。

結(jié)語

感謝大家在今天參與這次的Istio分享，由于時間有限皆警，很多細節(jié)無法在今天給大家盡情展開拦宣。如果大家對 Istio 感興趣，可以之后自行瀏覽 Istio 的官方網(wǎng)站信姓，我也預期會在之后陸陸續(xù)續(xù)的給出Istio相關(guān)的文章和分享鸵隧。

最后推薦給大家?guī)讉€資料：

1. Istio的中文資料: Istio.doczh.cn, 這是目前我和其他社區(qū)朋友正在一起翻譯的Istio官方文檔, 進度大概30%左右, 其中最適合入門了解的 concept 部分已經(jīng)翻譯完成.作為目前市面上唯一的一份Istio中文資料，推薦給大家閱讀意推。
2. Service Mesh的微信技術(shù)群豆瘫，由于服務網(wǎng)格的內(nèi)容實在太新，不容易找到人交流菊值，所以如果對這個技術(shù)有興趣打算深入研究的外驱，歡迎加入育灸。請聯(lián)系我的微信：id(aoxiaojian80)加群，請備注服務網(wǎng)格昵宇。
   今天的分享到此結(jié)束磅崭，感謝大家的全程參與，下次再會瓦哎！