分布式服务注册中心分析与设计

一、服务注册中心基础

服务注册中心

　　服务注册中心（Service Registration Center）：在分布式系统中，为了实现服务的自动发现、统一管理和治理，通常会搭建一个服务注册中心作为基础设施。它主要提供服务注册、服务发现、服务健康检测、负载均衡、服务容错等功能。

服务

　　服务是一个独立的功能模块，一般需要通过一个特定的端口暴露，支持不同的协议实现，如HTTP、RPC、WebSocket等。

服务实例

　　服务实例是指部署在某个物理机/容器中的某个具体的服务进程。在分布式架构中，服务可能有多个实例，分布在不同的服务器上。

服务端点

　　服务端点是指一个服务的具体处理方法，比如HTTP URL。服务断点唯一地表示了一个服务，通过这个断点才能调用对应的服务。

服务注册

　　服务注册是指将服务实例的信息（例如服务名、IP地址、端口号等）注册到注册中心，以便其他服务可以发现它。

服务发现

　　服务发现是指客户端从注册中心中查找和选择可用的服务实例，并通过负载均衡策略来分配请求。

负载均衡

　　负载均衡（Load Balance）是指将负载（工作任务）进行平衡、分摊到多个单元上进行运行，从而提高并发处理能力，是集群技术（Cluster）的一种应用。

CAP 理论

CAP理论，指在分布式系统中，一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）这三个基本需求无法同时满足。又称CAP定理或布鲁尔定理，是分布式系统中的一个核心理论，由Eric Brewer教授提出。

　　1. 一致性(Consistency)：数据在多个副本之间是否能够保持一致的特性。(当一个系统在一致状态下更新后，应保持系统中所有数据仍处于一致的状态)

　　2. 可用性(Availability)：系统提供的服务必须一直处于可用状态，对每一个操作的请求必须在有限时间内返回结果。

　　3. 分区容错性(Tolerance of network Partition)：分布式系统在遇到网络分区故障时，仍然需要保证对外提供一致性和可用性的服务，除非整个网络都发生故障。

　　在分布式系统中这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容错性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。

BASE 理论

BASE 理论是对 CAP 理论的一种扩展和补充。BASE 是指 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）。

BASE 理论认为，在面对大规模分布式系统的挑战时，一致性可以放松为最终一致性，并通过妥协可用性来获得系统的稳定性和高性能。

- 基本可用性指的是分布式系统在正常情况下可以提供满足用户需求的基本功能，即使在部分故障或网络分区的情况下。
- 软状态表示系统的状态可以因为时间、异步消息传递等因素而发生变化。
- 最终一致性是指系统在一定时间内达到数据的一致性，而不要求实时一致。

BASE 理论强调了在分布式系统中灵活性和性能的重要性，相对于强一致性，它更关注可用性和效率。通过放宽一致性要求，BASE 理论允许系统在分布式环境下实现更高的性能和可伸缩性。

二、注册中心原理和功能

原理

注册中心主要有三种角色：

- 服务提供者（RPC Server）：在启动时，向 Registry 注册自身服务，并向 Registry 定期发送心跳汇报存活状态。
- 服务消费者（RPC Client）：在启动时，向 Registry 订阅服务，把 Registry 返回的服务节点列表缓存在本地内存中，并与 RPC Sever 建立连接。
- 服务注册中心（Registry）：用于保存 RPC Server 的注册信息，当 RPC Server 节点发生变更时，Registry 会同步变更，RPC Client 感知后会刷新本地内存中缓存的服务节点列表。

最后，RPC Client 从本地缓存的服务节点列表中，基于负载均衡算法选择一台 RPC Sever 发起调用。

功能需求

根据注册中心原理的描述，注册中心必须实现以下功能：

- 服务注册：存储服务提供方节点上报的自身路由信息，并以集群形式组织数据（集群名与节点列表映射关系）。
- 服务发现：服务消费方通过注册中心拉取服务提供方节点列表。
- 节点保活：注册中心通过与已注册节点通讯，判断节点是否健康，并将不健康节点剔除。
- 信息订阅：服务消费方订阅服务提供方节点变更事件，发生变更时（发布新版本、扩缩容、服务器宕机）注册中心及时通知服务消费方。

　　可以看出，注册中心的核心功能是服务提供方节（端）点数据的存储于查询。因此，还需要保证所存储数据的可靠性（不丢失）还需要和系统的可用性。

三、常用注册中心对比

四、Nacos简介

Nacos 是 Alibaba 公司推出的开源工具，用于实现分布式系统的服务发现与配置管理。Nacos 是 Dubbo 生态系统中重要的注册中心实现。

Nacos 官网：https://nacos.io/zh-cn/

Github：https://github.com/alibaba/nacos

Nacos文档：https://nacos.io/zh-cn/docs/v2/upgrading/2.0.0-compatibility

　　服务注册中心---服务发现nacos

　AP、CP模式实现

Nacos中服务注册中心默认是AP模式，如果设置为CP模式
那么客户端设置 spring.cloud.nacos.discovery.ephemeral=false （默认为true），表示是启用AP模式

接下来我们看看Nacos中对于AP、CP模式是怎么实现的。

首先说明一下，在Nacos中默认基于HTTP的端口号是8848 ，Nacos2.0增加了gRPC，而gRPC有两个地方，一个是和客户端通信，一个是集群节点之间的通信。 Nacos中gRPC的端口号都是基于HTTP端口进行一定的漂移，客户端通信端口是漂移1000，即默认为：8848+1000=9848，而集群之间的通信端口漂移 1001，即8848+·1001=9849，这里需要注意如果网络安全需要开启相关端口的话，那么这里需要开通，8848,9848,9849，三个端口号。
————————————————

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/LeoHan163/article/details/121545067

Nacos篇之API及通用功能介绍

nacos-API代码解析

Nacos系列之服务注册与发现API讲解

五、Zookeeper

Windows下安装Zookeeper

Zookeeper客户端ZkClient、Curator的使用