服務網格社群爭吵最近新動向！ - Christian Posta

banq發表於2019-06-11

服務網格是一組重要的功能，可以在運營服務式架構時解決一些困難的服務到服務通訊挑戰。就像Kubernetes和容器有助於在一組計算機上提供一組很好的抽象來部署和執行工作負載一樣，服務網路也出現了抽象網路，使運營商和開發人員能夠控制請求路由，可觀察性和政策執行。這提供了很多潛力。
唯一的問題是，雖然Kubernetes已經成為用於抽象排程工作負載的底層基礎架構的強大API，但是沒有一個單一的實用API可以顯示服務網格中所需的功能。

“服務網介面”的公告提出SMI規範打算統一執行在Kubernetes上的服務網格所需的功能和API（儘管這有助於為在k8s之外執行的服務網路奠定基礎）。

樣做對服務網格社群有幾個直接的好處：

  • 服務網格實現可能很複雜; 專注於表現出與實現無關的關鍵功能的API可提高整體可理解性
  • 在服務網格社群的動盪世界中，關注能力並透過標準介面減少了對任何特定實現的依賴。
  • 服務網格公開了一組強大的旋鈕和槓桿，用於操縱和定義規則（程式設計網路）; 有些東西需要協調這些旋鈕和槓桿; 是否由供應商提供的擴充套件或您自己編寫的擴充套件 - 將網路程式設計到任何一個特定的實現，其假設將您與此實現聯絡起來，並可能使您的實現複雜化
  • 為較低層的穩定性（如服務網格）奠定基礎工作，為整個生態系統獲勝的進一步創新開啟了大門

最低公分母
社群中有些人對這種方法的可行性表示懷疑，而恕我直言，他們的聲音非常重要。例如，我非常尊重的Tim Hockin提到了SMI方法成為“最低共同點”的可能性，並且可以取悅任何人

服務網格的新功能仍然可以肯定出現（如不同服務網格實現的時間點上的不同功能集所示），但Istio，LinkerD，Consul，App Mesh等的功能似乎正在圍繞以下方面展開：

  • 流量請求路由（加權路由，L7請求級別匹配等），可以啟用金絲雀釋放等功能。這樣做的目的是減少爆炸半徑的變化影響。
    • 請參閱Istio，App Mesh; Linkerd和Hashicorp Consul的流量路由
  • 頂級度量標準集合，如延遲百分位數，吞吐量，錯誤率
    • 見Istio，App Mesh，Linkerd; Consul將在不久的將來輕鬆配置它
  • 政策執行基於服務標識
    • 請參閱Istio，Consul，Linkerd和App Mesh，以便在不久的將來新增它


語義並沒有那麼不同
目前，Istio已經為這些功能提供了成熟和開發的實現，但是還有其他一些實現也實現了這些功能並且正在發展壯大。實際上，這些實現的方向彼此非常相似，在易用性，使用者體驗，管理，整合等方面存在重要差異。但重點是“服務網格提供的功能”的語義。沒有那麼不同。恕我直言，圍繞這些不那麼不同的能力的API可能在社群的幫助下，包括Istio, linkerd, consul, App Mesh ！

Envoy Proxy變得普及
關於控制平面本身，其他服務網格提供商也希望在Envoy之上構建，我們將看到它們在實現中也沒有那麼多分歧。

基於現有實現
最後，SMI部分來自現有的服務網格實現。這不是一個夢想的，由財團驅動的，在由沒有實施，操作甚至使用服務網格的人們帶領的天空中的餡餅。相反，社群目前由具有現實生活，部署在生產中的服務網格實現的供應商和組織提供。從這些經驗中獲得實用API的能力並非遙不可及。

SMI由供應商領導
我所尊重的社群中另一個突出的聲音是Zack Butcher，他表達了他的觀點，即SMI沒有透過設計壞氣味的測試，因為它是由想要賣東西的供應廠商領導的。

SMI Spec的創始人之一Brendan Burns 有一個有趣的看法：

“服務網格中的當前技術水平，你必須將自己鎖定到一個實現是不好的。此外，沒有人可以為所有服務網格構建共享工具，這更糟糕。並且沒有人能夠構建包含服務網格apis 而不會選擇實現的的Helm charts。“

在我工作的Solo.io，我們有興趣看到服務網格的單一介面出現，因為我們經常會遇到需要解決的客戶：

  • 不確定選擇哪個網格
  • 想要建立在網格之上，但希望在動盪的環境中對沖他們的賭注
  • 想要更友好的使用者體驗來管理他們的服務網格
  • 需要將他們的南北流量與他們的東西方向的網格決策相結合
  • 希望供應商幫助他們，但......
  • 不確定任何一個網格供應商的動機

此外，企業發現供應商之間相互競爭以滿足他們的最終需求具有很大的價值（並且在此找到了很多價值！）我們在過去看過這種在Java和Java EE等社群中的表現。

贏家通吃？
在我看來，現實是我們最終將採用多種服務網格實現（無論是否設計），我們需要以某種方式統一它們（在其功能級別，整合級別）與他們，或管理他們或所有上述的水平）。

例如，我們與客戶和潛在客戶一起看到的真實用例是當前對Istio進行內部部署的投資，但其他團隊將進入AWS並全力以赴，包括使用AWS App Mesh。他們有一個真實的情況，他們需要在這些網格之上構建工具，他們正在構建自己的抽象。如果存在社群主導的抽象，他們會使用並看到這樣做的很多價值（至少不必自己做！）。

推動服務網路社群向前發展
目前，社群中的健康辯論是必要的，以表達我們可以探索和克服的關注點和異議以及機會，以便為終端使用者和平臺構建者提供服務網路的強大功能。服務網格代表了一組強大的應用程式網路功能，但實際上這不是最終遊戲。

就像像Kubernetes這樣的容器和編排系統已經使“容器變得無聊”，服務網格也會使應用程式網路變得無聊。為使用者，社群以及參與此社群的組成供應商創造價值的有趣機會將在堆疊中更高，包括在服務網格之上。

如果服務網格生態系統最終成為贏家 ，那就太棒了！我們將有一個API來構建我們的系統。如果沒有，並且我認為這會是更高機率的命題，那麼我們最好共同努力找出正確的API來展示這些可以透過服務網格提供的重要功能，而不管實現如何。
 

相關文章