服務網格接口（Service Mesh Interface，簡稱SMI）是微軟牽頭的多家公司最近剛宣佈的一項全行業規範倡議，它旨在定義一組通用的、可移植的API，爲開發人員提供跨不同服務網格技術的互操作性。SMI的宣佈在Kubecon歐盟場的主題演講中佔據了顯著地位。
隨着微服務、容器以及諸如Kubernetes之類的編排器的大量使用，服務網格技術變得越來越重要。由於服務網格技術的不斷涌現，許多廠商都推出了各種平臺來促進應用程序的開發。然而，這存在廠商鎖定的風險，開發人員將應用程序從一個平臺遷移到另一個平臺的可移植性。
在上層，SMI提供如下功能：
- Kubernetes上的服務網格標準接口
- 用於最通用的服務網格用例的基本特性
- 隨着時間的推移靈活地支持新的服務網格能力
- 使用服務網格技術實現生態系統創新的空間
SMI借鑑了Kubernetes資源Ingress等的原理，定義了一組通用的API，並允許廠商提供自己的最佳實現。使用這些API編程能爲應用程序提供可移植性。
InfoQ就SMI的發佈採訪了微軟首席項目經理Lachlan Evenson。討論的主題還包括Kubernetes上的服務網格生態系統及Gabe Monroy博客上的引用。
InfoQ：在KubeCon歐洲場的主題演講中談到“智能端點和啞管道（smart endpoints and dumb pipes）”，以及隨着微服務的發展，這些管道現在需要怎樣變得更加智能，您能概括下這意味着什麼嗎？
Evenson：多年來，網絡體系結構的口號是儘可能保持網絡管道的靜音，並在應用程序中構建智能。網絡的任務是轉發數據包，而用於加密、壓縮或身份認證的任何邏輯都應存在於網絡端點內。互聯網是以這句格言爲前提的，所以你可以說它運行得相當好。
但是今天，隨着微服務、容器和諸如Kubernetes之類的編排系統的爆炸式發展，工程團隊面臨着越來越多的網絡端點安全、管理和監控問題。服務網格技術通過使網絡變得更智能，爲解決這個問題提供瞭解決方案。服務網格技術不是教所有的服務加密會話、授權客戶端、發射合理的遙測數據，也不是在應用程序版本之間無縫地轉移流量，而是將這種邏輯推送到由一組單獨管理的API控制的網絡中。
InfoQ：我們可以先談下微服務和服務網格的關係嗎？根據 Kubecon歐洲場的走廊討論，SMI對於一般的微服務，尤其是對於Kubernetes來說，似乎還處於採用生命週期的早期，是這樣嗎？
Evenson：如我們所見，由於服務網格技術的激增，許多廠商爲應用程序開發人員提供了新的、令人興奮的選擇。但問題是，轉向網格技術的開發人員必須選擇一個廠商提供者並直接編寫他們的API。他們被鎖定了在服務網格實現中。如果沒有通用的接口，開發人員將失去可移植性和靈活性，並且從廣泛生態系統創新中獲益的能力也會受到限制。
除了Gabe Monroy在博客中提到的內容外，現在的時機正適合SMI，因爲與社區中的其他通用的抽象（CNI、CRI、Ingress、NetworkPolicy）一樣，它們專注於解決開發人員的需求，而不是指定技術實現。在服務網格領域創建一組通用的抽象，能促進生態系統的增長，並能爲開發人員和集羣管理員提供選擇最佳類實現的自由。
InfoQ：您能提供下更多的關於服務網格接口的技術細節，並解釋下這主要是針對開發人員的還是平臺提供商的嗎？如果是針對平臺提供商的，它會以怎樣方式影響開發人員呢？
Evenson：它是以不同的方式來針對兩者的。它允許平臺提供商爲最常用的服務網格特性提供單一抽象，同時能保持爲作業選擇最佳實現的自由。這使平臺能夠保持靈活性和一定的可移植性，同時使用戶能夠訪問最需要的服務網格特性。
從開發人員的角度來看，他們現在有了一組可以從服務網格中獲取需求的API。這些通用抽象刪除了實現中的某些特性。例如，“我希望能爲我的服務提供金絲雀部署”是一個常見的問題，他們可以簡單地使用SMI TrafficSplit API來處理這種複雜問題，而不必編寫離散的低級資源程序。
InfoQ：在主題演講中，提到服務網格接口類似於Kubernetes資源Ingress（在Kubernetes 1.1中引入）。公平地說，Ingress的功能範圍非常具體。而SMI則試圖提供跨多個不同的平臺（ISTIO、Linkerd、Consul等）的通用接口，這些平臺具有比網絡 ingress更多的功能。那將如何克服這一挑戰呢？
Evenson：我們不是隻關注服務網格生態系統的原始功能，而是與企業客戶合作，來了解他們關注服務網格的首要需求。我們讓這些共同的企業需求引導我們在SMI中創建抽象。
InfoQ： 服務網格空間中有大量的使用isito，那麼有多少isito內部構件或概念將出現在SMI中？或者是，SMI僅關注服務網格提供的核心功能呢？
Evenson：是後者，SMI將根據我們從企業客戶那裏瞭解到他們爲什麼使用服務網格，並基於這些信息提供最通用的抽象。
InfoQ：您能談下SMI社區及其路線圖嗎?
Evenson：SMI是一個開放項目，由微軟、Linkerd、HashiCorp、Solo.io、Kinvolk和Weaveworks聯合啓動。並得到了Aspen Mesh、Canonical、Docker、Pivotal、Rancher、Red Hat和VMware的支持。
我們聯合HashiCorp、Buoyant、Solo.io和其他公司根據從企業客戶處瞭解到的三大服務網格功能構建初始規範：
- 流量策略－跨服務應用身份和傳輸加密等策略
- 流量遙測 － 捕獲關鍵指標，如錯誤率和服務間的延遲
- 流量管理 - 在不同服務之間轉移流量
這只是我們希望通過SMI實現目標的開始階段。隨着更多令人興奮的網格功能的開發，隨着時間的推移，我們完全可以期待SMI API的逐步發展，期待新的功能可以擴展當前的規範。
我們正在與創始合作伙伴一起，識別其他應該定義的API，也在爲即將到來的項目里程碑構建路線圖。
綜上所述，服務網格技術已經引起應用程序開發人員的極大關注。SMI借鑑了經過時間考驗的應用程序開發原則，旨在爲多個廠商和平臺提供商提供統一的規範來實現在服務網格實現上的競爭，同時通過一組通用接口爲應用程序開發人員提供可移植性。
請訪問smi-spec.io 瞭解更多關於SMI的詳細信息，瞭解規範本身的相關信息請訪問 GitHub。
原文鏈接：
Service Mesh Interface (SMI): Q&A with Microsoft’s Lachlan Evenson