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
来源：oschina
链接：https://my.oschina.net/u/4302850/blog/4888778