Skip to main content

· 18 min read

Nacos 是什么?

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service的首字母简称,定位于一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。从 2018 年 7 月开始宣布开源以来,已经走过了第四个年头,在这四年里,备受广大开源用户欢迎,共收获23.3K的star数,10.3K的Fork数,在开源中国发布的 2021 年度 OSC 中国开源项目评选中,Nacos 被评为云原生领域人气指数 Top5 的项目,发布电子书《Nacos 架构与原理》6w+阅读,2w下载量,发布半年的时间里在阿里云藏经阁历史下载榜前十。Nacos 在社区共同的建设下不断成长,逐步的开始帮助用户解决实际问题,助力企业数字化转型,目前已经广泛的使用在国内的公司中,根据微服务领域调查问卷,Nacos 在注册配置中心领域已经成为国内首选,占有50%+国内市场份额,被头部企业广泛使用!

《2022中国开源发展蓝皮书》由中国开源软件推进联盟(COPU)牵头,联合中国开发者网络(CSDN)、北京开源创新委员会、开放原子开源基金会、中国电子信息产业发展研究院、中科院软件研究所等 85 家企业及行业机构、120 多位开源专家和志愿者共同协作编撰完成,旨在全面展现当前中国开源发展的全景图,为国家政府相关管理部门、科研院所、科技企业以及开源从业者提供更多的理论参考和数据支撑,进一步助力我国开源生态的蓬勃发展。

根据最近刚发布的《2022中国开源发展蓝皮书》报告中 Github中国项目活跃度TOP 20Nacos 排名全国第六,作为基础类型云原生中间件,能有如此活跃度是非常不容易的,在上一年度《2021中国开源发展蓝皮书》中,Nacos 排名全国第十,也表现 Nacos 不仅仅维持高的项目活跃度,而且项目关注度和活跃度还在逐步提高。

image.png image.png 同时阿里巴巴在国内企业中开源影响力排行第一,在《2022中国开源发展蓝皮书》中介绍:“阿里巴巴是国内参与开源技术生态建设的企业典范。自2011年至今,阿里累计开源项目超过3000个,代表性的项目包括龙蜥操作系统、Apache RocketMQ、Apache Dubbo、Spring Cloud Alibaba、 Nacos、Seata、PolarDB-X、PolarDB for PostgreSQL等”。 Nacos 是阿里巴巴微服务领域开源你项目活跃度排行第一,也得益于开源协作模式,并且在Nacos中有大量国内外知名公司的核心贡献者,其中也包含就职在腾讯、华为、小米等等知名企业的同学,也正是社区整体的贡献者和用户在帮助 Nacos 成长,让 Nacos 逐步完善生态,支持几乎所有主流语言,整合更多开源生态,也正是用户和社区贡献者让Nacos为企业数字化转型首选产品。

image.png

Nacos 使用上的3点重要建议

Nacos 版本选择

Nacos 经过4年的发展,目前在大版本演进上已经到了第二代 Nacos 架构,即 Nacos 2.x 版本,Nacos 2.x 版本是基于 Nacos 1.x 中用户反馈使用习惯以及产品演进方向而构建的产品能力,中间包含了比如一致性算法升级,对性能的 10 倍提升,以及支持插件化来满足社区的定制诉求。并且保障了很好的兼容性,在服务能力上 Nacos 2.x 是完全兼容 Nacos 1.x 的协议,也就是 Nacos 2.x 服务端是完全兼容Nacos 1.x的客户端。 image.png

在基本能力上,Nacos 2.x 一致性协议复用了阿里在该领域最佳实践,以长连接为基础,减低通信损耗,基于Distro协议原有协议进行升级,在存储模型、保活模型上进行了重构,并且用推送机制代替了之前的轮训机制,进一步提升了产品的高可用以及稳定性,整体也复用了阿里百万实例的基础模型,在CAP理论基础上,根据场景来去选择最适合的协议,贴合场景来平衡一致性、高可用以及分区容灾,做到服务发现以及配置管理每个场景下,都做到稳定性、高可用、高性能的保障。

image.png 在拓展能力上,Nacos 2.x版本开始支持插件化能力,基于插件化是更方便的支持用户各种场景,很多用户公司内部有完善的体系基于Nacos可以简单的改造就可以融合进入,在鉴权、配置加解密场景都可以做到按照用户需求进行定制,并且给出默认的开源实现供用户选择,加解密为例,开源给出的默认实现是基于AES,用户也可以进行自定义。并且目前数据库的插件已经在路上,后续还会在安全等更多方面支持可插拔的插件化能力。 image.png

Nacos 支持还能支持那些场景

Nacos基本核心能力是面向于整体分布式的服务注册与发现,以及分布式节点配置管理,使用领域可以说是非常广泛的,比较常用的包含,微服务领域、高可用领域、内容领域以及数据库领域等,目前在微服务领域Nacos基本能力使用最广,微服务领域定位在一站式解决了用户应用的寻址、流量、配置场景服务平台,在高可用领域Nacos积累了大量的经验,可以实现大量降级、容灾、多活的高可用场景,也可以支持内容分发以及数据库分库分表、主备切换等场景的基础能力,可以说分布式的场景下,基本都可以跟Nacos进行构建,也帮助业务后续拓展留足了准备。 image.png

Nacos 排查问题最佳实践

注册配置中心在分布式节点交互中起着重要的作用,在业务分布式场景出现问题的时候需要快速进行诊断,判断是否是注册配置中心出现了问题,还是业务层的问题。

