【架构师】零基础到精通——注册中心

博客昵称：架构师Cool
最喜欢的座右铭：一以贯之的努力，不得懈怠的人生。
作者简介：一名Coder，软件设计师/鸿蒙高级工程师认证，在备战高级架构师/系统分析师，欢迎关注小弟！
博主小留言：哈喽！各位CSDN的uu们，我是你的小弟Cool，希望我的文章可以给您带来一定的帮助
百万笔记知识库， 所有基础的笔记都在这里面啦，点击左边蓝字即可获取！助力每一位未来架构师！
欢迎大家在评论区唠嗑指正，觉得好的话别忘了一键三连哦！

注册中心

注册中心主要是为分布式服务的发布与发现提供一层统一标准化的基础组件，便于使用者直接操作简单接口即可实现服务发布与发现功能。

1、服务注册

服务注册有两种形式：客户端注册和代理注册。

1-1、客户端注册

客户端注册是服务自己要负责注册与注销的工作。当服务启动后注册线程向注册中心注册，当服务下线时注销自己。

这种方式缺点是注册注销逻辑与服务的业务逻辑耦合在一起，如果服务使用不同语言开发，那需要适配多套服务注册逻辑。

1-2、代理注册

代理注册由一个单独的代理服务负责注册与注销。当服务提供者启动后以某种方式通知代理服务，然后代理服务负责向注册中心发起注册工作。

这种方式的缺点是多引用了一个代理服务，并且代理服务要保持高可用状态。

2、服务发现

服务发现也分为客户端发现和代理发现。

2-1、客户端发现

客户端发现是指客户端负责向注册中心查询可用服务地址，获取到所有的可用实例地址列表后客户端根据负载均衡算法选择一个实例发起请求调用。

这种方式非常直接，客户端可以控制负载均衡算法。但是缺点也很明显，获取实例地址、负载均衡等逻辑与服务的业务逻辑耦合在一起，如果服务发现或者负载平衡有变化，那么所有的服务都要修改重新上线。

2-2、代理发现

代理发现是指新增一个路由服务负责服务发现获取可用的实例列表，服务消费者如果需要调用服务A的一个实例可以直接将请求发往路由服务，路由服务根据配置好的负载均衡算法从可用的实例列表中选择一个实例将请求转发过去即可，如果发现实例不可用，路由服务还可以自行重试，服务消费者完全不用感知。

3、心跳机制

如果服务有多个实例，其中一个实例出现宕机，注册中心是可以实时感知到，并且将该实例信息从列表中移出，也称为摘机。如何实现摘机？业界比较常用的方式是通过心跳检测的方式实现，心跳检测有主动和被动两种方式。

3-1、被动检测

被动检测是指服务主动向注册中心发送心跳消息，时间间隔可自定义，比如配置5秒发送一次，注册中心如果在三个周期内比如说15秒内没有收到实例的心跳消息，就会将该实例从列表中移除。

上图中服务A的实例2已经宕机不能主动给注册中心发送心跳消息，15秒之后注册就会将实例2移除掉。

3-2、主动检测

主动检测是注册中心主动发起，每隔几秒中会给所有列表中的服务实例发送心跳检测消息，如果多个周期内未发送成功或未收到回复就会主动移除该实例。

4、Dubbo注册中心

4-1、核心功能

针对使用者，主要关注注册中心的以下五个核心接口，通过以下五个核心接口，可以实现服务的动态发布、动态发现以及优雅下线等操作：

• 注册服务：将服务提供者的URL暴露至注册中心
• 注销服务：从注册中心将服务提供者的地址进行摘除
• 订阅服务：将从注册中心订阅需要消费的URL至本地,当注册中心的服务清单发展变化时,自动通知订阅者
• 退订服务：取消向注册中心订阅的服务监听者
• 查找服务：向注册中心查找指定的服务清单列表

4-2、生产特性

