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 (分散式系統的謬論) 點出以下容易被忽略、或者輕忽的觀點：

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

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

Service Mesh 簡介

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

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

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

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

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

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 不會發生故障，進而引發連鎖反應。

相關概念參閱：

實作

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 書中以下章節提到一些重點：

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

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

問題

  • 實務上導入 Microservice 架構已經不容易了，即使現在有很多類似的介紹，但是很多公司實際上還是不知道能帶來啥好處 XD
  • 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 … 等功能，但沒有誰取代誰的問題，而是使用場景的問題。

Service Mesh 相關文章

延伸閱讀

Comments

2018/02/06 13:30:00
Table of Content
Categories
Tags

About

  • 全站索引
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學

    • 著作

  • 個人著作：SRE實踐與開發平台指南
  • 共同著作：軟體測試實務 (2023)
  • 譯著：分散式系統設計 (2019)

    • 演講

  • 演講錄影 @ Youtube
  • 探索職涯、複利人生 - AWS Career Exploration Day 2023
  • 個人著作 SRE 書友見面會
  • 軟體測試實務 - 新書發表會
  • 探索職涯、成就未來 - AWS Career Exploration Day 2022
  • 從理想、到現實的距離，開啟品味軟體測試之路
  • 91APP 在 AWS 上的 SRE 實踐之路
  • 在矩陣型組織裡，如何有效管理 AWS 的成本結構與系統架構
  • 災難演練 @ AWS 實戰分享
  • 導讀持續交付 2.0 - 談當代軟體交付之虛實融合
  • 聊聊軟體交付的濫觴 談產出物管理
  • 從緊急事件 談 SRE 應變能力的培養
  • 邁向 API 經濟 - API Gateway 導入之旅
  • Monitoring Tools 大亂鬥 - AWS CloudWatch
  • Ops as Code using Serverless
  • 淺談系統監控與 CloudWatch 的應用

    • Facebook

    Complete Think

    AWS Certifications

  • 全站索引
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
    • ▲ TOP ▲