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

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

注册中心是用来集中管理微服务，实现服务的注册，发现，检查等功能，目前比较成熟的注册中心组件有很多，如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节点来完成，对于采用最终一致性的组件来说，水平扩容可以同时提升集群的写性能和读性能，但对实时数据的一致性不能提供保证。在安全方面，必须在每一次的注册、发布、心跳，都带上鉴权的信息，防止恶意注册导致的信息泄漏和服务攻击。

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