《重新定义Spring Cloud实战》——2.1.3　服务发现技术选型

2.1.3　服务发现技术选型

Jason Wilder在2014年2月的时候写了一篇博客《Open-Source Service Discovery》（http：//jasonwilder.com/blog/2014/02/04/service-discovery-in-the-cloud/），总结了当时市面上的几类服务发现组件，这里补充上consul以及一致性算法，如表2-1所示。

表2-1　服务发现组件对比

从列表看，有很多服务发现组件可以选择，针对AP及CP，本书主要选取了Eureka及Consul为代表来阐述。关于Eureka及Consul的区别，Consul的官方文档有一个很好的阐述（https：//www.consul.io/intro/vs/eureka.html），具体如下：

Eureka Server端采用的是P2P的复制模式，但是它不保证复制操作一定能成功，因此它提供的是一个最终一致性的服务实例视图；Client端在Server端的注册信息有一个带期限的租约，一旦Server端在指定期间没有收到Client端发送的心跳，则Server端会认为Client端注册的服务是不健康的，定时任务会将其从注册表中删除。Consul与Eureka不同，Consul采用Raft算法，可以提供强一致性的保证，Consul的agent相当于Netflix Ribbon + Netflix Eureka Client，而且对应用来说相对透明，同时相对于Eureka这种集中式的心跳检测机制，Consul的agent可以参与到基于gossip协议的健康检查，分散了Server端的心跳检测压力。除此之外，Consul为多数据中心提供了开箱即用的原生支持等。

那么基于什么考虑因素可以选择Eureka呢，主要有如下几点：

选择AP而不是CP，这一点在后面的章节会阐述。

如果团队是Java语言体系的，则偏好Java语言开发的，技术体系上比较统一，出问题也好排查修复，对组件的掌控力较强，方便扩展维护。

当然除此之外，更主要的是Eureka是Netflix开源套件的一部分，跟zuul，ribbon等整合的比较好。