服務網格和Istio初識

1、雲原生

雲原生的定義：

• 2010年，WSO2技術總監PaulFremantle 首次提出Cloud Native，他一直想用一個詞表達一個架構，這種架構能夠描述應用程式和中介軟體能夠在雲環境中有良好的執行狀態。雲原生有以下特性 分散式、彈性、多租戶，子服務，按需計量和計費，增量部署和測試
• 2013年，Netflix雲架構師，Adrian Cockcroft介紹了Netflix在AWS上基於Cloud Native的成功應用，Netflix在AWS上有上萬個例項
• 2015年，來自Pivotal的Matt Stine，他的電子書《遷移到雲原生應用架構》，他認為單體架構在向雲原生架構的演進過程中，需要流程、文化、技術共同變革，該書把Cloud Native描述為一組最佳實踐，具體包含如下內容：十二因子，微服務，敏捷基礎設施，基於API的協作，反脆弱性
• 2017年，Matt Stine在接受媒體採訪時又改了口風，將雲原生架構歸納為模組化、可觀察、可部署、可測試、可替換、可處理6特質；而Pivotal最新官網對雲原生概括為4個要點：DevOps+持續交付+微服務+容器
  2015年雲原生計算基金會（CNCF）成立，最初把雲原生定義為包括：容器化封裝+自動化管理+面向微服務。
• CNCF於2018年通過了對雲原生重新定義的提案，V1.0的定義如下：
  雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和執行可彈性擴充套件的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和宣告式API
  這些技術能夠構建容錯性好、易於管理和便於觀察的鬆耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕鬆地對系統作出頻繁和可預測的重大變更

雲原生的英文原文叫 Cloud Native ，從英文的角度來理解， Native 表示與生俱來，就是親生的，把 Cloud 和 Native 放到一起又該如何理解？詳細的解釋是：應用原生被設計為在雲上以最佳方式執行，充分發揮雲的優勢，享受雲的特點

雲原生這個詞看起來比較新鮮，其實從開發人員的角度來理解是很簡單的，就是應用在開發的時候就考慮到雲上提供的各種服務，充分利用雲的動態排程、自恢復、通過 API 訪問服務等基本特性，以及敏捷高效的特性。傳統的應用開發方式都是悶頭開發，不管應用跑在哪個基礎設施環境中，也不用考慮基礎設施提供的各種能力，讓應用能正常執行就好

上面都是從廣義上來理解雲原生，有點空洞，對應到具體的方法論就是大家耳熟能詳的三板斧

• 容器化
• 微服務
• DevOps

2、微服務架構

微服務或微服務架構是一種架構風格，它將一個應用程式構建為服務的集合。鬆散耦合的微服務集合提供了與單個單體應用相同的功能，但有額外的優勢。微服務可以獨立於其他服務進行開發和部署。它們是圍繞業務能力組織的，由較小的團隊擁有。它們在部署/開發中更小、更獨立，可以更好地維護和測試

開發人員經常將雲原生應用程式分解為多個執行特定動作的服務。例如，可能有一個只處理客戶的服務和另一個處理訂單或付款的服務。所有這些服務都通過網路相互溝通。如果一個新的付款需要被處理，請求會被髮送到付款服務。如果客戶資料需要更新，請求會被髮送到客戶服務等等

這種型別的架構被稱為微服務架構。這種架構有幾個好處。可以有多個較小的團隊從事個別服務。這些團隊可以靈活地選擇他們的技術棧和語言，並且通常有獨立部署和釋出服務的自主權。這種機制得以運作得益於其背後通訊網路。隨著服務數量的增加，它們之間的網路通訊也在增加。服務和團隊的數量使得監控和管理通訊邏輯變得相當複雜。由於我們也知道網路是不可靠的，它們會失敗，所有這些的結合使得微服務的管理和監控相當複雜

3、Kubernetes

Kubernetes 是現代基於容器的 DevOps 和微服務以及容器攜手並進的黃金標準，其設計之初就是按照雲原生的理念設計的

Kubernetes 是一款用於管理容器化工作負載和服務的可移植、可擴充套件的開源平臺，擁有龐大、快速發展的生態系統，它面向基礎設施，將計算、網路、儲存等資源進行緊密整合，為容器提供最佳執行環 境，並面向應用提供封裝好的、易用的工作負載與服務編排介面，以及運維所需的資源規格、彈性、執行引數、排程等配置管理介面，是新一代的雲原生基礎設施平臺。 從平臺架構而言， Kubernetes 的設計圍繞平臺化理念，強調外掛化設計與易擴充套件性，這是它與其他同類系統的最大區別之一，保障了對各種不同客戶應用場景的普遍適應性。另外， Kubernetes 與其他容器編排系統的顯著區別是 Kubernetes 並不把無狀態化、微服務化等條件作為在其上可執行的工作負載的約束

隨著網際網路的發展，後端服務和容器編排技術的日益成熟，微服務成為了後端服務的首選， Kubernetes 也已成為目前容器編排的事實標準

4、服務網格

服務網格被定義為一個專門的基礎設施層，用於管理服務與服務之間的通訊，使其可管理、可見、可控制。在某些版本的定義中，可能還會聽到服務網格如何使服務間的通訊安全和可靠。用一個更直接的句子來描述服務網格：服務網格是關於服務之間的通訊

