服务注册中心

注册中心与CAP理论介绍

1.注册中心

• 服务注册中心是微服务架构中的一个关键组件，它的主要作用是管理服务实例的注册、维护和发现。

• 是一个中心化的组件来分散的微服务实例的位置和状态。

• 注册中心有三种角色构成：

  • 服务提供者：是注册中心中的主动方，负责将自己的服务实例信息注册到注册中心。
  • 服务消费者：是注册中心中的被动方，负责从注册中心获取服务实例信息，并建立与这些服务实例的连接。
  • 注册中心：注册中心是服务提供者和服务消费者之间的中介，负责维护服务实例的注册信息，并支持服务发现功能。

  

2.注册中心基本功能

• 服务注册管理：管理服务提供者注册的服务信息，包括服务的地址、端口、API等。
• 服务发现：响应对服务消费者的查询请求，提供可用服务实例的列表。
• 服务发现：响应对服务消费者的查询请求，提供可用服务实例的列表。
• 健康检查：定期对服务实例进行健康检查，移除不可用的服务实例。
• 负载均衡：支持负载均衡策略，将请求分发到不同的服务实例。
• 服务治理：提供服务治理功能，如服务版本控制、服务依赖关系管理等。
• 高可用性：保证自己的高可用性，防止单点故障影响整个微服务架构。
• 动态伸缩：支持服务实例的动态增加和减少。
• 数据一致性：保证服务信息的一致性，防止数据不一致导致的服务调用错误。
• 安全性：实现安全机制，保护服务信息不被未授权访问或篡改。

2. CAP理论

• CAP理论是分布式系统设计中的一个重要概念，它描述了在分布式环境中，系统设计者在一致性、可用性和分区容错性三者之间的权衡关系。
• 一致性（Consistency）： 一致性指的是系统中的所有数据副本在任何时刻都保持同步。
• 可用性（Availability）： 可用性指的是系统对客户端的请求总是能够给出响应，无论这个响应是成功还是失败。
• 分区容错性（Partition tolerance）：系统在面对网络分区（如交换机失败、网络延迟或服务器宕机）时，仍然能够继续提供服务，并保证数据的一致性和可用性。

3. CAP不能全取的原因

• 一致性与可用性
  • 一致性要求所有节点在同一时间的数据都是完全一致的，这通常需要时间同步和状态同步机制。
  • 在发生网络分区时，为了保证一致性，系统可能需要拒绝或延迟某些操作，这会影响系统的可用性。
  • 在面临分区时，系统必须在一致性和可用性之间做出选择。
• 一致性与分区容错性
  • 一致性要求系统中的所有数据副本在任何时刻都保持同步。
  • 但在发生分区时，不同区域的数据可能会因为网络隔离而无法及时同步。
  • 为了保证一致性，系统可能会选择在分区解决之前拒绝或延迟操作，这会影响系统的分区容错性。
• 可用性与分区容错性
  • 可用性要求系统对客户端的请求总是能够给出响应，但在发生分区时，系统可能无法访问所有数据副本或部分节点。
  • 为了保证可用性，系统可能会选择继续服务，但这可能会导致数据不一致，从而牺牲一致性。

4.三大类

• CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。

• CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。

• AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

Eureka

1.基本介绍

• Eureka Server是服务注册中心，提供服务的注册和发现功能。服务在启动时，会向Eureka Server注册自己的信息，如主机名、端口、健康指标URL等。属于CAP里面的AP分支。
• Eureka包含两个组件：Eureka Server和Eureka Client。
  • Eureka Server提供服务注册服务，各个微服务节点通过配置启动后，会在Eureka Server中进行注册。这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观看到。
  • Eureka Client是一个Java客户端，用于简化Eureka Server的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除

2.自我保护机制

• 某时刻某一个微服务不可用了，Eureka不会立刻清理，依旧会对该微服务的信息进行保存。
• 此机制的触发条件是当某个微服务在一定时间内没有发送心跳时，Eureka不会立即清理该服务，而是继续保存其信息。
• 这样做是为了防止服务在网络分区之后，因为查询不到服务而产生更多的服务故障。

3. Eureka特点

• 高可用性：Eureka Server可以运行在多个实例上，并且它们之间可以相互复制注册表信息，这样即使一个实例宕机，其他实例仍然可以提供服务发现功能。 采用的是Peer to Peer 对等通信。这是一种去中心化的架构。
• 服务注册与发现：Eureka允许服务提供者在启动时注册自己，并且客户端可以通过Eureka Server获取到已注册服务的位置信息。
• 心跳检测：服务提供者需要定期向Eureka Server发送心跳，以表明服务仍然存活。如果Eureka Server在一定时间内没有收到服务提供者的心跳，它将会从注册列表中移除该服务。
• 客户端负载均衡：Eureka Client通常与负载均衡器（如Ribbon）结合使用，可以在客户端进行负载均衡，选择最佳的服务实例进行调用。

4. Eureka工作流程

