Istio 知多少 | 下一代微服務(wù)的守護(hù)者
1. 引言
在寫(xiě)完eShopOnContainers 知多少[12]：Envoy gateways后，就一直想進(jìn)一步探索Service Mesh，最近剛在極客時(shí)間上學(xué)完《Service Mesh入門(mén)》，又大致瀏覽了一遍官方文檔，對(duì)Istio也算有了基本的認(rèn)識(shí)。下面就根據(jù)自己的理解對(duì)Istio進(jìn)行簡(jiǎn)單的梳理，算是對(duì)知識(shí)的總結(jié)吧。
2. Cloud Native（云原生）
在介紹Istio之前，我們得先了解下Service Mesh，而Service Mesh 又是云原生的產(chǎn)物。因此，本著追本溯源的精神，我們得先了解下云原生。云原生（Cloud Native）這個(gè)概念是在2015年提出的，聽(tīng)的人多，真正能講清楚的人少，我也一樣。綜合多方資料，下面嘗試解讀一下。
云原生，雖然字都認(rèn)識(shí)，但真不好解釋。一般講云原生，其實(shí)是講云原生應(yīng)用，多了應(yīng)用二字，就更具象了。從字面上直譯：云，代表云端；原生：原本就生長(zhǎng)在那里；連起來(lái)就是「原本就生長(zhǎng)在云端的應(yīng)用」。
應(yīng)用怎么會(huì)原本就生長(zhǎng)在云端呢？云又是怎么發(fā)展而來(lái)呢？別急，我們先來(lái)看下云計(jì)算的發(fā)展來(lái)解答下云的由來(lái)。
我們知道傳統(tǒng)的應(yīng)用都是跑在本地服務(wù)器上，隨著虛擬化技術(shù)的發(fā)展，拉開(kāi)了云計(jì)算的序幕，一大批云計(jì)算廠(chǎng)商基于虛擬機(jī)技術(shù)，提供了IaaS，PaaS和SaaS等產(chǎn)品形態(tài)，極大的提高資源的利用率。企業(yè)本著降本增效的目的，逐步將應(yīng)用遷移到云上的Paas平臺(tái)上。而這一階段，被稱(chēng)為云計(jì)算的虛擬機(jī)時(shí)代，而這個(gè)時(shí)間節(jié)點(diǎn)在2013年之前，運(yùn)行在云端虛擬機(jī)上的應(yīng)用，還不叫云原生應(yīng)用。
2013年，Docker開(kāi)源，正式開(kāi)啟了容器技術(shù)時(shí)代，重新定義了 PaaS 的全新容器化思路。在容器技術(shù)的基礎(chǔ)上，“云”得到了極大的發(fā)展，2014年谷歌開(kāi)源Kubernetes，旨在解決容器的編排問(wèn)題（部署、伸縮和管理）。2017年容器編排大戰(zhàn)塵埃落定，Kubernetes成為最大贏家，標(biāo)志著K8S成為分布式資源調(diào)度和自動(dòng)化運(yùn)維的事實(shí)標(biāo)準(zhǔn)。Kubernetes 也逐漸體現(xiàn)出云原生時(shí)代底層操作系統(tǒng)的特征，向下封裝資源、向上支撐應(yīng)用。這個(gè)階段，可以稱(chēng)為云計(jì)算的容器時(shí)代。也正是在這個(gè)階段，云原生的概念被提出，其標(biāo)志事件就是2015年CNCF（云原生計(jì)算基金會(huì)）的成立，云原生這個(gè)詞才被大家熟知。
現(xiàn)在我們知道，云原生是在容器時(shí)代提出的概念。那為什么會(huì)提出云原生這個(gè)概念呢？別急我們來(lái)看下云計(jì)算發(fā)展過(guò)程中后端架構(gòu)的演進(jìn)。
從上圖可知，后端架構(gòu)從單體到分布式，再逐步演進(jìn)到微服務(wù)架構(gòu)。采用微服務(wù)架構(gòu)，就必須解決服務(wù)治理、流量控制、應(yīng)用觀(guān)察等問(wèn)題。其中2014年由Netflix 推出的Spring Cloud體系就是通過(guò)提供服務(wù)發(fā)現(xiàn)、負(fù)載均衡、失效轉(zhuǎn)移、動(dòng)態(tài)擴(kuò)容、數(shù)據(jù)分片、調(diào)用鏈路監(jiān)控等分布式系統(tǒng)的核心功能，一度成為微服務(wù)的最佳實(shí)踐。但是卻有一個(gè)很大的缺點(diǎn)就是其對(duì)應(yīng)用有很強(qiáng)的「侵入性」，應(yīng)用代碼中會(huì)包含大量的 SpringCloud 模塊。這時(shí)的應(yīng)用模型如下圖所示：
那如何解決侵入性的問(wèn)題呢？這個(gè)問(wèn)題在容器編排技術(shù)成熟之前，似乎沒(méi)有好的答案。但隨著K8S的成熟，這個(gè)問(wèn)題有了新的解法。Kubernetes的出現(xiàn)就是為了解決 SpringCloud 的問(wèn)題，不侵入應(yīng)用層，在容器層解決問(wèn)題。這就是理想的應(yīng)用開(kāi)發(fā)模型，應(yīng)用依托于“云”，最大化發(fā)揮“云”的優(yōu)勢(shì)，專(zhuān)注于業(yè)務(wù)需求的實(shí)現(xiàn)。
那應(yīng)用如何依托于“云”，最大化發(fā)揮“云”的優(yōu)勢(shì)呢？云原生就是為了解決這一問(wèn)題而提出的。其建立在“未來(lái)的軟件一定生長(zhǎng)于云”的核心假設(shè)之上提出的，云原生本質(zhì)上是一套指導(dǎo)軟件架構(gòu)設(shè)計(jì)的思想，依托該思想而設(shè)計(jì)的應(yīng)用：首先，應(yīng)用本身“生于云、長(zhǎng)于云”；其次，這樣的應(yīng)用能夠天然集成“云”環(huán)境，進(jìn)而釋放“云”的最大價(jià)值。?云原生定義了一條能夠讓?xiě)?yīng)用最大程度利用云能力、發(fā)揮云價(jià)值的最佳路徑。具體來(lái)說(shuō)，參考云原生計(jì)算基金會(huì)（CNCF）對(duì)云原生的定義，「云原生包括容器化封裝、自動(dòng)化管理、面向微服務(wù)、服務(wù)網(wǎng)格、聲明式 API。符合云原生架構(gòu)的應(yīng)用程序應(yīng)該是：采用開(kāi)源堆棧（Kubernetes+Docker）進(jìn)行容器化，基于微服務(wù)架構(gòu)提高靈活性和可維護(hù)性，借助敏捷方法、DevOps 支持持續(xù)迭代和運(yùn)維自動(dòng)化，利用云平臺(tái)設(shè)施實(shí)現(xiàn)彈性伸縮、動(dòng)態(tài)調(diào)度、優(yōu)化資源利用率。」
那如何實(shí)現(xiàn)云原生呢？Service Mesh交出了自己的答卷。
3. Service Mesh（服務(wù)網(wǎng)格）
先來(lái)看下Service Mesh的提出者，也就是第一代Service Mesh 產(chǎn)品Linkerd的CEO，對(duì)Service Mesh的定義：
?Service Mesh 通常被譯為服務(wù)網(wǎng)格，其是一個(gè)「基礎(chǔ)設(shè)施層」，用于處理服務(wù)間通信。云原生應(yīng)用有著復(fù)雜的服務(wù)拓?fù)洌?wù)網(wǎng)格負(fù)責(zé)在這些拓?fù)渲?strong style="color: rgb(53, 148, 247);">「實(shí)現(xiàn)請(qǐng)求的可靠傳遞」。在實(shí)踐中，服務(wù)網(wǎng)格通常實(shí)現(xiàn)為一組「輕量級(jí)網(wǎng)絡(luò)代理」，它們與應(yīng)用程序部署在一起，而「對(duì)應(yīng)用程序透明」。
?
PS: eShopOnContainers就是采用了Linkerd作為Service Mesh，基于其易于安裝和設(shè)置的特性。感興趣的同學(xué)，可訪(fǎng)問(wèn)鏈接一探究竟。
Service Mesh 通過(guò)在請(qǐng)求調(diào)用的路徑中增加Sidecar，將原本由客戶(hù)端完成的復(fù)雜功能下沉到Sidecar 中，實(shí)現(xiàn)對(duì)客戶(hù)端的簡(jiǎn)化和服務(wù)間通信控制權(quán)的轉(zhuǎn)移，當(dāng)系統(tǒng)中存在大量服務(wù)時(shí)，服務(wù)間的調(diào)用關(guān)系表現(xiàn)為網(wǎng)狀，這也是服務(wù)網(wǎng)格名稱(chēng)的由來(lái)。
「Service Mesh就是通過(guò)Sidecar模式將業(yè)務(wù)需求與非業(yè)務(wù)需求進(jìn)行隔離，解決侵入性問(wèn)題」。其中Sidecar主要就是用來(lái)處理諸如服務(wù)發(fā)現(xiàn)、負(fù)載均衡、請(qǐng)求熔斷等一系列非業(yè)務(wù)需求，應(yīng)用在部署時(shí)動(dòng)態(tài)插入Sidecar，以「對(duì)用戶(hù)透明的方式改變應(yīng)用行為」。以下是Service Mesh的核心流程：
4. Istio （帆）
主流的 Service Mesh 開(kāi)源軟件包括 Linkerd、Envoy 和 Istio。Linkerd 和 Envoy 都 直 接 體 現(xiàn) 了Service Mesh 的核心理念，在功能上較為相似，即實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)、請(qǐng)求路由、負(fù)載均衡等功能，解決服務(wù)之間的通信問(wèn)題，使得應(yīng)用對(duì)服務(wù)通信無(wú)感知。「而 Istio 站在了更高的角度，將 Service Mesh 分為了 Data Plane 和 Control Plane， 由 Data Plane負(fù)責(zé)微服務(wù)間的所有網(wǎng)絡(luò)通信，而 Control Plane負(fù) 責(zé) 管 理 Data Plane Proxy」， 且 Istio 天 然 支 持Kubernetes，這也彌合了應(yīng)用調(diào)度框架與 ServiceMesh 之間的空隙。
?Istio的官方定義: 它是一個(gè)完全開(kāi)源的服務(wù)網(wǎng)格，作為透明的一層接入到現(xiàn)有的分布式應(yīng)用程序里。它也是一個(gè)平臺(tái)，擁有可以集成任何日志、遙測(cè)和策略系統(tǒng)的 API 接口。Istio 多樣化的特性使您能夠成功且高效地運(yùn)行分布式微服務(wù)架構(gòu)，并提供保護(hù)、連接和監(jiān)控微服務(wù)的統(tǒng)一方法。
?
從定義中可以梳理出Istio提供了以下核心特性：
連接：請(qǐng)求路由、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、流量管理、灰度發(fā)布及A/B測(cè)試 保護(hù)：托管的認(rèn)證授權(quán)，及通信加密 控制：策略定義 觀(guān)測(cè)：日志、追蹤、指標(biāo)及監(jiān)控
目前的Istio已經(jīng)更新到1.8版本了，其架構(gòu)也從最開(kāi)始的復(fù)雜版本逐漸簡(jiǎn)化。現(xiàn)在的架構(gòu)圖如下所示：
從圖中可以看出主要包含兩大平面：
數(shù)據(jù)平面（Data plane）：由Envoy Proxy 充當(dāng)?shù)腟idecar組成。 控制平面（Control plane）：主要包含三大核心組件，Pilot、Citadel、Galley組成。 2.1. Pilot：主要是管理部署在Istio服務(wù)網(wǎng)格中的Envoy代理實(shí)例，為它們提供服務(wù)發(fā)現(xiàn)、流量管理以及彈性功能，比如：A/B測(cè)試、金絲雀發(fā)布、超時(shí)、重試、熔斷等。 2.2. Citadel：Istio的核心安全組件，負(fù)責(zé)服務(wù)的密鑰和數(shù)字證書(shū)管理，用于提供自動(dòng)生成、分發(fā)、輪換及撤銷(xiāo)密鑰和數(shù)據(jù)證書(shū)的功能。 2.3. Galley：負(fù)責(zé)向Istio的其它組件提供支撐功能，可以理解為Istio的配置中心，它用于校驗(yàn)進(jìn)入網(wǎng)絡(luò)配置信息的格式內(nèi)容正確性，并將這些配置信息提供給Pilot。
以上就是Istio的核心概念，關(guān)于Istio流量控制、安全及可觀(guān)察性的應(yīng)用，這里就先不展開(kāi)了，后續(xù)就結(jié)合Demo，再和大家分享了。
5. 最后
講真，通過(guò)翻閱資料，完成了對(duì)云計(jì)算、云原生、Service Mesh等概念的追本溯源，加深了云原生理念的認(rèn)知，拓展了自己的架構(gòu)視野，也大致了解了后續(xù)自己的學(xué)習(xí)和研究方向。希望本文對(duì)你或多或少也有所幫助，感謝閱讀！
寫(xiě)就本文，參考了很多資料，參考資料見(jiàn)文末，在此對(duì)原作者表示感謝！另外這里再向大家推薦兩份關(guān)于云原生和Service Mesh的PPT，梳理的非常完整，感興趣的同學(xué)可掃碼關(guān)注【微服務(wù)知多少】公眾號(hào)，回復(fù)“云原生”即可獲取。
?參考資料
?
未來(lái)已來(lái)：云原生 Cloud Native 暢談云原生（上）：云原生應(yīng)用應(yīng)該是什么樣子？ Service Mesh：下一代微服務(wù)？ What's Istio? InfoQ：云原生的技術(shù)探索與落地實(shí)踐 | 研究報(bào)告 CNCF Cloud Native Definition v1.0