开发者学堂课程【 Nacos 发展历程以及最佳实践： Nacos 发展历程以及最佳实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/7/detail/13
Nacos 发展历程以及最佳实践
内容介绍
一、课程规划
二、Nacos简介
三、注册配置中心最佳实践
四、总结和展望
一、课程规划
本课程从三部分进行介绍：
第一部分是Nacos介绍，主要进行Nacos的历史介绍，额外介绍社区发展状况，最后介绍Nacos生态发展情况。
第二部分是关于配置注册中心的领域的最佳实践的分享，当中包含Nacos使用方面的建议和Nacos用户可能接触到的场景，部分场景用户接触较少，会再次进行介绍。额外会介绍Nacos排查问题的最佳实践。
第三部分是Nacos后续的展望。当中会介绍Nacos3.0规划和参与开源建议。
二、Nacos 简介
官网如下：
https://nacos.io/
仓库如下：
https://github.com/alibaba/nacos
https://github.com/nacos-group
在发起Nacos开源项目时，团队考虑项目的名字。定义思考完成之后，希望寻找到特殊的名字，之后决定使用前缀，全称为动态的名字以及配置的服务，取开头为名。但按照以上逻辑取名，结果是dicos，是德克士的名字，所以之后考虑到真正的核心能力，希望强调的且希望将其简化掉的就是名字服务，Naming and configuration service。用首字母作为前缀，由此产生了Nacos。因为Nacos的产品和领域较少。
能够快速定位到产品，基于该点，在7月20号的凌晨同步发布了Nacos的源码以及官网，发布上线之后将信息同步到社区，有很大一部分人等待Nacos发布。发布完成之后，用户关注度和热情较高。对于Nacos来说，最重要的是使用的用户以及对Nacos的贡献者以及Nacos的核心成员，是Nacos发展到如今最重要的一笔财富。对于Nacos的仓库，主仓库分为两个，分别是Nacos在阿布里巴巴组下的主仓库，另一个是Nacos的group，是Nacos所有社区相关以及多语言、生态周边都在Nacos的group仓库下。Nacosgroup当中也有有帮助的信息，用户可以多关注。Nacos的主要功能是关于服务的注册与发现，配置管理，以及服务的管理平台。
服务发现以及配置管理是较为基础的能力，该能力在整个丰盛领域，微服务领域是较为重要的根基。Nacos的地面也较为基础。基于基础也进行了一些调研，最新的调研表示Nacos在微服务领域当中，国内的市场份的占有率是50%以上，占有率较高，被国内的企业广泛使用。
主仓库的基本数据：
对于Nacos的stop树，目前存在23000的树，但是stop树，并不是Nacos社区主要看中的。
Nacos社区主要看重贡献和活跃的指标，指标包括fog数以及核心贡献者数，核心贡献者数有240人左右。github最近的指标表示，由于只能选一个核心仓库当中的一个module，其中一个model有4000左右的引用。
该数据代表github上有四千多个项目是基于Nacos进行贡献开源的，该数据在横向对比当中，是较高的数据。对于Nacos的活跃度，在2020年时，有一份国内开源报告，报告当中表示Nacos的社会活跃度是全国第十，也就是国内所有的核心项目当中，Nacos的活跃度是第十。
2021年的报告当中，Nacos的活跃度已经提升至全国第六。在较为基础的产品当中，活跃度已经较高，得益于社区的用户的贡献。根据该活跃度，Nacos官网的UV，已经有将近160万
会话数不是PV，PV没有数据当中出现。PV数据大概是6,000万左右，在开元官网上已经非常高了。今年年初发布的《Nacos架构与原理》，现在在平台上的数据较小，因为许多人下载之后会互相分享，该方式较好传播，用户能够了解到，数据方面有6万阅读，2万下载。
在阿里云的藏金阁上的下载历史榜能够排到前十，由于只开放半年，该数据也相对较好。目前许多国内的企业也在使用Nacos，并且是Nacos的核心成员。例如阿里，腾讯，华为。
Nacos的生态发展：
对于Nacos的生态发展，Nacosgroup下是官方提供的，例如客户端，主流的客户端包括JAVA， golong，python ，c shop，c++，以及没有在官方当中，目前正在贡献的，例如ross，目前正在进行招募。在一些深度集成的社区，例如dubbo，sentinel，dapr， grpc，数据面上也有额外的集成。合作以及互相使用方面都较好。在生态发展方面，生态帮助Nacos完成了部分事情，例如场景上，适配上的部分要求，Nacos基于该要求和需求的能力，逐步成长。在该过程当中，Nacos通过成长帮助了更多的产品和业务场景，获得了使用。
三、注册配置中心最佳实践
该部分是本课程的重要场景。
第一部分首先讲解Nacos的版本，Nacos目前主推版本是Nacos2.0以上。该版本是Nacos最新发布的版本。Nacos第一代，也就是1.x版本，已经有一段时间，Nacos的2.x版本，已经发布到2.1.0了，是Nacos目前发布的最新版本。基于Nacos的历史上的原因，所以进行了从Nacos1.0升级到2.0的场景。同时也收集了1.0的用户的需求进行设计，当中最佳实践的建议是需要升级服务端和客户端至2.0以上。2.0以上是根据1.0的用户需求进行的设计的更符合用户使用习惯的场景。一方面升级了一致性的算法协议。另一方面支持长链接，额外支持插件化，在性能方面整体上相对于1.0的模式，提升了十倍，数量较大。主要在于根据1.0当中用户使用的场景以及需求进行了优化，得知了用户最常用的使用方向，最重要的一点在于Nacos2.x的客户端，只能连接Nacos2.x的服务端。但是Nacos2。x的服务端可以支持1.x的客户端。对于较早的客户端版本，也就是1.x的版本，在Nacos的服务端升级过程当中也兼容。所以不必在意客户端的兼容性，客户端可以慢慢升级，但是在服务端升级过程当中，重点需要放在服务端升级过程当中的兼容性即可。
细节介绍：
例如为什么要向2.x上进行升级，2.x大版本上针对于稳定性以及高可用以及性能上都进行了较高的保障。对于保障具体的点在于升级成了长链接，用长链接代替短链接。短链接的模式是应用，但是在短链接场景当中消耗较大。针对于该部分，长链接是在阿里巴巴内部使用了大概十年左右的模式，针对于场景当中较为合适。其次，对于distro协议，是Nacos独有的协议。该协议在升级时复用了阿里巴巴当中的最佳实践，针对于用户当前的场景，能够得知具体使用哪个模式。该场景符合用户使用，另一方面在于是阿里巴巴长时间的沉淀的协议。该协议复用了阿里巴巴内部使用的注册中心： kafixo 模式。通过推送机制代替了轮训机制，推送机制和轮训机制在开源领域有许多场景当中都有针对于比较和使用，性能方面，通过信息传输实时性上进行考虑，推送去完胜轮训机制。因为轮训机制带来的代价以及在过程当中的损耗高于推送机制。但轮训机制当中也存在一个模式，也就是长轮训模式，该模式的代价相对于较少，长轮训与推送机制比较，长轮训的模式也是一种模拟实现的推送机制，让用户更快感知数据的变化以及传递。在该过程当中，整体设计了更适合Naming 和config的数据模型。该模型在于之前部分场景当中，比如AP和CP应该如何进行考虑，针对该问题，社区当中也发布过文章，目前也有较大多数人正在讨论，也有用户进行反馈如果AP和CP都具有，会产生不平衡。
但逻辑上并不是，因为经常会研究移植性的事物，逻辑上Cap模式的确存在该场景，但是在真正的使用场景当中，应该对其进行选择。但是在Nacos当中使用的场景不同，例如复发性模块以及配置模块进行了细分。在AP场景上，做整体的服务注册与发现，能保证主电路的功能。在CP场景上能够保证存储模块，包含索引和原数据，更好的区分了数据的存储，更适合业务场景的方式。该方式从使用角度上来说，最能够保障用户的高可用场景。重点在于Nacos2.x版本，目前也是Nacos的最佳实践，许多能力和增量的特性都是在Nacos2.x当中构建，最新版本是2.1.0，建议升级2.0.4。sql端1.x版本可以平滑地升到2.0.4版本，如果是2.1.0版本，默认不兼容sql端的升级。对于sql端原地升级，如果是生产环境的升级，可以先升级到2.0.4版本，该版本是2.x版本当中较新的版本。如果想提升到2.1.0版本，存在一个开关，可以将该开关开启，建议先升级到2.0.4版本，之后再逐步升级到2.1.0。对于2. x版本已经较为稳定。以上是稳定性，高可用和高性能的保障。
Nacos2.0版本当中有许多丰富的功能，这些丰富的功能有很大一部分是应用方面的。控制层面上的功能，暂时不做讲解。首先讲解插件化带来的周边能力的增强。
插件化是Nacos2.x版本当中较为重要的一个功能。因为用户如果使用Nacos，有许多场景需要和内部系统进行整合，整合就需要一些定制能力。
插件化很好的解决了用户定制自己的功能的场景。针对于插件化，每个插件会给予默认的实践。插件化支持了健全体系，支持配置数据的加密和解密。通过加密和解密例子讲解插件化的实现。如图所示：
在运行时当中，Nacos通过sdk访问sql端，例如需要写配置，变更配置，推送配置，也就是接收该配置的变更。在该过程当中，加密解密部分存在加密解密的执行器，执行器执行加密和解密以及规则的解析。加密和解密的细节当中，通过了前格匹配，设置加密的算法类型。
通过该识别，进行到插件化模块。插件化进行插件的管理器，自动识别默认的现在加载的插件是什么，通过用户放入的插件就可以执行加密和解密。当中，社区默认支持 aes加密方式，加密方式用户也可以自定义。在生成密钥的时候，也可以使用kms，也就是阿里云的云服务，也可以不需要使用该方式，默认使用社区支持的加密方式，或者自己继承，以上过程就是插件化的流程。因为插件化涉及到客户端和服务端，都可以通过以上配置进行。之后还会发布一些插件化，例如消息通知以及trace的事件中心都会设置为插件化。每个公司还会存在自己的安全小组。因为需要实现自己公司的安全拦截，或是在于存储方面，部分用户提出不想存储在mysql上，对于配置中心的配置，希望存储到其他地方，以上需求都能够通过插件化实现。以上就是2.x版本在高可用、性能方面丰富的部分功能，在高版本当中进行了实现，能够帮助用户获取到更多的能力。建议用户升级到2.x版本。客户端1.x版本在2.x版本上的场景也支持，需要保证好sql的状态是ready的。许多用户反馈的问题集中在Nacos的集群配置方面。配置当中存在class. Config，该配置文件需要保证其集群内都是一致的，有许多用户在该方面检查的不够好，或是在写入存储方面有问题，导致了在场景上升级时会存在问题，即使重启，集群也会存在不稳定场景。以上是版本部分的讲解。
Nacos适用场景举例：
对于场景举例，在本讲解课程当中已经介绍了较大部分适用的场景，用户接触到的较大的部分主要是在微服务领域，包括spring生态，dubbo生态、mesh生态模式进行继承， spring生态包含spring、spring boot、spring cloud。Nacos常见的使用包含了服务上的服务注册，发现以及服务的管理，以及加密解密等场景，以上是较为常见的场景。部分高阶能力是基于Nacos在高可用领域当中的使用，例如阿里巴巴的异地多活，同城双活，也就是应用级别的容灾，容灾分为三个级别，应用级别是最高层的级别容灾。该场景是高可用的能力的使用，当中包含了流量防控、开关以及预案。以上场景都是Nacos用户可以使用或简单进行适配就可以在业务上使用的场景。也有许多是在前端生态上使用的场景，例如动态分发的场景，进行配置，文案的场景都可以通过配置做状态的改变。对于数据库领域，阿里内部也有各种各样的场景，例如分布式数据库，但是分布式数据库有许多类型的实践，对于当中的细节，例如容灾、分库分表，在Nacos的知识体系下有许多使用案例。以上领域都是较为常见用户可以进行使用的。额外还有许多场景可以进行使用，因为针对于服务发现以及配置管理，是在分布式里域当中最基础的能力，在分布式当中分为多个节点，节点和节点之间必须产生关系或产生调用。其中就必须有服务的注册和发现，是基本能力。分布式的节点有很多，每个节点都需要进行管理。在管理当中，运行时做管理就是状态的转变，当中就涉及必须进行分布式的配置管理。以上两个功能是最基础的功能，可以基于以上功能，在公司内部的场景进行延伸。
注册配置中心问题定位：
注册配置中心也是一个领域，因为其他产品也有配置中心和注册中心。目前讲解的主要是在于通用的场景当中应该如何解决。注册中心就是复发性，配置中心就是做分布式的配置管理。架构图如下：
在运行时当中，最佳实践会存在统一的云原生网关，之后是业务层的调用，业务层调用包含分布式节点的发行注册、发现以及配置的管理，还包括管控平台的使用。注册、配置中心是一个较为重要的节点，因为在分布式场景当中，如果注册、配置中心出现问题，就是大问题。要快速定位问题时，就需要定位注册、配置中心是否有问题。其次在于业务场景上是否存在问题，可以帮助业务去解决问题。例如在定位时，进行服务发现，服务发现的节点是否推送到各个分布式节点上，配置变更是否成功配置是否下发成功，配置是否推送成功，以上场景都是快速诊断的能力。
快速诊断问题定位：
注册中心方面，例如服务调用中断会先判断地址是否同步，作为consumer需要获取地址，地址是否获取正确，影响到业务流量。在注册中心当中，如果是推送模式，就需要查看推送的情况。推送情况在Nacos当中，可以通过日志进行查看。Nacos目前开源，也正在进行事件中心的研究。阿里云的msc云产品上提供了Nacos的推送轨迹能力，当中需要的信息在于一个服务最新更新的数据是否被consumer接收到，需要如上推送记录。记录当中的关键信息包含时间、对象，也就是客户端IP、推送节点的IP、推送的实例数以及节点的名称，对于以上情况，msc当中有最佳实践，用户可以在阿里云的msc上进行试用。场景当中可以定位到服务发现链路当中是否有推送节点，推送了几个实例，通过以上就能够推断是否与注册中心有关系。再看业务层获取到的地址、调用的场景是否有问题，以上就是注册中心场景上定位的最方便的方式。
对于配置中心的场景：
配置中心首先需要保证配置是否触及客户端，客户端是否成功收取到配置，以上是最首要定位问题时需要进行判断的。该判断也是通过msc当中的推送轨迹的功能进行说明。在开元侧，通过日志当中也能够查看，另一方面开源上也在贡献trace的模块，可以进行定位。查询时可以询配置的变更事件。变更事件当中有两部分信息：一部分信息是配置是何时变更，变更的时间点，另一部分是此次变更推送了哪些IP，也就是此次变更有哪些IP获取到了该数据。以上是查询数据的一个维度，额外也可以通过consumer，也就是订阅配置的IP，查询具体获取过哪些配置，以及配置的具体的MD5值，以上也能够追踪到配置是否下发成功，达到客户端。通过以上方式就能够做到配置的全生命周期的可回溯。包含配置写入成功配置的推送轨迹、配置的历史版本查询，能够判断配置是何时做变更，变更触及到哪一些客户，之前有哪些变更，以上就是原始的数据，能够帮助用户快速定位到具体的问题的方式，也就是配置中心的问题定位。注册中心以及配置中心，在用户侧来看，出问题最大的就是Consumer端口，也就是订阅数据的一端。订阅数据的一端否能够获取正确的数据，是用户在排查注册配置中心问题当中最首要的一点，判断完成之后就可以判断到底是哪方面的问题，基于以上线索，继续进行排查。
四、总结和展望
总结和展望包含Nacos3.0的展望以及部分建议：
Nacos3.0规划已经有一段时间，Nacos的核心成员讨论了Nacos3.0建设的方向，针对于Nacos3.0的建设大方向如下：
1. 开源品牌升级
开源品牌升级包含官网的升级，因为官网承载的访问量已经较高，目前历史的总UA已经达到将近160万，会进行官网的升级，也包含了官网内容上的升级。有许多场景，不仅是微服务场景，但面相的事物都是共通的，会扩大以上领域。其次是面向用户，之后会触及更多更广的用户，是较为重要的一个方向。接下来是涉及社区的反馈机制。目前的反馈机制上是正常运行的，但是时效性无法达到许多用户的要求，但是开源的时效性较难保障，所以针对于3.0的建设机制上考虑社区进行反馈优先级，将高优先级的场景，从用户侧往社区侧进行传达。之后是面向用户的需求进行加固设计，是最根源的部分。在书写《Nacos架构语言》时，讲述过Nacos3.0是面向于Nacos的第三阶段。第三阶段是Nacos向基础设施上沉淀的阶段。该阶段上建设的重点方向在于稳定性，对于稳定性方面加强建设投入。
2. 更多生态融合
3. 面向更多生态融合，也是Nacos3.0当中较为重要的阶段。
第一部分是关于用户xds协议，需要做深度融合Nacos目前支持xds协议，但是要将其融合进行到更深度的状态。目前支持mcp，Nacos一直是mcp优先支持的产品，包含jrbc生态，模式的支持的word生态都能够进行更好的兼容。其次是面向统一控制面，Nacos针对于统一控制面，有许多事物需要完善，会丰富数据面，该部分工作也在进行。接下来是面向K8S生态，会将数据融合打通。目前已经正在着手，对该部分进行调研。包含Nacos的应用性，K8S的数据体系，将以上两个体系融合，能够帮助用户基于之后的容器化更方便的使用Nacos以及进行微服务和分布式的应用。接下来是多环境以及多生态的数据打通，在该模式当中，初步存在Nacossink，在该方面会进行更多融合，将数据模式打通。额外在可观测能力生态方面进行增强，是之后的重点方向。
质量体系计划面向全流程或全生态，包含客户端的能力升级以及质量管理的升级。
4. 产品能力升级
最基础的部分是Nacos3.0产品能力的升级，第一点是移植性协议，在3.0当中也会进行升级。统一控制面是一个面向方向，能让用户在更少的平台进行更多的面向用户场景的业务。接下来就是存储计算分离也会在3.0当中进行考虑，该部分更面向于Nacos需要承载的容量，在社区建立体系之后会根据优先级发布。之后是分布式云的多数据中心的场景，也是Nacos在多数据中心模块当中需要进行考虑的。接下来就是插件化，目前2.0已经支持插件化。在3.0当中将插件化生态做强。将更多模式让用户定制，用户使用Nacos时，许多公司会有成熟的生态，或刚起步的可以使用默认生态。以上两种用户场景，最好的支持方式就是通过插件化接入，该方面之后会进行增强，在质量保证体系上，会进行升级。Nacos3.0的整体规划会通过issue的形式，放出任务，该任务会通过Nacos3.0标签标识。用户可以通过在社区中关注标签关注该任务，以上是Nacos3.0社区建设的规划。
建议参与开源社区的方式，主要面向于刚开始接入开源的用户。用户主要分为三阶段进行考虑，有时间的情况下可以参与开源。参与开源可以通过以下四方面：
第一方面是找到真正感兴趣的方向，感兴趣就能够持续沉淀该方向的能力。例如数据库，大数据，存储计算等等。以上都是一个方向，找到方向之后持续沉淀能力。找到方向，一方面是自己的兴趣，另一方面能够将自身价值放大。价值放大，包括社区活跃度，使用的场景，业务应用的场景，为社区贡献之后代码具体能够让多少人使用，一条主线就能够看出价值具体能够被放大到多大。不同的产品。是不一样的，可能与该产品的发展相关。
找到方向之后，更重要的点就是熟悉产品。开始熟悉产品当中的细节，熟悉开源产品的社区运营机制是怎样的，产品对应的领域，面向领域当中的背景可以在该步骤当中熟悉。例如数据库就是解决存储，索引以及成本的场景考虑。不同的产品有不同的考虑的背景，背景是产品要向下演进的方向。顺着一个开源产品就可以熟悉一个领域。第三部分是贡献开源，熟悉产品之后就可以开始着手贡献，就是从小问题入手，例如回答社区当中刚才过的坑我刚知道哪些地方不完善，需要进行补充。在熟悉产品时，已经了解了社区的机制。可以按照该机制贡献开源，接下来就是从小入手，在该阶段多帮助其他人解决问题。在循环过程当中逐步从刚开始的贡献者逐步成为第四阶段，也就是成为开源社区的核心。可以开始主导开源社区的模块，成为该核心的决策者。一方面能够帮助更多人解决该领域的问题，另一方面能够吸引用户持续贡献当前产品，通过该产品更多反馈社会。从以上四方向，伴随的方向就是找到一个产品，随着产品一起成长，成长到核心地位。做到三方面，一方面是个人的成长，包含代码、领域的熟悉。另一方面是开源的成长，产品随着用户的贡献不停长大，不停的进行产品能力的提成。第三方面是在该过程当中，面向该领域为社会做了贡献，例如企业由于在该领域的贡献变得更好，并且更容易解决该领域的问题。以上就是较为通用的场景。如果还没有再进行开源，建议开始贡献开源，让个人得到成长。基于该领域当中，拉普斯是一个较为合适的选择，对于配置中心，注册中心领域，较好的点在于是一个方式的基础，额外是一个原生领域的核心模块。
选择的过程当中，Nacos的社区活跃度也较好，在国内的使用范围较广在使用调研上，有50%的企业在微服务场景当中使用。Nacos当中有官网信息，可以帮助入门。也存在Nacos的电子书，可以免费下载。Nacos的机制也是成熟的。
在贡献方面，可以先通过issues进行搜索解决较为简单的问题，再逐步解决更难的问题。在该过程当中可以总结沉淀，帮助他人。成为核心就开始主导社区的模块，例如一个多语言的模块或是协议上的模块或是功能上的模块。都能够在该阶段进行主导，然后开始组建贡献小组，作为社区的核心人员，在线上线下进行分享，社区也有较多机会，开放给用户。
以上是参与开源的方式建议。看到不同领域解决的问题时，才会得知自己感兴趣的内容是什么。建议用户能够多了解社区活动。