image.png 在注册中心中,服务发现是业务排查问题第一优先级需要定位的,服务发现具体对应的就是服务地址数据是否同步到了业务节点上,那在Nacos场景上,推送记录就是最关键的一个特性能力,这部分能力可以通过Nacos日志查询到,目前Nacos社区已经开始计划设计事件中心来支撑这部分能力,为了更好的演示,这里也通过阿里云微服务引擎MSE展现一下白屏化的推送轨迹能力,用户可以通过服务名称或者客户端IP,进行查询变更的时间以及变更的内容,就可以快速明确当前注册中心是否存在问题,并且能帮住业务进一步定位具体原因。 image.png 在配置中心链路,同样存在第一时间定位的问题,这里也通过阿里云微服务引擎MSE的最佳实践,推送轨迹能力展现排查的思路,可以通过配置名称或者订阅者客户端IP进行查询配置的变更时间,以及推送时间,以及推送内容MD5值进行匹配。 image.png 并且在分布式配置管理领域,通过补全推送轨迹能力,加上已经支持的历史版本查询能力,可以帮助业务全流程的观测配置的生命周期。 image.png 关于注册配置中心排查问题的思路上,总结是两个重点,一是数据变更确认,二是快速确定关系并且进行恢复。大多数场景如果是业务变更引起的,一定要第一时间进行回顾变更,避免给业务带来问题。在稳定性要求比较高的领域,建议业务体系上面向1-5-10(故障1分钟发现,5分钟上线处理,10分钟恢复)建设稳定性,这部分也是比较通用的能力建设,这里就不进行详细拓展,后续有机会可以单独聊一下。

Nacos 规划

Nacos 已经经历了两个重要阶段,初创期和高速发展期,目前正处于被大规模使用的 Nacos 的第三阶段是成为基础设施,需要面向于基础设施进行演进,帮助企业数字化转型,深度的拥抱各个领域内的场景,并且更深度的帮助企业解决问题。Nacos 社区目前面向于第三阶段,开始筹备 Nacos 3.0 架构设计进行规划讨论,并且逐步开始进行落地。 目前针对 Nacos 3.0 的建设规划大图主要包含三部分,第一部分是开源品牌和社区的升级,主要是面向于社区建立更紧密的联系。第二部分是面向更多生态进行深度融合,包含K8S数据整合、以及多生态数据打通,第三部分是最基础的部分,产品能力升级,基于 Nacos2.x 的协议进行增强,并且支持统一控制面、多数据中心等基础能力,用于支撑 Nacos 3.0 生态建设以及品牌升级。 目前 Nacos 3.0 部分已经随着社区核心贡献者开展中,大多数还在规划阶段,后续会通过Github issues进行开放,随之会打上Nacos 3.0的标签,欢迎大家进行领取一起参与到Nacos 3.0的贡献。 image.png

参与开源建议

最后部分整合我个人意见,向没有参与过开源的同学给出一些参与开源的建议,首先我认为开源对于开发者以及社区贡献都是非常有益的,如果你有时间并且也想参与开源,那我建议你从以下四个步骤进行深入: 第一步找到自己感兴趣的方向,这个点比较重要,会影响你后续贡献的持久程度,当然这个也是在逐步摸索中的,不过如果对于方向确认好后,应对的产品列表选择就会比较明朗了,在这个步骤考虑兴趣是我首要建议的,其次我建议,也可以考虑当前项目一些详细信息,重点考虑是否能帮助个人把价值的放大,使用范围越广的项目就越能让你的贡献在社会价值放大,也正向会提高成就感。 第二步是熟悉项目和产品,找到了方向和项目之后,就可以开始着手熟悉当前产品的细节,熟悉当前项目的运营机制,以及面向于产品开始接触对应领域问题,领域问题最后会沉淀成为你对这个领域的经验。 第三步其实就可以贡献开源了,这一个步骤其实面向于前两步骤是可以适当提前并行做,关键是从小问题入手做起,这样可以帮助你在前两个步骤中更快的找到感觉,也能从小问题开始帮助他人,在社区中建立个人影响力。 第四步其实是水到渠成的,面向于活跃的社区,当你足够熟悉该领域该产品之后,有了足够的贡献,就会在开源中逐步主导社区的决策,也能在社区中帮助更多的人发展共建。 image.png 上边是对个人贡献开源产品流程建议,适用于大多数开源项目的贡献。额外在开源上我觉得Nacos是不错的选择,首先产品定位是比较基础,能帮助开发者沉淀更通用的领域能力,社区活跃度能保持全国第六,并且在微服务领域已经被广泛使用,能帮助个人很好的放大价值。 再就是Nacos的熟悉产品也会比较简单,Nacos.io 官网可以帮助你快速入门,也有Nacos电子书免费下载帮助你深度了解Nacos架构设计。贡献开源上可以从Nacos社区仓库中 good first issues开始,跟着产品演进的方向,从小事开始在社区中发声,最后在Nacos社区有很多核心模块需要主导者,并且在社区中成为核心贡献者有社区投票权利,主导未来Nacos发展方向,并且作为社区核心成员,会有很多线上线下分享的机会,帮助个人以及企业建立更多社会影响力。总之在开源领域其实只要你愿意熟悉,一定会有所收获,祝愿每一位开发者在自己喜欢的领域能做出你想要的产品。最后感谢Nacos开源社区每一位同学!

· 7 min read

欢迎在校同学们参与Nacos开源之夏,社区导师手把手让你的代码被社会广泛复用,来赚取最高12000奖金,可推荐入职/实习你心意公司,又拿钱又成长又有价值,你还等什么呢?报名马上截止,快来参与Nacos开源之夏。

