API 网关性能比较：Nginx vs. Zuul vs. Spring Cloud Gateway vs. Linke
|
我们今天谈的是 API 网关性能，这一点也涉及到高可用，简单介绍 Zuul 的高可用特性，高可用是非常关键的，因为外部请求到后端微服务的流量都会经过 Zuul，所以在生产环境中一般都需要部署高可用的 Zuul 来避免单点故障。一般我们有两种部署方案： 1. Zuul 客户端注册到 Eureka Server 这种情况是比较简单的情况，只需要将多个 Zuul 节点注册到 Eureka Server 上，就可以实现 Zuul 的高可用。事实上，这种情况下的高可用和其他服务做高可用的方案没有什么区别。我们来看下面这张图，当 Zuul 客户端注册到 Eureka Server 上时，只需要部署多个 Zuul 节点就可以实现高可用。Zuul 客户端会自动从 Eureka Server 查询 Zuul Server 列表，然后使用负载均衡组件(例如 Ribbon)请求 Zuul 集群。 2. Zuul 客户端不能注册到 Eureka Server 假如说我们的客户端是手机端 APP，那么不可能通过方案 1 的方式注册到 Eureka Server 上。这种情况下，，我们可以通过额外的负载均衡器来实现 Zuul 的高可用，例如 Nginx、HAProxy、F5 等。 如图所示，Zuul 客户端将请求发送到负载均衡器，负载均衡器将请求转发到其代理的其中一个 Zuul 节点，这样就可以实现 Zuul 的高可用。 Spring Cloud 虽然 Spring Cloud 带有“Cloud”，但是它并不是针对云计算的解决方案，而是在 Spring Boot 基础上构建的，用于快速构建分布式系统的通用模式的工具集。 使用 Spring Cloud 开发的应用程序非常适合在 Docker 或者 PaaS 上部署，所以又叫云原生应用。云原生可以简单理解为面向云环境的软件架构。 既然是工具集，那么它一定包含很多工具，我们来看下面这张图： 这里由于仅涉及到 API 网关的对比，因此我不逐一介绍其他工具了。 Spring Cloud 对 Zuul 进行了整合，但从 Zuul 来看，没有大变化，但是 Spring Cloud 整个框架经过了组件的集成，提供的功能远多于 Netflix Zuul，可能对比时会出现差异。 Service Mesh 之 Linkerd 我想 Turgay Celik 博士把 Linkerd 作为对比对象之一，可能是因为 Linkerd 为云原生应用提供弹性的 Service Mesh，而 Service Mesh 能够提供轻量级高性能网络代理，并且也提供微服务框架支撑。 从介绍来看，linkerd 是我们面向微服务的开源 RPC 代理，它直接立足于 Finagle(Twitter 的内部核心库，负责管理不同服务间之通信流程。事实上，Twitter 公司的每一项在线服务都立足于 Finagle 构建而成，而且其支持着每秒发生的成百上千万条 RPC 调用)构建而成，设计目标在于帮助用户简化微服务架构下的运维，它是专用于处理时间敏感的服务到服务的通信基础设施层。 和 Spring Cloud 类似，Linkerd 也提供了负载均衡、熔断机器、服务发现、动态请求路由、重试和离线、TLS、HTTP 网关集成、透明代理、gRPC、分布式跟踪、运维等诸多功能，功能是相当全了，为微服务框架的技术选型又增加了一个。由于没有接触过 Linkerd，所以暂时无法从架构层面进行分析，后续会补充这方面的内容，自己来做一次技术选型。 性能测试结果 Turgay Çelik 博士的那篇文章里使用了 Apache 的 HTTP 服务器性能评估工具 AB 作为测试工具。注意，由于他是基于亚马逊(AWS)公有云的进行的测试，可能和你实际物理机上的测试结果有出入。 实验中启动了客户端和服务端两台机器，分别安装多个待测试服务，客户端通过几种方式分别访问，尝试获取资源。测试方案如下图所示： 测试选择了三个环境，分别是：
测试过程均采用 200 个并行线程发送总共 1 万次请求，命令模板如下所示：
注意：由于 Turgay Çelik 博士的测试过程中是基于 Zuul 1 进行的测试，所以性能上较差，不能真实反映当前 Zuul 版本的性能状况。 从上面的结果来看，单核环境下，Zuul 的性能最差(950.57 次 /s)，直接访问方式性能最好(6519.68 次 /s)，采用 Nginx 反向代理方式较直接访问方式损失 26% 的性能(4888.24 次 /s)。在双核环境下，Nginx 的性能较 Zuul 性能强接近 3 倍(分别是 6187.14 次 /s 和 2099.93 次 /s)。在较强的测试环境下(8 核)，直接访问、Nginx、Zuul 差距不大，但是 Spring Cloud Zuul 可能由于内部整体消耗，导致每秒的请求数只有 873.14。 最终结论 （编辑：西安站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |