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 的架构图

你可能感兴趣的:(InfoQ公众号推送 - Eureka 2.0开源停止?看看阿里自研服务注册中心产品ConfigServer)