开源之夏是什么?

开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动,旨在鼓励在校学生积极参与开源软件的开发维护,促进优秀开源软件社区的蓬勃发展,培养和发掘更多优秀的开发者。 活动联合国内外各大开源社区,针对重要开源软件的开发与维护提供项目任务,并面向全球高校学生开放报名。 学生可在本活动中自主选择感兴趣的项目任务进行申请,并在中选后获得该开源项目资深维护者(社区导师)亲自指导的机会,完成项目并贡献给社区后,参与学生还将获得开源之夏活动奖金和结项证书。

Nacos&开源之夏2022

Nacos被评为2021Github年度全国社区活跃度第六,Nacos开源产品定位是更易于构建云原生应用的动态服务发现、配置管理和服务管理平台,用云原生方式解决分布式领域核心问题。 自2018年孵化并开源以来,共收获21.8K的star数,9.5K的Fork数,在开源中国发布的 2021 年度 OSC 中国开源项目评选中,Nacos 被评为云原生领域人气指数 Top5 的项目,发布电子书《Nacos 架构与原理》阅读量近10W+,现已被大量微服务架构的软件公司选型作为其服务注册与发现中心。目前在国内服务注册中心及配置管理领域中市场占有率排名第一。 此次Nacos社区开放的题目中包含了Nacos第三代架构的部分核心功能模块,将直接参与社区的核心功能,欢迎进入Nacos开源之夏参与Nacos3.0的建设,为未来五年开源微服务发展奠定基础。

参与Nacos开源之夏条件

  • 本活动面向年满 18 周岁在校学生。
  • 暑期即将毕业的学生,只要在申请时学生证处在有效期内,就可以提交申请。
  • 海外学生可提供录取通知书、学生卡、在读证明等文件用于证明学生身份。

参与Nacos开源之夏,你能获得什么?

  1. 【你的代码被社会广泛复用】你的代码可能会运行在上万家企业核心业务逻辑中,帮助企业解决问题。
  2. 【赢得最高12000奖金】奖金总额根据项目难度分为进阶 12000 元、基础 8000 元(注:奖金数额为税前人民币金额)
  3. 【社区核心人员辅导快速成长】只要你报名被选中,每个题目的导师会精心手把手教你融入社区,帮助你完成题目的设计以及最终的落地。
  4. 【推荐入职/实习】在本次编程之夏项目中表现优秀同学,可推荐入职/实习 你心意的公司工作。
  5. 【额外获得社区礼包】所有参与本次编程之夏项目的同学,均可获得Nacos社区大礼包。

百分百有奖品拿哦,现在唯一的问题是时间不多了,赶紧上车报名,截止报名时间是6月4日,6个核心题目,快点来报名参与Nacos编程之夏吧。

报名方式

点开Nacos开源之夏的链接 选择你喜欢的题目,Nacos社区围绕Nacos第三代架构精心计划了题目包含 “服务网格生态”、“多数据源建设”、“CoreDNS支持”、“K8S元数据同步”、“Nacos2.X建设”等技术方向展开。进行报名。 具体流程请参考学生指南访问可能会比较慢,请多等一下) 请注意找导师沟通截止流程时间,优先更导师沟通,能帮助你更好的了解题目。 想要报名的同学,请用钉钉扫码加入Nacos开源之夏2022钉钉群,方便大家交流题目内容。 image.png

参考资料

Nacos Github:https://github.com/alibaba/nacos Nacos 官网:http://nacos.io 为了让同学们更好地了解Nacos,我们提供了电子书供大家阅读学习 对于微服务分布式事务有兴趣的同学,可以尝试填报Seata开源之夏 参与开源之夏

· 12 min read

2.1.0

在社区和开源之夏的导师同学的共同努力下,2.1.0版本的主要目标已经基本完成,经过了近1个月的Beta测试后,在51劳动节,Nacos社区发布2.1.0版本作为给所有社区参与者的劳动节礼物。

新版本内容

2.1.0版本主要增加了认证插件和配置加密插件能力。 并关闭默认支持服务端从 1.X 版本升级的能力,若需要使用平滑升级能力,需要在配置文件中开启此功能。 对于客户端,此版本重构了类扫描逻辑并删除了 org.reflections 依赖,以解决 org.reflections 冲突时的不兼容问题。 最后,这个版本做了一些控制台优化并修复了 2.0.4 中发现的一些问题。 详细变更日志如下:

## Features

