SerCe的部落格：您不需要任何服務網格

banq發表於2020-11-20

服務網格最近吸引了大量的眼球。每次技術會議期間至少是有幾次關於服務網格的討論，可以輕鬆地說服人們必須在其基礎架構中擁有服務網格。但是，炒作並不能很好地表明新的閃亮技術是否適合您的問題。因此，在下面，我將嘗試對服務網格進行反炒作，以期在您決定是否需要它時減少混亂。
 

歷史
讓我們回顧歷史，看看有關在Lyft上介紹Envoy的早期文章之一。
事實證明，幾乎每個具有中等規模的面向服務架構的公司都存在與Lyft在開發和部署Envoy之前所遇到的相同問題：

  • 一種由多種語言組成的體系結構，每種語言都包含一個RPC庫，包括速率限制，斷路，超時，重試等的部分（或零）實現。
  • 統計資訊，日誌記錄和…的不同或部分實現。

儘管Envoy本身並不是服務網格，但概述的問題描述了發明服務網格的確切原因。透過強制通訊經過服務網格代理（即資料平面），它們為服務新增了“速率限制，斷路……”以及其他可靠性，可觀察性和安全性功能。此外，它們需要一個單獨的元件（控制平面）來控制配置。
但是，在這一點上，很多人都錯過了引入服務網格的環境。服務網格能夠解決問題不是因為不可能以任何其他方式解決它們。
許多具有競爭力的RPC庫具有服務網格中的資料平面層的功能，例如Finagle，gRPC，Armeria，Servicetalk等等。畢竟，第一個服務網格Linkerd 1.0由Finagle支援。RPC庫還需要一個元件來提供服務發現和配置管理，以使其成為真正的網格。例如Zookeeper或Consul等這樣的一個元件，在服務網格中這樣的元件稱為控制平面。
為什麼要引入一個新概念來解決以前已經解決的問題？引入服務網格概念並不是為了解決以前從未解決過的問題，而是以不需要對應用程式程式碼進行任何修改的方式解決這些問題，如果我們難以引入一個RPC層時，服務網格非常方便構建現有的異構微服務環境。
當您聽到服務網格時，可能您想到的第一印象是Istio和Envoy，但它們並不是第一個進入市場的服務網格。率先進入此空間的Linkerd作者在“為什麼需要服務網格”中準確地描述了這種情況。有趣的是，在Internet上許多宣傳文章中，這種情況經常被忘記或省略。
如果一種技術方案能很好地解決問題，即使解決了很多人都遇到的問題，也無法為技術帶來很多炒作。背後總是有一個贊助商。我不知道贊助人是誰，我將推測，但是在開源是基本要求的世界裡，很難出售RPC庫。那裡沒有明確的業務模型，這就是為什麼大多數成熟的RPC庫都是由大型科技公司開源的，而它並不是核心業務模型的一部分。庫只是程式碼，而不是基礎架構的一部分。服務網格是另一回事。這是一個孤立的，非常重要的基礎架構。作為供應商，您不僅可以提供有關配置和部署的諮詢，還可以出售圍繞它的完整託管解決方案。
 

何時使用？
現在，我們已經確定了問題，解決方案，最重要的是，提出解決方案的背景已經確定，讓我們看一下替代方案。秉承KISS的精神，最明顯的方法是使用RPC庫作為您的首選語言。這是上下文至關重要的地方：如果您有大量的服務，每個服務都以自己的語言/生態系統編寫，並且它們共享的唯一語言是HTTP，那麼擁有一個共享的RPC庫將變得很困難。 也許，您已經擁有部署和執行服務的結構，但是每個人都害怕接觸它們，沒人知道它們是如何工作的，並且每次重新部署都是一次冒險。服務網格可以為您提供幫助，因為至少您將能夠定期向網格推出新的基礎架構功能。
另一方面，如果您在單個應用程式堆疊中編寫了一系列健康的服務，那麼在引入服務網格之前最好三思而後行。透過簡單地引入或發展共享的RPC庫，您將獲得完全相同的好處，並且避免了維護服務網格的弊端。透過徹底研究服務網格限制，您可以避免陷入幻想破滅的低谷。
 

不同生態系統
您選擇的服務網格的生態系統可能與您服務的生態系統不同。漂亮的網站總是讓您相信該解決方案是即插即用的，始終有效，而且永遠不會失敗。實際上，早晚出現的問題，錯誤，行為怪異都會像往常一樣顯示出來。到那時，您將需要讓工程師在服務網格的生態系統中工作，當它與主應用程式不同時，該生態系統將有效地限制可以引入更改或解決問題的人員。這很可能會重新引入孤島，這與整個DevOps精神背道而馳。正在做DevOps-y事情的DevOps工程師團隊反對DevOps。
 

不必要的開銷
不僅在每個服務之前都有一個代理會增加開銷並消耗資源，而且您還需要時間（或者一組人） ）進行管理。是的，它可以幫助簡化某些任務-是的，現在您可以將帶有幾行YAML的Canary部署新增到簡單的應用程式中。但是，您仍然需要管理代理本身的金絲雀部署，這些代理之前沒有代理。問題剛被推高了。
 

將您的架構限制為代理支援的內容
在閱讀本段時，HTTP / 3正在緩慢地推廣到Internet。它使用UDP作為傳輸。為什麼使用UDP而不是建立您要求的全新協議？這是因為，除了TCP和UDP之外，其他任何東西都是被容易被遮蔽，網際網路上的各種代理（路由器，閘道器等）“遮蔽”。這種現象被稱為ossification。因此，僅保留TCP或UDP是實際選擇，甚至UDP也被各種公司代理部分阻止，這減慢了採用速度。
即使您的微服務環境相比Internet而言可能要小得多，您也可以與服務網格進行比較。代理可以透過限制服務之間的通訊方式來ossify您的應用程式體系結構。
 

選擇
這對您作為工程師意味著什麼？是否需要採用服務網格方法的答案歸結為您要改善的微服務環境的狀態。與RPC框架相比，服務網格使您能夠：

  1. 與部署服務相比，部署基礎架構更改的頻率更高。
  2. 在不更改服務程式碼的情況下介紹基礎設施更改。


要點1.非常重要，無論出於何種原因您都不能經常重新部署服務，例如，可能沒人記得它是如何完成的，或者可能還有其他限制。當您的堆疊是異構的時，第2點非常重要。例如，某些服務是用Go構建的，某些是用Java構建的，有些是在Haskell中構建的，等等。定期部署的同類均勻服務定義了服務網格是否是最適合您的解決方案。
 

結論
圍繞服務網格有很多炒作，我認為太多了。但是，在致力於一項技術之前，瞭解其解決的問題以及制定解決方案的環境至關重要。服務網格並不是最終的“良好實踐”，而僅僅是解決一系列問題的一種模式，這是一個沉重的負擔。
服務網格是解決許多問題的令人驚奇的技術。並非在每種情況下，它都是最佳解決方案。

 

相關文章