你们的服务注册中心进行过选型调研吗?对比一下各种服务注册中心?
Eureka服务注册发现集群原理:
Eureka,peer-to-peer,部署一个集群,但是集群里每个机器的地位是对等的,各个服务可以向任何一个Eureka实例服务注册和服务发现,集群里任何一个Eureka实例接收到写请求之后,会自动同步给其他所有的Eureka实例。
Zookeeper服务注册发现原理:
Leader + Follower两种角色,只有Leader可以负责写也就是服务注册,他可以把数据同步给Follower,读的时候leader/follower都可以读。
一致性保障:CP or AP
CAP,C是一致性,A是可用性,P是分区容错性。
ZooKeeper是有一个leader节点会接收数据, 然后同步写其他节点,一旦leader挂了,要重新选举leader,这个过程里为了保证C,就牺牲了A,不可用一段时间,但是一个leader选举好了,那么就可以继续写数据了,保证一致性。
Eureka是peer模式,可能还没同步数据过去,结果自己就死了,此时还是可以继续从别的机器上拉取注册表,但是看到的就不是最新的数据了,但是保证了可用性,强一致,最终一致性。
阐述一下你们的服务注册中心部署架构,生产环境下怎么保证高可用?
Eureka高可用,至少2台做集群。
两个分支内相互配置另一台的ip和端口号。
你们系统遇到过服务发现过慢的问题吗?怎么优化和解决的?
eureka,必须进行优化参数:
// 客户端的有效负载缓存应该更新的时间间隔,默认为30 * 1000毫秒
eureka.server.responseCacheUpdateIntervalMs = 30000(30s) -> 3000(3s)
// 从eureka服务器注册表中获取注册信息的时间间隔(s),默认为30秒
eureka.client.registryFetchIntervalSeconds = 30000 -> 3000
// 客户端多长时间发送心跳给eureka服务器,表明它仍然活着,默认为30 秒
eureka.client.leaseRenewalIntervalInSeconds = 30 -> 3
// 过期实例应该剔除的时间间隔,单位为毫秒,默认为60 * 1000
eureka.server.evictionIntervalTimerInMs = 60000 -> 6000(6s)
// Eureka服务器在接收到实例的最后一次发出的心跳后,需要等待多久才可以将此实例删除,默认为90秒
eureka.instance.leaseExpirationDurationInSeconds = 90 -> 9(s)
服务发现的时效性变成秒级,几秒钟可以感知服务的上线和下线
说一下自己公司的服务注册中心怎么技术选型的?生产环境中应该怎么优化?
服务注册、故障 和发现的时效性是多长时间?
注册中心最大能支撑多少服务实例?
如何部署的,几台机器,每台机器的配置如何,会用比较高配置的机器来做,8核16G,16核32G的高配置机器来搞,基本上可以做到每台机器每秒钟的请求支撑几千绝对没问题。
可用性如何来保证?
有没有做过一些优化,服务注册、故障以及发现的时效性,是否可以优化一下,用eureka的话,可以尝试一下,配合我们讲解的那些参数,优化一下时效性,服务上线、故障到发现是几秒钟的时效性。
zk,一旦服务挂掉,zk感知到以及通知其他服务的时效性,服务注册到zk之后通知到其他服务的时效性,leader挂掉之后可用性是否会出现短暂的问题,为了去换取一致性。
如果需要部署上万服务实例,现有的服务注册中心能否抗住?如何优化?
核心思想:注册中心主从架构,分片存储服务注册表,服务按需主动拉取注册表,不用全量拉取/推送,避免反向通知瞬时高并发。
自研注意点:
客户端:
1. 服务拉取:不用全量拉取,按需拉取(有疑问,怎么设计按需拉取?)。还需要一个用于校验拉取增量数据之后数据是否完整的过程。
2. 心跳发送。
3. 服务下线。
服务端:
1.服务注册: 服务注册表注意读写高并发控制,保证线程安全,也要降低锁的争用。
2. 健康检查:单位时间内,如果所注册服务没有续约,则要将其下线。
3. 集群同步:根据具体业务需求,制定合适的集群架构方案,保证吞吐量。
参考资料:
21天互联网Java进阶面试训练营(分布式篇)-- 中华石杉