Service Mesh Interface詳細介紹

SMI介紹

SMI是什麼？

5月21號，在 kubeconf上，微軟聯合一衆小夥伴，宣佈了 Service Mesh Interface，簡稱SMI。SMI是一個服務網格規範，定義了通用標準，包含基本特性以滿足大多數場景下的通用需求。

援引來自SMI官方網站 smi-spec.io 的介紹資料，對 Service Mesh Interface 的定位是：

A standard interface for service meshes on Kubernetes.

Kubernetes上的 service mesh 的標準接口

微軟的官方博客文章這樣介紹SMI：

SMI定義了一組通用可移植的API，爲開發人員提供跨不同服務網格技術的互通性，包括Istio，Linkerd和Consul Connect。

SMI 是希望在各家 Service Mesh 的實現之上建立一個抽象的API層，然後通過這個抽象來解耦和屏蔽底層 Service Mesh 實現，讓上層的應用、工具、生態系統可以建立在一個業界標準之上，從而實現跨不同實現的可移植性和互通性。

SMI推出的背景

Idit Levine，初創公司 solo.io 的創始人兼CEO，作爲SMI推出的重要力量之一，撰文描述了 SMI 推出的背景：

服務網格生態系統正在興起，衆多的網格供應商和不同的用例需要不同的技術。所以問題來了：我們如何實現在不破壞最終用戶體驗的前提下促進行業創新？通過以一組標準API達成一致，我們可以提供互通性，並在不同網格以及爲這些網格構建的工具之上維持最終用戶體驗。

今天發佈的 Service Mesh Interface（SMI）是使這一構想走向行業現實的重要一步。

下面這幅圖片可以非常清晰的表述SMI的定位，也可以幫助我們一起來解讀SMI推出的背景：

Service Mesh的價值正在被普遍認可：從最早的Linkerd，Envoy，到兩年前Google力推Istio，以及 Linkerd2 的推出，最近 AWS 推出了 App Mesh，Google 則將 Istio 搬上了Google Cloud 推出了 Istio 的公有云託管版本 Google Cloud Service Mesh，還推出了單獨的控制平面產品 Google Traffic Director。微軟也在去年推出了Azure完全託管版本的Service Fabric Mesh （預覽版）。雲市場三巨頭都已經先後出手。
市場上出現了衆多的Service Mesh產品：開源的，閉源的，大公司出的，小公司出的，市場繁榮的同時也帶來了市場碎片化的問題。

在雲原生理念下，我們推崇應用輕量化，只關注業務邏輯。Service Mesh技術很好的實現了這一戰略目標：運行在 service mesh 上的應用可以和底層 service mesh 的具體實現解耦。理論上應用在不同的 service mesh 實現上遷移是可行的，從這一點說，service mesh 在雲原生的道路上邁出了重要一步。
但是，所有圍繞業務應用的外圍工作，比如通過 service mesh對流量進行控制，配置各種安全/監控/策略等行爲，以及在這些需求上建立起來的工具和生態系統，卻不得不牢牢的綁死在某個具體的 service mesh實現上，所謂”供應商鎖定”。
其根本問題在於各家實現不同，又沒有統一標準。因此，要想解決上述問題，就必須釜底抽薪：解決 Service Mesh 的標準化問題。

微軟給出的解決方案就是引入SMI，作爲一個通用的行業規範/標準，如果能讓各家 service mesh 提供商都遵循這個標準，則有機會在具體的 service mesh 產品之上，抽象出一個公共層（如定義一組通用可移植的API），屏蔽掉上層應用/工具/生態系統對具體 service mesh 產品的實現細節。

是不是覺得 SMI 的概念有種熟悉的味道？是的，沒錯，類似的事情在k8s中之前就發生過很多次，比如 CNI、CRI、CSI，還有下圖展示的 Ingress：

在SMI中，將這個目標稱爲 “Interoperability” / 互通性。我個人理解，這其實和 google 一直在倡導的 “not lock-in” 是一個概念：有通用的社區標準/行業標準，在此基礎上客戶可以在多個實現/多個供應商之間自由選擇和遷移，沒有被綁定的風險，而且提供給用戶的功能以及使用方式也保持一直，也就是 Idit Levine 所強調的 “維持最終用戶體驗”。

