常用服务注册中心与发现（Eurake、zookeeper、Nacos）笔记（一）基础概念

基础概念

注册中心

在服务治理框架中，通常都会构建一个注册中心，每个服务单元向注册中心登记自己提供的服务，将主机与端口号、版本号、通信协议等一些附加信息告知注册中心，注册中心按照服务名分类组织服务清单，服务注册中心还需要以心跳的方式去监控清单中的服务是否可用，若不可用需要从服务清单中剔除，达到排除故障服务的效果。

服务注册中心的作用就是服务注册与服务发现。注册中心解决的是服务管理和服务的依赖关系管理,为了解耦服务提供者和服务消费者。其架构图如下:

主要功能

（1）服务注册:服务提供方将自身路由信息发布到注册中心,供消费方获取由于提供方建立连接并发起调用

• 路由信息: 注册服务节点ip、监听端口等路由信息；
• 服务信息：序列化协议、路由规则、节点权重；

（2） 服务发现： 服务消费方通过访问注册中心获取服务提供方节点路由信息；

• 启动拉取：服务消费方启动后，从注册中心提取提供方节点列表，建立连接，进行RPC调用。
• 通知回调：接受注册中心变更通知，重新获取数据，更新节点列表；
• 轮询拉取：服务消费方运行过程中定时拉取服务提供方节点列表，用来更新本地数据；

（3）健康检查：确保已注册节点健康度，能够及时准确剔除失效节点，保证服务发现正确性

• 失效原因：部署重启，服务假死，异常终止
• 解决方案：上报心跳，服务探测

（4）变更通知：当服务提供方节点发生变更时，注册中心应该能够第一时间把变更事件或变更后的数据推送到服务订阅方；

• 注册中心内为每个服务提供方建立订阅列表，当服务方节点变更时通知所有订阅该服务的消费方节点

（5）服务治理：注册中心除了实现服务注册与发现，还可以用来实现服务治理相关功能

• 服务扩容/缩容， 机器迁移，权重，灰度流量

设计要点

（1）数据可靠性：数据冗余存储，确保不会因为单节点故障导致数据丢失

（2）数据一致性：各节点间数据同步，保证数据一致性。采用什么协议来保证各个节点数据是一致的。我们可以采用Gossip 协议

• Gossip协议基本思想就是：一个节点想要分享一些信息给网络中的其他的一些节点。于是，它周期性的随机选择一些节点，并把信息传递给这些节点。这些收到信息的节点接下来会做同样的事情，即把这些信息传递给其他一些随机选择的节点。一般而言，信息会周期性的传递给N个目标节点，而不只是一个；
• 主要特点就是：周期性散播消息、随机选择N个节点散播、散播不重复不回传

（3）服务可用性：多节点对等的对外提供服务，由数据可靠性和一致性保证了服务的可用性。

CAP理论

CAP理论是分布式架构中重要理论；

• 一致性（Consistency）：所有节点在同一时间具有相同的数据；
• 可用性（Availability）： 保证每个请求不管成功或者失败都有响应；
• 分隔容忍（Partition tolerance）： 系统中任意信息的丢失或失败不会影响系统的继续运作。

在一个分布式系统中，强一致性（C）、高可用性（A）、分区容错（P）三个因素之间只能满足两个，不能同时满足三个。

AP： Availability(可用性)-Partition tolerance(分区容错性)系统，简单来说，AP系统是指在面对网络分区或失败的情况下，系统能够保证可用性，但不保证数据一致性；

CP：Consistency(一致性)-Partition tolerance(分区容错性)系统是指在面对网络分区或失败的情况下，系统能够保证数据一致性，但不保证可用性。

CAP 不可都取，只能取其中2个的原因如下：

（1）如果C是第一需求的话，那么会影响A的性能，因为要数据同步，不然请求结果会有差异，但是数据同步会消耗时间，期间可用性就会降低。

（2）如果A是第一需求，那么只要有一个服务在，就能正常接受请求，但是对于返回结果变不能保证，原因是，在分布式部署的时候，数据一致的过程不可能像切线路那么快。

（3）如果同时满足一致性和可用性，那么分区容错就很难保证了，也就是单点，也是分布式的基本核心。

AP 和 CP 系统的选择取决于我们的应用场景和需求。如果应用需要保证数据的一致性，那么我们应该选择 CP系统；如果应用需要保证可用性，并且可以容忍数据的不一致性，那么我们可以选择 AP 系统。

注册中心客户端组件功能

（1） 服务发现： 从注册中心查询可用provider实例清单；

（2）实例缓存： 将从注册中心查询到provider 实例清单缓存到本地，不需要在每次使用时都去注册中心临时获取。

服务发现

由于在服务治理框架下运行，服务间的调用不再通过指定具体的实例地址来实现，而是通过向服务名发起请求调用实现。

远程客户端组件

远程客户端组件与微服务提供者之间一般使用某种RPC 通信机制来进行服务消费，常见的RPC通信方式是Rest API， 底层为Http传输协议。远程客户端组件则通常以模块组件的方式完成REST API的远程调用。

微服务提供者provider

微服务提供者通常以Web服务的方式提供REST API接口。

微服务提供者的主要功能如下：

（1） 服务注册：Provider微服务实例在启动时将自己的信息注册到注册中心上的过程。

（2） 心跳续约：Provider实例会定时向服务注册中心提供“心跳”，以表明自己还处于可用的状态。当一个Provider实例停止心跳一段时间后，注册中心会认为该服务实例不可用了，就会将该服务实例从服务注册列表中剔除。如果被剔除的Provider实例过一段时间后继续向注册中心提供心跳，那么服务注册中心会将该Provider实例重新加入服务注册表中。

（3）健康状况查询：Provider实例能提供健康状况查看的API，注册中心或者其他的微服务Provider能够获取其健康状况。

微服务提供者的服务注册和心跳续约一般都会通过注册中心客户端组件来完成。。

注册中心、微服务提供者、远程客户端组件之间的关系大致如下：