1. 引言

在寫完eShopOnContainers 知多少[12]：Envoy gateways后，就一直想進一步探索Service Mesh，最近剛在極客時間上學完《Service Mesh入門》，又大致瀏覽了一遍官方文檔，對Istio也算有了基本的認識。下面就根據自己的理解對Istio進行簡單的梳理，算是對知識的總結吧。

2. Cloud Native（云原生）

在介紹Istio之前，我們得先了解下Service Mesh，而Service Mesh 又是云原生的產物。因此，本著追本溯源的精神，我們得先了解下云原生。云原生（Cloud Native）這個概念是在2015年提出的，聽的人多，真正能講清楚的人少，我也一樣。綜合多方資料，下面嘗試解讀一下。

云原生，雖然字都認識，但真不好解釋。一般講云原生，其實是講云原生應用，多了應用二字，就更具象了。從字面上直譯：云，代表云端；原生：原本就生長在那里；連起來就是「原本就生長在云端的應用」。

應用怎么會原本就生長在云端呢？云又是怎么發展而來呢？別急，我們先來看下云計算的發展來解答下云的由來。

我們知道傳統的應用都是跑在本地服務器上，隨著虛擬化技術的發展，拉開了云計算的序幕，一大批云計算廠商基于虛擬機技術，提供了IaaS，PaaS和SaaS等產品形態，極大的提高資源的利用率。企業本著降本增效的目的，逐步將應用遷移到云上的Paas平臺上。而這一階段，被稱為云計算的虛擬機時代，而這個時間節點在2013年之前，運行在云端虛擬機上的應用，還不叫云原生應用。

2013年，Docker開源，正式開啟了容器技術時代，重新定義了 PaaS 的全新容器化思路。在容器技術的基礎上，“云”得到了極大的發展，2014年谷歌開源Kubernetes，旨在解決容器的編排問題（部署、伸縮和管理）。2017年容器編排大戰塵埃落定，Kubernetes成為最大贏家，標志著K8S成為分布式資源調度和自動化運維的事實標準。Kubernetes 也逐漸體現出云原生時代底層操作系統的特征，向下封裝資源、向上支撐應用。這個階段，可以稱為云計算的容器時代。也正是在這個階段，云原生的概念被提出，其標志事件就是2015年CNCF（云原生計算基金會）的成立，云原生這個詞才被大家熟知。

現在我們知道，云原生是在容器時代提出的概念。那為什么會提出云原生這個概念呢？別急我們來看下云計算發展過程中后端架構的演進。

從上圖可知，后端架構從單體到分布式，再逐步演進到微服務架構。采用微服務架構，就必須解決服務治理、流量控制、應用觀察等問題。其中2014年由Netflix 推出的Spring Cloud體系就是通過提供服務發現、負載均衡、失效轉移、動態擴容、數據分片、調用鏈路監控等分布式系統的核心功能，一度成為微服務的最佳實踐。但是卻有一個很大的缺點就是其對應用有很強的「侵入性」，應用代碼中會包含大量的 SpringCloud 模塊。這時的應用模型如下圖所示：

那如何解決侵入性的問題呢？這個問題在容器編排技術成熟之前，似乎沒有好的答案。但隨著K8S的成熟，這個問題有了新的解法。Kubernetes的出現就是為了解決 SpringCloud 的問題，不侵入應用層，在容器層解決問題。這就是理想的應用開發模型，應用依托于“云”，最大化發揮“云”的優勢，專注于業務需求的實現。

那應用如何依托于“云”，最大化發揮“云”的優勢呢？云原生就是為了解決這一問題而提出的。其建立在“未來的軟件一定生長于云”的核心假設之上提出的，云原生本質上是一套指導軟件架構設計的思想，依托該思想而設計的應用：首先，應用本身“生于云、長于云”；其次，這樣的應用能夠天然集成“云”環境，進而釋放“云”的最大價值。?云原生定義了一條能夠讓應用最大程度利用云能力、發揮云價值的最佳路徑。具體來說，參考云原生計算基金會（CNCF）對云原生的定義，「云原生包括容器化封裝、自動化管理、面向微服務、服務網格、聲明式 API。符合云原生架構的應用程序應該是：采用開源堆棧（Kubernetes+Docker）進行容器化，基于微服務架構提高靈活性和可維護性，借助敏捷方法、DevOps 支持持續迭代和運維自動化，利用云平臺設施實現彈性伸縮、動態調度、優化資源利用率。」

那如何實現云原生呢？Service Mesh交出了自己的答卷。

3. Service Mesh（服務網格）

先來看下Service Mesh的提出者，也就是第一代Service Mesh 產品Linkerd的CEO，對Service Mesh的定義：