從這個角度說，我很欣喜的看到 SMI 的推出，雖然這條路可能不是那麼容易走，但是，的確，”Service Mesh Interface（SMI）是使這一構想走向行業現實的重要一步”。

和通用數據平面API的關係

在SMI提出來之前不久（大概早兩個星期），CNCF也在進行類似的標準化操作：CNCF正在籌建通用數據平面API工作組（Universal Data Plane API Working Group / UDPA-WG)，以制定數據平面的標準API，爲L4/L7數據平面配置提供事實上的標準，初始成員將包括 Envoy 和 gRPC 項目的代表。事實上是 Google 在驅動，主要參與的項目是 Istio 和 Envoy。

下面這張圖片展示UDPA 和 SMI 這兩個新近推出的 Service Mesh 標準API的關係：

Universal Data Plane API 是數據平面的標準，控制平面通過這個API來控制數據平面的行爲。工作組的初始成員來自包括 Envoy 和 gRPC 項目的代表，背後的公司主要是 Google 。
Service Mesh Interface 是控制平面的標準，上層的應用/工具/生態體系通過 Service Mesh Interface 來實現跨不同的Service Mesh實現爲最終用戶提供一致性的體驗。SMI由微軟牽頭，聯合 Linkerd，HashiCorp，Solo，Kinvolk和Weaveworks。

SMI的目標和願景

關於 SMI 的目標和願景，我援引 Idit Levine 的這段話（這段話也同樣出現在 smi-spec 的 github 首頁）：

SMI 是在 Kubernetes 上運行服務網格的規範。它定義了由各種供應商實現的通用標準。這使得最終用戶的標準化和服務網格供應商的創新可以兩全其美。SMI 實現了靈活性和互通性。

更詳細而明確的目標描述來自 smi-spec 的 github 首頁：

目標

SMI API的目標是提供一組通用的，可移植的Service Mesh API，Kubernetes用戶可以以供應商無關的方式使用這些API。通過這種方式，可以定義使用Service Mesh技術的應用程序，而無需緊密綁定到任何特定實現。

然後還特別強調：

非目標

SMI項目本身不實現服務網格。SMI只是試圖定義通用規範。同樣，SMI不定義服務網格的具體範圍，而是一個通用子集。歡迎SMI供應商添加超出SMI規範的供應商特定擴展和API。我們希望隨着時間的推移，隨着更多功能被普遍接受爲服務網格的一部分，這些定義將遷移到SMI規範中。

總結：首先非常明確的一點是，SMI是定義標準API，而不是標準實現。

而 SMI 的具體目標，在 SMI 的官方網站是這樣介紹的：

A standard interface for service meshes on Kubernetes: Kubernetes上的 service mesh 的標準接口
A basic feature set for the most common service mesh use cases：用於最通用的服務網格用例的基本特性
Flexibility to support new service mesh capabilities over time：隨着時間的推移靈活地支持新的服務網格能力
Space for the ecosystem to innovate with service mesh technology: 使用服務網格技術實現生態系統創新的空間

SMI社區

有需求，有市場，有想法，有目標，我們再來看看 SMI 陣營現在都有什麼力量。

微軟在推出 SMI 時的描述到：SMI是一個開放項目，由微軟，Linkerd，HashiCorp，Solo，Kinvolk和Weaveworks聯合啓動; 並得到了Aspen Mesh，Canonical，Docker，Pivotal，Rancher，Red Hat和VMware的支持。

陣營還是挺強大的：

