服務網格重蹈ESB的覆轍？為什麼需要SMI服務網格介面？ - samnewman

banq發表於2019-05-23

SMI（Service Mesh Interface）是一組API，允許不同的服務網格（Service Mesh）相互操作。

微軟的這篇文章概述了SMI背後的一點，摘錄部分內容如下：
今天，我們很高興推出Service Mesh Interface（SMI），它定義了一組通用的可移植API，為開發人員提供跨不同服務網格技術的互操作性，包括Istio，Linkerd和Consul Connect。SMI是一個與微軟，Linkerd，HashiCorp，Solo.io，Kinvolk和Weaveworks合作開展的開放專案，受到Aspen Mesh，Canonical，Docker，Pivotal，Rancher，Red Hat和VMware的支援。

多年來，網路架構的流行做法是讓管道盡可能愚蠢，在應用程式端點中構建智慧（banq注：啞管與智慧端點）。網路的工作只是轉發資料包，而加密，壓縮或標識身份的任何邏輯都必須存在於端點內。網際網路是以這種習慣為前提的，所以你可以說它運作得相當好。

但是，隨著像Kubernetes這樣的微服務，容器和編排系統的爆炸式增長，工程團隊面臨著越來越多的網路端點的安全，管理和監控。服務網格技術是透過讓網路管道更智慧，從而更智慧地提供安全管理監控等問題的解決方案。（banq注：與啞管與智慧端點的習慣正好相反）

服務網格技術不是讓所有端點服務來進行加密會話，授權客戶端，發出合理的遙測，並在應用程式版本之間無縫轉換流量，而是將此邏輯推入網路，由一組單獨的管理API控制，這是雲原生態系統中的流行模式。

我們看到服務網格技術激增，許多供應商為應用程式開發人員提供了新的令人興奮的選擇。問題是轉向網格技術的開發人員必須選擇提供者並直接寫入這些API。它們被鎖定在服務網格實現中。如果沒有通用介面，開發人員就會失去可移植性，靈活性，並限制從廣泛的生態系統中獲益的能力。

Service Mesh Interface提供：
  • Kubernetes網格的標準介面
  • 最常見的網格用例的基本功能集
  • 隨著時間的推移靈活地支援新的網格功能
  • 生態系統利用網格技術進行創新的空間


思考
“保持端點智慧，管道愚蠢”這是通用原則和想法，上面微軟這篇文章直接指出Service Meshes正在逐漸遠離這個想法，這是一件好事。

當初企業匯流排ESB就也是違背這套原則，今天在服務網格上再次出現，說明這個概念很難讓人理解！

我第一次聽到@jimwebber或@iansrobinson所說的 “保持你的端點聰明，管道愚蠢”這句話。這是對生活在中介軟體中的應用程式智慧的反應，需要對中介軟體進行更改以推出新功能。

這句話“並不”意味著管道本身不應該是一個好的管道。如果您使用訊息代理，則希望它執行保證傳遞等操作。關鍵是把你的聰明才智放在管道還是端點的問題。

人們過去會在訊息代理層中進行業務流程編排，現在看到人們在API閘道器中也在做同樣的事情，這變得很常見了，這些閘道器很快將成為微服務基礎上的企業服務匯流排（banq注：ESB最初是SOA基礎上，由於加入了很多業務，變成泥球和混亂的根源）。

將業務邏輯放入中介軟體是有問題的，因為您需要協調部署，但也需要協調控制，因為構建應用程式的人通常與管理中介軟體更改的人不同。

所以，回到原來的概念。保持端點智慧和管道愚蠢就是要保持業務功能不受中介軟體影響，確保您可以更快地釋出軟體。

服務網格可以幫助我們解決使用微服務架構中出現的一些問題。但作為一種中介軟體形式，它們容易受到與ESB一樣的濫用，只不過現在是表現為API閘道器。

API閘道器將和ESB一樣形成生產力的泥潭，這些公司可能會在服務網格中犯同樣的錯誤。但我們不能直接責怪這個工具。

但佈道推廣服務網格的人必須確保他們至少清楚如何使用該工具，因此值得確保我們談論相同的事情。

如果您想在服務網格中使用與路由，跟蹤，流量整形，服務發現等相關的“智慧”，那就直接使用吧，但是保持與您的服務，業務功能相關的邏輯在您的控制範圍內，如果您開始讓這些東西滲透到您的中介軟體中，您將重複90年代所犯的相同錯誤。

順便說一句，這種在業務功能和路由/傳輸之間分離關注點的想法絕不是新的。我和其他許多人都將@TotherAlistair的埠和介面卡/六角形架構思想作為微服務中的現有技術架構。

請記住，微服務架構的核心概念是實現獨立可部署性，因此我們需要找到構建架構的方法，以便針對此目標進行最佳化。

因此，如果您發現自己經常需要更改中介軟體，無論是ESB，API閘道器還是服務網格，請暫停一下，問問自己，您的架構是否適合您，或者您是否在為您的架構工作？

相關文章