服务网格狂热： 选择 Aspen Mesh 或 NGINX

随着容器生态系统的不断壮大，服务网格也将继续走向成熟。 不过，我们仍处于早期阶段，目前有多种方法可用于通过服务网格解决容器内流量管理问题。

我们（即我们公司）在今年春天正式收购 NGINX 之前回答了很多问题。 其中一些重点关注技术和解决方案“重叠”的领域。 毕竟，NGINX 和 F5 都提供基于代理的应用交付解决方案。 NGINX 和 F5 都在构建服务网格。 问题是，哪一个会获胜？

因为收购通常都是这样运作的。

正如我和 NGINX 的同事经常重申的那样，我们估计，这些重叠的技术更多的是互补而非竞争。 我们的服务网格解决方案也是如此。

我们的逻辑源自应用交付的共同愿景。 我们都看到了容器和云、微服务以及大量安全漏洞对应用交付架构和模型的影响。 同样，不再存在“一个数据路径来交付所有应用”，也不再存在“一个应用交付模型来交付所有应用服务”。 云引入了多种数据路径。 容器引入了新的数据路径。 两者都将应用服务的可能放置范围从基于网络的代理（ADC）扩展到从客户端到网络到服务器到容器到云的一系列位置。

正如我们在“弥合鸿沟”系列的一篇重点关注架构的文章中所指出的那样，选择在何处以及如何提供应用服务取决于许多因素。 这不仅仅是供应商实施或“企业与 FOSS”之间的选择；这是一个必须考虑位置（云或本地）、运营模式，甚至实施的简易性与所需功能的选择。 考虑到交付路径的广度，这为插入应用服务提供了多种选择。

这就是为什么我们将 F5 和 NGINX 的组合视为互补而非竞争。 因为应用交付的整体市场不再是在单一位置竞争放置，而是在多个位置竞争放置。

服务网格旨在扩展、保护并提供对容器环境的可见性。 作为一项新兴且快速发展的技术，有多种模型正在涌现。 一种是基于 sidecar 代理的使用（ Envoy已成为领先的CNCF项目和行业标准 sidecar 代理），另一种利用每个应用程序的代理，即NGINX Plus 。

我们目前计划支持两者，因为客户对于容器基础设施的选择有非常强烈的意见。 一些人喜欢Istio和 Envoy，而其他人则对 NGINX 的一切进行了标准化。

容器环境中必须操作和管理的组件数量如此之多，以至于现有的技术专业知识是选择服务网格的重要因素。 已将 NGINX 作为其基础设施标准化的组织自然倾向于采用 NGINX 服务网格解决方案，因为它包含所有 NGINX 软件，从 NGINX 代理或 NGINX 单元到 NGINX 控制器。 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。

您的选择取决于多种因素，我们认为这个新兴领域足够重要，可以继续支持满足不同需求和要求组合的选择。