微軟：SMI的帶頭大哥，雲計算的三巨頭之一
Buoyant：Service Mesh 技術的拓荒牛 + 佈道者，小而彌堅的初創公司，有一個不大但是力量很強又非常有經驗還很務實的團隊。其旗下的 Linkerd2 已經明確表示將支持 SMI。
HashiCorp：大名鼎鼎的 consul 就出自這裏，Consul Connect 也是目前活躍的 service mesh 實現之一，雖然Consul Connect在國內知名度和影響力都很小（也就年度總結的時候捎帶着看一眼狀態的那種）。Consul Connect 目前也表示提供了對 SMI 的支持。
Solo.io：深藏不露的初創型小公司，”產品面很廣，除了 Service Mesh 方面大有名氣的 SuperGloo 和 Service Mesh hub 之外，還有遠程調試、混沌工程、unikernels 以及微服務網關等幾個產品。”（這段話我從秀龍的文章裏面抄過來的，總結的很好）。另外，業界網紅 Christian Posta 前段時間加入這家公司。solo公司旗下的 SuperGloo 是業界第一個 service mesh 編排產品，因此對 SMI 的熱愛和支持是無可復加的。SuperGloo 和 Service Mesh Hub 已經實現了對 SMI 的支持。
Mesery 和 Kinvolk：這兩家公司最近在 service mesh社區有點名氣，因爲他們近期做了 Istio vs Linkerd 的性能測試並給出了報告，鬧的滿城風雨。而且他們也都喜歡用 solo 出的 SuperGloo（畢竟業界號稱 service mesh 編排的也就獨此一家）。
Aspen Mesh： F5 （沒錯，就是那個巨貴的F5）出的的Istio商業版本。但是沒有看到 Aspen Mesh 給出支持 SMI 的信息，暫時還不知道 Aspen Mesh 和 SMI 的關係。
vmware：vmware在2018年底推出了 VMware NSX Service Mesh ，和Aspen Mesh一樣也是基於 Istio 。

其他公司就不再一一列出來了，主要是不清楚他們在 SMI 這個事情上扮演什麼角色。

而關鍵點在於，Google （還有同屬Istio陣營的 IBM / Lyft）不在其列。而 Service Mesh 的其他玩家，幾乎都參與了 SMI，甚至包括原本在 Istio 項目上和 google 一直合作的公司，耐人尋味。

SMI規範內容

SMI規範介紹

Service Mesh Interface 規範涵蓋最常見服務網格能力：

Traffic Policy/流量策略 - 跨服務應用身份和傳輸加密等策略
Traffic Telemetry/流量遙測 - 捕獲關鍵指標，如錯誤率和服務間的延遲
Traffic Management/流量管理 - 在不同服務之間轉移流量

SMI規範由多個API組成：

Traffic Access Control/流量訪問控制 - 根據客戶端的身份配置對特定pod和路由的訪問，以將應用程序鎖定到僅允許的用戶和服務。
Traffic Specs/流量規範 - 定義流量的表示方式，基於每個協議的基礎。這些資源與訪問控制和其他類型的策略協同工作，以在協議級別管理流量。
Traffic Split/流量分割 - 逐步引導各種服務之間的流量百分比，以幫助構建金絲雀推出。
Traffic Metrics/流量指標 - 暴露通用的流量指標，供dashboard和autoscaler等工具使用。

注意：SMI 被指定爲 Kubernetes Custom Resource Definitions（CRD）和 Extension API Servers 的集合。這些API可以安裝到Kubernetes集羣上，並使用標準工具進行操作。

在設計上，SMI 強調 “Provider Agnostic（供應商無關）”：

SMI API的目標是提供一組通用的可移植的服務網格API，Kubernetes用戶可以以供應商無關的方式使用這些API。通過這種方式，人們可以定義使用服務網格技術的應用程序，而無需緊密綁定到任何特定實現。

下面我們來詳細看一下 SMI 規範的具體API定義，其定義來自https://github.com/deislabs/smi-spec 。

Traffic Spec

Traffic Spec資源用於讓用戶定義流量。通常與Access Control（訪問控制）和其他策略一起使用，以具體定義需要如何處理流經網格的特定類型流量。

用戶往往希望在服務網格內運行許多不同的協議。當然，主要會是HTTP，但也會有其他協議。 Traffic Spec規範中的每個資源都旨在與特定協議1：1匹配。這讓用戶可以以協議特定的方式來定義流量。

HTTPRouteGroup

HTTPRouteGroup 資源用於描述HTTP/1和HTTP/2流量，它枚舉了應用程序可以提供的路由。

apiVersion: specs.smi-spec.io/v1alpha1
kind: HTTPRouteGroup
metadata:
  name: the-routes
