Spring Cloud中国社区博客

Eureka2.0的开发动机和改进点

一.为什么开发Eureka 2.0?(Why Eureka 2.0?)

目前的Eureka是一个非常稳定的系统,在具有数万个节点的大型云环境下的部署中进行了测试。但是,它有以下主要限制:
只支持单一的客户端获取注册信息视图:Eureka服务器只支持客户端获取全量的注册信息,不支持获取特定的应用程序或 VIP地址的注册信息。这就对在Eureka注册的所有客户机造成了内存限制,即使它们只需要Eureka注册信息的一小部分。
仅支持按计划更新:Eureka客户端基于轮询机制从服务器中获取更新。即使服务器没有变更也需要客户端不停的轮询,从而在客户端会有一定的开销,同时按照一定时间间隔的轮询会导致变更之后反馈给客户端有延时。
复制算法限制了可扩展性:Eureka基于广播复制模型,即所有服务器将数据和心跳复制到所有对等体。对于Eureka包含的数据集来说,这是简单有效的,但是复制是通过变更服务器通过Http请求通知到所有对等节点来实现的。因为每个节点都必须承受eureka上的整个写入负载,限制了可扩展性。
虽然Eureka 2.0提供了更加丰富的功能集合,但上述限制是本版本中改进的主要驱动因素。

二.Eureka2.0的改进点(Eureka 2.0 Improvements)

基于上述动机,Eureka 2.0实现了以下改进:
注册数据的按需订阅模式:Eureka的一个客户端可以选择它关注的注册信息(Eureka服务器全部注册信息的一部分),而Eureka服务器仅发送其关注的注册信息。例如:一个客户端可以说我只关注应用程序“WebFarm”,然后服务器将只发送WebFarm实例相关的信息。Eureka服务器提供多种注册信息选择的标准,同时提供动态更新客户端注册信息的方法;
从服务端所有变更都推送改进为只推送客户端关注内容:不同于当前的客户端拉模式,Eureka服务器只推送客户端关注的变更信息;
优化复制:与Eureka1.0一样,Eureka 2.0依然遵循广播复制模型,即每个节点将数据复制到所有其他节点。然而,复制算法更加优化,去掉了在注册中心每个实例发送心跳的需求,大大减少了复制流量,实现了更高的可伸缩性;
自动扩展的Eureka服务器:Eureka2.0将读取(数据发现)和写入(注册)关注点划分为独立的集群。由于写入负载是可预测的(与区域中的实例数成比例),所以写入集群是提前计算好扩展能力进行部署。另一方面,读取负载是不可预测的(与客户端的订阅成比例),因此读取集群是自动扩展的;
审计日志:Eureka2.0为注册信息所做的任何更改提供了详细的审计日志。这有助于Eureka的所有者和用户洞察了解Eureka中各个应用程序实例的状态。审计日志默认是保存在日志文件中,同时支持基于插件的方式适配不同的存储类型;
仪表盘:Eureka2.0提供了一个丰富的仪表板(相对于Eureka 1.0的非常基本的仪表盘),可以查看注册信息视图、服务器运行状况、订阅状态和审核日志等信息

《Eureka 2.0 Motivations》的英文版本:https://github.com/Netflix/eureka/wiki/Eureka-2.0-Motivations