Nacos架构&原理.pdf

目录作者6推荐序7前9序言9简介13Nacos 简介13Nacos 架构17Nacos 总体设计17Nacos 架构17Nacos 配置模型21Nacos 内核设计28Nacos 致性协议28Nacos 自研 Distro 协议38Nacos 通信通道42Nacos 寻址机制56Nacos 服务发现模块63Nacos 注册中心的设计原理63Nacos 注册中心服务数据模型80Nacos 健康检查机制89Nacos 配置管理模块97配置致性模型97Nacos 可设计100Nacos 高可用设计100Nacos 鉴权插件103Nacos 账号权限体系103Nacos 认证机制110Nacos 前端设计117Nacos 前端设计117Nacos 性能报告122Nacos Naming 大规模测试报告122Nacos 态130Nacos Spring 生态130Nacos Docker&Kubernetes 生态137Nacos 服务网格生态148Nacos Golang 生态163Nacos C#生态169Nacos-Sync 简介175Nacos 最佳实践179企业落地最佳实践179掌门教育微服务体系 Solar|阿里巴巴 Nacos 企业级落地上篇179掌门教育微服务体系 Solar|阿里巴巴 Nacos 企业级落地中篇209掌门教育微服务体系 Solar|阿里巴巴 Nacos 企业级落地下篇224虎牙直播在微服务改造的实践总结239虎牙在全球 DNS 秒级生效上的实践249叽里呱啦 Nacos 1.1.2 升级 1.4.1 最佳实践267服务发现最佳实践281Eureka 平滑迁移 Nacos 方案281Nacos 打通 CMDB 实现就近访问288跨注册中心服务同步实践298配置管理最佳实践310Nacos 限流最佳实践310Nacos 无缝支持 confd 配置管理320结语326结语326作者推荐序推荐序阿里巴巴合伙人阿里巴巴合伙人-蒋江伟（小邪）蒋江伟（小邪）随着企业加速数字化升级，越来越多的系统架构采用了分布式的架构，主要目的是为了解决集中化和互联网化所带来的架构扩展性和面对海量用户请求的技术挑战。这里面其中有个关键点是软负载。因为整个分布式架构需要有个软负载来协作各个节点之间的服务在线离线状态、数据致性、以及动态配置数据的推送。这里面最简单的需求就是将个配置准时的推送到不同的节点。即便如此简单需求，随着业务规模变大也会变的非常复杂。如何能将数据准确的在 3 秒钟之内推送到每个计算节点，这是当时提出的个要求，围绕这个要求，系统要做大量的研发和改造，类似的这种关键的技术挑战点还非常非常的多。本书就是将面对复杂的分布式计算场景，海量并发的业务场景，对软负载个系统的进行阐述，通过 Nacos 开源分享阿里软负载最佳实践，希望能够帮助到各位开发者，各位系统架构师，少走弯路。阿里巴巴云原生应用平台负责人阿里巴巴云原生应用平台负责人-丁宇（叔同）丁宇（叔同）在阿里中间件开源、自研、商业三位体的战略中，微服务 DNS（Dubbo+Nacos+Spring-cloud-alibba/Sentinel/Seata）组合始终走在前列，引领着微服务领域的发展趋势。Nacos 作为核心引擎孵化于 2008 年的阿里五彩石项目，自主研发完全可控，经历十多年双 11 洪峰考验，沉淀了高性能、高可用、可扩展的核心能力，2018 年开源后引起了开发者的广泛关注和大量使用。本书也将介绍Nacos 偏 AP 分布式系统的设计、全异步事件驱动的高性能架构和面向失败设计的高可用设计理念等。相信开发者阅读后不仅可以更深入了解 Nacos，也有助于提高分布式系统的设计研发能力。阿里巴巴中间件负责人阿里巴巴中间件负责人-胡伟琪（白慕）胡伟琪（白慕）阿里巴巴在 10 多年分布式应用架构实践过程中，产出了大批非常优秀的中间件技术产品，其中软负载领域的 Diamond、Configserver、Vipserver，无论在架构先进性、功能丰富度以及性能方面均有非常出色的积累，2018 年初中间件团队决定把这领域的技术进行重新梳理并开源，这就是本书介绍的主角 Nacos，经过三年时间的发展，Nacos 已经被大量开发者和企业客户用于生产环境，本书详尽介绍了 Nacos 的架构设计、功能使用和最佳实践，推荐分布式应用的开发人员、运维人员和对该领域感兴趣的技术爱好者阅读。推荐序前言前序阿里做开源大概有两个阶段，第个阶段是 2018 年之前，取之于开源，反哺于社区，开源是种情怀，是种文化，是种展示技术影响力和技术实力的方式，包括我在内很多阿里技术人都是因此影响加入。阿里凭借着互联网场景和规模的优势走在了时代的前列，完成了去 IOE，创造了企业级互联网架构等壮举，并且开源了很多自主产品如 Dubbo、RocketMQ、Tengine、Jstorm 等，产生了巨大的影响力，在互联网行业广泛使用，但是这阶段的开源除了情怀和展示技术影响力之后很难量化对公司的价值，因此也比较难以持续发展。第二个阶段是 2018 年开始，随着云计算发展，开源作为种标准加速云计算发展，尤其 K8s 迅速崛起给我们很多启示，作为家云计算公司，阿里巴巴也在 2018 年制定了个全面开源，加速企业数字化转型，影响 100w 开发者的战略目标，这个阶段的开源发生了本质的两个变化，第更重视社区和生态建设，第二更注重自研、开源、商业化三位体，讲清开源的价值，能够持续投入开源，解决第阶段难以持续的问题。Nacos 也是在这个大势下应运而生，并且快速成为国内首选。2018 年产品规划会起到舟山小岛上，关于是否开源的时候面临几个核心问题进行深度讨论，第个是我们开源是否晚了，如何定位和打造竞争力；第二是内部有三个产品（Configserver 非持久注册中心，VIPServer 持久化注册中心，Diamond 配置中心），是开源三个产品还是合成个产品开源；第三个问题是开源产品跟商业化产品的关系是什么，是否会削弱商业化产品的竞争力。围绕这几个问题，我们吵到深夜两点。前言前言2018 年开源是否晚了？是否要做？如何定位和打造竞争力？相比当时比较流行的竞品，我们确实开源晚了些，但是相比于整个行业其实不晚，因为当时云原生和微服务整个普及度还很低；还有我主管当时还强调两个点，第个点是我们当时是个闭源的个软件，经常有业务方跳出来说你看 Eureka 多好，你们哪里哪里不行，如果我们不开源去打打，怎么更好的证明我们更好，还有个点是当时我们有商业化产品的，虽然我们知道我们更好，但是奈何用户选择的是 Eureka，我们只能兼容，而且我们不出去，不成为默认标准，不知道未来还要被迫兼容更多不如我们的产品，这对我们来说是个灾难。因此我们决定开源。迎面而来的是第二个问题，开源的定位和竞争力是什么？内部三个产品的开源策略是什么？由于当时 Spring-cloud 的崛起，微服务多个模块逐步被划分，包括注册中心、配置中心，如果从产品定位上，期望定位简单清晰，利于传播，我们需要分别开源我们内部产品，这样又会分散我们品牌和运营资源。另外大部分客户没有阿里这么大的体量，模块拆分过细，部署和运维成本都会成倍上涨，而且阿里巴巴也是从最早个产品逐步演化成 3 个产品的，因此我们最终决定将内部三个产品合并统开源。定位为：个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。由于我们在阿里内部发展了 10 年，在易用、规模、实时、稳定沉淀了核心竞争力，围绕阿里Dubbo 和 Spring-cloud-alibaba 生态进行推广，建立阿里 DNS（Dubbo+Nacos+Spring-cloud-alibaba/Seata/Sentinel）微服务最佳实践。随着我们选择三合的开源模式，又面临另外个问题，未来内部和商业化关系是什么，代码关系是什么？这个问题应该说直持续，但是我们定下来开源、自研、商业化三位体的战略，以开源为内核，以商业化为扩展；开源做生态，商业化做企业级特性，阿里内部做性能和高可用；开源做组件，商业化做解决方案；并且随着时间推移，基本按照这思路完成的正循环，全面系统的打造了 Nacos 各个维度的能力。前言简介简介Nacos 简介NacosNacos 起源起源Nacos 在阿里巴巴起源于 2008 年五彩石项目（完成微服务拆分和业务中台建设），成长于十年双十的洪峰考验，沉淀了简单易用、稳定可靠、性能卓越的核心竞争力。随着云计算兴起，2018年我们深刻感受到开源软件行业的影响，因此决定将 Nacos（阿里内部 Configserver/Diamond/Vipserver 内核）开源，输出阿里十年的沉淀，推动微服务行业发展，加速企业数字化转型！简介简介NacosNacos 生态生态Nacos 几乎支持所有主流语言，其中 Java/Golang/Python 已经支持 Nacos 2.0 长链接协议，能最大限度发挥 Nacos 性能。阿里微服务 DNS（Dubbo+Nacos+Spring-cloud-alibaba/Seata/Sentinel）最佳实践，是 Java 微服务生态最佳解决方案；除此之外，Nacos 也对微服务生态活跃的技术做了无缝的支持，如目前比较流行的 Envoy、Dapr 等，能让用户更加标准获取微服务能力。生态仓库：https:/ 发展发展&规划规划2018 年当我们决定做开源的时候，从 0.X 开始核心是把阿里内部的能力抽象好内核，然后逐步开放出去，在这个阶段虎牙作为 Nacos 最早用户开始使用，解决直播行业迅速发展的规模和高可用等问题，然后 Nacos 在视频和直播行业广泛使用。2019 年当我们开放核心能力和竞争力之后，就开始与 Dubbo/Spring-cloud-alibaba 生态完成集成，随着云原生的大势迅速被互联网行业使用。与此同时我们完成了多语言生态和服务网格生态的布局。2020 年 Nacos 迅速被成千上万家企业采用，并构建起强大的生态。但是随着用户深入使用，逐渐暴露些性能问题，因此我们启动了 Nacos 2.0 的隔代产品设计，凭借 10 倍性能提升激发社区简介Nacos 架构Nacos 架构Nacos 总体设计Nacos 架构Nacos 开源之前在阿里内部已经发展了十年，沉淀了很多优秀的能力，也有很多历史负担，在开源的时候我们取其精华进行开源，为了提升代码的健壮性和扩展性，进行了充分的分层和模块化设计。设计原则设计原则极简原则，简单才好用，简单才稳定，简单才易协作。架构致性，套架构要能适应开源、内部、商业化（公有云及专有云）3 个场景。扩展性，以开源为内核，商业化做基础，充分扩展，方便用户扩展。模块化，将通用部分抽象下沉，提升代码复用和健壮性。长期主义，不是要个能支撑未来 3 年的架构，而是要能够支撑 10 年的架构。开放性，设计和讨论保持社区互动和透明，方便大家协作。架构图架构图整体架构分为用户层、业务层、内核层和插件，用户层主要解决用户使用的易用性问题，业务层主要解决服务发现和配置管理的功能问题，内核层解决分布式系统致性、存储、高可用等核心问题，插件解决扩展性问题。Nacos 架构Nacos 架构内核层内核层插件机制：实现三个模块可分可合能力，实现扩展点 SPI 机制，用于扩展自己公司定制。事件机制：实现异步化事件通知，SDK 数据变化异步通知等逻辑，是 Nacos 高性能的关键部分。日志模块：管理日志分类，日志级别，日志可移植性（尤其避免冲突），日志格式，异常码+帮助文档。回调机制：SDK 通知数据，通过统的模式回调用户处理。接口和数据结构需要具备可扩展性。寻址模式：解决 Server IP 直连，域名访问，Nameserver 寻址、广播等多种寻址模式，需要可扩展。推送通道：解决 Server 与存储、Server 间、Server 与 SDK 间高效通信问题。容量管理：管理每个租户，分组下的容量，防止存储被写爆，影响服务可用性。流量管理：按照租户，分组等多个维度对请求频率，长链接个数，报文大小，请求流控进行控制。缓存机制：容灾目录，本地缓存，Server 缓存机制，是 Nacos 高可用的关键。启动模式：按照单机模式，配置模式，服务模式，DNS 模式模式，启动不同的模块。致性协议：解决不同数据，不同致性要求情况下，不同致性要求，是 Nacos 做到 AP 协议的关键。存储模块：解决数据持久化、非持久化存储，解决数据分片问题。插件插件Nameserver：解决 Namespace 到 ClusterID 的路由问题，解决用户环境与 Nacos 物理环境映射问题。CMDB：解决元数据存储，与三方 CMDB 系统对接问题，解决应用，人，资源关系。Metrics：暴露标准 Metrics 数据，方便与三方监控系统打通。Trace：暴露标准 Trace，方便与 SLA 系统打通，日志白平化，推送轨迹等能力，并且可以和计量计费系统打通。接入管理：相当于阿里云开通服务，分配身份、容量、权限过程。用户管理：解决用户管理，登录，SSO 等问题。权限管理：解决身份识别，访问控制，角色管理等问题。Nacos 架构Nacos 架构Nacos 配置模型背景背景在单体架构的时候我们可以将配置写在配置文件中，但有个缺点就是每次修改配置都需要重启服务才能生效。当应用程序实例比较少的时候还可以维护。如果转向微服务架构有成百上千个实例，每修改次配置要将全部实例重启，不仅增加了系统的不稳定性，也提高了维护的成本。那么如何能够做到服务不重启就可以修改配置？所有就产生了四个基础诉求：需要支持动态修改配置需要动态变更有多实时变更快了之后如何管控控制变更风险，如灰度、回滚等敏感配置如何做安全配置Nacos 架构Nacos 架构配置项（Configuration Item）个具体的可配置的参数与其值域，通常以 param-key=param-value 的形式存在。例如我们常配置系统的日志输出级别（logLevel=INFO|WARN|ERROR）就是个配置项。配置集（Configuration Set）组相关或者不相关的配置项的集合称为配置集。在系统中，个配置文件通常就是个配置集，包含了系统各个方面的配置。例如，个配置集可能包含了数据源、线程池、日志级别等配置项。命名空间（Namespace）用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之是不同环境的配置的区分隔离，例如开发测试环境和生产环境的资源（如数据库配置、限流阈值、降级开关）隔离等。如果在没有指定 Namespace 的情况下，默认使用 public 命名空间。配置组（Group）Nacos 中的组配置集，是配置的维度之。通过个有意义的字符串（如 ABTest 中的实验组、对照组）对配置集进行分组，从而区分 Data ID 相同的配置集。当您在 Nacos 上创建个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP。配置分组的常见场景：不同的应用或组件使用了相同的配置项，如 database_url 配置和 MQ_Topic 配置。配置 ID（Data ID）Nacos 中的某个配置集的 ID。配置集 ID 是划分配置的维度之。Data ID 通常用于划分系统的配置集。个系统或者应用可以包含多个配置集，每个配置集都可以被个有意义的名称标识。DataID 尽量保障全局唯，可以参考 Nacos Spring Cloud 中的命名规则：Nacos 架构Nacos 架构1.Nacos 提供可视化的控制台，可以对配置进行发布、更新、删除、灰度、版本管理等功能。2.SDK 可以提供发布配置、更新配置、监听配置等功能。3.SDK 通过 GRPC 长连接监听配置变更，Server 端对比 Client 端配置的 MD5 和本地 MD5是否相等，不相等推送配置变更。4.SDK 会保存配置的快照，当服务端出现问题的时候从本地获取。配置资源模型Namespace 的设计就是用来进行资源隔离的，我们在进行配置资源的时候可以从以下两个角度来看：从单个租户的角度来看，我们要配置多套环境的配置，可以根据不同的环境来创建 Namespace。比如开发环境、测试环境、线上环境，我们就创建对应的 Namespace（dev、test、prod），Nacos 会自动生成对应的 Namespace Id。如果同个环境内想配置相同的配置，可以通过Group 来区分。如下图所示：Nacos 架构Nacos 架构配置存储模型（ER 图）Nacos 存储配置有几个比较重要的表分别是:config_info 存储配置信息的主表，里面包含 dataId、groupId、content、tenantId、encryptedDataKey 等数据。config_info_beta 灰度测试的配置信息表，存储的内容和 config_info 基本相似。有个 beta_ips 字段用于客户端请求配置时判断是否是灰度的 ip。config_tags_relation 配置的标签表，在发布配置的时候如果指定了标签，那么会把标签和配置的关联信息存储在该表中。his_config_info 配置的历史信息表，在配置的发布、更新、删除等操作都会记录条数据，可以做多版本管理和快速回滚。Nacos 架构Nacos 架构因此，为了满足服务发现注册中心的可用性，强致性的共识算法这里就不太合适了，因为强致性共识算法能否对外提供服务是有要求的，如果当前集群可用的节点数没有过半的话，整个算法直接“罢工”，而最终致共识算法的话，更多保障服务的可用性，并且能够保证在定的时间内各个节点之间的数据能够达成致。上述的都是针对于 Nacos 服务发现注册中的非持久化服务而言（即需要客户端上报心跳进行服务实例续约）。而对于 Nacos 服务发现注册中的持久化服务，因为所有的数据都是直接使用调用 Nacos服务端直接创建，因此需要由 Nacos 保障数据在各个节点之间的强致性，故而针对此类型的服务数据，选择了强致性共识算法来保障数据的致性。从配置管理来看配置数据，是直接在 Nacos 服务端进行创建并进行管理的，必须保证大部分的节点都保存了此配置数据才能认为配置被成功保存了，否则就会丢失配置的变更，如果出现这种情况，问题是很严重的，如果是发布重要配置变更出现了丢失变更动作的情况，那多半就要引起严重的现网故障了，因此对于配置数据的管理，是必须要求集群中大部分的节点是强致的，而这里的话只能使用强致性共识算法。为什么是 Raft 和 Distro 呢对于强致性共识算法，当前工业生产中，最多使用的就是 Raft 协议，Raft 协议更容易让人理解，并且有很多成熟的工业算法实现，比如蚂蚁金服的 JRaft、Zookeeper 的 ZAB、Consul 的 Raft、百度的 braft、Apache Ratis；因为 Nacos 是 Java 技术栈，因此只能在 JRaft、ZAB、ApacheRatis 中选择，但是 ZAB 因为和 Zookeeper 强绑定，再加上希望可以和 Raft 算法库的支持团队随时沟通交流，因此选择了 JRaft，选择 JRaft 也是因为 JRaft 支持多 RaftGroup，为 Nacos 后面的多数据分片带来了可能。Nacos 架构Nacos 架构沉，使其成为 Core 模块的能力，彻底让服务注册发现模块只充当计算能力，同时为配置模块去外部数据库存储打下了架构基础。当前当前 NacosNacos 的致性协议层的致性协议层正如前面所说，在当前的 Nacos 内核中，我们已经做到了将致性协议的能力，完全下沉到了内核模块作为 Nacos 的核心能力，很好的服务于服务注册发现模块以及配置管理模块，我们来看看当前 Nacos 的架构。可以发现，在新的 Nacos 架构中，已经完成了将致性协议从原先的服务注册发现模块下沉到了内核模块当中，并且尽可能的提供了统的抽象接口，使得上层的服务注册发现模块以及配置管理Nacos 架构32模块，不再需要耦合任何致性语义，解耦抽象分层后，每个模块能快速演进，并且性能和可用性都大幅提升。NacosNacos 如何做到致性协议下沉的如何做到致性协议下沉的既然 Nacos 已经做到了将 AP、CP 协议下沉到了内核模块，而且尽可能的保持了样的使用体验。那么这个致性协议下沉，Nacos 是如何做到的呢？致性协议抽象其实，致性协议，就是用来保证数据致的，而数据的产生，必然有个写入的动作；同时还要能够读数据，并且保证读数据的动作以及得到的数据结果，并且能够得到致性协议的保障。因此，致性协议最最基础的两个方法，就是写动作和读动作public interface ConsistencyProtocol extends CommandOperations./*Obtain data according to the request.*param request request*return data link Response*throws Exception link Exception*/Response getData(ReadRequest request)throws Exception;/*33Nacos 架构*Data operation,returning submission results synchronously.*param request link com.alibaba.nacos.consistency.entity.WriteRequest*return submit operation result link Response*throws Exception link Exception*/Response write(WriteRequest request)throws Exception;.任何使用致性协议的，都只需要使用 getData 以及 write 方法即可。同时，致性协议已经被抽象在了 consistency 的包中，Nacos 对于 AP、CP 的致性协议接口使用抽象都在里面，并且在实现具体的致性协议时，采用了插件可插拔的形式，进步将致性协议具体实现逻辑和服务注册发现、配置管理两个模块达到解耦的目的。public class ProtocolManager extends MemberChangeListener implements DisposableBean.private void initAPProtocol()ApplicationUtils.getBeanIfExist(APProtocol.class,protocol-Class configType=ClassUtils.resolveGenericType(protocol.getClass();Config config=(Config)ApplicationUtils.getBean(configType);injectMembers4AP(config);protocol.init(config);ProtocolManager.this.apProtocol=protocol;);Nacos 架构 Class configType=ClassUtils.resolveGenericType(protocol.getClass();Config config=(Config)ApplicationUtils.getBean(configType);injectMembers4CP(config);protocol.init(config);ProtocolManager.this.cpProtocol=protocol;);.其实，仅做完致性协议抽象是不够的，如果只做到这里，那么服务注册发现以及配置管理，还是需要依赖致性协议的接口，在两个计算模块中耦合了带状态的接口；并且，虽然做了比较高度的致性协议抽象，服务模块以及配置模块却依然还是要在自己的代码模块中去显示的处理致性协议的读写请求逻辑，以及需要自己去实现个对接致性协议的存储，这其实是不好的，服务发现以及配置模块，更多应该专注于数据的使用以及计算，而非数据怎么存储、怎么保障数据致性，数据存储以及多节点致的问题应该交由存储层来保证。为了进步降低致性协议出现在服务注册发现以及配置管理两个模块的频次以及尽可能让致性协议只在内核模块中感知，Nacos 这里又做了另份工作数据存储抽象。数据存储抽象正如前面所说，致性协议，就是用来保证数据致的，如果利用致性协议实现个存储，那么服务模块以及配置模块，就由原来的依赖致性协议接口转变为了依赖存储接口，而存储接口后面的具体实现，就比致性协议要丰富得多了，并且服务模块以及配置模块也无需为直接依赖致性协议而承担多余的编码工作（快照、状态机实现、数据同步）。使得这两个模块可以更加的专注自35Nacos 架构己的核心逻辑。对于数据抽象，这里仅以服务注册发现模块为例public interface KvStorage enum KvType/*Local file storage.*/File,/*Local memory storage.*/Memory,/*LSMTree storage.*/LSMTree,AP,CP,/获取个数据byte get(byte key)throws KvStorageException;/存入个数据void put(byte key,byte value)throws KvStorageException;Nacos 架构Nacos 架构同时，针对存储层，进步实现插件化的设计，对于中小公司且有运维成本要求的话，可以直接使用 Nacos 自带的内嵌分布式存储组件来部署套 Nacos 集群，而如果服务实例数据以及配置数据的量级很大的话，并且本身有套比较好的 Paas 层服务，那么完全可以复用已有的存储组件，实现 Nacos 的计算层与存储层彻底分离。Nacos 架构Nacos 架构在全量拉取操作完成之后，Nacos 的每台机器上都维护了当前的所有注册上来的非持久化实例数据。数据校验在 Distro 集群启动之后，各台机器之间会定期的发送心跳。心跳信息主要为各个机器上的所有数据的元信息（之所以使用元信息，是因为需要保证网络中数据传输的量级维持在个较低水平）。这种数据校验会以心跳的形式进行，即每台机器在固定时间间隔会向其他机器发起次数据校验请求。旦在数据校验过程中，某台机器发现其他机器上的数据与本地数据不致，则会发起次全量拉取请求，将数据补齐。写操作对于个已经启动完成的 Distro 集群，在次客户端发起写操作的流程中，当注册非持久化的实例的写请求打到某台 Nacos 服务器时，Distro 集群处理的流程图如下。Nacos 架构Nacos 架构这种机制保证了 Distro 协议可以作为种 AP 协议，对于读操作都进行及时的响应。在网络分区的情况下，对于所有的读操作也能够正常返回；当网络恢复时，各个 Distro 节点会把各数据分片的数据进行合并恢复。小结小结Distro 协议是 Nacos 对于临时实例数据开发的致性协议。其数据存储在缓存中，并且会在启动时进行全量数据同步，并定期进行数据校验。在 Distro 协议的设计思想下，每个 Distro 节点都可以接收到读写请求。所有的 Distro 协议的请求场景主要分为三种情况：1.当该节点接收到属于该节点负责的实例的写请求时，直接写入。2.当该节点接收到不属于该节点负责的实例的写请求时，将在集群内部路由，转发给对应的节点，从而完成读写。3.当该节点接收到任何读请求时，都直接在本机查询并返回（因为所有实例都被同步到了每台机器上）。Distro 协议作为 Nacos 的内嵌临时实例致性协议，保证了在分布式环境下每个节点上面的服务信息的状态都能够及时地通知其他节点，可以维持数十万量级服务实例的存储和致性。Nacos 架构Nacos 架构SDK 和 Server 之间客户端 SDK 需要感知服务节点列表，并按照某种策略选择其中个节点进行连接；底层连接断开时，需要进行切换 Server 进行重连。客户端基于当前可用的长链接进行配置的查询，发布，删除，监听，取消监听等配置领域的 RPC 语意接口通信。感知配置变更消息，需要将配置变更消息通知推送当前监听的客户端；网络不稳定时，客户端接收失败，需要支持重推，并告警。感知客户端连接断开事件，将连接注销，并且清空连接对应的上下文，比如监听信息上下文清理。Server 之间通信单个 Server 需要获取到集群的所有 Server 间的列表，并且为每个 Server 创建独立的长链接；连接断开时，需要进行重连，服务端列表发生变更时，需要创建新节点的长链接，销毁下线的节点长链接。Server 间需要进行数据同步，包括配置变更信息同步,当前连接数信息，系统负载信息同步，负载调节信息同步等。Nacos 架构Nacos 架构1.功能性诉求客户端连接生命周期实时感知能力，包括连接建立，连接断开事件。客户端调用服务端支持同步阻塞，异步 Future，异步 CallBack 三种模式。底层连接自动切换能力。响应服务端连接重置消息进行连接切换。选址/服务发现。服务端连接生命周期实时感知能力，包括连接建立，连接断开事件。服务端往客户端主动进行数据推送，需要客户端进行 Ack 返回以支持可靠推送,并且需要进行失败重试。服务端主动推送负载调节能力。2.性能要求性能方面，需要能够满足阿里的生产环境可用性要求，能够支持百万级的长链接规模及请求量和推送量，并且要保证足够稳定。3.负载均衡常见的负载均衡策略：随机，hash，轮询，权重，最小连接数，最快响应速度等短连接和长链接负载均衡的异同：在短连接中，因为连接快速建立销毁，“随机，hash，轮询，权重”四种方式大致能够保持整体是均衡的，服务端重启也不会影响整体均衡，其中“最小连接数，最快响应速度”是有状态的算法，因为数据延时容易造成堆积效应；长连接因为建立连接后，如果没有异常情况出现，连接会直保持，断连后需要重新选择个新的服务节点，当出现服务Nacos 架构Nacos 架构对高于平均值的节点进行数量调控，设置数量上限(临时和持久化)，并可指定服务节点进行切换。(未来终态版本)自动化管控方案：基于每个 server 间连接数及负载自动计算节点合理连接数，自动触发 reblance，自动削峰填谷。实现周期较长，比较依赖算法准确性。3.连接命周期心跳保活机制Nacos 架构Nacos 架构5.安全性支持基础的鉴权，数据加密能力。6.低成本多语实现在客户端层面要尽可能多的支持多语言，至少要支持个 Java 服务端连接通道，可以使用多个主流语言的客户端进行访问，并且要考虑各种语言实现的成本，双边交互上要考虑 thin sdk，降低多语言实现成本。7.开源社区文档，开源社区活跃度，使用用户数等，面向未来是否有足够的支持度。四、长链接选型对比grpcWebSockettbremote（阿里自研协议）Rsocketnettymina客户端通信sync支持支持支持支持无 rpc 语意 无 rpc 语意future支持不支持支持支持无 rpc 语意 无 rpc 语意callback结合 guava实现不支持支持支持(依赖 jdk 1.8+completableFuture）无 rpc 语意 无 rpc 语意服务端推送sync无 ack支持支持支持无 rpc 语意 无 rpc 语意future不支持支持支持支持无 rpc 语意 无 rpc 语意callback不支持支持支持支持无 rpc 语意 无 rpc 语意Nacos 架构93%支持支持GO支持不支持支持支持1.12+93%无无C+支持不支持支持支持14+60%（C+11 使用较多）无无C#支持不支持不支持支持无无Node.js支持不支持支持支持无无51Nacos 架构grpcWebSockettbremote（阿里自研协议）Rsocketnettymina多语言支持JS支持支持不支持支持无无Ruby支持不支持不支持支持无无Python支持不支持不支持支持3.6+96%无无Kotlin支持不支持不支持支持无无rust支持1.39+dart支持2.6其他Github Star/Issue最高 go 版本：11.9K/124 issue最高 java 版本：1.8/47issue备注服务端推送Ack 自建服务端支持多语言，客户端只能在浏览器中使用JS私有协议rsocket 私有协议，社区活跃度，用户数般需要自定义rpc 协议需要自定义rpc 协议在当前的备选框架中，从功能的契合度上，Rsocket 比较贴切我们的功能性诉求，性能上比 grpc要强些，开源社区的活跃度上相对 grpc 要逊色很多。版本分布参考：https:/ https:/ 架构Nacos 架构server 间致性Server 间同步消息接收处理轻量级实现，重试失败时，监控告警。断网：断网太久，重试任务队列爆满时，无剔除策略。2.服务致性模型Nacos 架构Nacos 架构六、核心模型组件设计Nacos 架构Nacos 架构*param memberManager link ServerMemberManager*/void injectMemberManager(ServerMemberManager memberManager);/*The addressing pattern finds cluster nodes.*param members link Collection*/void afterLookup(Collection members);/*Addressing mode closed.*throws NacosException NacosException*/void destroy()throws NacosException;（ServerMemberManager 存储着本节点所知道的所有成员节点列表信息，提供了针对成员节点的增删改查操作，同时维护了个 MemberLookup 列表，方便进行动态切换成员节点寻址方式。）可以看到，MemberLookup 接口非常简单，核心接口就两个 injectMemberManager 以及afterLookup，前者用于将 ServerMemberManager 注入到 MemberLookup 中，方便利用ServerMemberManager 的存储、查询能力，后者 afterLookup 则是个事件接口，当 MemberLookup 需要进行成员节点信息更新时，会将当前最新的成员节点列表信息通过该函数进行通知给ServerMemberManager，具体的节点管理方式，则是隐藏到具体的 MemberLookup 实现中。接着来介绍下当前 Nacos 内部实现的几种寻址机制。Nacos 架构Nacos 架构192.168.16.101:8847192.168.16.102192.168.16.103该文件默认只需要填写每个成员节点的 IP 信息即可，端口会自动选择 Nacos 的默认端口 8848，如过说有特殊需求更改了 Nacos 的端口信息，则需要在该文件将该节点的完整网路地址信息补充完整（IP:PORT）。当 Nacos 节点启动时，会读取该文件的内容，然后将文件内的 IP 解析为节点列表，调用 afterLookup 存入 ServerMemberManager。private void readClusterConfFromDisk()Collection tmpMembers=new ArrayList();try List tmp=ApplicationUtils.readClusterConf();tmpMembers=MemberUtils.readServerConf(tmp);catch(Throwa