微服务注册中心微服务注册中心Eureka架构深入解读架构深入解读
微服务架构中最核心的部分是服务治理,服务治理最基础的组件是注册中心。随着微服务架构的发展,出现了很多微服务架构
的解决方案,其中包括我们熟知的 Dubbo 和 Spring Cloud。
关于注册中心的解决方案,dubbo 支持了 Zookeeper、Redis、Multicast 和 Simple,官方推荐 Zookeeper。Spring Cloud 支
持了 Zookeeper、Consul 和 Eureka,官方推荐 Eureka。
两者之所以推荐不同的实现方式,原因在于组件的特点以及适用场景不同。简单来说:
ZK 的设计原则是 CP,即强一致性和分区容错性。他保证数据的强一致性,但舍弃了可用性,如果出现网络问题可能会影响
ZK 的选举,导致 ZK 注册中心的不可用。
Eureka 的设计原则是 AP,即可用性和分区容错性。他保证了注册中心的可用性,但舍弃了数据一致性,各节点上的数据有
可能是不一致的(会最终一致)。
Eureka 采用纯 Java 实现,除实现了注册中心基本的服务注册和发现之外,极大的满足注册中心的可用性,即使只有一台服
务可用,也可以保证注册中心的可用性。
本文将聚焦到 Eureka 的内部实现原理,先从微服务架构的部署图介绍 Eureka 的总体架构,然后剖析服务信息的存储结构,
最后探究跟服务生命周期相关的服务注册机制、服务续约机制、服务注销机制、服务剔除机制、服务获取机制、和服务同步机
制。
Eureka 总体架构
下面是 Eureka 注册中心部署在多个机房的架构图,这正是他高可用性的优势(Zookeeper 千万别这么部署)。
从组件功能看:
黄色注册中心集群,分别部署在北京、天津、青岛机房;
红色服务提供者,分别部署北京和青岛机房;
淡绿色服务消费者,分别部署在北京和天津机房;
从机房分布看:
北京机房部署了注册中心、服务提供者和服务消费者;
天津机房部署了注册中心和服务消费者;
青岛机房部署了注册中心和服务提供者;
组件调用关系
服务提供者
启动后,向注册中心发起 register 请求,注册服务
在运行过程中,定时向注册中心发送 renew 心跳,证明“我还活着”。
停止服务提供者,向注册中心发起 cancel 请求,清空当前服务注册信息。