服务注册中心
注册中心与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模型，但在某些情况下可以通过配置来实现近似于强一致性的行为。
-源码编译)
详解)
)
