近年來，隨著企業不斷加大對微服務和容器化應用程式的投資，Service Mesh 已從前端技術穩步轉向主流應用程式。根據雲端原生運算基金會在 2020 年開展的一項關於雲端原生技術使用情況的調查，我們得出了以下結論。
要點 1：Service Mesh 的使用人數迅速增長。
要點 2：容器使用人數的增加表明，越來越多的企業需要進階流量管理和安全防護工具，並可能會從網格中受益。
要點 3：三大容器挑戰相互關聯。
您做好使用 Service Mesh 的準備了嗎？
我們認為，這已經不是「我是否必須使用 Service Mesh？」的二元問題了，而是「我何時做好使用 Service Mesh 的準備？」我們認為，對於在生產環境中部署容器並使用 Kubernetes 進行編排的任何人而言，其應用程式和基礎架構設施的成熟度水準都足以讓 Service Mesh 的價值體現出來。
但與任何技術一樣，在實際需要 Service Mesh 之前就提前部署的做法弊大於利，它帶來的風險和開銷要超出可為您的企業所帶來的潛在好處。對於想要採用 Service Mesh 的客戶， 我們根據以下 6 點來確認其準備情況並瞭解其現代化進程。您對以下陳述的肯定回答越多， Service Mesh 為您創造的價值就越大。
1：Kubernetes 是您生產環境中的唯一平台。
無論您已將生產應用程式移轉到 Kubernetes，還是剛開始測試將應用程式移轉到容器工作負載，Kubernetes 都在您的長期應用程式管理路線圖中。
2：您需要一個零信任的生產環境，並需要 Service 之間配置雙向 TLS（mTLS）。
您已為生產應用程式採用零信任模型，並需要在容器化環境中保持這種級別的安全性，或者您正在使用移轉作為強制功能來提供您的服務級別安全性。
3：無論在數量還是服務深度上，您的應用程式都很複雜。
您擁有一個大型的分散式應用程式。它有多個 API 依賴項，並很可能需要外部依賴項。
4：您擁有一個成熟的生產 CI/CD 流程。
「成熟」取決於您的企業。我們將該術語應用到以程式設計方式部署 Kubernetes 基礎架構和應用程式的過程，可能使用的工具包括 Git、Jenkins、Artifactory 或 Selenium。
5：您經常在生產環境中進行部署 —— 至少每天一次。
我們發現，對於這個問題，大多數人的回答都是「否」—— 儘管他們已將應用程式移轉到了生產 Kubernetes 中，但他們還沒有使用 Kubernetes 來支援持續的版本修訂。
6：您的 DevOps 團隊已準備好開始使用強大的工具部署超現代應用程式！
即使 Service Mesh 為 NetOps 團隊擁有，但通常由 DevOps 團隊在集群集群內進行管理，後者需要準備好將網格新增到其架構中。
對上述 6 個陳述的回答不完全都是「是」？沒有關係！請繼續閱讀，瞭解您在做好準備之後， 接下來該做的工作，包括您可以做些什麼來讓您的團隊做好使用 Service Mesh 的準備。
如何選擇適合您應用程式的 Service Mesh
在您準備好使用 Service Mesh 之後，您還需要從眾多 Service Mesh 選項中做出選擇。就像 Kubernetes 已成為事實上的容器編排標準一樣，Istio 通常被視為事實上的 Service Mesh 標準。事實上，Istio 很容易被認為是唯一的選擇，不僅因為它很受歡迎，還因為它的目標是解決 Kubernetes 網路環境中的所有問題。儘管有宣傳自家產品的嫌疑，但我們還是要在這裡告訴您，Istio 既不是唯一的選擇，也不是適用於每個人或每個用例的選擇。Istio 讓您的環境變得非常複雜，可能需要集整個工程師團隊的力量來執行，而最終帶來的問題通常比解決的問題還要多。
為了明確說明哪種 Service Mesh 最適合您的應用程式，我們建議您與您的團隊和利益相關者舉行一次戰略規劃會議。下面是一個對話指南，可協助您推動這些討論。
第 1 步：您為何想要使用 Service Mesh？
換句話說，您需要 Service Mesh 解決什麼問題？舉例來說，您的企業可能要求在 Service 之間配置 mTLS，或者您需要「端對端」加密，包括從邊緣進入（針對入向流量）和從網格內流出（針對出向流量）的流量。或者，您可能需要為您的全新 Kubernetes Service 配備企業級流量管理工具。
第 2 步：如何使用 Service Mesh？
這取決於您的角色。
・如果您是開發人員：
⎯ 您是否計畫提高正在移轉到 Kubernetes 傳統應用程式的安全性？
⎯ 在將應用程式重構為原生 Kubernetes 應用程式時，您是否打算將安全性納入其中？
・如果您負責平台和基礎架構：
⎯ 您是否打算將 Service Mesh 新增到 CI/CD 流程中，以便在每個新集群集群中自動部署 和配置，並在開發人員啟動新實例時可用？
第 3 步：影響您選擇的因素有哪些？
您的 Service Mesh 是否需要不受基礎架構的限制？是否需要與您的視覺化工具相容？是否是 Kubernetes 原生工具？是否需要易於使用？您是否預見到未來要使用與網格中的 Service 到 Service（東西向）流量管理工具相同的工具在邊緣管理出入向（南北向）流量？
第 4 步：評估 Service Mesh 選項
回答完這些問題之後，您將會獲得明確的需求（以作為您的評估選項）清單。在此過程中，還有兩個額外的領域需要評估：Service Mesh 的資料層和 Service Mesh 可能帶來的隱藏成本。
資料層 —— 資料層直接影響著客戶的效能體驗，因為回應緩慢的資料層會降低整個 Kubernetes 引擎的速度，並且會影響系統效能。根據下列問題來評估待選 Service Mesh 的資料層是否可以滿足您的需求。
・這個資料層已經上市多少年了？
・它的容量是多少？
・它是否具有你將來需要且想要的整合功能？
・它如何衡量並提供可觀察性？
・它能否從災難性故障中動態恢復？
如欲瞭解更多資訊，請閱讀《資料層並非商品》。
隱藏成本 —— 部署和營運 Service Mesh 的任何成本可能都不是顯而易見的，一旦您超出了更新換代的範圍，成本就會激增。用以下問題來準確瞭解您的 Service Mesh 選擇可能帶來的任何隱藏成本。
・執行控制層需要多少個容器鏡像？每個鏡像必須有多大？
・您的 Service Mesh 的 Ingress Controller 的容量是多少？
・您的 Sidecar 可以跟上您的服務需求嗎？
・您會執行多個集群集群或多租戶嗎？
・您的 Service Mesh 需要多少 Kubernetes CustomResourceDefinitions（CRD）？
・您是否需要專門的人員來執行 Service Mesh？如果需要，需要多少人員？
・您所選的 Service Mesh 是否將您限制在一個特定的軟體或雲端平台？
如欲瞭解更多資訊，請閱讀《Service Mesh 的隱藏成本》。
F5 NGINX Service Mesh
NGINX Service Mesh 於 2020 年作為開發版推出，是為開發人員最佳化的免費輕量型服務網格，它提供了最簡單的方法來實現 mTLS，以及 Kubernetes 中東西向（Service 到 Service） 流量和南北向（入向和出向）流量的端對端加密。為了以一種侵入性最小但仍提供進階靈活性和關鍵洞察力的方式讓您完全控制應用程式資料層，我們建構了自己的 Service Mesh。
我們相信，如果您需要具有以下功能的網格，您一定會對 NGINX Service Mesh 一見鍾情：
關於 NGINX Service Mesh 架構
NGINX Service Mesh 有兩個主要的元件。
控制層
我們建構了一個輕量型的控制層，可與 Kubernetes API 伺服器搭配使用，動態支援和管理應用程式。它會隨著應用程式的擴展和部署而做出回應和更新，以便讓每個工作負載實例自動得到保護，並與其他應用程式元件整合 —— 實現「一次設定，自動執行」，從而讓您專注於處理業務。
資料層
NGINX Service Mesh 真正厲害之處是全面整合的高效能資料層。我們的資料層利用 F5 NGINX Plus 的強大功能來執行高可用和可擴展的容器化環境，將企業流量管理、效能和可擴展性提升到了市場最高水準。它提供了生產級 Service Mesh 部署所需的無縫且透明的負載平衡、反向代理、流量路由、身分和加密功能。當與基於 NGINX Plus 版本的 F5 NGINX Ingress Controller 搭配使用時，它還提供可透過單一配置管理的統一資料層。
NGINX Service Mesh 的優勢
您可從 NGINX Service Mesh 獲得的幾項優勢：
• 較低的複雜性
NGINX Service Mesh 易於使用且不受基礎架構的限制。它實現了 Service Mesh Interface（SMI）規範，該規範定義了 Kubernetes Service Mesh 的標準介面，並提供了 SMI 擴展性，在部署新應用程式時，可大幅減少人工作業和生產流量中斷。NGINX Service Mesh還與 NGINX Ingress Controller 進行了原生整合，建立了一個統一的資料層，支援您在邊緣位置集中和簡化出入向（南北向）流量管理以及 Service 到 Service（東西向）反向代理 Sidecar 流量管理的配置。與其他網格不同，NGINX Service Mesh 不需要將 Sidecar注入 NGINX Ingress Controller，因此不會增加 Kubernetes 環境的延遲率和複雜性。
• 更高的彈性
借助我們的智慧容器流量管理功能，您可以指定策略來限制流向新部署之 Service 實例的流量，並隨著時間的推移逐漸放寬限制。借助速率限制和斷路器等功能，您可以完全控制通過 Service 的流量。您可以利用各種強大的流量分配模型，包括速率整形、服務品質（QoS）、服務節流、藍綠部署、灰度發佈、斷路器模式、A/B 測試和 API 閘道功能。
• 細細緻性的流量洞察力
NGINX Service Mesh 可用於使用 Opentracing 和 Prometheus 進行指標收集和分析。NGINX Plus API 透過 NGINX Service Mesh Sidecar 和 NGINX Ingress Controller Pod產生指標。借助內建的 Grafana 儀表板，您可以查看各種指標（指標資訊可精確到毫秒、每日對比和流量峰值），從而進一步瞭解應用程式和 API 效能。
• 保護容器化應用程式
將 mTLS 加密和七層防護擴展到各個微服務，並利用存取控制來定義描述應用程式拓撲的策略 —— 讓您能夠以細細緻性的方式控制哪些 Service 被授權進行相互通訊。NGINXService Mesh 支援進階安全功能（包括配置控制和治理），以及對出入向和 Service到 Service 流量的放行清單支援。借助以 NGINX Plus 版本為基礎的 NGINX Ingress Controller，您還可以預設封鎖存取內部 Service 的南北向流量，並將 NGINX App Protect當作邊緣防火牆。
還沒準備好使用 Service Mesh？
如果您還沒準備好使用 Service Mesh，那麼您可能對 Kubernetes 不熟悉，或者正在努力克服大型生產部署所面對的障礙。現在正逢其時，您可以採用生產級 Ingress Controller 和內建安全防護來解決複雜性、安全性、視覺化和可擴展性等常見的 Kubernetes 挑戰。
立即試用
NGINX Service Mesh 完全免費，您可立即下載並在 10 分鐘內完成部署！您可查看我們的文件以獲取更多資訊。我們希望瞭解您的使用體驗，歡迎您在 GitHub 上發表您的意見。如果事實證明 Istio 最能滿足您的需求，請查看 F5 的 Aspen Mesh。它是一個建立在開放原始碼 Istio 之上的企業級 Service Mesh，擁有即時流量 GUI，是尋求交付 5G 服務之提供商的完美之選。