1. 引言
在寫完eShopOnContainers 知多少[12]：Envoy gateways後，就一直想進一步探索Service Mesh，最近剛在極客時間上學完《Service Mesh入門》，又大體瀏覽了一遍官方文檔，對Istio也算有了基本的認識。下面就根據本身的理解對Istio進行簡單的梳理，算是對知識的總結吧。web
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，梳理的很是完整，感興趣的同窗可掃碼關注【微服務知多少】公衆號，回覆「雲原生」便可獲取。
❝參考資料
❞
將來已來：雲原生 Cloud Native 暢談雲原生（上）：雲原生應用應該是什麼樣子？ Service Mesh：下一代微服務？ What's Istio? InfoQ：雲原生的技術探索與落地實踐 | 研究報告 CNCF Cloud Native Definition v1.0
本文分享自微信公衆號 - 微服務知多少（dotnet-microservice）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。