对比Eureka和Nacos 的区别 Zuul和Spring Gateway的区别

Eureka与Nacos的区别

1.功能差异

2.部署安装

3.稳定及扩展

4.总结

Spring gateway与zuul的区别

1. 产品对比

2 性能对比

3总结

Eureka与Nacos的区别

1.功能差异

模块	Nacos	Eureka	说明
注册中心	是	是	服务治理基本功能，负责服务中心注册
配置中心	是	否	Eureka 需要配合Config实现配置中心，且不提供管理界面
动态刷新	是	否	Eureka需要配合MQ实现配置动态刷新，Nacos采用Netty保持Tcp长链接试试推送
可用区AZ	是	是	对服务集群划分不同区域，实际区域隔离，提供容灾自动切换
分组	是	否	Nacos可以根据月舞和环境进行分组管理
元数据	是	是	提供服务标签数据，例如环境或服务标识
权重	是	否	Nacos默认提供权重设置功能，调整承载流量压力
健康检查	是	是	Nacos支持有客户端或服务段发起的健康检查，EureKa是由客户端发起心跳
负载均衡	是	是	均提供负载均衡策略，Eureka采用Ribbon进行负载均衡
管理界面	是	否	Nacos支持对服务在线管理，Eureka只提供预览服务状态的界面

2.部署安装

模块	Nacos	Eureka	说明
Mysql	是	否	Nacos需要采用Mysql镜像数据持久化
MQ	否	是	Eureka需要采用MQ进行配置中心刷新
配置中心	是	否	Eureka解决Config实现配置中心
配置文件			Nacos支持在线编辑，Eureka本地文件或者git远程文件
集群	是	是	Nacos需要配置集群ip再启动

3.稳定及扩展

模块	Nacos	Eureka	说明
版本	1.0.0	1.9.9	Eureka2.0已停止开发,Nacos处于1.x-2.0开发
厂商	阿里巴巴	Netflix	Netflix已长期用于生产,阿里刚起步
生产建议	否	是	Nacos0.8以前不可用于生产,建议生产采用Nacos1.0,便于节省配置中心集群和服务管理
生产建议	否	是	Nacos0.8以前不可用于生产,建议生产采用Nacos1.0,便于节省配置中心集群和服务管理

4.总结

采用Eureka方案的考虑

想用Spring Cloud原生全家桶
想用本地文件和Git作为配置管理的,将配置与服务分开管理
考虑短期的稳定性

采用Nacos方案的考虑

想在线对服务进行上下线和流量管理
不想采用MQ实现配置中心动态刷新
不想新增配置中心生产集群
考虑引入Spring Cloud Alibaba生态

Spring gateway与zuul的区别

1. 产品对比

下边以表格形式对Zuul1和Gateway作简单对比：

对比项	Zuul1.x	Gateway
实现	基于Servlet2.x构建，使用阻塞的API。	基于Spring 5、Project Reactor、Spring Boot 2，使用非阻塞式的API。
长连接	不支持	支持
不适用场景	后端服务响应慢或者高并发场景下，因为线程数量是固定（有限）的，线程容易被耗尽，导致新请求被拒绝。	中小流量的项目，使用Zuul1.x更合适。
限流	无	内置限流过滤器
上手难度	同步编程，上手简单	门槛较高，上手难度中等
Spring Cloud集成	是	是
Sentinel集成	是	是
技术栈沉淀	Zuul1开源近七年，经受考验，稳定成熟。	未见实际落地案例
Github used by	1007 repositories	102 repositories
Github issues	88 Open / 2736 Closed	135 Open / 850 Closed

注：Github used by和Github issues统计时间截止2019/8/26。

2 性能对比

2.1.1 低并发场景

不同的tps，同样的请求时间（50s），对两种网关产品进行压力测试，结果如下：

tps	测试样本Zuul1/Gateway，单位个	平均响应时间Zuul1/Gateway, 单位毫秒	99%响应时间小于Zuul1/Gateway，单位毫秒	错误比例Zuul1/Gateway
20tps	20977 / 20580	11 / 14	16 / 40	0% / 0%
50tps	42685 / 50586	18 / 12	66 / 22	0% / 0%

并发较低的场景下，两种网关的表现差不多

2.1.2 高并发场景

配置同样的线程数（2000），同样的请求时间（5分钟），后端服务在不同的响应时间（休眠时间），对两种网关产品进行压力测试，结果如下：

休眠时间	测试样本Zuul1/Gateway，单位个	平均响应时间Zuul1/Gateway, 单位毫秒	99%响应时间小于Zuul1/Gateway，单位毫秒	错误次数Zuul1/Gateway，单位个	错误比例Zuul1/Gateway
休眠100ms	294134 / 1059321	2026 / 546	6136 / 1774	104 / 0	0.04% / 0%
休眠300ms	101194 / 399909	5595 / 1489	15056 / 1690	1114 / 0	1.10% / 0%
休眠600ms	51732 / 201262	11768 / 2975	27217 / 3203	2476 / 0	4.79% / 0%
休眠1000ms	31896 / 120956	19359 / 4914	46259 / 5115	3598 / 0	11.28% / 0%

Zuul网关的tomcat最大线程数为400，hystrix超时时间为100000。

Gateway在高并发和后端服务响应慢的场景下比Zuul1的表现要好。

2.1.3 官方性能对比

Spring Cloud Gateway的开发者提供了benchmark项目用来对比Gateway和Zuul1的性能，官方提供的性能对比结果如下：

网关	Avg Req/sec/Thread	Avg Latency
Spring Cloud Gateway	3.24k	6.61ms
Zuul1	2.09k	12.56ms
none	11.77k	2.09ms

测试工具为wrk，测试时间30秒，线程数为10，连接数为200。

从官方的对比结果来看，Gateway的RPS是Zuul1的1.55倍，平均延迟是Zuul1的一半。

3总结

Zuul1的开源时间很早，Netflix、Riot、携程、拍拍贷等公司都已经在生产环境中使用，自身经受了实践考验，是生产级的API网关产品。

Gateway在2019年离开Spring Cloud孵化器，应用于生产的案例少，稳定性有待考证。

从性能方面比较，两种产品在流量小的场景下性能表现差不多；并发高的场景下Gateway性能要好很多。从开发方面比较，Zuul1编程模型简单，易于扩展；Gateway编程模型稍难，代码阅读难度要比Zuul高不少，扩展也稍复杂一些。