InfoQ公众号推送 - Eureka 2.0开源停止？看看阿里自研服务注册中心产品ConfigServer

原文地址：https://mp.weixin.qq.com/s/28q55ua9jgMz4zwzVySdew

我的 Eureka 2.0 实践，参见：

• Spring Cloud 学习笔记 - No.1 服务注册发现 Eureka
• Spring Cloud 学习笔记 - No.2 服务消费 Ribbon & Feign

Eureka1.0 架构存在的问题

• 订阅端（Consumer）拿到的是服务的全量的地址：这个对于客户端的内存是一个比较大的消耗，特别在多数据中心部署的情况下，某个数据中心的订阅端往往只需要同数据中心的服务提供端即可。
• pull 模式：客户端采用周期性向服务端主动 pull 服务数据的模式（也就是客户端轮训的方式），这个方式存在实时性不足以及无谓的拉取性能消耗的问题。
• 一致性协议：Eureka 集群的多副本的一致性协议采用类似“异步多写”的 AP 协议，每一个 server 都会把本地接收到的写请求（register/heartbeat/unregister/update）发送给组成集群的其他所有的机器（Eureka 称之为 peer），特别是 hearbeat 报文是周期性持续不断的在 client->server->all peers 之间传送；这样的一致性算法，导致了如下问题：
  • 每一台 Server 都需要存储全量的服务数据，Server 的内存明显会成为瓶颈。
  • 当订阅者（Consumer）却来越多的时候，需要扩容 Eureka 集群来提高读的能力，但是扩容的同时会导致每台 server 需要承担更多的写请求，扩容的效果不明显。
  • 组成 Eureka 集群的所有 server 都需要采用相同的物理配置，并且只能通过不断的提高配置来容纳更多的服务数据。

Eureka2.0 主要就是为了解决上述问题而提出的，主要包含了如下的改进和增强：

• 数据推送从 pull 走向 push 模式，并且实现更小粒度的服务地址按需订阅的功能。
• 读写分离：写集群相对稳定，无需经常扩容；读集群可以按需扩容以提高数据推送能力。
• 新增审计日志的功能和功能更丰富的 Dashboard。

阿里巴巴服务注册中心 ConfigServer 技术发现路线

2008 年，无 ConfigServer 的时代：
借助用硬件负载设备 F5 提供的 vip 功能，服务提供方只提供 vip 和域名信息，调用方通过域名方式调用，所有请求和流量都走 F5 设备。
遇到的问题：

• 负载不均衡：对于长连接场景，F5 不能提供较好的负载均衡能力。如服务提供方发布的场景，最后一批发布的机器，基本上不能被分配到流量。需要在发布完成后，PE 手工去断开所有连接，重新触发连接级别的负载均衡。
• 流量瓶颈：所有的请求都走 F5 设备，共享资源，流量很容易会打满网卡，会造成应用之间的相互影响。
• 单点故障：F5 设备故障之后，所有远程调用会被终止，导致大面积瘫痪。

2008 年，ConfigServer 单机版 V1.0：
单机版定义和实现了服务发现的关键的模型设计（包括服务发布，服务订阅，健康检查，数据变更主动推送，这个模型至今仍然适用），应用通过内嵌 SDK 的方式接入实现服务的发布和订阅；这个版本很重要的一个设计决策就是服务数据变更到底是 pull 还是 push 的模式，我们从最初就确定必须采用 push 的模式来保证数据变更时的推送实时性（Eureka1.x 的架构采用的是 pull 的模式）

2009 年初，ConfigServer 单机版 V1.5：
单机版的 ConfigServer 所面临的问题就是当 ConfigServer 在发布 / 升级的时候，如果应用刚好也在发布，这个时候会导致订阅客户端拿不到服务地址的数据，影响服务的调用；所以当时我们在 SDK 中加入了本地的磁盘缓存的功能，应用在拿到服务端推送的数据的时候，会先写入本地磁盘，然后再更新内存数据；当应用重启的时候，优先从本地磁盘获取服务数据；通过这样的方式解耦了 ConfigServer 和应用发布的互相依赖；这个方式沿用至今。

2009 年 7 月，ConfigServer 集群版本 V2.0：
当时我们选择了单机存储全量服务数据全量的方案。为了简化数据同步的逻辑，服务端使用客户端模式同步：服务端收到客户端请求后，通过客户端的方式将此请求转发给集群中的其他的 ConfigServer，做到同步的效果，每一台 ConfigServer 都有全量的服务数据。

2010 年底，ConfigServer 集群版 V2.5：
我们对数据同步的方案进行了升级，去除了基于客户端的同步模式，采用了批量的基于长连接级别的数据同步 + 周期性的 renew 的方案来保证数据的一致性。

2012 年底，ConfigServer 集群版 V3.0：
在 2011 年双十一之前我们完成了 V3 架构的落地，类似 Eureka2.0 所设计的读写分离的方案，我们把 ConfigServer 集群拆分成 session 和 data 两个集群，客户端分片的把服务数据注册到 session 集群中，session 集群会把数据异步的写到 data 集群，data 集群完成服务数据的聚合后，把压缩好的服务数据推送到 session 层缓存下来，客户端可以直接从 session 层订阅到所需要的服务数据；这个分层架构中，session 是分片存储部分的服务数据的（我们设计了 failover 方案），data 存储的是全量服务数据（天生具备 failover 能力）；

data 集群相对比较稳定，不需要经常扩容；session 集群可以根据数据推送的需求很方便的扩容（这个思路和 Eureka2.0 所描述的思路是一致的）；session 的扩容不会给 data 集群带来压力的增加。session 集群我们采用低配的虚拟机即可满足需求，data 由于存储是全量的数据我们仍然采用了相对高配的物理机（但是同 V2.5 相比，对物理机的性能要求已经大幅下降）。

2014 年，ConfigServer 集群版 V3.5
2017 年，ConfigServer 集群版 V4.0

Nacos

Nacos 是阿里巴巴的新开源项目，其核心定位是 “一个更易于帮助构建云原生应用的动态服务发现、配置和服务管理平台”。

将通过Nacos项目将阿里巴巴在建设共享服务体系中使用的服务发现、配置及服务管理平台贡献给开源社区，通过打造Dubbo + Nacos的经典组合进一步释放Dubbo在云原生及Service Mesh时代中，在大规模微服务治理、流量治理、服务集成与服务共享等服务平台能力建设上的威力，同时Nacos会非常关注对主流开源社区，如Spring Cloud和Kubernetes云原生体系的无缝对接与支持。

Nacos 的架构图