https://www.cnblogs.com/yunyunde/p/11194647.html
Eureka原理
Region和Availability Zone均是AWS的概念。
- Region表示AWS中的地理位置,例如us-east-1、us-east-2、eu-west-1等;
- 每个Region都有多个Availability Zone,彼此内网打通;
- 各个Region之间完全隔离,彼此内网不打通;
- AWS通过这种方式实现了最大的容错和稳定性。
Spring Cloud中,默认使用的Region是us-east-1,部分含义如下:
| US East (N. Virginia) |
| US East (Ohio) |
| US West (N. California) |
| US West (Oregon) |
非AWS环境下,可将将Region理解为内网没有打通的机房,将Availability Zone理解成相同机房的不同机架(内网打通)。
Eureka架构详解
如图是Eureka集群的工作原理。图中的组件非常多,概念也比较抽象,我们先来用通俗易懂的文字翻译一下:
-
Application Service:服务提供者;
-
Application Client:服务消费者;
-
Make Remote Call调用RESTful API;
-
us-east-1c、us-east-1d等都是Availability Zone,它们都属于us-east-1这个region。
由图可知,Eureka包含两个组件:Eureka Server 和 Eureka Client,它们的作用如下:
-
Eureka Server提供服务发现的能力,各个微服务启动时,会向Eureka Server注册自己的信息(例如IP、端口、微服务名称等),Eureka Server会存储这些信息;
-
Eureka Client是一个Java客户端,用于简化与Eureka Server的交互;
-
微服务启动后,会周期性(默认30秒)地向Eureka Server发送心跳以续约自己的“租期”;
-
如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳,Eureka Server将会注销该实例(默认90秒);
-
默认情况下,Eureka Server同时也是Eureka Client。多个Eureka Server实例,互相之间通过增量复制的方式,来实现服务注册表中数据的同步。Eureka Server默认保证在90秒内,Eureka Server集群内的所有实例中的数据达到一致(从这个架构来看,Eureka Server所有实例所处的角色都是对等的,没有类似Zookeeper、Consul、Etcd等软件的选举过程,也不存在主从,所有的节点都是主节点。Eureka官方将Eureka Server集群中的所有实例称为“对等体(peer)”)
-
Eureka Client会缓存服务注册表中的信息。这种方式有一定的优势——首先,微服务无需每次请求都查询Eureka Server,从而降低了Eureka Server的压力;其次,即使Eureka Server所有节点都宕掉,服务消费者依然可以使用缓存中的信息找到服务提供者并完成调用。
综上,Eureka通过心跳检查、客户端缓存等机制,提高了系统的灵活性、可伸缩性和可用性。
TIPS
事实上,这个官方架构图是有一点问题的:Eureka Server本身也集成了Eureka Client,彼此通过Eureka Client同步数据给其它实例又或者从其他实例同步数据。