Zookeeper会有一些未知的问题出现，所以需要生产特性来应对各种可能出现的问题，从而提升产品的质量。该类功能针对使用者一般情况是没办法直接感受到，但其发挥的作用就是保障产品的高质量服务：

• 自动重连：与Zookeeper或Redis的连接断开后，支持自动重新连接
• 自动切换：与Zookeeper或Redis的连接失败后，支持自动切换
• 自动清理：Zookeeper或Redis中的数据过期后，支持自动清理（超时自动摘除）
• 自动恢复：与Zookeeper或Redis自动重连成功后，支持自动恢复（即再次发起注册、订阅或监听动作）
• 自动重试：失败自动重试（注册、注销、订阅、退订、监听和取消监听失败，无限重试至成功为止）
• 自动缓存：Client订阅的服务清单会自动离线缓存至JVM本地的文件（变更通知时更新）

5、业界方案

下面结合各个维度对比一下各组件：

方案	优点	缺点	访问协议	一致性算法
Zookeeper	1.功能强大，不仅仅只是服务发现；2.提供watcher机制可以实时获取服务提供者的状态；3.广泛使用，dubbo等微服务框架已支持	1.没有健康检查；2.需要在服务中引入sdk，集成复杂度高；3.不支持多数据中心	TCP	Paxos（CP）
Consul	1.开箱即用，方便集成；2.带健康检查；3.支持多数据中心；4.提供web管理界面	不能实时获取服务变换通知	HTTP/DNS	Raft（CP）
Nacos	1.开箱即用，适用于dubbo，spring cloud等；2.AP模型，数据最终一致性；3.注册中心，配置中心二合一(二合一也不一定是优点)，提供控制台管理；4.纯国产，各种有中文文档，久经双十一考验	刚刚开源不久，社区热度不够，依然存在bug	HTTP/DNS	CP+AP
Eureka			HTTP	AP

5-1、Zookeeper

5-2、Consul

Consul是HashiCorp公司推出的开源工，使用Go语言开发，具有开箱即可部署方便的特点。Consul是分布式的、高可用的、 可横向扩展的用于实现分布式系统的服务发现与配置。

Consul有哪些优势？

• 服务注册发现：Consul提供了通过DNS或者restful接口的方式来注册服务和发现服务。服务可根据实际情况自行选择
• 健康检查：Consul的Client可以提供任意数量的健康检查，既可以与给定的服务相关联，也可以与本地节点相关联
• 多数据中心：Consul支持多数据中心，这意味着用户不需要担心Consul自身的高可用性问题以及多数据中心带来的扩展接入等问题

Consul的架构图

Consul 实现多数据中心依赖于gossip protocol协议。这样做的目的：

• 不需要使用服务器的地址来配置客户端；服务发现是自动完成的
• 健康检查故障的工作不是放在服务器上，而是分布式的

Consul的使用场景

Consul的应用场景包括服务注册发现、服务隔离、服务配置等。

• 服务注册发现场景中consul作为注册中心，服务地址被注册到consul中以后，可以使用consul提供的dns、http接口查询，consul支持health check

• 服务隔离场景中consul支持以服务为单位设置访问策略，能同时支持经典的平台和新兴的平台，支持tls证书分发，service-to-service加密

• 服务配置场景中consul提供key-value数据存储功能，并且能将变动迅速地通知出去，借助Consul可以实现配置共享，需要读取配置的服务可以从Consul中读取到准确的配置信息

5-3、Nacos

Nacos 英文全称为 Dynamic Naming and Configuration Service，是一个由阿里巴巴团队使用 Java 语言开发的开源项目。

Nacos 是一个更易于帮助构建云原生应用的动态服务发现、配置和服务管理平台（参考自 Nacos 官网）。

Nacos 的命名是由 3 部分组成：

Nacos 作为服务注册中心经历了十年“双十一”的洪峰考验，具有简单易用、稳定可靠、性能卓越等优点，可以帮助用户更敏捷、容易地构建和管理微服务应用。