[#5695] Add a plugin SPI for configuration encryption and decryption for Nacos 2.0
[#5696] Add a plugin SPI for authentication for Nacos 2.0.
[#7930] Default close support upgrade from 1.X feature.
[#7992] Support cluster grpc client to set thread pool size.
[#8220] Add reset raft cluster operation.

## Enhancement & Refactor

[#7487] Add generics for the CacheBuilder.
[#7879] Refactor destroy method of AbstractMemberLookup.
[#7924][#8214] Add ldap auth plugin.
[#7952] Ignore read request for raft follower's state machine to enhance raft stability.
[#7966] Add more information in Auth/Distro/Curcuit-Filter when cause some server error.
[#7971] Stop version judge Task and release thread after upgrade completely.
[#8072] Enhance memory cost in DistroProtocol initialization.
[#8107] Enhance console change password operation.
[#8156] Support js and css of console auto-upgrade.


## BugFix

[#1717][#7359] Fix XSS vulnerabilities.
[#6273] Fix loop request for offline server nodes API.
[#6999] Fix Nacos client does not support logback overload log configuration.
[#7757] Fix jraft read request deserialize to write request problem.
[#7780] Fix config a-b-a problem.
[#7941] Fix version comparison error in Config Detail page.
[#8087] Fix text out of box in configuration manager.
[#8108] Fix throw NPR for health check for v2.
[#8050] Fix configuration about Distro changes could not take effect.
[#8161] Fix console can't use relative path problem.
[#8163] Fix multi-instance share the same local snapshot.
[#8196] Fix subscriber api without count when the query number is more than subscriber count.

## Dependency

[#7758] Update module nacos-consistency protobuf-maven-plugin version to 0.6.1.
[#7886] Enhance package scan logic and remove org.reflections dependency.

## Tests

[#4981] Add much unit test.
[#8009] Fix NPE of unit test.

插件化

支持插件化是2.1.0版本的主要改动之一。Nacos通过SPI 的方式,允许用户和开发者实现自己的对应功能插件使用;目前Nacos已经支持鉴权和加解密的插件化能力。

鉴权

自从Nacos 1.2 版本加入鉴权功能后,社区对鉴权功能的讨论一直持续。原因是Nacos目前的鉴权系统设计为防止错用及用户隔离。但社区中对鉴权能力的要求不局限于此,为了满足不同的用户对鉴权程度的不同要求。Nacos社区希望设计一套用于鉴权的API,并将其注入到网络请求的流程中。 Nacos目前的鉴权实现也已经重构成默认的鉴权插件,社区所贡献的LADP也已改造完成,使用方式和以前一致;如果需要开发自定义的鉴权插件,可以参考文档鉴权插件实现。

加解密

在Nacos社区中,许多用户关注配置中某些敏感信息的安全性问题。除了通过鉴权,社区也希望能对配置内容中的敏感信息进行加密。由于用户和开发者所使用或对接的算法和加解密系统可能不同,因此Nacos社区设计了一套用于加解密的API,并将其注入到发布和查询配置的工作流程中。 更多加解密插件的细节可以参考文档配置加密插件

默认关闭兼容1.X服务端升级

默认关闭支持服务端从 1.X 版本升级的能力是Nacos2.1.0版本的另一个重要改动。在2.0.X版本中,数据结构进行了一些重新设计,导致和1.X的数据无法直接兼容,为了方便社区用户从1.X平滑升级到Nacos2.0版本,Nacos2.0版本除了兼容1.X的openAPI外,还新增了双写数据等逻辑;但这部分逻辑对系统资源有较大的损耗,并且由于机制较为复杂,导致部分直接使用2.0版本的用户可能会遇到一些版本切换的疑问。因此在Nacos2.1版本中,我们默认关闭了兼容1.X服务端平滑升级能功能,关闭该功能后直接部署2.1版本将不会再从1.X模式进行检测和升级,而是直接运行在2.X的数据模式下,同时也支持2.0版本直接升级2.1版本。 若是希望从Nacos1.X直接升级到Nacos2.1.0版本,则需要在application.properties文件中设置配置nacos.core.support.upgrade.from.1x=true,此时Nacos2.1版本会和Nacos2.0版本一样,以1.X的数据模式启动,并开始自动升级检测,待全集群数据一致,且准备完毕后,切换至2.0数据模式,更多升级相关的内容,请参考文档升级文档

社区

在过去的一年里,社区内涌现出大量优秀的贡献者,他们为Nacos社区持续不断的注入活力和内容;正是有你们的关注和贡献,Nacos才能在2021年获得开源中国最受欢迎项目的奖项,在此郑重感谢去年参与社区贡献的Contributor,Committer和PMC同学,以及其他通过各种方式参与到社区的同学。 感谢同学们的持续贡献,正是有了大家的共同努力,Nacos才能变得越来越完善。 OSCHINA-Nacos.jpg

新PMC&Committer

Nacos社区新晋级了一位PMC同学和两位Committer同学。 来自滴滴出行的sanxun0325同学作为Nacos,Dubbo Go,Sentinal的Committer,在社区十分活跃,在过去的2021年也是为Nacos社区的go-sdk做出了大量贡献,并主导着Nacos-go-sdk社区的发展;因此提名为Nacos社区的PMC。

另外,来自微众银行MajorHe1和小米科技hujun-w-2同学,鉴于持续的大量社区贡献,经社区PMC及Committer的投票表决,提名为Nacos社区的Committer,希望二位能继续保持活跃,为Nacos社区添砖加瓦。

MajorHe1-committer.jpghujun-w-2-committer.jpg

年度优秀Committer

2021年度,Nacos社区有许多Committer利用自己的业余时间,持续的贡献者Nacos社区。为了感谢,Nacos社区评选出了12位2021年度优秀Committer,并特意制作了奖杯及卫衣,希望在2022年度,仍然能看到你们的身影。 这12位优秀Committer分别是(根据字母顺序):

没有被选中的Committer同学也不要担心,2022年度我们仍然会保持这个活动,希望2022年度优秀Committer有你们的名字。 2021-committer-rewards.JPG

贡献者激励活动

相信很多贡献者都已经收到了Nacos寄出的小礼物了,此类的活动Nacos社区会持续进行,只需要您持续关注社区,积极参与社区共建,就能够获得哦。 Nacos-cup.jpg

代码贡献活动

Nacos社区预计在7月会再次进行贡献者的激励活动,届时会统计并评选出数十位2022年7月前较为活跃的贡献者(不仅是Nacos的主干仓库,也包含了nacos-group下的各个仓库),并寄出新的社区纪念礼品;下期的贡献者礼品是雨伞,赶紧进行贡献获取吧。

优秀社区文章活动

Nacos社区的贡献并不只包含代码,社区也欢迎广大用户或开发者发表技术文章来和大家分享关于Nacos的技术心得;其中包括但不限于:Nacos的应用、源码解析、产品融合和社区合作等。欢迎大家提交文章到Nacos官方文档的博客栏目中,或发布在自己的微信公众号及博客中;对于优秀的社区文章,Nacos社区会收录到博客栏目及阿里开源的官方网站中,并会给文章作者寄送相应的礼物。

开源之夏2022

在2021年,Nacos社区参与了由ISCAS(中国科学院软件研究所)和openEuler社区托管的开源之夏2021活动,在导师、高校同学和主办方的共同努力下,完成了数个意义非凡的课题,其中就包括本次发版中最关键的两个改动:鉴权插件及配置加密插件。 今年,开源之夏2022如期而至,Nacos社区也再次参与活动,并制定了6个课题,欢迎关注开源之夏2022 ,参与Nacos的开源之夏2022。

About Nacos

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。 Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。

· 4 min read

Current documentation describes how to install a high availability Nacos cluster with one-click through Rainbond, a cloud native application management platform. This approach is suitable for users who are less familiar with Kubernetes, containerization and other complex technologies, and lowers the barrier to deploying Nacos in Kubernetes.

Background

Combination of Rainbond and Nacos

Rainbond is an easy to use open source cloud native application management platform. With the help of it, users can complete the deployment, operation and maintenance of microservices in a graphical interface. With the help of Kubernetes and containerization technology, automatic operation and maintenance capabilities such as fault self-healing and elastic expansion can be endowed to users' applications.

Rainbond has a built-in native Service Mesh microservice framework, and also has a good integration experience with other microservice frameworks such as Spring Cloud and Dubbo. Therefore, a large number of Rainbond users may also be users of the Nacos microservices registry. Instead of worrying about how to deploy a Nacos cluster, the Rainbond team made Nacos a one-click application template for free download and installation by open source users. This installation method greatly reduces the deployment burden of users using Nacos clusters. Currently, versions 1.4.2 and 2.0.4 are supported.

About application template

Application template is package manager for Rainbond cloud native application management platform. Users can install applications into Rainbond with one-click. No matter how complex the application is, the application template abstracts it into an package, which is installed with docker images of all the components, configuration information, and relationships between all the components.

Prerequisite

  • Deployed Rainbond cloud native application management platform,Quick Start Can run in a PC within a container.

  • Internet connection.

Quick Start

  • Access the built-in open source app store

Select the App Store on the left, switch to the Open Source App Store, and search nacos to find the Nacos-cluster application.

nacos-1

  • One-click install

Click Install on the right of nacos-Cluster to enter the installation page. After filling in simple information, click OK to start the installation, and the page automatically jumps to the topology view.

nacos-2

Parameters:

OptionsInstructions
团队名称User-defined workspace isolated by namespace
集群名称Select which K8s cluster Nacos will be deployed to
选择应用Select the application to which Nacos will be deployed, which contains several associated components
应用版本Select the version of Nacos, the useable versions are 1.4.2 and 2.0.4

After a few minutes, the Nacos cluster is installed and up and running.

nacos-3

  • Testing

Other microservice components that need to perform service registration can connect to the Nacos cluster using ${NACOS_HOST}:${NACOS_PORT} after built dependencies to Nacos.

  • Service registration

    curl -X PUT "http://${NACOS_HOST}:${NACOS_PORT}/nacos/v1/ns/instance?serviceName=nacos.naming.serviceName&ip=20.18.7.10&port=8080"
  • Service discovery

    curl -X GET "http://${NACOS_HOST}:${NACOS_PORT}/nacos/v1/ns/instance/list?serviceName=nacos.naming.serviceName"
  • Publish config

    curl -X POST "http://${NACOS_HOST}:${NACOS_PORT}/nacos/v1/cs/configs?dataId=nacos.cfg.dataId&group=test&content=helloWorld"
  • Get config

    curl -X GET "http://${NACOS_HOST}:${NACOS_PORT}/nacos/v1/cs/configs?dataId=nacos.cfg.dataId&group=test"

Advanced

  • The one-click installation of the Nacos cluster contains three instances, and the self-organizing and electing of the cluster is done automatically by initContailer.

nacos-4

  • Mysql is integrated as the data source by default. You can switch to other external data sources by configuring the following environment variables in the Nacos-server-2.0.4 component's environment configuration.
NameNecessaryDescription
MYSQL_SERVICE_HOSTYDatabase address
MYSQL_SERVICE_PORTYDatabase port
MYSQL_SERVICE_USERYDatabase username
MYSQL_SERVICE_PASSWORDYDatabase password
MYSQL_SERVICE_DB_NAMEYDatabase name
  • Nacos-server-2.0.4 data persistence directory is generated by default.

nacos-5

  • By default, the health check mechanism of Nacos-server-2.0.4 is configured to ensure that instances are automatically offline when faults occur and online after recovery.

nacos-6

· 7 min read

Apache APISIX Introduction

Apache APISIX is a dynamic, real-time, high-performance API gateway.

APISIX provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more. Apache APISIX not only has many practical plug-ins, but also supports plugin dynamic change and Hot-loading.

Nacos Introduction

Nacos is an easy-to-use, open source platform for dynamic service discovery, service configuration and service management. It provides a set of simple and useful features enabling you to realize dynamic service discovery, service configuration, service metadata and traffic management. Nacos makes it easier and faster to construct, deliver and manage your microservices platform. It is the infrastructure that supports a service-centered modern application architecture with a microservices or cloud-native approach.

Service Registry

Service Registry is the core component of service management, similar to the role of directory service, and one of the most basic facilities in the microservices architecture. It is mainly used to store service information, such as service provider URL, routing information, and so on. The service registry is implemented by mapping complex service-side information to simple and understandable information for the client.

The core functions of the Service Registry are as follows:

  • Service registration: Service providers register with the Service Registration Center.

  • Service discovery: Service consumers can find the call routing information of service providers through the registry.

  • Health check: Ensure that service nodes registered with the service registry can be invoked normally, and avoid the waste of call resources caused by invalid nodes.

Why do you need a service registry?

The registry is essentially to decouple service providers and service consumers. In the microservice system, each business service will call each other frequently, and the IP, port and other routing information of each service need to be managed uniformly. But how do you manage it? You can provide information about existing services to a unified service registry for management through the Service Registration function of the Service Registry.

From the above description, you can know that the registry can help users quickly find services and service addresses through mapping. As business updates iterate, services change frequently. Clients can still pull a list of services through the service discovery function of the registry after registering new services or service downtime on the service side. If the service node of the registry changes, the registry sends a request to notify the client to pull again.

If the service on the server side suddenly goes down and there is no feedback to the service registry, the client can show the service side its service status by actively reporting the heartbeat at regular intervals through the health check function of the service registry. If the service status is abnormal, the service registry will be notified, and the service registry can remove the down service nodes in time to avoid waste of resources.If the service on the server side suddenly goes down and there is no feedback to the service registry, the client can show the service side its service status by actively reporting the heartbeat at regular intervals through the health check function of the service registry. If the service status is abnormal, the service registry will be notified, and the service registry can remove the down service nodes in time to avoid waste of resources.

What application scenarios does Apache APISIX + Nacos provide for users?

Apache APISIX + Nacos can centralize business-independent control of each microservice node into Apache APISIX for unified management, that is, the ability to proxy and route forwarding interface services through Apache APISIX. After each microservice is registered on Nacos, Apache APISIX can obtain a list of services through Nacos's service discovery function and find the corresponding service address to implement dynamic proxy.

img

Apache APISIX realizes service discovery based on Nacos

Prerequisites

This article is based on the following environments.

Step 1: Service Register

  1. Use Node.js's Koa framework starts a simple test service on port 3005 as upstream.
const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
ctx.body = 'Hello World';
});

app.listen(3005);
  1. Register the service on the command line by requesting the Nacos Open API.
curl -X POST 'http://127.0.0.1:8848/nacos/v1/ns/instance?serviceName=APISIX-NACOS&ip=127.0.0.1&port=3005&ephemeral=false'
  1. After service registration, use the following command to query the current service.
curl -X GET 'http://127.0.0.1:8848/nacos/v1/ns/instance/list?serviceName=APISIX-NACOS'

Examples of correct returned results are as follows:

{
"name": "DEFAULT_GROUP@@APISIX-NACOS",
"groupName": "DEFAULT_GROUP",
"clusters": "",
"cacheMillis": 10000,
"hosts": [
{
"instanceId": "127.0.0.1#3005#DEFAULT#DEFAULT_GROUP@@APISIX-NACOS",
"ip": "127.0.0.1",
"port": 3005,
"weight": 1.0,
"healthy": true,
"enabled": true,
"ephemeral": true,
"clusterName": "DEFAULT",
"serviceName": "DEFAULT_GROUP@@APISIX-NACOS",
"metadata": {},
"instanceHeartBeatInterval": 5000,
"instanceHeartBeatTimeOut": 15000,
"ipDeleteTimeout": 30000,
"instanceIdGenerator": "simple"
}
],
"lastRefTime": 1643191399694,
"checksum": "",
"allIPs": false,
"reachProtectionThreshold": false,
"valid": true
}

Step 2:Added Nacos Route

Create a new route using the Admin API provided by Apache APISIX. APISIX selects the service discovery type to use through the upstream.discovery_type field. upstream.service_name needs to be associated with the corresponding service name of the registry. Therefore, when creating a route, specify the service discovery type as Nacos.

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
"uri": "/nacos/*",
"upstream": {
"service_name": "APISIX-NACOS",
"type": "roundrobin",
"discovery_type": "nacos"
}
}'

In the above command, the request header X-API-KEY is the access token of the admin API, which can be viewed under apisix.admin_key.key in theconf/config.yaml file.

After successful addition, examples of correct returned results are as follows:

{
"action": "set",
"node": {
"key": "\/apisix\/routes\/1",
"value": {
"update_time": 1643191044,
"create_time": 1643176603,
"priority": 0,
"uri": "\/nacos\/*",
"upstream": {
"hash_on": "vars",
"discovery_type": "nacos",
"scheme": "http",
"pass_host": "pass",
"type": "roundrobin",
"service_name": "APISIX-NACOS"
},
"id": "1",
"status": 1
}
}
}

In addition, you can also pass other service related parameters in upstream.discovery_args to specify the namespace or group where the service is located. For details, please refer to the following table:

NameTypeRequirementDefaultValidDescription
namespace_idstringoptionalpublicThis parameter is used to specify the namespace of the corresponding service
group_namestringoptionalDEFAULT_GROUPThis parameter is used to specify the group of the corresponding service

Step 3: Verify configuration results

Use the following command to send the request to the route to be configured.

curl -i http://127.0.0.1:9080/nacos/

Examples of correct returned results are as follows:

HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Content-Length: 11
Connection: keep-alive
Date: Thu, 27 Jan 2022 00:48:26 GMT
Server: APISIX/2.12.0

Hello World

It can be seen from the example that the new route in Apache APISIX can find the correct service address through Nacos service discovery and respond normally.

Summary

This article introduces the concept of registry and how Apache APISIX cooperates with Nacos to implement routing proxy based on service discovery. How to use Apache APISIX with Nacos in actual scenarios depends on the specific business requirements and past technical architecture.

To get more information about the nacos plugin description and full configuration list, you can refer to the official documentation.

· 7 min read

Nacos 2.0.3

Nacos2.0.3 中,Nacos社区继续针对1.X到2.0.X升级的健壮性和高可用做了充分优化,扫除上生产的稳定性忧虑;Java/Spring-boot/Golang/C#/Cpp多语言客户端也全面支持Nacos2.0,拉齐多语言代差;并且优化了大量控制台UI的易用功能,提升用户使用效率。

主要变更内容如下:

## Features

[#6384] Add redo feature for nacos client naming.

## Enhancement

[#1469] Add cluster delete button.
[#5884] Add the permission for history config.
[#5909] Enhance LADP auth log print out when auth check failed.
[#5999] Adpat nacos endpoint in AddressServerMemberLookup.
[#6100] Enhance config managerment UI.
[#6129] Add ServerConfigChangeEvent when config file changed.
[#6142] Redo register and subscribe when reconnection auth check failed.
[#6160] Optimization of IP address acquisition method in nacos client.
[#6175] If the client already disconnect, ignore this request to avoid NPE.
[#6178] Unified configuration page style
[#6204] Get data from database if user or role info not found in cache.
[#6367] Add IOReactorExceptionHandler to avoid IOReactor out of loop when meet unknown Network error.
[#6386] Stop v1 distro verification when cluster upgraded to v2.
[#6403] Make the expired time of naming client be configurable in nacos-server.

## BugFix

[#6107] Fix Chinese account show with gibber in home page.
[#6109] Fix get InstanceUpgradeHelper instance error for double write service.
[#6116] Fix unable to check client beats when register same ip and port in old clients with high concurrent.
[#6169] Fix cluster page internationalization.
[#6198] Fix NPE when use StringUtils.join illegal.
[#6295] Fix instance metadata will not be removed for ip port client.
[#6335] Fix startup error when the JAVA_HOME path contains spaces under Linux/Unix/Mac system.
[#6382][#6476] Fix nacos-istio serviceInfo.getChecksum() always is empty.
[#6423] Fix yaml parse concurrent problem.

完整的Release Note请查看 2.0.3

从Nacos1.X升级Nacos2.0.X

Nacos服务端支持从1.X平滑升级到Nacos2.0.X;由于Nacos2.0对服务发现的数据结构进行了重构,因此升级过程中会采用异步双写数据的功能,在升级到2.0模式前,对数据进行校验,保证升级过程中的稳定运行。

在集群所有节点都升级到Nacos2.0.X版本之后,集群中的每一台节点都将开启自检,检查Nacos1.X模式下的数据是否和Nacos2.0模式下的数据一致,主要对比的是两个模式下的服务数及实例数是否相等,以及是否还有双写任务。 只有服务数及实例数相等,且没有双写任务之后,Nacos节点才会判定自身节点已经准备好升级到2.0模式,可以通过控制台的集群管理中节点元数据的readyToUpgrade字段来判断该节点是否准备完成。

当集群中所有节点都完成准备后,集群节点将会切换运行模式到2.0模式,此时请求流量将会切换至2.0模式运行,且开始接受gRPC的请求。如果未切换时,来自gRPC的请求将会提示Nacos cluster is running with 1.X mode, can't accept gRPC request temporarily. Please check the server status or close Double write to force open 2.0 mode.

另外,从Nacos2.0.2版本开始,Nacos为升级添加了一些接口方便用户检查升级状态,找到升级到2.0模式不成功的原因,并且在特殊情况下能够进行主动补偿。

比如接口/nacos/v1/ns/upgrade/ops/metrics, 可以快速的查看到当前节点的状态,如当前1.X模式的服务数,实例数;2.0模式的服务数,实例数;双写任务遗留量;对应模式缺失的服务名等等内容,帮助用户快速定位升级问题。

更多升级相关信息请查看 Nacos 2.0 升级文档

客户端支持2.0

目前Golang、C#、Cpp、nacos-spring-boot,客户端已经支持了nacos2.0的grpc能力,欢迎大家试用 ​

Python的多语言客户端正在紧张开发中,相信很快能与大家见面。 Nodejs部分欢迎社区小伙伴一起参与建设~

2.1版本预告

自2.0版本12月初社区发布后,经过数个版本的优化,功能和性能趋于稳定;因此社区开始规划2.1版本。

在Nacos2.1版本中,我们计划移除对Nacos1.X服务端的升级支持,以移除1.X模式及双写等冗余代码,提升代码质量及可读性,用户仍可以从2.0.X版本进行升级。

在功能上,Nacos2.1版本将会开放部分功能的插件化能力,如已经在进行的Selector插件,鉴权插件及配置加解密插件。

另外,我们会对Nacos2.0的第三方依赖进行一些精简,减少用户使用过程中依赖冲突的问题。

社区

感谢来自社区同学们的持续贡献,正是有了大家的共同努力,Nacos才能变得越来越完善。

在此郑重感谢对本次Release有卓越贡献的社区同学(根据字母顺序):

期待各位成为Nacos committer。

About Nacos

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。

Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。

· 8 min read

Nacos2.0通过升级通信协议和框架、数据模型的方式将性能提升了约10倍,解决继 Nacos 1.0 发布逐步暴露的性能问题。本文通过压测 Nacos1.0,Nacos1.0升级Nacos2.0过程中,Nacos2.0 进行全面性能对比,直观的展示Nacos2.0所带来的性能提升。

压测准备

环境准备

为了方便Nacos部署升级和展示核心性能指标,我们是从阿里云微服务引擎MSE中购买的一个2核CPU+4G内存的三节点Nacos集群。

压测模型

为了展示不同规模下的系统表现,我们采用逐步增压的方式进行压测,将压力分为3个批次进行逐步启动,并观察每个批次下集群的运行表现。同时会在压力集群之外,再增加一个Dubbo服务的Demo,并使用Jmeter以100TPS的压力不停的调用,以模拟不同压力下,对实际业务调用存在的可能影响。

压测过程中,会在适当的时候对服务端和客户端进行升级;服务端的升级将直接使用MSE提供的一键升级功能,客户端的升级会使用分批次轮流重启的方式进行。

压测模型

压测过程

Nacos1.X Server + Nacos1.X Client

首先启动第一批施压集群,对MSE Nacos1.2.1进行施压,在6000个Providers的压力下,集群稳定时CPU大约25%,能够稳定保持6000实例。

1.X6000实例CPU 1.X6000实例

随后启动第二批施压集群,增加4000个Provider,合集10000个Provider。此时集群峰值CPU已经达到60%,稳定运行时大约在45%左右,集群能够稳定运行。

1.X10000实例CPU 1.X10000实例

在前两批的压力下,集群没有出现稳定性问题,所以Dubbo的调用保持正常,没有错误发生。

1.X10000实例Dubbo

当第三批施压集群启动之后,压力总计14000个Provider。此时集群先是短暂的注册到13000个实例,之后很快出现实例数下跌,CPU跑满的问题。并且缩小时间范围可以看到,下跌后的实例仍然在小范围抖动。

1.X14000实例CPU 1.X14000实例 1.X14000实例抖动

同时Dubbo的调用出现错误,从Consumer的日志可以看出,是由于服务端无法支撑这个级别的压力,导致Dubbo Provider被摘除,所以调用的时候出现了No provider的错误。

1.X14000实例Dubbo 1.X14000实例Dubbo错误

Nacos2.X Server + Nacos1.X Client

由于服务端升级期间,会进行实例的双写操作,因此在升级过程中服务端存储的实例数会是实际实例值的两倍。根据上述测试结果,需要先将实例数回滚回第一批6000实例之后,或是升级配置扩容机器之后再尝试升级。本文使用回滚压力的方式,先停止后启动的施压集群。让集群恢复正常后再执行升级。

升级前6000实例CPU 升级前6000实例 升级前6000实例Dubbo

从监控图中可以看出,在停止后两批压力后,集群很快就恢复到了正常,运行稳定,Dubbo调用也恢复正常。之后使用MSE的升级功能,进行升级。升级过程中由于双写的性能损耗,导致CPU有较大的抖动;而且因为双写导致的实例数翻倍,实际上相当于12000实例的极限压力,服务端仍然有一定的抖动,因此导致了些许Dubbo的错误。若是在非极限压力下升级,将不会有此影响。

升级后14000实例CPU 升级后14000实例 升级后14000实例Dubbo

随着服务端升级完成停止双写,消除了双写带来的性能损耗,CPU使用降低并趋于稳定,同时实例数也不再抖动,Dubbo调用完全恢复;如同1.X服务端一样,分两个批次启动施压集群,对比两个版本间在相同压力下的性能表现。

升级后14000实例CPU 升级后14000实例 升级后14000实例Dubbo

由于客户端依旧使用的是1.X的客户端,服务端的使用水位依然非常高,在全部压力启动后,CPU几乎达到100%;虽然没有像1.X服务端一样,出现大规模实例下跌,但是运行一段时间后依旧有少量的实例抖动,说明仅升级Nacos服务端到2.0版本能有一定的改善,但是没有彻底解决性能问题。

升级后14000实例抖动

Nacos2.X Server + Nacos2.X Client

为了完全释放Nacos2.0的性能,还需要将施压集群的客户端也升级到2.0以上版本。同样将分3个批次进行替换,期间由于Provider进行了重启,服务端有出现实例的下跌再恢复属于正常现象。随着施压集群的升级,可以发现CPU有了非常明显的下降,最终达到稳定时,CPU由最初的接近100%,降低到20%,集群稳定运行14000个实例。

2.X14000实例CPU 2.X14000实例 2.X14000实例Dubbo

压测结果

如上所述,我们能够得到2核CPU+4G内存的三节点集群在不同版本下的性能差异:

服务端版本客户端版本压力规模集群稳定性CPU使用
Nacos1.XNacos1.X14000完全不稳定100%
Nacos2.X(升级中)Nacos1.X6000有一定抖动100%
Nacos2.XNacos1.X14000有一定抖动100%
Nacos2.XNacos2.X14000稳定20%

由此可见,Nacos2.0确实对性能有较大的提升,新用户建议直接全部采用Nacos2.0,老用户建议先升级Server端,然后在逐步升级客户端释放红利。最后从整个压测视角的监控,来直观的感受一下不同版本在不同阶段的性能表现:

监控纵览