在企業組織中採用服務網格的挑戰：從API閘道器到微服務通訊逐步引入 – Christian Posta

banq發表於2019-10-20
API微服務

最近，我為DZone及其遷移到微服務報告撰寫了一篇文章，介紹了在企業組織中採用服務網格的挑戰。在那篇文章中，我們要解決的第一件事是“無論您是否應該採用服務網格”，這就是我所說的：

首先回答“否”。如果您剛剛開始使用微服務和少量服務，請確保首先準備好基礎部分。微服務及其關聯的基礎架構是一項最佳化，使您可以更快地對應用程式進行更改。在沒有服務網格的情況下，您可以邁出一大步。您甚至可能想要服務網格帶來的一些好處，而沒有所有的複雜性。看看類似Gloo的東西，它是基於Envoy代理構建的API閘道器。

我認為這是目前非常重要的考慮因素，原因有兩個：

  1. 通常，服務網格實現尚未準備好投入生產
  2. 在服務網格上全押的複雜性仍然很高

這並不意味著會有團隊成功使用服務網格，或者您應該遠離它。我確實認為您應該做好準備，以便在準備就緒並從中受益時最終引入網格。例如，在報告中，我列出了您可能要使用服務網格的以下原因：
  • 跨多個叢集大規模部署微服務
  • 容器/ k8和VM的混合部署
  • 用於構建服務的語言的異構部署
  • 網路可觀察性的觀點不完整且不一致

即使這樣，您仍將面臨以下挑戰：
  • 選擇哪一個？
  • 誰來支援它？
  • 單個叢集中的多租戶問題
  • 沒有管理多個群集的好方法
  • 適應現有服務（邊車生命週期，比賽條件等）
  • 開發人員和運維實施之間的區別是什麼
  • 非容器環境/混合環境
  • 集中與分散

透過過去兩年多來我在Red Hat和Solo.io的工作，我一直在幫助人們解決這些難題（順便說一句，如果您想在這些方面進行聊天/需要幫助，請聯絡@christianposta），但是我一直在我們的客戶/使用者中觀察到並且建議過一段時間的一件事是，您對服務網格的採用應該始終以某種程度的隔離（即，獨立地）採用資料平面技術開始。瞭解其工作原理，如何操作，除錯等。
例如，在我最近的一次演講中，我說過從Envoy開始（Envoy是許多服務網格實現的基礎資料平面技術）。
當然，如果要使用Envoy，我建議從Gloo開始，後者基本上是Enterprise Envoy發行版，具有邊緣和API閘道器功能，可以很好地插入服務網格中。一旦有了適當的位置，對它感到滿意，就可以準備使用它，甚至可以透過代理分層來引入一些隔離。
下一個連續的方法是將閘道器向下推送到您的應用程式體系結構中。我們看到我們的使用者也採用了針對每個應用程式邊界的閘道器方法，這種方法開始給人以“網格的感覺”，但給應用程式帶來了一些結構（例如，API閘道器模式）。我已經開始將其稱為“路標”架構。就像飛行員使用航路點來指導其飛行計劃一樣，這些閘道器為您的體系結構增加了結構，同時解決了南北向交通問題，例如安全性和API解耦問題，同時為成功採用服務網格奠定了基礎。
最後，您可以開始在不受邊界限制的應用程式中引入服務網格代理，以解決服務網格最適合的棘手的服務到服務通訊挑戰。

這裡的重要部分是閘道器仍然起著非常有用的作用！它們在為您的體系結構新增結構和航點的同時，在需要時將其餘的實現細節與其他服務分離和隱藏。在許多方面，這都遵循DDD有界上下文模型，其中閘道器提供了“反腐敗”層。否則，如果您將所有服務都視為對等方，那麼您將開始向死亡之星堅定前進。

希望引入服務網格可以從小處開始，緩慢地擴充套件有意義的地方，從而為成功實現服務網格奠定基礎，並在您能夠消費並從中獲得價值的同時，將網格的全部功能帶給您的應用程式。否則，您可能會冒險一次引入太多的複雜性，而這將超出您實現應用程式和基礎架構現代化的意圖。


 

相關文章