?

Service Mesh 通常被譯為服務網格，其是一個「基礎設施層」，用于處理服務間通信。云原生應用有著復雜的服務拓撲，服務網格負責在這些拓撲中「實現請求的可靠傳遞」。在實踐中，服務網格通常實現為一組「輕量級網絡代理」，它們與應用程序部署在一起，而「對應用程序透明」。

?

PS: eShopOnContainers就是采用了Linkerd作為Service Mesh，基于其易于安裝和設置的特性。感興趣的同學，可訪問鏈接一探究竟。

Service Mesh 通過在請求調用的路徑中增加Sidecar，將原本由客戶端完成的復雜功能下沉到Sidecar 中，實現對客戶端的簡化和服務間通信控制權的轉移，當系統中存在大量服務時，服務間的調用關系表現為網狀，這也是服務網格名稱的由來。

「Service Mesh就是通過Sidecar模式將業務需求與非業務需求進行隔離，解決侵入性問題」。其中Sidecar主要就是用來處理諸如服務發現、負載均衡、請求熔斷等一系列非業務需求，應用在部署時動態插入Sidecar，以「對用戶透明的方式改變應用行為」。以下是Service Mesh的核心流程：

4. Istio （帆）

主流的 Service Mesh 開源軟件包括 Linkerd、Envoy 和 Istio。Linkerd 和 Envoy 都 直 接 體 現 了Service Mesh 的核心理念，在功能上較為相似，即實現服務發現、請求路由、負載均衡等功能，解決服務之間的通信問題，使得應用對服務通信無感知。「而 Istio 站在了更高的角度，將 Service Mesh 分為了 Data Plane 和 Control Plane， 由 Data Plane負責微服務間的所有網絡通信，而 Control Plane負 責 管 理 Data Plane Proxy」， 且 Istio 天 然 支 持Kubernetes，這也彌合了應用調度框架與 ServiceMesh 之間的空隙。

Istio?

Istio的官方定義: 它是一個完全開源的服務網格，作為透明的一層接入到現有的分布式應用程序里。它也是一個平臺，擁有可以集成任何日志、遙測和策略系統的 API 接口。Istio 多樣化的特性使您能夠成功且高效地運行分布式微服務架構，并提供保護、連接和監控微服務的統一方法。

?

從定義中可以梳理出Istio提供了以下核心特性：

連接：請求路由、服務發現、負載均衡、流量管理、灰度發布及A/B測試

保護：托管的認證授權，及通信加密

控制：策略定義

觀測：日志、追蹤、指標及監控

目前的Istio已經更新到1.8版本了，其架構也從最開始的復雜版本逐漸簡化。現在的架構圖如下所示：

Istio Architecture

從圖中可以看出主要包含兩大平面：

數據平面（Data plane）：由Envoy Proxy 充當的Sidecar組成。

控制平面（Control plane）：主要包含三大核心組件，Pilot、Citadel、Galley組成。

2.1. Pilot：主要是管理部署在Istio服務網格中的Envoy代理實例，為它們提供服務發現、流量管理以及彈性功能，比如：A/B測試、金絲雀發布、超時、重試、熔斷等。

2.2. Citadel：Istio的核心安全組件，負責服務的密鑰和數字證書管理，用于提供自動生成、分發、輪換及撤銷密鑰和數據證書的功能。

2.3. Galley：負責向Istio的其它組件提供支撐功能，可以理解為Istio的配置中心，它用于校驗進入網絡配置信息的格式內容正確性，并將這些配置信息提供給Pilot。

以上就是Istio的核心概念，關于Istio流量控制、安全及可觀察性的應用，這里就先不展開了，后續就結合Demo，再和大家分享了。

5. 最后

講真，通過翻閱資料，完成了對云計算、云原生、Service Mesh等概念的追本溯源，加深了云原生理念的認知，拓展了自己的架構視野，也大致了解了后續自己的學習和研究方向。希望本文對你或多或少也有所幫助，感謝閱讀！

寫就本文，參考了很多資料，參考資料見文末，在此對原作者表示感謝！另外這里再向大家推薦兩份關于云原生和Service Mesh的PPT，梳理的非常完整，感興趣的同學可掃碼關注【微服務知多少】公眾號，回復“云原生”即可獲取。

?

參考資料

未來已來：云原生 Cloud Native

暢談云原生（上）：云原生應用應該是什么樣子？

Service Mesh：下一代微服務？

What's Istio?

InfoQ：云原生的技術探索與落地實踐 | 研究報告

CNCF Cloud Native Definition v1.0

?

總結

以上是生活随笔為你收集整理的Istio 知多少 | 下一代微服务的守护者的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。