Service Mesh的起源：爲什麼會出現Service Mesh技術？
微服務架構的特性
特點 1：圍繞業務構建團隊
特點 2：去中心化的數據管理
微服務架構面臨什麼樣的問題？
微服務架構的優勢
- 團隊層面：內聚，獨立開發業務，沒有依賴
- 產品層面：服務彼此獨立，獨立部署，沒有依賴
- 微服務是軟件架構的銀彈嗎？而銀彈理論已經說明了沒有任何一種技術和管理上的進步，可以極大的提升生產效率
服務之間的網絡通信是微服務架構的一大痛點，當微服務越來越多時，整體的調用鏈路就呈現一個複雜的圖狀：
爲什麼網絡通信是微服務架構的痛點？分佈式計算的 8 個謬論（Fallacies of Distributed Computing Explained）：
- 網絡是可靠的
- 網絡延遲是 0
- 帶寬是無限的
- 網絡是安全的
- 網絡拓撲從不改變
- 只有一個管理員
- 傳輸成本是 0
- 網絡是同構的
如何管理和控制服務間的通信？
- 服務註冊/發現
- 路由，流量轉移
- 彈性能力（熔斷、超時、重試）
- 安全
- 可觀測性
Service Mesh的發展：Service Mesh技術是如何演進的？
第一階段：控制邏輯和業務邏輯耦合
- 網絡調用、熔斷、服務發現等控制邏輯與業務邏輯交雜耦合在一起
第二階段：公共庫
- 這個公共庫可以是第三方的，例如Spring Cloud體系中的一些相關框架
- 在這個階段達到了控制邏輯和業務邏輯解耦、消除重複
- 但需要花人力和時間成本去學習這個庫以及維護它，並且通常是語言綁定，且仍有侵入
第三階段：代理
- 公共庫不再和現在的業務邏輯部署在一起，而是單獨抽出一個代理模塊，由該模塊去包含相應的控制邏輯
- 功能簡陋，但思路正確
第四階段：邊車模式（Sidecar)
- 在應用旁邊部署一個Sidecar，由Sidecar去處理所有的網絡請求以及相應的控制邏輯，然後再把請求轉發給應用
第五階段：Service Mesh 的出現
微服務通信的濟世良方：什麼是Service Mesh？它能幫你做什麼？
Service Mesh 的定義
- 所謂 Service Mesh 就是一個用來進行請求轉發的基礎設施層，它通常是以Sidecar的形式部署，並且對應用透明
Service Mesh 的產品形態
- Service Mesh 是 Sidecar 的網絡拓撲模式。整體上分爲數據平面和控制平面
Service Mesh 的主要功能
Service Mesh 和 Kubernetes 的關係
Service Mesh 和 API 網關的異同點
- 功能有重疊，但角色不同
- Service Mesh 在應用內，API 網關在應用之上（邊界）
Service Mesh 技術標準
列王的紛爭：市面上有哪些主流的Service Mesh產品？
Linkerd
- 第一個 Service Mesh 產品
- 2016 年底在 GitHub 上發佈 0.x
- 2017 年加入 CNCF，4 月發佈 1.0 版本
- Conduit – Linkerd2.0：支持 Kubernetes，輕量化
- Linkerd 的敗局？
envoy
- 2016 年 9 月發佈
- 定位於 Sidecar 代理
- 第 3 個從 CNCF 畢業的產品
- 穩定可靠，性能出衆
- Istio 的默認數據平面
- xDS 協議成爲數據平面的事實標準
Istio
- 2017 年 5 月發佈 0.1
- 光環加身：Google，IBM，Lyft 背書
- 第二代 Service Mesh，增加了控制平面，奠定目前 Service Mesh 的產品形態
- 收編 Envoy，直接擁有高水準的數據平面
- 受到社區強烈追捧
AWS App Mesh
- 2018 年 re:Invent 公佈
- 2019 年 4 月 GA 發佈
- 支持自家的多種計算資源的部署
國內發展情況
- 螞蟻金服：SOFA Mesh，MOSN 數據平面
- 幾大雲廠商（騰訊、阿里、百度）
- 華爲、微博
- 其他