Service Mesh：Istio 的前世今生
來源：https://morven.life/posts/the_history_of_istio/
其實要徹底了解Istio以及服務(wù)網(wǎng)格出現(xiàn)的背景，就得從計算機發(fā)展的早期說起。
下面這張圖展示的的通信模型變種其實從計算機剛出現(xiàn)不久的上世紀50年代開始就得到廣泛應(yīng)用，那個時候，計算機很稀有，也很昂貴，人們手動管理計算機之間的連接，圖中綠色的網(wǎng)絡(luò)棧底層只負責(zé)傳輸電子信號和字節(jié)碼：
隨著計算機變得越來越普及，價格也沒那么貴了，計算機之間的連接數(shù)量和通信的數(shù)據(jù)量出現(xiàn)了瘋狂式的增長，人們越來越依賴網(wǎng)絡(luò)系統(tǒng)，工程師們必須確保他們開發(fā)的服務(wù)能夠滿足用戶的要求。于是，如何提升系統(tǒng)質(zhì)量成為人們關(guān)注的焦點。機器需要知道如何找到其他節(jié)點，處理同一個通道上的并發(fā)連接，與非直接連接的機器發(fā)生通信，通過網(wǎng)絡(luò)路由數(shù)據(jù)包，加密流量……除此之外，還需要流量控制機制，流量控制可以防止下游服務(wù)器給上游服務(wù)器發(fā)送過多的數(shù)據(jù)包。
于是，在一段時期內(nèi)，開發(fā)人員需要在自己的代碼里處理上述問題。在下面這張圖的示例中，為了確保下游服務(wù)器不給其他上游服務(wù)造成過載，應(yīng)用程序需要處理流量控制邏輯，于是網(wǎng)絡(luò)中的流量控制邏輯和業(yè)務(wù)邏輯就混雜在一起：
幸運的是，上世紀60年代末，TCP/IP協(xié)議棧的出現(xiàn)解決了可靠傳輸和流量控制等問題，此后盡管網(wǎng)絡(luò)邏輯代碼依然存在，但已經(jīng)從應(yīng)用程序里抽離出來，成為操作系統(tǒng)網(wǎng)絡(luò)棧的一部分，工程師只需要按照操作系統(tǒng)的調(diào)用接口進行編程就可以解決基礎(chǔ)的網(wǎng)絡(luò)傳輸問題：
進入21世紀，計算機越來越普及，也越來越便宜，相互連接的計算機節(jié)點越來越多，業(yè)界出現(xiàn)了各種網(wǎng)絡(luò)系統(tǒng)，如分布式代理和面向服務(wù)架構(gòu)(SOA)：
分布式為我們帶來了更高層次的能力和好處，但卻帶來了新的挑戰(zhàn)。這時候工程師的重心開始轉(zhuǎn)移到應(yīng)用程序的網(wǎng)絡(luò)功能上面，這時候的服務(wù)之間的對話以“消息”為傳輸單元，當(dāng)工程師們通過網(wǎng)絡(luò)進行調(diào)用服務(wù)時，必須能為應(yīng)用程序消息執(zhí)行超時、重試、確認等操作。
于是，有工程師是開始嘗試使用消息主干網(wǎng)（messaging backbone）集中式地來提供、控制應(yīng)用程序網(wǎng)絡(luò)功能，如服務(wù)發(fā)現(xiàn)、負載均衡、重試等等，甚至，比如協(xié)議調(diào)解、消息轉(zhuǎn)換、消息路由、編排等功能，因為他們覺得如果可以將這些看似同一層面的內(nèi)容加入到基礎(chǔ)設(shè)施中，應(yīng)用程序或許會更輕量、更精簡、更敏捷等等。這些需求絕對是真實的，ESB(Enterprise Service Bus)演變并滿足了這些需要。ESB在是2005年被提出的，它的概念特別類似于計算機硬件概念里的USB, USB作為電腦中的標準擴展接口，可以連接各種外部設(shè)備；而ESB則就把路由管理、協(xié)議轉(zhuǎn)換、策略控制等通用應(yīng)用程序網(wǎng)絡(luò)功能加到現(xiàn)有的集中式消息總線里：
這看似行得通！
可是，在實施SOA架構(gòu)的時候，工程師們發(fā)現(xiàn)這種架構(gòu)有點兒用力過度，矯枉過正了。集中式的消息總線往往會成為架構(gòu)的瓶頸，用它來進行流量控制、路由、策略執(zhí)行等并不像我們想象那么容易。加上組織結(jié)構(gòu)過于復(fù)雜，使用專有格式（XML等），需要業(yè)務(wù)邏輯需要實現(xiàn)路由轉(zhuǎn)換和編排等功能，各個服務(wù)之間耦合度很高，在敏捷運動的時代背景下，ESB架構(gòu)已經(jīng)無法跟上時代的節(jié)奏了。
在接下來的幾年內(nèi)，REST革命和API優(yōu)先的思潮孕育了微服務(wù)架構(gòu)應(yīng)用，而以docker為代表的容器技術(shù)和以Kubernetes為代表的容器編排技術(shù)的出現(xiàn)促進了微服務(wù)架構(gòu)的落地。事實上，微服務(wù)時代可以以Kubernetes的出現(xiàn)節(jié)點劃分為“前微服務(wù)時代”和“后微服務(wù)時代”：
“前微服務(wù)時代”基本上是微服務(wù)作為用例推動容器技術(shù)的發(fā)展，而到“后微服務(wù)時代”，特別是成為標準的Kubernetes其實在驅(qū)動和重新定義微服務(wù)的最佳實踐，容器和Kubernetes為微服務(wù)架構(gòu)的落地提供了絕佳的客觀條件。
微服務(wù)架構(gòu)有很多好處，比如：
快速分配計算資源
快速部署升級迭代
易于分配的存儲
易于訪問的邊界等等
但是作為較復(fù)雜的分布式系統(tǒng)，微服務(wù)架構(gòu)給運維帶來了新的挑戰(zhàn)。當(dāng)工程師開始接嘗試微服務(wù)架構(gòu)，必須考慮如何進行微服務(wù)治理。狹義的微服務(wù)治理，關(guān)注的是微服務(wù)組件之間的連接與通訊，例如服務(wù)注冊發(fā)現(xiàn)、東西向路由流控、負載均衡、熔斷降級、遙測追蹤等。
歷史總是驚人的相似，第一批采用微服務(wù)架構(gòu)的企業(yè)遵循的是與第一代網(wǎng)絡(luò)計算機系統(tǒng)類似的策略，也就是說，解決網(wǎng)絡(luò)通信問題的任務(wù)又落在了業(yè)務(wù)工程師的肩上。
這個時候出現(xiàn)了看到諸如Netflix OSS堆棧、Twitter Finagle以及赫赫有名的Spring Cloud這樣的框架和類庫幫助業(yè)務(wù)工程師快速開發(fā)應(yīng)用程序級別的網(wǎng)路功能，只需要寫少量代碼，就可以把服務(wù)發(fā)現(xiàn)，負載均衡，路由管理，遙測收集，監(jiān)控告警等這些功能實現(xiàn)：
但是如果仔細想一下的話，就會發(fā)現(xiàn)這樣編寫微服務(wù)程序的問題很明顯。
這些類庫或者框架是特定語言編寫的，并且混合在業(yè)務(wù)邏輯中（或在整個基礎(chǔ)設(shè)施上層分散的業(yè)務(wù)邏輯中）。姑且不說類庫和框架的學(xué)習(xí)成本和門檻，我們知道微服務(wù)架構(gòu)問世的一個承諾就是不同的微服務(wù)可以采用不同的編程語言來編寫，可是當(dāng)你開始編寫代碼的時候會發(fā)現(xiàn)有些語言還沒有提供對應(yīng)的類庫。這是一個尷尬的局面！這個問題非常尖銳，為了解決這個問題，大公司通常選擇就是統(tǒng)一編程語言來編寫微服務(wù)代碼另外的問題是，升級怎么辦？框架不可能一開始就完美無缺，所有功能都齊備，沒有任何BUG。升級一般都是逐個版本遞進升級，一旦出現(xiàn)客戶端和服務(wù)器端版本不一致，就要小心維護兼容性。實際上，每做出一次變更都需要進行集成、測試，還要重新部署所有的服務(wù)——盡管服務(wù)本身并沒有發(fā)生變化。
與網(wǎng)絡(luò)協(xié)議棧一樣，工程師們急切地希望能夠?qū)⒎植际椒?wù)所需要的一些特性放到底層的平臺中。這就像工程師基于HTTP協(xié)議開發(fā)非常復(fù)雜的應(yīng)用，無需關(guān)心底層TCP如何控制數(shù)據(jù)包。在開發(fā)微服務(wù)時也是類似的，業(yè)務(wù)工程師們聚焦在業(yè)務(wù)邏輯上，不需要浪費時間去編寫服務(wù)基礎(chǔ)設(shè)施代碼或管理系統(tǒng)用到的軟件庫和框架。把這種想法囊括到之前架構(gòu)中，就是下邊這幅圖所示的樣子：
不過，在網(wǎng)絡(luò)協(xié)議棧中加入這樣的一個層是不實際的。貌似可以嘗試一下代理的方案！事實上，確實有有一些先驅(qū)者，嘗試過使用代理的方案，例如nginx，haproxy，proxygen等代理。也就是說，一個服務(wù)不會直接與上游服務(wù)發(fā)生連接，所有的流量都會流經(jīng)代理，代理會攔截服務(wù)之間的請求并轉(zhuǎn)發(fā)到上游服務(wù)。可是，那時候代理的功能非常簡陋，很多工程師嘗試之后覺得沒有辦法實現(xiàn)服務(wù)的客戶端所有的需求。
在這樣的訴求下，第一代的Sidecar出現(xiàn)了，Sidecar扮演的角色和代理很像，但是功能就齊全很多，基本上原來微服務(wù)框架在客戶端實現(xiàn)的功能都會有對應(yīng)的實現(xiàn)：
但是第一代的sidecar有一個重要的限制，它們是專門為特定基礎(chǔ)設(shè)施組件而設(shè)計的，導(dǎo)致無法通用。例如，Airbnb的Nerve和Synapse，它們工作的基礎(chǔ)是服務(wù)一定是注冊到ZooKeeper上的，而Netflix的Prana要求一定要使用Netflix自己的Eureka注冊服務(wù)…
隨著微服務(wù)架構(gòu)日漸流行，新一波的sidecar出現(xiàn)了，可以用在不同基礎(chǔ)設(shè)施組件上，我們把他們叫做通用型的sidecar。其中Linkerd是業(yè)界第一個通用型sidecar，它是基于Twitter微服務(wù)平臺而開發(fā)的，實際上也正是它創(chuàng)造了Service Mesh，即服務(wù)網(wǎng)格的概念。2016年1月15日，Linkerd 0.0.7版本發(fā)布，隨后加入CNCF，1.0版本于2017年4月份發(fā)布；隨后的通用型sidecar就是大名鼎鼎來自于Lyft的envoy，Lyft在2016年9月發(fā)布envoy的1.0版本之后。2017年9月envoy加入CNCF；最后一個比較新的sidecar來自于我們熟悉的NGINX，叫做Nginmesh，2017年9月發(fā)布了第一個版本。
有了通用型sidecar，每個微服務(wù)都會有一個sidecar代理與之配對，服務(wù)間通信都是通過sidecar代理進行的。正如我們在下這幅圖上看到的那樣，sidecar代理之間的連接形成了一種網(wǎng)格網(wǎng)絡(luò)：
這就是服務(wù)網(wǎng)格概念的來源，下面是服務(wù)網(wǎng)格概念地官方定義，它不再把sidecar代理看成單獨的組件，并強調(diào)了這些sidecar代理所形成的網(wǎng)絡(luò)的重要性。
A service mesh is a dedicated infrastructure layer for making service-to-service communication safe, fast, and reliable.
實際上，就像TCP/IP網(wǎng)絡(luò)棧為我們抽象了網(wǎng)絡(luò)傳輸?shù)募毠?jié)一樣，有了服務(wù)網(wǎng)格，我們不需要再擔(dān)心微服務(wù)之間通信的各種網(wǎng)絡(luò)訴求，如服務(wù)發(fā)現(xiàn)和負載均衡，流量管理，策略執(zhí)行，監(jiān)控告警等。
服務(wù)網(wǎng)格的概念出現(xiàn)之后，有部分工程師們開始將的微服務(wù)部署到更為復(fù)雜的運行時（如Kubernetes和Mesos）上，并開始使用這些基礎(chǔ)平臺提供的網(wǎng)絡(luò)工具來管理整個服務(wù)網(wǎng)格里的所有sidecar，也就是從一系列獨立運行的sidecar代理轉(zhuǎn)向使用集中式的控制面板來管理所有的sidecar代理。
在Google內(nèi)部，很早通過一個分布式平臺對微服務(wù)進行管理，通過代理處理內(nèi)部與外部的協(xié)議。這些代理的背后是一個控制面板，它在開發(fā)者與運維人員之間提供了一層額外的抽象，在這層抽象之上對跨語言與系統(tǒng)平臺的服務(wù)進行管理。經(jīng)過實戰(zhàn)的檢驗，這套架構(gòu)已經(jīng)證明它能夠確保高伸縮性、低延遲性，并為Google的各項服務(wù)提供了豐富的特性。
在2016年，Google決定開發(fā)一個對微服務(wù)進行管理的開源項目，它與Google內(nèi)部使用的平臺有很大的相似性，該項目命名為“Istio”, Istio在希臘語中的意思是“啟航”。就在Google啟動Istio項目的幾乎同一時間，IBM也發(fā)布了一個名為Amalgam8的開源項目，這是一個基于NGINX代理技術(shù)，為微服務(wù)提供基于內(nèi)容的路由方案的項目。隨后，Google和IBM意識到這兩個項目在使用場景與產(chǎn)品愿景上存在很大一部分交集，于是答應(yīng)成為的合作伙伴，IBM放棄Amalgam8的開發(fā)，共同基于Lyft公司 的envoy項目打造Istio這款產(chǎn)品。
Istio的出現(xiàn)將服務(wù)網(wǎng)格的概念發(fā)揚光大，它創(chuàng)新性地將服務(wù)網(wǎng)格邏輯上劃分為控制面板和數(shù)據(jù)面板，
隨著分布式應(yīng)用一起部署的sidecar成為數(shù)據(jù)平面（Data Plane），它能夠攔截網(wǎng)絡(luò)請求，并控制服務(wù)之間的通信；
而集中是的管理模塊成為控制平面（Control Plane），它提供策略實施、遙測數(shù)據(jù)收集以及證書輪換等功能；
在整個網(wǎng)絡(luò)里面，所有的流量都在sidecar代理的控制當(dāng)中，所有的sidecar代理都在控制面板控制當(dāng)中，因此，可以通過控制面板控制整個服務(wù)網(wǎng)格，這是Istio帶來的最大的革新。
就如我們在上面這幅圖上看到的那樣，Istio默認使用envoy作為sidecar代理（事實上，Istio利用了envoy內(nèi)建的大量特性，例如服務(wù)發(fā)現(xiàn)與負載均衡、流量拆分、故障注入、熔斷器以及金絲雀發(fā)布等功能），而在控制平面Istio也分為四個主要模塊：
Pilot: 為sidecar代理提供服務(wù)發(fā)現(xiàn)功能和配置下發(fā)功能；它將控制流量的高級路由規(guī)則轉(zhuǎn)換為特定于envoy的配置，并在運行時將它們傳播到envoy；
Mixer: 負責(zé)在服務(wù)網(wǎng)格上執(zhí)行訪問控制和策略檢查，并從envoy代理收集遙測數(shù)據(jù)；代理提取請求級屬性，發(fā)送到Mixer進行評估；
Citadel: 證書分發(fā)和管理中心；通過內(nèi)置身份和憑證管理，用于升級服務(wù)網(wǎng)格中未加密的流量，并為運維人員提供基于服務(wù)標識的訪問策略；
Galley: 統(tǒng)一的配置消化，驗證和分發(fā)中心；未來的版本中Galley將承擔(dān)更多的責(zé)任，從而將其他的Istio組件與從底層平臺（例如Kubernetes）細節(jié)中隔離開來；
2018年7月31日，Istio1.0正式發(fā)布，距離最初的0.1版本發(fā)布以來已經(jīng)過了一年多時間了。
從0.1起，Istio就在蓬勃發(fā)展的社區(qū)、貢獻者和用戶的幫助下迅速發(fā)展。現(xiàn)在已經(jīng)有許多公司成功將Istio應(yīng)用于生產(chǎn)，并通過Istio提供的洞察力和控制力獲得了真正的價值。Istio幫助大型企業(yè)和快速發(fā)展的創(chuàng)業(yè)公司，如eBay、Auto Trader UK、Descartes Labs、HP FitStation、Namely、PubNub和Trulia使用Istio從頭開始連接、管理和保護他們的服務(wù)。
同時，整個Istio生態(tài)系統(tǒng)也不斷的擴張，envoy增加了許多對生產(chǎn)級別服務(wù)網(wǎng)格至關(guān)重要的功能，包括與許多可觀察性工具的集成，像Datadog、 SolarWinds、 Sysdig、Google Stackdriver和Amazon CloudWatch這樣的可觀察性提供商也編寫了插件來將Istio與他們的產(chǎn)品集成在一起；Red Hat構(gòu)建的Kiali為網(wǎng)格管理和可觀察性提供了良好的用戶體驗；Knative無服務(wù)化項目也正基于Istio開發(fā)下一代下一代流量路由堆棧；Apigee宣布計劃在他們的API管理解決方案中使用它。
- END -
?推薦閱讀? Kubernetes 企業(yè)落地核心技術(shù)方案
點亮，服務(wù)器三年不宕機
