Eureka是在部署AWS的背景下面设计的,其设计认为,在云端,特别是大规模部署情况下面,失败是不可以避免的,可能是因为eureka自身部署失败或者网络分区等情况导致服务不可用,这些问题是不可以避免的,要解决这个问题就需要eureka在网络分区的时候,还能够正常提供服务,因此eureka选择满足availability这个特性。 |
eureka是在部署AWS的背景下面设计的,其设计认为,在云端,特别是大规模部署情况下面,失败是不可以避免的,可能是因为eureka自身部署失败或者网络分区等情况导致服务不可用,这些问题是不可以避免的,要解决这个问题就需要eureka在网络分区的时候,还能够正常提供服务,因此eureka选择满足availability这个特性。
eureka选择了A也就必须放弃C,也就是说在eureka中采用最终一致性的方式来保证数据的一致性问题,因此实例的注册信息在集群的所有节点之间的数据都不是强一性的,需要客户端能支持负载均衡算法及失败重试等机制。
一般而言在分布式系统的数据有多个副本之间的复制方式,可以分为主从复制和对等复制
一个主副本和多个从副本,所有数据的写操作都是提交到主副本,最后由主副本更新到其他的从副本(常采用异步更新),通常写是整个系统的瓶颈所在。
副本之间不分主从,任何的副本都可以接受写数据,然后副本之间进行数据更新。在对等复制中,由于每一个副本都可以进行写操作,各个副本之间的数据同步及冲突处理是一个比较难解决的问题。
使用region来代表一个独立的地理区域,比如us-east-1、us-east-2,、us-west-1等。在每一个region下面还分为多个AvailabilityZone,一个region对应多个AvailabilityZone,不同的region之间相互隔离。默认情况下面资源只是在单个region之间的AvailabilityZone之间进行复制,跨region之间不会进行资源的复制。
AvailabilityZone看成是region下面的一个一个机房,各个机房相对独立,主要是为了region的高可用考虑的,一个region下面的机房挂了,还有其他的机房可以使用。
一个AvailabilityZone可以设置多个server实例,他们之间构成peer节点,然后采用peer to peer的复制模式进行数据复制。
在分布式系统设计中,通常需要对应用实例的存活进行健康检验,这里比较难处理的就是网络偶尔抖动或者短暂不可用而造成的误判。因此eureka设计了self preservation机制。server和client之间有一个租约,client定期发送心跳来维护这个租约,表示心跳还活着,eureka通过当前注册的实例数量,去计算每分钟应用从应用实例接受到的心跳数量,如果近一分钟接受到的租约的次数小于等于指定的阈值,则关闭租约失效剔除,禁止定时任务剔除失效的实例,从而保护注册信息。
自我保护模式的设计哲学是:在不确定节点是否可用的情况下,尽可能保留节点!
原文地址:https://www.linuxprobe.com/service-eureka.html