matches:
- name: metrics
  pathRegex: "/metrics"
  methods:
  - GET
- name: health
  pathRegex: "/ping"
  methods: ["*"]

上面的例子定義兩個match，metrics和health。 name 字段是key，所有字段都是必需的。正則表達式用於匹配URI。 HTTP Mesh可以具體制定如 GET 或用 * 來匹配所有。

HTTPRouteGroup 當前的功能限制（未來會加入，只是當前作爲第一個版本內容還比較少）：

只支持 HTTP 協議，連 gRPC 都還未支持
match 字段當前僅適用於 URI。很明顯這是不夠的，未來計劃擴展以支持HTTP header，Host等。

個人看法：目前在只有 HTTP 協議支持，而且 HTTP 路由定義居然不支持 HTTP header 匹配，足夠說明目前 SMI 的確是處於項目早期狀態。

TCPRoute

TCPRoute資源用於描述 L4 TCP流量。這個路由極其簡單（或者叫做簡陋），定義應用程序接收到的原始的、無協議特徵的流量。

看完下面的yaml例子就明白爲什麼稱爲極其簡單了：

apiVersion: specs.smi-spec.io/v1alpha1
kind: TCPRoute
metadata:
  name: tcp-route

上面的路由只做了定義，尚未與任何資源相關聯。我們繼續看如何使用，比如與Access Control 配合。

Traffic Access Control

Traffic Access Control 資源用來爲應用程序定義訪問控制策略：

訪問控制屬於授權（authorization）範疇，默認身份驗證（Authentication）已經由底層實現處理
SMI規範中的訪問控制是附加的，默認情況下拒絕所有流量。

TrafficTarget 規範

TrafficTarget 規範用來定義流量訪問控制，而 SMI 中訪問控制是基於服務身份（service identity）的，並且目前只支持通過 Kubernetes service account 來指派服務身份（其他身份機制將在稍後支持）。

流量訪問控制有三個概念，分別在 TrafficTarget 中以三個字段定義：

Source：流量的來源，體現爲具體的 Pod 列表，目前支持通過selector來實現，暫時不支持以資源的方式選擇（如指定Deployment、指定Service）
Destination：流量的目標，同樣體現爲具體的 Pod 列表，也只支持selector
Route：流量規範，用來區分 Destination 提供的多種不同的流量訪問方式，如下圖中的api訪問和獲取metrics信息

在這個例子中，展示對api進行訪問和獲取metrics信息這兩個操作的流量訪問控制：

# 定義TrafficSpec
apiVersion: specs.smi-spec.io/v1alpha1
kind: HTTPRouteGroup
metadata:
  name: api-service-routes
matches:
  - name: api  # api訪問的流量
    pathRegex: /api
    methods: ["*"]
  - name: metrics # 獲取metrics的流量
    pathRegex: /metrics
    methods: ["GET"]

---
kind: TrafficTarget
apiVersion: access.smi-spec.io/v1alpha1
metadata:
 name: api-service-metrics # 定義獲取metrics的Target
 namespace: default
destination:	# 通過 ServiceAccount 選擇pods
 kind: ServiceAccount
 name: api-service
 namespace: default
specs: # 引用traficSec定義的route，指定爲獲取metrics
- kind: HTTPRouteGroup
  name: api-service-routes
  matches:
    - metrics
sources: # 通過 ServiceAccount 選擇pods
- kind: ServiceAccount
  name: prometheus
  namespace: default

---
kind: TrafficTarget
apiVersion: access.smi-spec.io/v1alpha1
metadata:
 name: api-service-api # 定義訪問api接口的Target
 namespace: default
destination: # 通過 ServiceAccount 選擇pods
 kind: ServiceAccount
 name: api-service
 namespace: default
 port: 8080
specs: # 引用traficSec定義的route，指定爲api訪問
- kind: HTTPRouteGroup
  name: api-service-routes
  matches:
    - api
sources: # 通過 ServiceAccount 選擇pods
- kind: ServiceAccount
  name: website-service
  namespace: default
- kind: ServiceAccount
  name: payments-service
  namespace: default

上述實例定義了兩個容許的訪問控制：

