为什么需要注册中心

• 在微服务架构中，系统被拆分成了若干个独立的服务，因此服务之间需要进行通信和协作。为了实现服务的发现和调用，需要一个中心化的注册中心来进行服务的注册和发现。注册中心可以让服务通过名字进行访问，而不用关心服务的物理位置和实现细节

• 服务注册中心就是在整个的微服务架构中单独提出一个服务，这个服务不完成系统的任何的业务功能，仅仅用来完成对整个微服务系统的服务注册和服务发现，以及对服务健康状态的监控和管理功能。

注册中心的主要作用是：

• 服务的注册和注销：服务在启动时将自己的信息注册到注册中心，服务关闭时注销自己的信息。

• 服务的发现和访问：客户端通过注册中心查询服务的信息，获取服务的地址和端口，然后进行调用。

• 健康检查和服务摘除：主动的检查服务健康情况，对于宕机的服务将其摘除服务列表

• 服务的负载均衡和路由：注册中心可以根据服务提供者的负载情况和调用方的请求路由选择合适的服务提供者。

注册中心的原理

主要架构

• 各个微服务在启动时，将自己的网络地址等信息注册到注册中心，注册中心存储这些数据。

• 服务消费者从注册中心查询服务提供者的地址，并通过该地址调用服务提供者的接口。

• 各个微服务与注册中心使用一定机制（例如心跳）通信。如果注册中心与某微服务长时间无法通信，就会注销该实例。

• 微服务网络地址发送变化（例如实例增加或IP变动等）时，会重新注册到注册中心。这样，服务消费者就无需人工修改提供者的网络地址了.

服务注册的实现

• 服务进程在注册中心注册自己的元数据信息。通常包括主机和端口号，有时还有身份验证信息，协议，版本号，以及运行环境的信息。
• 服务注册有两种形式：客户端注册和代理注册。

客户端注册（调用方实现）

• 客户端注册是服务自己要负责注册与注销的工作。当服务启动后注册线程向注册中心注册，当服务下线时注销自己.
• 缺点：注册注销逻辑与服务的业务逻辑耦合在一起，如果服务使用不同语言开发，那需要适配多套服务注册逻辑。
  
  代理注册
• 代理注册由一个单独的代理服务负责注册与注销。当服务提供者启动后以某种方式通知代理服务，然后代理服务负责向注册中心发起注册工作.
  

服务发现

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

客户端发现（调用方实现）

• 客户端发现是指客户端负责向注册中心查询可用服务地址，获取到所有的可用实例地址列表后客户端根据负载均衡算法选择一个实例发起请求调用
• 这种方式非常直接，客户端可以控制负载均衡算法。但是缺点也很明显，获取实例地址、负载均衡等逻辑与服务的业务逻辑耦合在一起，如果服务发现或者负载平衡有变化，那么所有的服务都要修改重新上线。
  

代理发现

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

心跳机制

• 如果服务有多个实例，其中一个实例出现宕机，注册中心是可以实时感知到，并且将该实例信息从列表中移出，也称为摘机。

• 心跳检测有主动和被动两种方式。
• 被动检测是指服务主动向注册中心发送心跳消息，时间间隔可自定义，比如配置5秒发送一次，注册中心如果在三个周期内比如说15秒内没有收到实例的心跳消息，就会将该实例从列表中移除。
• 主动检测是注册中心主动发起，每隔几秒中会给所有列表中的服务实例发送心跳检测消息，如果多个周期内未发送成功或未收到回复就会主动移除该实例
  ————————————————

                        版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

原文链接：https://blog.csdn.net/weixin_42774617/article/details/131740758

常用的注册中心

Zookeeper

• 经典的服务注册中心中间件
  java体系中，大部分的集群环境都是依赖zookeeper管理服务的各个节点

Eureka

• Netflix开发的服务发现框架
  基于REST的服务 用于服务注册、管理、负载均衡、服务故障转
• 其组件特点：
  包含两个组件：EurekaServer 和 EurekaClient
  EurekaServer提供注册服务，服务节点的信息可以在界面中直观的看到
  允许在注册服务时，自定义实现检查自身状态的是够健康的方法
  EurekaClient简化与EurekaServer的交互，同时也是一个内置的、使用轮询负载算法的负载均衡器

Consule

• 用于服务发现和配置的工具分布式的，高度可用的，并且具有极高的可伸缩性
• 提供了功能齐全的控制面板, 主要特点：服务发现、健康检查、键值存储、安全服务通信、多数据中心、ServiceMesh
• 提供多个数据中心支持，基于Fabio做负载均衡
  八卦池，其中包含给定数据中心的所有节点

Nacos

• 用于微服务的发现、配置、管理. 更敏捷、容易地构建、交付、管理微服务平台

注册中心的高可用

• 在微服务中，注册中心作为一个存储所有服务中心的地方必然不可能是单机的。因为如果注册中心无法使用，那么服务提供者就无法对外暴露自己的服务，消费者也无法获取自己需要调用的服务的具体地址，整个应用将会崩溃。首先需要保证的就是注册中心的高可用。
  一致性和可用性的抉择

一致性和可用性的抉择

• 根据CAP理论, 分布式系统一般分为CP类型和AP类型

CP类型注册中心

• Zookeeper是一个典型的CP类型的组件。
• zookeeper实现了paxos算法，zookeeper集群有一个节点作为leader，如果leader节点挂了zk会通过ZAB协议来进行leader选举，但是在选举的过程中zk是不能对外提供服务的。
• 而且当因为网络分区导致zk集群出现断裂问题时，由于ZAB协议需要半数以上的节点参与，所以可能会有部分或者全部的zk节点无法对外提供服务。但是zk可以保证所有可用节点都数据都是一致，即使节点崩溃，在恢复后也会和其他节点保持一致，这就是zk牺牲了可用性而保证的强一致性。

AP类型注册中心

• 而类似与eureka的注册中心则是AP类型的。eureka实现高可用是通过启动多个eureka server服务，每一个eureka server即是提供者也是消费者，每个eureka server将自己作为服务注册给其他的eureka server，这样每个eureka server都是其他server 的replica。eureka这种模式中每个节点都是平等的，不存在leader、flower。
• 当集群中某一个server节点宕机，请求可以直接转移到其他节点。即使发生了网络分区，尽管不同分区之间无法进行通信，但是在每一个分区内的节点是通信并且可以正常对外提供服务，这样就保证了在server节点宕机的情况下的注册中心的可用性。
• 而问题在于由于不同分区无法通信，就导致可能一部分节点的数据和另一部分有差别，这就是牺牲了强一致性来换取系统可用性。

注册中心的选择

• 首先我们应该明确的是其实注册中心的存在与否应该是不能直接影响服务的调用的。服务之间的调用时通过http或者rpc等协议直接调用的，注册中心只是提供一个调用地址。服务是否可以正常使用不能直接靠注册中心节点信息来决定。
• 即使注册中心出现问题，只要服务本身没有宕机，理论上来说还是应该正常对外提供服务。所以很明显对于我们来说AP类型的注册中心是要优于CP类型的注册中心的。
• 当然在实际实现过程中很多框架都会尽可能的去修补这些问题，比如eureka会定时的同步各个节点的数据，尽可能的做到数据一致性。dubbo的zk注册中心实现过程中也会本地缓存服务信息并不是完全通过zk信息来决定是否剔除服务等。所以实际在选择时还是需要根据自身实际以及是否还有其他需求来确定。