Service Mesh

最近很常看到這個詞：Service Mesh，源自於 Buoyant - CEO Willian Morgan 在 APRIL 25, 2017 發表的文章：What’s a service mesh? And why do I need one?

Mesh 可以翻譯為：網、網狀物

Service Mesh 第一次出現是 Buoyant 內部的會議，然後 2016/09/29 公開

分散式架構帶來的問題

計算計科學家 Peter Deutsch 在九零年代就提出 Fallacies of distributed computing (分散式系統的謬論) 點出以下容易被忽略、或者輕忽的觀點：

The network is reliable (網路是可靠的)
Latency is zero (網路沒有延遲)
Bandwidth is infinite (頻寬是無限的)
The network is secure (網路是安全的)
Topology doesn’t change (網路拓墣不會改變)
There is one administrator (網路上有個管理員)
Transport cost is zero (傳輸沒有成本)
The network is homogeneous (網路是同質的)

微服務 就是一種分散式架構，不管是否使用 Cloud 或者自建機房，在分散式架構之下，這八點問題都會被放大，同時需要更加被關注，Service Mesh 概念就因應而生。

Peter Deutsch: 生於美國麻塞諸塞州波士頓，計算機科學家、程式設計師、音樂家、企業家。曾參與程式語言 Smalltalk 的創作、Java 編譯技術 Just-in-Time 的開發，他提出的分散式系統的謬論正是 Chaos Engineering 關注的。

關於分散式系統參閱：聊聊分散式系統

Service Mesh 簡介

Service Mesh 中文翻譯成 服務網格，概念上可以這樣解釋：

一種基礎架構 (infrastructure layer) 的服務，負責處理的是 Service 跟 Service 之間通訊的安全、可靠、速度。
現代網路的基礎協議是 TCP/IP，Microservice 的通訊就是 Service Mesh

Microservice 這幾年很夯，是新一代架構的顯學，他雖然聽起來很美好、很夯、很潮、很強，每個 Service 都可以自己選擇適當的語言、生態圈，更有彈性了，大家都可以各玩各的，變成小圈圈，但實踐上，過程中很容易會用各自的語言重新造輪子，像是認證、可靠機制、斷路器 … 等，像是 Java 的 Spring Cloud。

技術上來講，Service Mesh 跟這些很類似：

API Gateway
Reverse Proxy

但實際上，概念卻是不一樣的。

Service Mesh 是跨程式語言、輕量級，主要負責在 Microservice 裡，服務跟服務之間的通訊所需要的功能，如下：

Traffic Control
Service Discovery
Circuit Breakers (斷路器)
Load Balancing
Router
Logging and Tracing
Observability

在 Microservice 的架構裡，Service Mesh 的目的就是像是寫 Web Application，實際上只要知道 HTTP，卻不需要知道 TCP 概念是一樣的。微服務演進過程，大多用 Reservse Proxy、API Gateway 解決類似的問題，分散式系統的設計模式稱為 Sidecar Pattern。

Sidecar Pattern

Sidecar Pattern (中文翻成 側車、邊車)，有以下常用情境：

將 HTTPS 添加到舊服務：通常內部舊的服務都沒有 HTTPS，要符合資安規範，透過 Sidecar Pattern 讓舊服務全部走 HTTPS，舊服務不用改動
使用 Sidecar 作動態配置：傳統配置檔 (JSON, YAML) 是放在服務容器裡，透過 Sidecar Pattern 動態更換配置檔

上述說明詳細參閱 CH02 Sidecar Pattern - Designing Distributed Systems by Brendan Burns (K8s Architect)

Service Mesh 通常就是以 Sidecar Pattern 的方式實踐。

目的

說了這麼多， Service Mesh 對系統架構有什麼好處？對於 Service to Service 來講，彼此之間的協議很重要，協議很抽象，想像是 SLA 好了。

Serivce A 有 Rate Limit 1000rps，Service B 有 500rps，假設這兩個關係是：

A depends on B
B depends on A

那麼當 A 送出超過 500rps 的時候，B 有 Service Mesh ，所以 B 會受到保護，不會因此被 A 打掛。而 A 會收到類這樣的訊息：目前不提供服務，請稍候，如此才能保護 B 不會發生故障，進而引發連鎖反應。

相關概念參閱：

CH21: 處理系統超載 (Handling Overload)

CH22: 處理連鎖故障 (Addressing Cascading Failures)

實作

Service Mesh 目前比較有名的實作有：

Linkerd: 來自 Buoyant, written by Scala (JVM), 已加入 CNCF
Istio: 來自 Goolgle、IBM、Lyft 共同協作 (富爸爸)。支援 k8s, github
Envoy: 來自 Lyft, written by C++, 已加入 CNCF
nginmesh: Nginx 的實作 (跟 istio 整合)

因為要大的 Scale、解決單體難以擴充、維護的問題，出現了微服務；微服務又帶來了新的問題，像是架構更複雜了、更容易重造輪子了、基礎架構更重要了、團隊溝通更複雜了 ….微服務 實際上只是一種方法、手段，技術是要解決問題，滿足商業目標的。

Concepts in Site Reliability Engineering

SRE 書中以下章節提到一些重點：

CH21: 處理系統超載 (Handling Overload)
- 防止超載 (Rate Limit): 相關實作原理參考 Rate Limit and Throttling 整理
- 降級 (斷路器)
CH22: 處理連鎖故障 (Addressing Cascading Failures)
- 資源之間的依賴關係
- 服務不可用
- 服務過載
- 降級 (degradation)

這些重點其實就是 Service Mesh 或者 API Gateway 的功能。

Rate Limit 在 GCP or AWS 很多 API 都已經實作，更多參考 Rate Limit and Throttling 的整理

問題

實務上導入 Microservice 架構已經不容易了，即使現在有很多類似的介紹，但是很多公司實際上還是不知道能帶來啥好處 XD
- 最近的介紹： How to break a Monolith into Microservices by MartinFowler (2018/04/24)
Service Mesh 可以說是 Microservice in Microservice … 所以，要讓團隊能夠體驗它有啥好處不是很容易 ~~聽起來很潮就是了~~
- 成員Ａ：最近在做啥新功能
- 成員Ｂ：導入 Service Mesh！
- 成員Ａ：那是啥？可以講中文嗎？
- 成員Ｂ：他的中文叫 …. Service Mesh！
架構變得更彈性，但也更複雜，找問題挑戰很大

結論

Service Mesh 是通用組件，Sidecar Pattern 說明應用場景，以及在 k8s 如何實踐。他的目的是要解決 Microservice 之間通訊的問題，包含 Discovery、Security、Reliability、Traffic Control、Circuit Breakers …

Service Mesh 跟 API Gateway 是不一樣的。前者是 內部服務 通訊，後者是 對外服務 通訊點。兩者個功能面有些重疊，都有 traffic control、observability、logging … 等功能，但沒有誰取代誰的問題，而是使用場景的問題。

更多 API Gateway 介紹、應用場景、解決方案，參考我的整理：Overview API Gateway

Update 2018/06/15: API Gateway Private Endpoint

Service Mesh

分散式架構帶來的問題

Service Mesh 簡介

Sidecar Pattern

目的

實作

Concepts in Site Reliability Engineering

問題

結論

Service Mesh 相關文章

延伸閱讀

Comments

About

著作

演講

Facebook

AWS Certifications