對於以 ServiceAccount 爲 api-service 運行的 pods，容許來自以 ServiceAccount 爲 prometheus 的 pods 訪問 api-service-routes 定義下的 metrics 路由
對於以 ServiceAccount 爲 api-service 運行的 pods，容許來自以 ServiceAccount 爲 website-service 和 payments-service 的 pods 訪問 api-service-routes 定義下的 api 路由

其中有部分字段爲可選字段：

matches 字段：如果省略，則對 TrafficSpec 下定義的所有Route都生效
Port字段：如果省略，則表示所有端口

SMI 流量訪問控制的規則是默認都不容許訪問，只有通過 TrafficTarget 指定的符合條件的流量才容許訪問。而訪問控制的執行，是明確要求在訪問的服務器端（即Destination）強制執行，而是否在客戶端（即Source）進行訪問控制則由SMI的具體實現來決定。

注意目前 Traffic Access Control 在定義 Source 和 Destination 時，都是通過 Selector 來定義的，我們細看這張圖片：

從訪問控制的業務語義上看，上面兩個 TrafficTarget 翻譯出來就是：

容許以 ServiceAccount prometheus 運行的服務訪問以 ServiceAccount api-service 運行的服務的 metrics
容許以 ServiceAccount web-service 和 payment-service 運行的服務訪問以 ServiceAccount api-service 運行的服務的 api

而不是我們平時熟悉的資源方式如”容許A服務訪問B服務”，即訪問控制中對服務的標示目前只能通過 ServiceAccount + Selector 來完成，而不是通過簡單的服務Id或者名稱來指定資源。請注意”容許以身份A運行的服務訪問以身份B運行的服務” 和 “容許A服務訪問B服務” 的細微差別。

關於這一點，在 SMI 的文檔的”Tradeoffs”中提到：

Resources vs selectors - it would be possible to reference concrete resources such as a deployment instead of selecting across pods.

資源 vs 選擇器 - 可以引用具體資源（如deployment）而不是pod選擇。

Traffic Split

Traffic Split 資源用來實現流量的百分比拆分，熟悉Istio的同學應該非常瞭解這個功能的強大。

但是 SMI 中 Traffic Split 的配置方式和 Istio 有非常大的不同，比如下面的配置，要對 foobar 服務按照版本進行流量拆分，v1 和 v2 權重分別爲 1 和 500m （1=1000m），在 Traffic Split 的配置中會出現多個 service：

apiVersion: split.smi-spec.io/v1alpha1
kind: TrafficSplit
metadata:
  name: foobar-rollout
spec:
  service: foobar # root service，客戶端用這個服務名來連接目標應用
  backends: # root service 後面的服務，有自己的selectors, endpoints 和 configuration
  - service: foobar-v1
    weight: 1
  - service: foobar-v2
    weight: 500m

“foobar”：通過 spec.service 指定，這是 Traffic Split 的 root service，是要配置進行流量拆分的目標服務的FQDN，客戶端用這個 service 進行通信，也就是說這個 root service 是暴露給客戶端的。
“footer-v1” 和 “footer-v2”：這兩個後端服務，是”隱藏”在 root service 後面的，通常是 root service 的子集，典型實現上是 selector 多加一個 version label 限制。

這樣，如果要對某個服務的兩個子集進行流量拆分，典型如版本v1和版本v2，在 SMI 中就會有三個 k8s service 定義：

資源	selector （label）	描述
service foobar	`app: foobar`	root service
service foobar-v1	`app: foobar, version: v1`	backend service
service foobar-v2	`app: foobar, version: v2`	backend service

這三個 service 和 pod 的關係如下圖所示：

我們來對比 Istio 中實現類似功能的方式，Istio中需要爲準備進行流量拆分的服務定義 VirtualService，通過 subset 來區分不同的流量去向：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: foobar-route
spec:
  hosts:
  - foobar
  http:
  - route:
    - destination:
        host: foobar
        subset: v2
      weight: 25
    - destination:
        host: foobar
        subset: v1
      weight: 75

subset 在 DestinationRule 中定義，注意這裏只涉及到 labels，服務（以host標誌）並沒有多個，還是 foobar：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: foobar-destination
spec:
  host: foobar
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