• Server端启动成功后，进入等待服务端注册阶段。
• 在启动过程中如果配置了集群，集群之间定 同步注册表，每个 Eureka Server 都存在独立完整的服务注册表信息。
• Client端启动时根据配置的Server 地址去注册中心注册服务。会每 30s 向 Eureka Server 发送一次心跳请求，证明客户端服务正常。Server 某周期内没有收到 Eureka Client 的心跳，注册中心则认为该节点失效，会注销该实例。
• Client端定时全量或者增量从注册中心获取服务注册表，并且将获取到的信息缓存到本地。
• Client 程序关闭时向Server 发送取消请求，Server 将实例从注册表中删除。

Zookeeper

1.基本介绍

• zookeeper是一个分布式协调工具，可以实现注册中心功能。属于CAP里边的CP分支。
• 它采用了一种称为ZAB的协议来保证数据的一致性，并采用主从节点复制的方式来实现数据的高可用性。
• 主要用于管理和维护大型分布式系统中的配置信息、命名服务、状态同步等。

2.主要功能

• 配置管理：可以用于存储和同步分布式系统的配置信息。当配置发生变化时，所有订阅了该配置的服务都会收到通知并自动更新。
• 命名服务：提供了一个类似DNS的服务，允许分布式系统中的服务注册自己的名字，并可以通过这个名字被其他服务发现和访问。
• 分布式锁：可以用于实现分布式锁，确保在分布式环境中对共享资源的访问是同步的，防止多个服务同时修改同一资源。
• 队列管理：可以用于管理分布式队列，支持先进先出（FIFO）的队列操作，确保消息的顺序性和可靠性。
• 集群管理：可以帮助管理分布式系统中的集群，包括服务器的加入、退出、健康状态监控等。
• 数据一致性：使用ZAB协议来保证数据的一致性，确保所有节点上的数据最终是一致的。
• 高可用性：集群中的数据是通过复制的方式在多个节点上保存的，即使部分节点宕机，系统仍然可以继续提供服务。
• 负载均衡：可以与负载均衡器配合使用，如Ribbon，以实现客户端的负载均衡。
• 服务发现：允许服务提供者在启动时注册自己，并且客户端可以通过查询和发现所需的服务。

3.工作流程

• 服务提供者启动时，会将其服务名称，ip地址注册到配置中心。
• 服务消费者在第一次调用服务时，会通过注册中心找到相应的服务的IP地址列表，并缓存到本地，以供后续使用。
• 当消费者调用服务时，不会再去请求注册中心，而是直接通过负载均衡算法从IP列表中取一个服务提供者的服务器调用服务。
• 不具有自我保护机制，当某项服务宕机后相应的ip会被移出注册中心。当其再次上线时会重新注册。

Consul

1.基本介绍

• Consul 是一套开源的分布式服务发现和配置管理系统，用 Go 语言开发。属于CAP里边的CP分支。
• 提供了微服务系统中的服务治理、配置中心、控制总线等功能。
• 这些功能中的每一个都可以根据需要单独使用，也可以一起使用以构建全方位的服务网格。

2.功能

• 服务发现：提供HTTP和DNS两种发现方式。
• 健康监测：支持多种方式，HTTP、TCP、Docker、Shell脚本定制化监控。
• KV存储：Key、Value的存储方式。
• 多数据中心：Consul支持多数据中心。
• 具有可视化Web界面。

3.工作流程

• 服务注册：服务实例在启动时向Consul注册自己的信息，包括服务ID、名称、地址、端口和健康检查URL等。
• 健康检查：Consul定期对注册的服务实例进行健康检查，通过HTTP GET请求访问健康检查URL。若检查失败，则标记服务实例为不健康。
• 服务发现：服务消费者通过Consul查询健康的服务实例列表，并根据列表选择一个实例进行调用。
• 负载均衡：Consul可与负载均衡器（如Ribbon）配合，实现客户端负载均衡。负载均衡器根据Consul提供的服务实例列表，选择一个实例进行调用。
• 服务调用：服务消费者通过负载均衡器向选定的服务实例发送请求，服务实例处理请求并返回响应。
• 服务注销：当服务实例不再可用时，向Consul发送注销请求。Consul从注册列表中移除该实例，并通知其他服务消费者。

管理工具异同点

1.相同点

• 三者都提供了服务发现的功能，允许服务实例注册自己，并且可以被其他服务实例发现和调用。
• 都可以对注册的服务实例进行健康检查，以确保只有健康的服务实例被其他服务调用。
• 这三个系统都支持高可用性，可以通过集群部署来提高系统的可靠性。
• 都可以应用负载均衡。

2.不同点

• Eureka遵循CAP定理中的AP模型，即可用性和分区容错性，而不是强一致性。好死不如赖活着。
• Zookeeper遵循CAP定理中的CP模型，即一致性和分区容错性，牺牲了可用性。
• Consul也遵循CAP定理中的CP模型，但在某些情况下可以通过配置来实现近似于强一致性的行为。