浅析微服务注册中心的注册与发现

By | 2021年3月5日

浅析微服务注册中心的注册与发现

注册中心是用来集中管理微服务,实现服务的注册,发现,检查等功能,目前比较成熟的注册中心组件有很多,如Consul,eureka,zookeeper,etcd,nacos,不同组件之间性能,并发,高可用都会有差距。但对于用户来说基本的功能实现都是透明的。其实如果我们自己开发一套注册中心也可以,能够满足基本的功能即可。

  1. 支持IP端口的注册:注册中心提供接口将服务发布者的信息添加进去。

  2. 提供一些其他信息,如服务名称,只注册IP仅能实现基本功能,如果需要加密或者负载均衡时,如对相同服务下不同节点设置不同权重进行流量分配,都需要更加详细的规则参数来实现。

  3. 优雅关闭,服务下线功能是必须的,既然注册了必须在节点失效的时候及时剔除掉,如果没有及时下线,会造成大量请求依旧错误的访问。注册中心可以提供关闭接口,而应用程序里也应在shutdown的时候调用接口来合理进行下线操作。

  4. 健康检查功能,上面的优雅关闭只是正常情况,当用户采用kill -9这种粗暴的停止方式,或者网络不通等异常情况发生,注册中心需要及时检查到异常情况的发生。健康检查也分为很多种。

    1. 客户端心跳连接:客户端每隔一定时间主动发送“心跳”的方式来向服务端表明自己的服务状态正常,心跳可以是 TCP 的形式,也可以是 HTTP 的形式。
    2. 保持长连接:可以通过维持客户端和服务端的一个 socket 长连接自己实现一个客户端心跳的方式。
    3. 创建会话:ZooKeeper 并没有主动的发送心跳,而是依赖了组件本身提供的临时节点的特性,通过 ZooKeeper 连接的 session 来维持临时节点。
    4. 注册中心主动探测:调用服务发布者某个 HTTP 接口来完成健康检查,例如consul就有这样的探测机制。
  5. 连接注册中心:简单的方法就是在配置文件中固定注册中心IP地址,然而这样的扩展性会很差,无法支持水平扩容的多机部署,或者写多台服务器的地址,类似Kafka从中获取元数据信息,然后再进行二次连接。

  6. 服务发现:如果查看本机发布和订阅的服务,注册中心需要提供了丰富的接口,支持根据应用名、IP、订阅服务名、发布服务名,来进行多层次的组合查询。

  7. 服务订阅(非必需):服务有节点退出或新的节点加入时,订阅者如何及时收到通知,这里便是pull和push的问题,push典型的,例如zookeeper基于socket长连接实现notify,还有一种长轮询的实现,这两种都有一定的技术难度,通过pull的方式定时轮询会简单一些,但需要调整合适的请求时间间隔,频率越高注册中心所承受的压力也越大。

当服务节点数越来越多时,注册中心的性能会成为瓶颈,这时候就需要通过水平扩容来提升服务注册中心集群的性能,对于采用了类 Paxos 协议的强一致性的组件,由于每次写操作需要过半的节点确认,水平扩容只能提升集群的读性能,而不能提升集群的写性能,因为所有的写操作都需要leader节点来完成,对于采用最终一致性的组件来说,水平扩容可以同时提升集群的写性能和读性能,但对实时数据的一致性不能提供保证。在安全方面,必须在每一次的注册、发布、心跳,都带上鉴权的信息,防止恶意注册导致的信息泄漏和服务攻击。

最后,基于以上这些可以实现一个注册中心的大致轮廓,而更加高级的功能,如服务高可用和容灾,安全问题还需要进一步完善。

发表评论

电子邮件地址不会被公开。 必填项已用*标注