在Istio 中，service 和 subset 的關係如下圖所示：

可以看到 SMI 中的 backend service 和 Istio 中的 subset 在功能上幾乎是對等的。

但是：SMI 和 Istio 的根本差異在於 Istio 中的 subset 是一個虛擬的抽象對象，在k8s中並沒有實體資源。而在 SMI 中，backend service 是實實在在存在的 k8s service 資源。

這裏個人覺得有一個隱憂：在 SMI 中，爲了進行流量拆分，就不得不爲每個版本建立一個獨立的k8s service，service 數量會比 Istio 方案多很多。

另外就是在權重設置上的細微的差別，SMI 用的是相對weight（比如可以設置爲1:2），而 Istio 是嚴格的百分比，而且要求總和爲100。

Traffic Metrics

Traffic Metrics 資源提供通用集成點，工具可以通過訪問這些集成點來抓取指標。Traffic Metrics 遵循 metrics.k8s.io 的模式，其即時指標可用於各種 CLI工具，HPA伸縮等。

和大多數Metrics系統一致，SMI的Traffic Metrics 數據包含兩個核心對象：

Resource：Metrics 和資源綁定，資源可以是 pod 和更高級別的概念如 namespaces, deployments 或者 services 。Pod是 Metrics 可以關聯的最細粒度的資源，通過集合可以得到推斷出其他。
Edge：表示流量來源或其目的地，描述力量的方向。

TrafficMetrics

TrafficMetrics是核心資源，關聯到資源，具有edge，延遲百分位數和請求量：

apiVersion: metrics.smi-spec.io/v1alpha1
kind: TrafficMetrics
resource:
  name: foo-775b9cbd88-ntxsl
  namespace: foobar
  kind: Pod
edge:
  direction: to
  resource:
    name: baz-577db7d977-lsk2q
    namespace: foobar
    kind: Pod
timestamp: 2019-04-08T22:25:55Z
window: 30s
metrics:
- name: p99_response_latency
  unit: seconds
  value: 10m
- name: p90_response_latency
  unit: seconds
  value: 10m
- name: p50_response_latency
  unit: seconds
  value: 10m
- name: success_count
  value: 100
- name: failure_count
  value: 100

TrafficMetrics 的定義和使用暫時沒看到有特殊之處。

SMI規範總結

從上面我們詳細分析的 SMI 主要規範的定義看，Traffic Access Control / Traffic Specs / Traffic Split / Traffic Metrics 這四個目前定義好的規範，無論從功能還是從API設計上看，都缺乏亮點，至少與目前大家熟悉的 Istio API 相比，沒有明顯優勢：

Traffic Specs 中 HTTPRouteGroup 只支持HTTP1.1，甚至不支持header，TCPRoute更是簡陋到極致
Traffic Access Control 只支持 ServiceAccount
Traffic Split：需要爲每個需要拆分的流量額外增加 k8s service
TrafficMetrics：平平無奇

考慮到目前 SMI 還是第一個版本，處於項目早期階段，不夠成熟情有可原，我們更要關注的是其後續版本的演進，希望未來 SMI 可以成長爲一個足夠堅實而可用的標準API。

SMI分析

前面我們分析過 SMI 推出的背景，我歸結爲關鍵的兩點：

有利可圖：Service Mesh技術被普遍看好，其長遠價值被各大廠商認可
有機可趁：作爲市場領頭羊的Google和Istio，表現疲軟

另外Google在Istio項目上，表現也有些令人費解：

遲遲不進CNCF：早先還有未能發佈1.0版本不滿足CNCF要求的藉口，而最近則感覺Google一直在避免討論這個話題
Istio一直沒有對 Service Mesh 技術進行標準化：只關注自己的 Istio API，對於標準化和基於標準化構建生態系統完全沒興趣。即便是統一數據平面API的標準化動作，也讓人覺得是 Envoy 在推動。
宣傳和現實的差距：Istio 1.0 的 “Product Ready”，1.1 版本的”Enterprise Ready”，很讓人無語，我很期待 1.2 版本出來時的口號。
架構設計的不務實：Mixer 是被嘲弄的重災區，躲在Mixer身後的Pilot其實問題也一堆，而 Mixer v2 的進展則成爲衡量 Istio 未來走向的風向標，是要成爲工業級可用的堅實產品，還是繼續擺弄優雅架構做花瓶？未來一年我們拭目以待。
整個社區對Istio的不滿情緒一直在醞釀和累積：這次 SMI 推出引發的轟動，很大程度是這種情緒的發泄——除了Google之外幾乎所有的 Servic Mesh 的玩家都參與進來了，這就足夠說明問題了。

