美团面试:如何设计一个注册中心? Hollis 共
2747字,需浏览
6分钟
·
2022-01-01 15:21
不管是出于面试,还是深入学习注册中心,关于如何设计一个注册中心都是一个很好的话题。 单个系统分别部署在不同服务器上,如果我们订单系统需要调用商品系统的某个服务: 怎么调用? 方法2:商品系统开发的朋友把对应 API
地址存放到某个地方。 方法3:直接通过Nginx,使用域名进行转发到某个实例上。 这时候,订单系统就可以通过上述方法调用商品系统的 API
了。 问题来了 实际线上环境中,很少是单体机构的,很多都是做了集群的,也就是说每个服务会有N个实例,少则几个几十个,多则几百上千上万。如果此时我们还用上面三种方法,当我们的商品系统某个服务下线(宕机了),或者新增实例,此时是非常的头疼。 注册中心来了 我们能不能搞一个第三方的节点,这个节点就用来存放我们商品系统的服务信息,这样一来,其他系统需要服务信息,直接去第三方节点上去获取即可。此时,其他系统只要知道这个第三方的节点地址就可以了。这个第三方的节点,我们也称之为 注册中心
。 下面我们用服务提供方(商品系统)称之为provider,服务调用方(订单系统)我们称之为consumer。 如何设计一个注册中心 服务注册 服务列表保存通常有三种方式:本地内存、数据库、第三方缓存系统 注册上去后,consumer需要服务地址的时候,就可以用相应key去注册中心获取对应的服务列表。 同一个服务注册中心,我们可以注册多个服务,比如用户服务、商品服务、订单服务... 服务消费 consumer端通过key获取指定的服务地址列表。 以上的还是蛮简单的吧,简单来说,我们就是引用了一个第三方的服务来存放我们的服务提供者列表。并且以key-value的形式存储,key我们可以理解为服务名称,value就是服务实例列表。 注册中心高可用 高可用无非就是做集群,我们可以对注册中心部署多个节点。在消费端consumer只需要知道一个服务注册中心集群地址 cluster-url
即可。 动态感知服务上下线 consumer拿到服务列表后,会把服务列表保存起来,保存到本地缓存里。 consumer通过一定的负载均衡算法,选择出一个地址,最后发起远程的调用。 此时,服务注册中心的服务列表还是之前的列表,如果consumer调用到过掉的节点上,那岂不是会出问题呀。 所以,我们的服务注册中心需要知道哪个服务节点挂了,然后从对应服务列表里删除。 有种办法叫做心跳检测 heartBeat
,即就是服务注册中心,每隔一定时间去监测一下provider,如果监测到某个服务挂了,那就把对应服务地址从服务列表中删除。 可是不对呀,此时consumer端本地列表里还有过掉的服务地址,怎么办呢? 对于服务注册中心来说,就是服务列表里增加一个服务地址。 但是在消费端存在同样的问题,就是服务注册中心的服务列表和consumer端的服务列表不一样了。 其实很简单,此时,我们得思维换一下,因为consumer的服务列表是来自于服务注册中心,我们就可以把consumer理解为消费端,服务注册中心理解为服务端。此时,consumer端就可以去服务端(服务注册中心)拉取provider服务列表。 push:服务注册中心主动推送服务列表给consumer。 pull:consumer主动从注册中心拉取服务列表。 不管是push还是pull,都会存在consumer和服务注册中心的通信管道。如果他们之间断开了,那就无法获取服务列表了。 还有就是服务注册中心知道consumer的地址,比如 我得知道你的微信好友,不然我怎么把我手里的资源发给你 如果服务注册中心要push到consumer,此时他们之间需要建立一个会话,所以,在服务注册中心会维护一个会话管理的模块。还有一种方式就是consumer提供一个 API
,这个 API
给服务注册中心进行回调。 本质是我们是使用HTTP协议还是使用Socket监听 push有个不好点,那就是服务注册中心需要维护大量的会话,而且还需要对每个会话维持一个心跳,一遍知晓这些会话状态,得确保这些consumer能收到数据, 另外就是pull,pull其实就相对push就简单多了。pull和我们前面说的心跳机制是类似的,consumer端启动定时任务,每个多久拉取服务注册中心的服务列表。pull也不需要去维护大量的会话,我只需要每隔多久调用接口拉取服务列表即可。但是这里还是会存在一个问题,因为是定时去拉取,所以会存在一定的数据延迟,比如consumer刚刚拉取服务列表,但就在拉取结束的后,某个服务provider挂了,consumer就要等下次拉取才知道对应服务provider挂了。 如果定时任务是每隔30秒拉去一次,那就是说,延迟最长时间是30秒。 还有一种方式long-pull,也叫长轮询,是上面两种方案的优化方案,consumer发起拉取请求时,先把这个请求hold住,当服务注册中心有发生变化后,consumer端能立马感知。 与简单轮询相似,只是在服务端在没有新的返回数据情况下不会立即响应,而会挂起,直到有数据或即将超时 缺点
:还是存在占用服务端资源的问题,虽然及时性比轮询要高,但是会在没有数据的时候在服务端挂起,所以会一直占用服务端资源,处理能力变少 应用
:一些早期的对及时性有一些要求的应用:web IM 聊天 通过上面的服务注册、服务消费、注册中心高可用以及动态感知服务的上下线,这就是我们去实现一个服务注册中心的通用模型。 小总结 有道无术,术可成;有术无道,止于术
欢迎大家关注 Java之道 公众号
好文章,我 在看 ❤️
浏览
27 点赞
评论
收藏
分享
手机扫一扫分享
分享
举报
点赞
评论
收藏
分享
手机扫一扫分享
分享
举报