為什么要做這次分享？
已經了解到公司基礎架構部門和很多業務部門的技術已經在落地Service Mesh了，Service Mesh本身是個基礎設施，最終肯定會推向各個業務，那對業務開發人員或多或少會有影響，
為了使平台開發工程師和業務開發工程師那時候能更好的溝通，就想對Service Mesh做一個入門的介紹。
Service Mesh的實踐會涉及到容器相關的知識，比如docker和k8s，如果不了解並不影響這次分享，因為這個分享更多的是講述如何理解Service Mesh。
通過本次分享希望大家了解：
-
什么是service mesh？
-
它和微服務有什么關系？
-
基於服務mesh化的思想我們能做些什么？
什么是Service Mesh
“網”是Service Mesh稱呼的由來
微服務當前是什么樣子，和目前的微服務之間的調用相比Service Mesh的區別在哪。
不需要知道目標服務在哪，只需要知道目標sidecar在哪
概述
一個專注於服務間通信的基礎設施。”
Linkerd的CEO William對Service Mesh的描述：
對於數百個服務或數千個實例，以及不時需要重新調度的業務層實例，單個請求通過的調用鏈可能變的非常復雜，而且服務可能由不同的語言編寫，服務通信的復雜性和重要性導致我們急需一個專門的基礎設施層來處理服務間的通信，該層需要與業務代碼解耦，並且具有捕獲底層環境的動態機制。這就是 Service Mesh 。
注： Linkerd是業界第一個Service Mesh，也是他們第一次提出Service Mesh概念。
誕生背景
機器之間頻繁使用網絡交換信息的時候需要處理網絡通信的問題，比如數據丟失，順序錯誤延時阻塞等問題，需要進行流控
TCP和HTTP等標准協議出現以后，對於網絡的處理下沉到了網絡棧里面，和操作系統集成在一起
初代微服務模式
初代微服務-All-in-one
初代微服務模式的時候，應用程序里面加上了大量的非業務性的代碼，業務開發人員除了需要關注業務
的實現還要關注微服務中的服務注冊發現、重試、熔斷等等。
有了微服務開發組件/庫“全家桶以后”
引入了微服務開發“全家桶”，例如Spring Cloud、Netflix OSS套件以后，開發人員從繁重
的保證微服務治理的任務中解放出來，只需要關注自己的業務實現即可。大大簡化了微服務開發的難度，
這也是Spring Cloud等框架后面流行的重要原因之一。
但是，這樣就完美了嗎？大家可以想想當下在進行微服務開發的時候，
是否真的只需要關心業務邏輯。
現階段微服務痛點：我們的服務變成了集成了中間件各種功能的胖客戶端
“事實上，微服務開發做了這么多額外的努力僅僅是為了保證請求能夠成功到達正確的服務”
比如寫一個用戶服務，對用戶做CRUD操作，和剛才說的這些東西有一毛錢關系嗎？這些和服務本身沒關系，那統一處理服務間的通訊就變成了我們需要解決的根源問題。
Sidecar
“它是一個代理，將關於服務通訊的功能抽離出來獨立運行。”
戰爭片里面的戰車。吃雞里面也有
這種在微服務中將業務邏輯與服務通信解藕，並分離為兩個獨立運行組件的做法，正是 Service Mesh 概念的雛形。
那我們再來看一下Sidecar在服務里是以什么形式存在？
這個時期的Sidecar是有局限性的，各個企業為自己的基礎架構定制的。
Service Mesh
有了Sidecar以后，那就有人提出了基於Sidecar的通用型的解決方案
Service Mesh更強調Sidecar連接形成的網絡
“Service Mesh是基於Sidecar的通用方案。”
“Service Mesh 的願景是希望開發者再也不需要將精力花費在服務通信上。
服務通信由每個微服務的 Sidecar 負責”
Service Mesh-主要優勢
- 去中心化：集中式代理變為分布式代理，避免單點故障，比如路由轉發、認證鑒權由統一的網關服務變為以進程的方式和業務服務進程共存
- 跨語言：無需一個語言一個客戶端，均可以HTTP、TCP、gRPC等方式通信
- 和業務解耦：將管理和運維功能從業務服務中抽離，避免中間件客戶端或服務端版本升級對業務造成的影響
- 其他：不需要應用程序做大量改動
Service Mesh是一個基於Sidecar代理模型來處理服務間通信的基礎設施。
Service Mesh的實現：Istio
概述
應用集裝箱被docker這個貨船運載着在大海上無憂無慮的遨游。
K8s是掌舵者，他來管理和控制貨船的行為。
想在大海上無憂無慮的航行，還需要什么，對，帆，有了帆，船在能走的更穩，那這個帆就是我們要說的Istio
是Service Mesh的一個完整的解決方案，作為透明的一層接入到現有的分布式應用程序里。並提供保護、連接和監控微服務的統一方法。
總體架構
Istio 服務網格從邏輯上分為數據平面和控制平面。
數據平面 由一組智能代理（Envoy）組成，被部署為 sidecar。這些代理負責協調和控制微服務之間的所有網絡通信。他們還收集和報告所有網格流量的遙測數據。
控制平面 管理並配置代理來進行流量路由。
服務發現指的是發現sidecar暴露的ip和端口。Istio有一個注冊表（存放服務的地址）來支撐服務路由和負載均衡，它本身不提供服務發現，它是基於底層平台的服務注冊發現能力，
順便將服務的信息通過Pilot組件注冊到其自身的注冊表里。
Sidecar流量劫持，Service和envoy的通信：iptables捕獲和重定向
Envoy
“用於協調服務網格中所有服務的入站和出站流量。”
Envoy（使者的意思） 是 istio 中負責"干活"的模塊,如果將整個 istio 體系比喻為一個施工隊,那么 Envoy 就是最底層負責搬磚的民工, 所有體力活都由 Envoy 完成. 所有需要控制,決策,管理的功能都是其他模塊來負責,然后配置給 Envoy。
Pilot
Envoy在其中扮演的負責搬磚的民工角色, 而指揮Envoy工作的民工頭就是Pilot模塊.
Pilot（領航員的意思）提供了連接，控制的功能。
1、平台啟動一個服務的新實例，該實例通知其平台適配器。
2、平台適配器使用 Pilot 抽象模型注冊實例。
3、Pilot 將流量規則和配置派發給 Envoy 代理，來傳達此次更改。
-
Envoy API負責和Envoy的通訊, 主要是發送服務發現
信息和流量控制規則給Envoy，這些API將istio和Envoy
的實現解耦，使得Envoy可以被其他廠商的數據平面產品接管。 -
Abstract Model 定了一個抽象模型,定義在istio中什么是
服務以從特定平台細節中解耦, 為跨平台提供基礎。 -
Platform Adapter則是這個抽象模型的現實實現版本, 用
於對接外部的不同平台。 -
Rules API 提供接口給外部調用以管理 Pilot, 包括
命令行工具istioctl以及未來可能出現的第三方管理界面。
基於上述的架構設計, Pilot提供以下重要功能：
- 請求路由
- 服務發現和負載均衡
- 故障處理
- 故障注入
- 規則配置
Citadel
“堡壘”的意思。
“之前的版本叫做Istio-Auth。
Citadel通過內置的身份和證書管理，可以支持強大的服務到服務以及最終用戶的身份驗證。”
重要功能：
- 加密
- 身份認證
- 訪問控制
- 密鑰管理
Galley
“之前叫做Mixer。
Galley 是 Istio 的配置驗證、提取、處理和分發組件。它負責將其余的 Istio 組件與從底層平台
（例如 Kubernetes）獲取用戶配置的細節隔離開來。”
重要功能：
- 前提條件檢查，如：認證，黑白名單，ACL檢查
- 配額管理，如：限流
- 遙測報告，如：日志，監控，指標
核心特性
在前面的組件加持下提供的核心特性：
- 流量管理。路由，負載均衡，定義流量配比等。
- 可觀察性。監控，日志，追蹤等。
- 服務身份和安全。身份認證，訪問控制和流量安全防護等。
Istio 是基於Service Mesh，對微服務提供連接，保護，控制，觀測的完整解決方案。
服務Mesh化
先來思考一個問題：
當Service Mesh將業務和服務間的通信解耦之后，當前的微服務還能不能再純粹一點？
Service Mesh中的Sidecar的關鍵在於“解耦”。
而Sidecar這個車艙里不僅僅可以“坐”流量管理的邏輯，也可以將中間件放入其中，
實現業務和中間件的解耦。
即服務Mesh化 = 服務（中間件） + Sidecar
API Gateway Mesh
上面這張圖是一個雲原生，南北+東西流量的架構圖，在Service Mesh環境下使用集中式API Gateway的架構圖
為什么有了service mesh還需要API Gateway？
API Gateway VS Service Mesh
之前了解到Service Mesh也是提供了路由轉發，負載均衡，認證、限流等功能，那他和傳統的API Gateway有什么區別呢？
- API Gateway將內部服務以可管理的方式暴露出去，Service Mesh將業務邏輯和應用網絡解耦；
- API Gateway管理南北流量（外部流量），Service Mesh管理東西流量（服務內部流量）；
- API Gateway是中心化的路由轉發，Service Mesh是類似分布式的，客戶端下的路由轉發，Sidecar 之間是點對點的調用；
- API Gateway里面可能會包含偏業務的一些邏輯， Service Mesh只管理服務間的流量；
隨着兩者的發展，他們開始有了融合，功能上逐漸出現了重疊，那我們能不能把兩者合為一體呢？
結合前面對服務Mesh化的理解，可以得出一個結論：
API Gateway Mesh = API Gateway + Sidecar，
類似的消息隊列（MessageQueue）+ Sidecar = Message Mesh。
帶來的好處
中心化，集中式網關，目前最常見的
中心化網關：單點問題，多一次網絡消耗
客戶端嵌入式，去中心化，Rout提供簡單的路由，將更偏業務的認證鑒權，協議轉換，復雜的路由抽象成一個gateway的jar包或者js文件，和語言有關
客戶端嵌入式網關（去中心化）：
不同語言需要提供不同的client，
接入困難，客戶端升級困難
API Gateway Mesh，去中心化，基於Sidecar代理模型，將gateway以獨立進程和應用部署在一起，達到低成本接入，平滑升級，支持多語言系統
API Gateway Mesh = API Gateway + Sidecar
回顧
1、什么是service mesh？
答：基於Sidecar代理模式的處理服務間通信和流量管理的基礎設施。
2、Service Mesh和微服務有什么關系？
答：它是雲原生時代下保證微服務架構之間通信的一種解決方案，使微服務本身只需關注業務實現。
3、基於服務mesh化的思想我們能做些什么？
答：我們可以借鑒Sidecar的解耦思想，將業務變得更純粹，如API Gateway Mesh，MessageQueue Mesh等。