利用幾天時間蚯斯，讀了下<<云原生網(wǎng)絡Istio>云原生網(wǎng)絡Istio>箫攀。
發(fā)現(xiàn)它的強大之處抑月，并且讓我們能夠更好的玩轉(zhuǎn)微服務子漩，所以做個筆記來梳理所看的就很有必要了豫喧。

Istio是什么？

Istio是一個用于服務治理的開放平臺幢泼。

服務治理的三種形態(tài)

1. 應用程序中包含治理邏輯

    在微服務化的過程中嘿棘，將服務拆分后會發(fā)現(xiàn)一堆麻煩事，連基本的業(yè)務連通都成為問題旭绒。  
    所以在處理一些治理邏輯鸟妙，例如如何找到對端的服務實例，怎么選擇一個對端實例請求時挥吵，  
    都需要自己用代碼來實現(xiàn)重父。所以微服務越多，重復的代碼越多忽匈，維護艱難房午，高度耦合。  
    這樣不管是對治理邏輯升級還是對業(yè)務的升級丹允，都要改同一段代碼郭厌。如下圖所示:  
   

image.png

2. 治理邏輯獨立的代碼

    在解決第一種形態(tài)的問題時袋倔，會很容易想到把治理的公共邏輯抽象成一個公用庫，  
    讓所有的微服務都適用這個公用庫折柠。也就是SDK模式(如下圖)宾娜，非常典型的框架就是spring cloud。  
    SDK模式雖然在代碼上解耦了業(yè)務和治理邏輯扇售，但業(yè)務代碼和SDK還是要一起編譯前塔，還在同一個進程內(nèi)。  
    所以會有幾個問題:業(yè)務代碼需要和SDK屬于同一種語言承冰。在治理邏輯升級時华弓，還需要用戶的整個服務升級。
   

image.png

3. 治理邏輯獨立的進程

    SDK模式仍舊侵入了用戶的代碼困乒，那就再解耦一層寂屏，把治理邏輯徹底從用戶的業(yè)務代碼中剝離出來，  
    就是如下圖所示的Sidecar模式娜搂。  
    顯然迁霎，在這種形態(tài)下面，用戶的業(yè)務代碼和治理邏輯都以獨立的進程存在涌攻，  
    這樣可以做到與開發(fā)語言無關欧引，升級也相互獨立。
   

image.png

Service Mesh(服務網(wǎng)格)

實際上服務治理的第三種形態(tài)就可以認為是當前最流行概念Service Mesh的雛形恳谎。它有幾個特點:

• 治理能力獨立(sidecar)
• 應用程序無感知
• 服務網(wǎng)格是一種處理服務通信的基礎設施層

image.png

Istio問世

image.png

image.png

image.png

與Kubernetes完美結(jié)合

從場景上看Kubernetes已經(jīng)提供了非常強大的應用負載的部署芝此，升級，擴容等運行管理能力因痛。K8s中的Service機制也已經(jīng)可以做服務注冊婚苹，服務發(fā)現(xiàn)和負載均衡，支持通過服務名訪問到服務實例鸵膏。
但是K8s對服務間訪問的管理如服務的熔斷膊升，限流，動態(tài)路由谭企，調(diào)用鏈追蹤都不在它的能力范圍內(nèi)廓译，所以Istio就成了K8s的最完美幫手。

image.png

Istio與Kubernetes架構關系

image.png

1. 數(shù)據(jù)面
   數(shù)據(jù)面Sidecar運行在Kubernetes的Pod里债查，作為一個Proxy和業(yè)務容器部署在一起非区。在服務網(wǎng)格的定義中要求應用程序在運行的時候感知不到Sidecar的存在钧栖。而基于Kubernetes的一個Pod多個容器的優(yōu)秀設計使得部署運維對用戶透明惜索，用戶甚至感知不到部署Sidecar的過程。用戶還是用原有的方式創(chuàng)建負載甘有，通過Istio的自動注入服務，可以自動給指定的負載注入Proxy管怠。如果在另一種環(huán)境下部署和使用Proxy淆衷，則不會有這樣的便利。

2. 統(tǒng)一服務發(fā)現(xiàn)
   Istio的服務發(fā)現(xiàn)機制非常完美地基于Kubernetes的域名訪問機制構建而成渤弛，省去了再搭一個類似Eureka的注冊中心的麻煩祝拯，更避免了在Kubernetes上運行時服務發(fā)現(xiàn)數(shù)據(jù)不一致的問題。
   盡管Istio強調(diào)自己的可擴展性的重要性在于適配各種不同的平臺暮芭，也可以對接其他服務發(fā)現(xiàn)機制鹿驼，但在實際場景下欲低，通過深入分析Istio幾個版本的代碼和設計辕宏，便可以發(fā)現(xiàn)其重要的能力都是基于Kubernetes進行構建的。

3. 基于Kubernetes CRD描述規(guī)則
   Istio的所有路由規(guī)則和控制策略都是通過Kubernetes CRD實現(xiàn)的砾莱，因此各種規(guī)則策略對應的數(shù)據(jù)也被存儲在Kube-apiserver中瑞筐，不需要另外一個單獨的APIServer和后端的配置管理。所以腊瑟，可以說Istio的APIServer就是Kubernetes的APIServer聚假，數(shù)據(jù)也自然地被存在了對應Kubernetes的etcd中。
   Istio非常巧妙地應用了Kubernetes這個好基座闰非，基于Kubernetes的已有能力來構建自身功能膘格。Kubernetes里已經(jīng)有的，絕不再自己搞一套财松，避免了數(shù)據(jù)不一致和用戶使用體驗的問題瘪贱。

好啦，后面會整理Istio中的一些基本概念和Demo辆毡。