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的官方定義:
它是一個完全開源的服務網格，作為透明的一層接入到現有的分布式應用程序里。它也是一個平台，擁有可以集成任何日志、遙測和策略系統的 API 接口。Istio 多樣化的特性使您能夠成功且高效地運行分布式微服務架構，並提供保護、連接和監控微服務的統一方法。
從定義中可以梳理出Istio提供了以下核心特性：
- 連接：請求路由、服務發現、負載均衡、流量管理、灰度發布及A/B測試
- 保護：托管的認證授權，及通信加密
- 控制：策略定義
- 觀測：日志、追蹤、指標及監控
目前的Istio已經更新到1.8版本了，其架構也從最開始的復雜版本逐漸簡化。現在的架構圖如下所示：
從圖中可以看出主要包含兩大平面：
- 數據平面（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，梳理的非常完整，感興趣的同學可關注【微服務知多少】公眾號，回復”雲原生“即可獲取。
參考資料