在過去兩年，社區一直在期待Google和Istio，但是，這種期待在持續兩年的失望之後，開始轉向另外的方向：或許我們要更多的考慮Istio之外的選擇了。

Service Mesh 的戰爭，我們原以爲會以Istio的勝利而迅速結束，但是現在看來，可能這場戰爭纔剛剛開始。

是重新認真審視這張圖片的時候了：

SMI 的推出，意義並不僅僅在於這個 Service Mesh 標準本身，而是帶有另外一種特殊含義，就如陳勝吳廣的揭竿而起，傳遞給四方的消息是：天下苦秦久矣！

文章最後，希望未來有更多的優秀 Service Mesh 產品出現，也希望 Istio 可以知恥而後勇。Service Mesh 技術要想成功普及，一定需要一個或者多個強力產品的出現，而 SMI 的出現則爲這場短期不能結束的紛爭帶來了一個理論可能：無論產品競爭如何激烈，都不影響上層生態，從而避免站隊失敗的風險和由此帶來的猶豫與觀望。這纔是我個人覺得 SMI 推出的最大意義所在。

參考資料

smi官方網站
smi-spec項目@github
Interoperability with the new Service Mesh Interface
意外：Servicemesh Interface（SMI）
Hello Service Mesh Interface (SMI): A specification for service mesh interoperability: 來自微軟的博客，比較權威，本文很多內容是援引自此文
Service Mesh Interface (SMI) and our Vision for the Community and Ecosystem：作者 Idit Levine，是初創公司 solo.io 的創始人兼CEO，本文同樣大量援引此文的內容
Democratizing Service Mesh on Kubernetes: kubecon上宣佈SMI的 keynote，作者 Gabe Monroy ，Microsoft Azure Container Compute的 Lead Product Manager，本文部分圖片來自這個演講的PPT
How the Service Mesh Interface (SMI) fits into the Kubernetes landscape: 介紹SMI和其他類似的kubernetes Interface 如 CNI、CRI、CSI等。
KubeCon EU 2019: Top 10 Takeaways: 來自網紅 Daniel Bryant 的文章，包含對 SMI 和 Istio 的看法。
Service Mesh Wars with William Morgan：這是我見過的抨擊Istio最爲猛烈的一篇文章，極其火爆，又很有道理的樣子
To Istio and beyond: Azure’s Service Mesh Interface: 有軟文嫌疑，但是還是能看出微軟推出SMI的基本想法
HashiCorp Consul supports Microsoft’s new Service Mesh Interface: 介紹 Consul Connect 對 SMI 的支持

作者介紹

敖小劍

中年碼農

我目前研究的方向主要在Microservice、Servicemesh、Serverless等和Cloud Native相關的領域，歡迎交流和指導

本文轉載自敖小劍的博客。

原文鏈接：

https://skyao.io/post/201906-service-mesh-interface-detail/

Service Mesh Interface詳細介紹

SMI介紹

SMI是什麼？

SMI推出的背景

和通用數據平面API的關係

SMI的目標和願景

SMI社區

SMI規範內容

SMI規範介紹

Traffic Spec

Traffic Access Control

Traffic Split

Traffic Metrics

SMI規範總結

SMI分析

參考資料

作者介紹

DAPPER 事務 TRANSACTION

死生之地不可不察：論API標準化對Dapr的重要性

雲原生分佈式應用運行時 Dapr 在阿里的實踐

Mecha：將Mesh進行到底

Service Mesh 通用數據平面 API（UDPA）最新進展深度介紹

Service Mesh發展趨勢(續)：棋到中盤路往何方

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結