作者：Christian Posta
譯者：羅廣明
原文：https://blog.christianposta.com/challenges-of-adopting-service-mesh-in-enterprise-organizations/
編者按
本文作者介紹了企業組織採用服務網格面臨的哪些挑戰，建議企業應該從數據平面開始逐步推進，從瞭解它、熟悉它、再到擴大規模使用它，並且以介紹其演講的幻燈片爲切入點介紹了架構演進的步驟。
正文
最近，我寫了一篇關於在企業組織中採用服務網格的具有哪些挑戰的文章，這篇文章是爲DZone及其遷移到微服務的報告撰寫的。在這篇文章中，我們首先要解決的問題之一是“你是否應該沿着採用服務網格的道路走下去”，我是這麼說的:
首先回答“不”。如果您剛剛開始使用微服務架構和少量的服務，請確保您首先準備好了基礎部分。微服務及其相關的基礎設施是一種優化方式，可以讓您更快的變更應用程序。在沒有服務網格的情況下，您可以朝着更快的方向前進。你甚至可能想要一些服務網格帶來的好處，而不是去關注它所有的複雜性。那麼，請看看類似Gloo的產品，一個建立在Envoy代理上的API網關。
我認爲在當前時刻，這是一個非常重要的考慮，有以下兩大原因:
- 總的來看，服務網格的實現還沒有準備好投入生產。
- 全部投入(all-in)到一個服務網絡的複雜性仍然很高。
這並不意味着沒有團隊成功地使用了服務網格，或者您應該遠離它。但是，我確實認爲您應該建立這樣的能力，當您真正準備好了並且可以從中獲益的時候，最終能成功地將服務網格引入。例如，在報告中，我列出了您可能想要使用服務網格的原因:
- 跨多個集羣部署大量微服務
- 容器/k8s和虛擬機的混合部署
- 用於構建服務的語言的異構部署
- 網絡可觀測性的不完整和不一致視圖
即使有了以上這些理由，你依然會面臨這些挑戰:
- 選擇哪一個服務網格產品？
- 誰來做技術支持？
- 單集羣的多租戶問題
- 缺乏多集羣的管理方法
- 已有服務如何適配（sidecar的生命週期、競態條件等等）
- 開發人員與運維人員的界限在哪裏
- 非容器環境/混合環境
- 中心化 vs 去中心化
通過我在Red Hat和現在Solo.io加起來兩年以上的工作，我一直在幫助人們解決那些棘手的問題(順便說一句，如果你想交談/需要這些方面的幫助，可以通過@christianposta聯繫我)。但有一件我從我們的客戶/用戶一直觀察到，並且持續一段時間提出建議，那就是你採用服務網格的第一步，應該總是先使用在一定程度上（自行）隔離的數據平面技術，要了解它是如何工作的，如何實施，如何調試等等。
例如，在我最近做的一次演講中，我說過要從Envoy（Envoy是許多服務網格實現的底層數據平面技術）開始。PPT如下:
從架構的角度來看，它可能是這樣的:
當然，如果你要使用Envoy，我建議從Gloo開始，這基本上是一個具有edge與API網關能力的企業版Envoy，並且很好地植入了服務網格。一旦你有了它，對它熟練使用，那麼你就會準備好增加它的使用，甚至可能通過代理的分層引入一些隔離:
接下來的方法是將網關推入到應用架構中。我們看到我們的用戶在每個應用程序邊界採用一個網關的方法，開始有了一個網格的“感覺”，但在應用程序引入了一些結構(例如，API網關模式)。我開始稱之爲“waypoints”架構。就像飛行員使用航路點（waypoints）來指導他們的飛行計劃一樣，這些網關爲您的應用架構增加了結構，同時解決了諸如安全性和API解耦的南北通信問題，同時爲成功採用服務網格奠定了基礎。
最後，您可以開始在應用程序中引入獨立於邊界的服務網格代理，以解決棘手的但恰恰是服務網格技術最擅長解決的service-to-service通信挑戰:
這裏重要的部分是網關，並且仍然有非常有用的用途！它們嚮應用架構中添加結構和路徑點，同時在需要的地方將某些實現細節與其他服務分離並隱藏起來。在很多方面，這都遵循了DDD有界上下文模型，網關提供了一個“反腐敗”層。否則，如果你只是把所有的服務都當作“夥伴”，你就會開始堅定地邁向死星:
希望這篇文章有助於您奠定一個成功的方法，通過小範圍使用服務網格，然後逐漸緩慢擴展有意義的各個地方，並且你的應用程序可以從服務網格架構中獲益。否則，您將承擔同時引入太多複雜性的風險，這將違背您實現應用程序和基礎設施現代化的意圖。
關於 ServiceMesher 社區
ServiceMesher 社區是由一羣擁有相同價值觀和理念的志願者們共同發起，於 2018 年 4 月正式成立。
社區關注領域有：容器、微服務、Service Mesh、Serverless，擁抱開源和雲原生，致力於推動 Service Mesh 在中國的蓬勃發展。