但是，服務網格是如何幫助通訊的呢？讓我們思考一下通訊邏輯和它通常所在的地方。在大多數情況下，開發人員將這種邏輯作為服務的一部分來構建。通訊邏輯是處理入站或出站請求的任何程式碼，重試邏輯，超時，甚至可能是流量路由。因此，無論何時服務 A 呼叫服務 B ，請求都要經過這個通訊程式碼邏輯，這個邏輯決定如何處理這個請求

如果我們採用微服務的方法，最終可能會有大量的服務。我們如何處理所有這些服務的通訊邏輯呢？我們可以建立一個包含這種邏輯的共享庫，並在多個地方重用它。假設我們對所有的服務都使用相同的堆疊或程式語言，共享庫的方法可能會很有效。如果我們不這樣做，我們將不得不重新實現這個庫，這會帶來巨大的工作量而且效率低下。你也可能使用自己本身不擁有程式碼庫的服務。在這種情況下，我們無法控制通訊邏輯或監控

另外一個問題是配置。除了配置你的應用程式外，我們還必須維護通訊邏輯配置。如果我們需要同時調整或更新多個服務，我們將不得不為每個服務單獨進行調整

服務網格所做的是，它將這種通訊邏輯、重試、超時等從單個服務中分離出來，並將其移到一個單獨的基礎設施層。在服務網格的情況下，基礎設施層是一個網路代理的陣列。這些網路代理的集合（每個服務例項旁邊都有一個）處理你的服務之間的所有通訊邏輯。我們稱這些代理為 sidecar ，因為它們與每個服務並存

我們讓 Customer 服務直接與 Payment 服務通訊，現在我們有一個 Customer 服務旁邊的代理與 Payment 服務旁邊的代理通訊。服務網格控制平面以這樣一種方式配置代理，即它們透明地攔截所有入站和出站請求。這些代理的集合（基礎設施層）形成了一個網路網格，稱為服務網格

將通訊邏輯從業務和應用邏輯中分離出來，可以使開發人員專注於業務邏輯，而服務網格運維人員則專注於服務網格配置

因此，用到服務網格 sidecar 模式後，應用的拓撲可能是這樣

服務網格為我們提供了一種一致的方式來連線、保護和觀察微服務。網格內的代理捕獲了網格內所有通訊的請求和指標。每一次失敗、每一次成功的呼叫、重試或超時都可以被捕獲、視覺化，併發出警報。此外，可以根據請求屬性做出決定。例如，我們可以檢查入站（或出站）請求並編寫規則，將所有具有特定頭值的請求路由到不同的服務版本

5、Istio

Istio 是服務網格技術雲原生 Cloud Native 時代的產物，是雲原生應用的新型架構模式，而云原生又是雲端計算產業發展的新制高點

2016 年， Google 決定開發一個對微服務進行管理的開源專案，它與 Google 內部使用的平臺有很大的相似性，該專案被命名為 Istio , Istio 在希臘語中的意思是“啟航”。就在 Google 啟動 Istio 專案的幾乎同一時間， IBM 也釋出了一個名為 Amalgam8 的開源專案，這是一個基於 Nginx 代理技術，為微服務提供基於內容路由方案的專案。隨後， Google 和 IBM 意識到這兩個專案在使用場景與產品願景上存在很大一部分交集，於是答應成為合作伙伴， IBM 放棄 Amalgam8 的開發，與 Google 共同基於 Lyft 公司開源的 envoy 專案打造 Istio 這款產品

Istio 是一個與 Kubernetes 緊密結合的適用於雲原生場景的 Service Mesh 形態的用於服務治理的開放平臺

Istio 與 Kubernetes 的關係如下

Istio 的出現將服務網格的概念發揚光大，它創新性地將服務網格從邏輯上劃分為“資料面板”和“控制面板

sidecar

在整個網路裡面，所有的流量都在 sidecar 代理的控制當中，所有的 sidecar 代理都在控制面板控制當中，因此，可以通過控制面板控制整個服務網格，這是 Istio 帶來的最大革新

Istio 提供一種簡單的方式來為已部署的服務建立網路，該網路具有負載均衡、服務間認證、監控等功能，只需要對服務的程式碼進行一點或不需要做任何改動，讓服務支援 Istio ，只需要在環境中部署一個特殊的 sidecar 代理，使用 Istio 控制平面功能配置和管理代理，攔截微服務之間的所有網路通訊

• HTTP、gRPC、WebSocket 和 TCP 流量的自動負載均衡
• 通過豐富的路由規則、重試、故障轉移和故障注入，可以對流量行為進行細粒度控制
• 可插入的策略層和配置 API，支援訪問控制、速率限制和配額
• 對出入叢集入口和出口中所有流量的自動度量指標、日誌記錄和追蹤
• 通過強大的基於身份的驗證和授權，在叢集中實現安全的服務間通訊

本文就寫（參考）到這裡，後面圍繞 Istio 做更多學習、實踐的分享

See you ~

參考

https://istio.io/latest/zh/docs/concepts/what-is-istio/

https://www.infoq.cn/article/fA42rfjV*dYGAvRANFqE

https://mp.weixin.qq.com/s/csY8T02Ck8bnE3vVcZxVjQ