服务网格热潮：选择Aspen Mesh还是NGINX

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

随着更广泛的容器生态系统不断发展，服务网格也在持续走向成熟。不过，这项技术仍处于早期阶段，目前业界正采用多种方法，借助服务网格解决容器内部的流量管理问题。

今年春季正式收购NGINX之前，我们（这里指公司）收到了许多问题。其中有几个问题聚焦于技术和解决方案的“重叠”领域。毕竟，NGINX和F5都提供基于代理的应用交付解决方案，也都在构建服务网格。问题是，哪一个会胜出？

因为收购往往就是这样。

正如我和NGINX的同事多次强调的那样，我们认为，那些被指存在重叠的技术，与其说是相互竞争，不如说是优势互补。我们的服务网格解决方案也是如此。

我们的逻辑源于对应用交付的共同愿景。我们都看到了容器和云、微服务以及大量安全漏洞对应用交付架构和模式的影响。正如不再存在“通过一条数据路径交付所有应用”，也不再存在“通过一种应用交付模式交付所有应用服务”。云引入了多条数据路径，容器则引入了一条新的数据路径。两者都拓宽了应用服务的部署位置选择，使其不再局限于基于网络的代理（即ADC），而是可以部署在从客户端、网络、服务器、容器到云的众多位置。

正如我们在“聚焦架构的文章”中所述，该文章属于“弥合鸿沟”系列，应用服务的交付位置和方式取决于多种因素。这不仅是在不同供应商的实现方案之间，或在“企业级方案与FOSS”之间做选择，还必须考虑部署位置（云端或本地）、运营模式，甚至需要权衡实施便捷性与所需功能。鉴于交付路径覆盖范围广泛，可在多个位置插入应用服务。

因此，我们认为F5与NGINX的组合产品线相辅相成，而非相互竞争。因为整个应用交付市场的竞争焦点已不再是单一位置的部署，而是多个位置的部署。

服务网格旨在帮助容器环境实现扩展、增强安全性并提供可观测性。作为一项新兴且快速发展的技术，服务网格已出现多种模式。其中一种基于边车代理（Envoy已成为具有广泛影响力的CNCF项目和业界标准的边车代理）；另一种则采用每应用代理，例如NGINX Plus。

我们目前计划同时支持这两种模式，因为客户在容器基础设施的选择上往往有明确偏好。有些客户倾向于使用Istio和Envoy，另一些客户则全面采用NGINX作为标准。

容器环境中需要运维和管理的组件数量众多，因此，现有技术专长是选择服务网格时的重要考量因素。已在基础设施中将NGINX作为标准的组织，自然更可能倾向于采用NGINX服务网格解决方案，因为该方案完全由NGINX软件组成，涵盖NGINX代理、NGINX Unit和NGINX Controller。现有的NGINX及其开源生态系统运维经验有助于减少部署阻力和延迟。

其他组织对Istio和Envoy等替代开源解决方案也持相同看法。Aspen Mesh使用Envoy并基于Istio实现，因此更适合已在底层技术上进行投入的组织。它是经过测试、强化、打包和审核的Istio发行版。Aspen Mesh在Istio基础上增加了多项功能，包括通过Aspen Mesh仪表板提供更简单的用户体验、支持用户指定、衡量和落实业务目标的策略框架，以及Istio Vet和Traffic Claim Enforcer等工具。与NGINX一样，Aspen Mesh也能与F5 BIG-IP良好集成。

NGINX和Aspen Mesh均提供Kubernetes集群管理和可视化功能。Aspen Mesh和NGINX的解决方案均支持本地部署。两者都提供跟踪和指标功能，这些功能对于解决可见性问题至关重要。Replex发布的《Kubernetes现状报告》指出，37%的组织将可见性列为生产环境中的主要挑战。

偏好采用基于边车代理的服务网格方案的组织会更倾向于选择Aspen Mesh。认为基于每个应用代理的服务网格更符合自身需求的组织会更倾向于选择NGINX。

具体选择取决于多种因素。我们认为，这一新兴领域非常重要，因此将继续支持能够满足不同需求和要求组合的多种选择。

关于作者

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章