Istio在服務網格方面有很大的領先優勢，但只在早期採用者中如此。根據雲計算基金會（CNCF）的調查，在已經在生產中使用服務網格的用戶中，63%的用戶已經採用了Istio，這是linker的兩倍多。其他的選擇中，除了HashiCorp的Consul之外，佔比都不超過10%。
如果考慮到它通常與Envoy一起部署的事實，Istio的優勢就沒有那麼嚇人了。Envoy最近無可否認做得很好。CNCF社區中Envoy項目的生產使用率從2019年的17%上升到2020年的24%。但評估該項目的人從35%下降到21%，這可能意味着許多組織考慮並拒絕了Envoy，這可能會對未來服務網格的採用產生影響。並不是每個人都將Envoy與服務代理或入口控制聯繫起來。當篩選掉這一功能時，只有18%的用戶在生產或評估情況下使用了Envoy。
超過一半（55%）的爲Ingress使用Envoy的受訪者在生產中有服務網格。另有26%的人正在積極測試服務網格，9%的人計劃在未來12個月內開始。其中大部分都傾向於Istio，以及基於項目技術的解決方案，例如F5 Networks的Aspen Mesh和Tetrate。
另一個調查則顯示，並非所有的服務網格採用都將來自CNCF社區（那裏充斥着供應商和大公司）。NGINX在2020年6月調查了近500人，調查結果顯示，16%使用NGINX入口控制器（NIC），其中19%還使用服務網格，另有33%計劃在12個月內使用。此外，57%的調查對象已經在生產應用程序中使用了容器。
如前所述，NGINX Service Mesh（NSM）是爲那些如果一開始就用Istio會過於複雜的組織設計的。對於希望避免Kubernetes複雜性的組織來說，到目前爲止，只有6%的在使用NSM，但它很快會對爲Ingress使用NGINX的組織有更強的吸引力。
除了NGINX，Traefik Maesh還通過集成自己的入口控制器來降低複雜性。之前，人們想知道服務網格有沒有集成了控制和數據平面的解決方案。市場正在努力交付這樣的解決方案。2021年，下一代服務網格採用者是否會把Envoy或Istio排除在堆棧外？如果這樣，還有哪些技術可以與之最佳集成？像AWS App Mesh這樣的簡化產品會吸引Kubernetes以外的用戶嗎？
原文鏈接：
When Service Meshes Can Emerge from Envoy/Istio Shadows – The New Stack
