本系列代码地址:https://github.com/HashZhang/spring-cloud-scaffold/tree/master/spring-cloud-iiford
Eureka 目前 1.x 版本还在更新,但是应该不会更新新的功能了,只是对现有功能进行维护,升级并兼容所需的依赖。 Eureka 2.x 已经胎死腹中了。但是,这也不代表 Eureka 就是不能用了。如果你需要一个简便易于部署的注册中心,Eureka 还是一个很好的选择。云服务环境中,基本上所有实例地址和微服务名称都在不断变化,也并不太需要 Eureka 所缺少的持久化特性。当你的集群属于中小规模的时候(节点小于 1000 个), Eureka 依然是一个不错的选择。当你的集群很大的时候,Eureka 的同步机制可能就限制了他的表现。
Eureka 的设计比较小巧,没有复杂的同步机制(例如 Nacos 基于 Raft,Zookeeper 基于 Zab),也没有复杂的持久化机制,集群关系只是简单的将收到的客户端请求转发到集群内的其他 Eureka 实例。Eureka 本身也只有注册中心的功能,不像其他种类的注册中心那样,将注册中心和配置中心合在一起,例如 Consul 和 nacos。
这里我们忽略所有的 AWS 相关的术语以及配置还有相关逻辑处理。
Eureka 中的术语:
spring.application.name
指定的服务名称。首先,Service A 通过 Eureka Client 发送注册请求(Register)到同一可用区的 Eureka Server 1。之后通过发送心跳请求(Renew)到这个 Eureka Server 1. Eureka Server 1 收到这些请求的时候,会处理这些请求并将这些请求转发到其他的集群内的 Eureka Server 2 和 Eureka Server 3. Eureka Server 2 和 Eureka Server 3 不会再转发收到的 Eureka Server 1 转发过来的请求。然后,Service B 还有 Service C 通过 Eureka 获取到了 Service A 的位置,最后调用了 Service A。
对于本地没有查询到的微服务,Eureka Server 还会从远程 Region 的 Eureka Server 去获取,例如这里对于 Service D,本地没有查到,Eureka Server 会返回远程 Region 的 Service D 的实例。由于本地有 Service A,所以肯定不会返回远程 Region 的 Service A 的实例。并且,本地是定时拉取的远程 Region 的 Service 列表,并不是每次查询的时候现查询的。
一般的,微服务之间的互相调用,并不经过 Eureka,也不会涉及到 Eureka 客户端了,而是通过负载均衡器调用,这个我们后面就会提到。
我们这一节详细分析了 Eureka 的架构,以及其中的核心概念。下一节,我们将开始介绍我们微服务的注册中心 Eureka 的实例配置。