Nacos 发布 0.9.0 版本，该版本加强了 Nacos-Sync 稳定性，增加了监控体系，完善了测试用例，并且支持 Naming 和 Config 的分模块启动，此外还修复了社区提出的一些 issues：

• [#412] Nacos can support Dubbo service registration discovery and configuration management
• [#388] Cluster name should be provided in the Instance
• [#377] Clean up messy code in Naming module
• [#369] Support instance list persisted on disk
• [#366] Findbugs-maven-plugin version
• [#362] The metadata will lost when online or offline instance through web ui
• [#352] Refactoring internationalization Nacos console
• [#278] Nacos docker img
• [#243] Optimize the efficiency of integration testing, it’s taking too long now

感谢以下 Contributors 对 Nacos 0.9.0版本的贡献，他们是：

@paderlol、@jifengnan、@loadchange、@nkorange、@hxy1991、@huangyunbin、@darkness463、@luoxn28、@TsingLiang、@xuechaos、@nanamikon、@systp、@jameslcj、@pader.zhang

详情参考：https://github.com/alibaba/nacos/releases/tag/0.9.0

Nacos team 介绍 ：https://nacos.io/en-us/docs/nacos-dev.html （持续扩展中，欢迎加入）

如何加入 Nacos team：https://nacos.io/en-us/docs/contributing-dev.html

相比文字和图片，直播提供了人与人之间更丰富的沟通形式，其对平台稳定性的考验很大，那么倡导“以技术驱动娱乐”的虎牙直播（以下简称“虎牙”）是如何在技术上赋能娱乐，本文将为您介绍虎牙在DNS、服务注册、CMDB和服务配置中心等方面的实践。

文章整理自虎牙基础保障部中间件团队负责人张波（社区ID：zhangjimmy）在Dubbo Meetup 广州站沙龙上的分享，阿里巴巴中间件授权发布，分享议题如下：

• 为什么选用Nacos
• DNS-F的技术价值和应用场景
• 服务注册的实践
• CMDB的应用和实践
• 服务配置的实践

##为什么选用 Nacos

虎牙关注 Nacos 是从v0.2 开始的（最新版本：Pre-GA v0.8），我们也参与了社区的建设，可以说是比较早期的企业用户。

Nacos 是一个更易于帮助构建云原生应用的动态服务发现、配置和服务管理平台，提供「注册中心」、「配置中心」和「动态DNS服务」三大功能。

首先，在虎牙的微服务场景中，起初有多个注册中心，每一个注册中心服务于某一部分微服务，缺少一个能融合多个注册中心，并把他们逐一打通，然后实现一个能管理整个微服务体系的大的注册中心。

以下内容摘自我们考虑引入Nacos时，在服务注册中心方案上的选型对比：

Nacos提供 DNS-F功能， 可以与K8S、Spring Cloud和Dubbo等多个开源产品进行集成，实现服务的注册功能。

其次，在服务配置中心方案的选型过程中，我们希望配置中心和注册中心能够打通，这样可以省去我们在微服务治理方面的一些投入。因此，我们也同步比较了一些服务配置中心的开源方案：

例如Spring Cloud Config Server、Zookeeper和ETCD，总体评估下来，基于我们微服务体系现状以及业务场景，我们决定使用Nacos作为我们的服务注册和服务发现的方案。使用过程中，我们发现，随着社区版本的不断更新和虎牙的深入实践，Nacos的优势远比我们调研过程中发现的更多，接下来，我将围绕DNS-F、Nacos-Sync、 CMDB和负载均衡4方面来分享虎牙的实践。

##DNS - F 的技术价值

Nacos 提供的DNS-F功能的第一个技术价值在于，弥补了我们内部微服务没有一个全局动态调度能力的空白。刚才提到，虎牙有多个微服务体系，但并没有一个微服务具备全局动态调度的能力，因为它们各自都是独立的。目前，我们通过Nacos已经融合了四个微服务体系的注册中心，最终目标是把所有的微服务都融合在一起，实现全局动态调动的能力。

第二，DNS-F解决了服务端端到端面临的挑战，即延时大、解析不准、故障牵引慢的问题。

如何去理解呢？

当内部有多个微服务体系的时候，每一个体系的成熟度是不同的。例如，有一些微服务框架对同机房或CMDB路由是不支持的，当一个服务注册到了多个IDC中心，去调用它的服务的时候，即便是同机房，也可能调用到一个不是同机房的节点。这样就会无端的造成服务的延时和解析不准。

即使我们基于DNS做一些解析的优化，但仍然无法完全解决服务的延时和解析不准。这是因为DNS都是IP策略的就近解析，无法根据服务的物理状态、物理信息进行路由。此外，当一个核心服务出现问题，如果缺少一个融合了多个调用方和被调用方的信息的统一的注册中心，就很难去准确判断如何去牵引，从而导致故障牵引慢。有了Nacos后，就可以接入一个统一的注册中心以及配置中心，去解决这些问题。（目前，虎牙还在微服务体系的改造过程中，未完全实现统一的注册中心）

第三，提供专线流量牵引能力。虎牙的核心机房的流量互通，是使用专线来实现的。专线的特性就是物理建设的，而且我们的专线建设可能不像BAT那么大，例如我们专线容量的冗余只有50%，假设某个直播异常火爆，突发流量高于平常的两百倍，超过了专线的建设能力，这时候一个服务就有可能会导致全网故障。但是，通过全局的注册中心和调动能力，我们就可以把流量牵引到其他地方，例如迁移到公网，甚至牵引到一个不存在的地址，来平衡一下。即便某个服务出现问题，也不会影响我们的全局服务。

第四，支持服务端的多种调度需求，包括同机房路由、同机器路由，以及同机架路由，Nacos都可以去做适配。此外，基于Nacos 的DNS-F功能，我们还实现了加速外部域名解析和服务故障牵引秒级生效。

##DNS - F 的应用场景

这张图是Nacos DNS-F的一个具体实现，实际上是拦截了OS层的DNS请求。如果经过DNS的域名是内部服务，它就会从Nacos Server 获取结果，如果不是，就会转发到其它的LocalDNS进行解析。

以数据库高可用的应用场景为例，我们的数据库切换效率比较低，依赖业务方修改配置，时效不确定，通常需要10分钟以上（备注：我们的数据库实际上已经实现了主备的功能，但当一个主服务出现问题的时候，总是要去切换IP。）切换IP的过程中，依赖运维和开发的协作，这是一个比较长的过程。

引入DNS后，当主出现问题的时候，就可以很快的用另外一个主的IP来进行替换，屏蔽故障，而且节点的故障检测和故障切换都可以自动完成，并不依赖运维和开发的协作，节省了时间。当然，这个场景的解法有很多，比如说使用MySQL - Proxy也可以去解这个问题，但我们的MySQL - Proxy还在建设中，想尽快的把这个问题解决，所以采用了DNS的方式。

下面我们再着重分享下基于DNS-F对LocalDNS的优化。虎牙还没有去建设自己的LocalDNS，大部分使用的是一些公共的DNS，大致有以下这些组成。

这种组成方式会存在一个问题。假设服务突然一下崩溃后，之后服务又马上正常了，这种情况我们无法重现去找到崩溃原因。因为很多场景下，是一个公共DNS的请求超时导致的，甚至一个解析失败导致的，在那一刻，因为无法保留现场的，所以就发现不了问题。

以我们的监测数据来看，DNS解析错误的比例达到1‰左右，超时比例将更高。意思是在使用公共DNS的情况下，服务有1‰的几率是会超时或失败，如果服务没有做好容错，就会出现异常。同时，一些公共DNS解析的延时都是不定的，比如在亚马逊上一些比较不好的节点，它的延时会比较高，平均超过三四十毫秒。

然后我们基于DNS-F对LocalDNS做了一些优化。优化结果如下：

• 平均解析时间从之前的超过两百毫秒降低到两毫秒以下；
• 缓存命中率从92%提升到了99%以上；
• 解析失败率之前是1‰，现在基本上没有了。

优化的效果也体现在我们的风控服务上，平均延迟下降10ms，服务超时比例下降25%，降低了因延迟或服务超时导致的用户上传的图片或文字违规但未被审核到的风险。

##服务注册的实践

虎牙的核心业务是跑在Tars上的。

Tars：腾讯开源的一款微服务框架。

Tars主要是支持C++，但对Java、PHP等开发语言的支持力度比较差，这就使得我们非C++的业务方去调用它就会很别扭。引入Nacos以后，我们通过Nacos支持的DNS协议来实现服务发现过程中对全语言的支持。

当然，Nacos不只是一个注册中心，它具备了融合多个数据中心的能力，支持多数据源的同步，例如，我们目前已经支持了Taf（虎牙内部的一个重要微服务体系）、Nacos自身、ZooKeeper、以及K8S上一些服务注册的同步。

同时，基于Nacos集群的双向同步功能(Nacos-Sync)，我们实现了国内的两个可用区，以及国外的多个可用区之间的数据值同步，最终实现了一处注册、多地可读。

Nacos-Sync是事件机制，即同步任务通过事件触发，可以灵活地开启和关闭你要同步的任务，然后根据服务变化事件触发监听，保证实时性，最后通过定时的全量突发同步事件，保证服务数据的最终一致。同时，Nacos-Sync也支持服务心跳维持，即多个数据中心的心跳，可以使用Nacos-Sync代理要来实现远端同步。此外，也支持心跳与同步任务绑定，便于灵活控制。

由于Taf上有数万个注册服务，同步的量特别大，所以我们在Nacos-Sync做了一些改造，通过任务分片来实现数万服务同步的可用性保障。改造步骤是先以服务为粒度定义任务，然后在多个分片上分散任务负载，最后以单分片多副本来保证任务可用性。

##对接 CMDB，实现就近访问

在服务进行多机房或者多地域部署时，跨地域的服务访问往往延迟较高，一个城市内的机房间的典型网络延迟在1ms左右，而跨城市的网络延迟，例如上海到北京大概为30ms。此时自然而然的一个想法就是能不能让服务消费者和服务提供者进行同地域访问。

Nacos定义了一个SPI接口，里面包含了与第三方CMDB约定的一些方法。用户依照约定实现了相应的SPI接口后，将实现打成Jar包放置到Nacos安装目录下，重启Nacos即可让Nacos与CMDB的数据打通。

在实际的落地过程中，我们是在DNS-F接入Taf，在DNS-F上实现Taf的中控接口，无缝对接Taf的sdk。DNS-F提供缓存负载均衡和实例信息，Nacos则提供负载均衡信息的查询接口。

##服务配置的实践

虎牙的域名（www.huya.com）会接入华南、华中、华北多个IDC机房，每个机房都会建设一个Nginx去做负载均衡，经过负载均衡的流量会通过专线返回到我们的后端服务器上。在这个过程中，如果我们去修改一个在中间的配置，需要下发到多个机房的上百个负责负载均衡的机器上，如果出现配置下发不及时，或下发配置失败，极大可能会出现故障，同时，负责均衡服务的机器对弹性能力的要求较高，在业务高峰如果不能快速扩容，容易出现全网故障。

传统的配置下发方式是通过服务端下发文件更新配置，更新配置生效时间长，由于需要预先知道负责均衡集群的机器信息，扩缩容需要等元信息同步以后才能接入流量，扩容流量的接入时间较长。

引入Nacos后，我们采用了配置中心监听方式，通过客户端主动监听配置更新，配置便可秒级生效，新扩容服务主动拉取全量配置，流量接入时长缩短3分钟+。

##虎牙对 Nacos 改造和升级的总结

引入Nacos的过程中，我们所做的改造和升级总结如下。

一是在DNS-F上，我们增加了对外部域名的预缓存的支持，Agent的监控数据对接到公司的内部监控，日志输出也对接到内部的日志服务，然后和公司的CMDB对接，并实现了DNS-F Cluster集群。我们之所以去构建一个DNS-FCluster集群，是为了避免内存、硬盘或版本问题导致的DNS服务无效，有了DNS-F Cluster集群，当本地Agent出现问题的时候，就可以通过集群去代理和解析DNS请求。

二是在Nacos-Sync上，我们对接了TAF注册服务和K8S注册服务，以及解决了多数据中心环形同步的问题。

三是在Nacos CMDB上，我们对Nacos CMDB进行了扩展，对接了虎牙自己的CMDB，并对接了内部的负载均衡策略。

###本文作者 张波，社区ID zhangjimmy，Nacos Committer，虎牙基础保障部中间件团队负责人，阿里云MVP。

###其他服务化改造实践：

• 网易考拉在服务化改造方面的实践
• 微众银行的金融级消息服务平台建设实践和思考
• 消息规模超千亿，同程艺龙的消息系统建设实践
• 滴滴出行基于RocketMQ构建企业级消息队列服务的实践

阿里巴巴微服务开源项目?Dubbo Nacos? 于本周发布?v0.8.0?PRE-GA版本，终于初步完成了Road Map一个重要的里程碑版本（第一个可安全上生产的版本，特别感谢在前期勇于在生产上尝试Nacos的客户，社区会尽快寄出小礼品，表达对大家的感激之情），V0.8.0 版本主要在支持了登录、命名空间、Metrics监控（对接Prometheus）、通过Nacos-Sync 组件支持从传统的注册中心平滑的往Nacos服务数据迁移等特性，以更稳定和更高可用的姿态让用户在生产环境中支撑大家的微服务平台。

Nacos 登录​

Nacos控制台支持登录、登出特性，以便更安全的上生产使用。

命名空间​

Nacos自0.5.0版本支持命名空间以来，配置服务先支持了命名空间，服务发现模块则在这个0.8.0版本支持了多命名空间，使用服务发现的命名空间可以实现服务数据的逻辑隔离。使用服务发现模块的多命名空间与配置模块基本相同，在Nacos控制台上查看想要使用的命名空间ID，在客户构造时传入该命名空间ID：

Properties properties = new Properties();

properties.put(PropertyKeyConst.NAMESPACE, "74a3dbb9-36cb-43f5-8d31-006acfd61caa");

properties.put(PropertyKeyConst.SERVER_ADDR, "127.0.0.1:8848");

NamingService naming = NamingFactory.createNamingService(properties);

这样通过这个NamingService实例读写的就都是命名空间74a3dbb9-36cb-43f5-8d31-006acfd61caa下的数据了。当然您也可以不指定命名空间ID，这样将会默认分配到public命名空间。发布完服务可以到Nacos控制台上查询服务信息：

Metrics监控​

通过Metrics信息暴露，对接Prometheus加强Nacos实时监控，以便让用户对产品更有控制力。

Nacos 通过micrometer统计了运行时的核心指标：

• 系统指标包括cpu load jvm等
• 业务指标包括配置数，域名数，长连接，QPS，RT等
• 异常指标记录了Nacos运行的内部异常micrometer提供了转化器能转化成多种metrics格式，Nacos目前支持常用的prometheus、elastic search和influxdb，后续可以根据具体情况进行调整。

具体的详情可以参考官网监控文档。

Nacos-Sync 支持服务平滑迁移​

提供Nacos-Sync同步工具支持用户做服务数据的平滑迁移迁移，支持用户从其他注册中心平滑迁移到Nacos上来，同时支持多个Region独立Nacos服务同步，目前Nacos-Sync支持的源注册中心主要包括ZooKeeper,Eureka等。

使用场景​

• 双向同步功能,支持Dubbo+Zookeeper服务平滑迁移到Dubbo+Nacos,享受Nacos更加优质的服务

• 多个网络互通的Region之间服务共享,打破Region之间的服务调用限制

支持的范围​

Nacos-Sync支持用户扩展不同注册中心服务同步，目前已支持的同步类型如下:

• Nacos数据同步到Nacos
• Zookeeper数据同步到Nacos
• Nacos数据同步到Zookeeper
• Eureka数据同步到Nacos
• Consul数据同步到Nacos

配置同步服务​

Nacos-Sync提供了控制台方便你配置同步的服务数据:

• 同步任务管理页面

• 注册中心管理页面

​

具体项目信息请参考Nacos-Sync产品页

蓬勃发展的 Nacos 社区​

DISS is cheap, show me your hand 比吐槽更重要的是搭把手，参与社区一起发展Nacos

• 作为用户关注和加入 Nacos 社区

Nacos 社区正在蓬勃发展，截止到发文为止，Nacos 短短几个月已经有 9 个微信群，其中 7 个已满员，1个QQ群，1个钉钉群，关注 Nacos 的社区人数已经近5000人，在 Nacos 群里跟 “道（基）友” 切磋技术，交流经验，招聘交友，抢抢红包...不亦乐乎。

要加入 Nacos 微信社区，你可以通过扫下面的“超哥”“超哥”** 帮你拉入 “Nacos社区微信交流群”

• 作为代码贡献者加入 Nacos 社区

从Nacos用户发展而成贡献者顺理成章，而Nacos开发团队也确实在日趋壮大，从开始的只有4个代码contributor发展到目前的34个，在0.8.0 版本的开发中，社区同学贡献了很大的力量，在此特别感谢戚月同学设计登录UI，黄清昊同学贡献登录代码，王彦民同学贡献命名空间代码，张龙同学贡献nacos-sync代码，李晨同学贡献配置管理代码，明亦同学保证这个关键版本的测试质量，相信后续有跟多同学参与到Nacos社区的共建中。

而社区也正在计划在合适的时机上，将在Nacos官网 nacos.io 中添加团队介绍页，将大家正式公布于众，欢迎大家加入Nacos社区，贡献社区。用Apache的话说，“社区高于代码”!

新人时刻 - "什么是Nacos？"​

还不知道什么是Nacos? 没关系，在github上star一下跟程序猿兄弟打个招呼吧!!

Nacos 是阿里巴巴于7月份新开源的项目，Nacos的主要愿景是期望通过提供易用的 动态服务发现、服务配置管理、服务共享与管理 的基础设施，帮助用户在云原生时代更好的构建、交付、管理自己的微服务平台。

github项目地址在 这里

更多与 Nacos 相关的开源项目信息​

• Nacos
• Dubbo Registry Nacos
• Nacos DNS-F
• Nacos Docker
• Nacos Spring Project
• Nacos Spring Boot
• Spring Cloud Alibaba
• Dubbo
• Sentinel
• Spring Cloud
• Nepxion Discovery
• Spring Cloud Gateway Nacos

虎牙直播平台(https://www.huya.com/)​

虎牙直播是中国一家以游戏直播为主的视频直播网站。网站以YY直播为名创建于2011年，隶属于欢聚时代，2014年11月24日更名为虎牙直播，开始独立运营。其海外版本为以东南亚为市场的Nimo TV。虎牙直播是国内最为资深的以游戏内容为核心的直播平台，其在游戏方面有丰富的独家资源，汇聚目前最为火爆的游戏，如英雄联盟、王者荣耀、球球大作战、守望先锋、炉石传说、绝地求生、绝地求生手游——刺激战场、全民突击等主题的直播内容。

虎牙中间件团队介绍​

虎牙中间件团队主要负责虎牙服务注册发现与配置中心 ，负责均衡，中间件等平台相关的建设，致力于保障改进虎牙用户接入的请求成功率及请求耗时，为虎牙提供稳定可靠全球基础接入服务设施，服务间通信的基础设施。

虎牙团队成功引入Nacos到生产环境​

nacos dns数据库高可用场景上落地​

通过DNS-F和nacos实现基于域名的服务发现，数据库接入由ip方式改成域名接入，数据库切换在秒级完成，已在内部数十个业务系统上完成接入。

nacos cmdb方案落地​

nacos通过支持spi扩展的方式， 支持虎牙将cmdb的数据导入到nacos中， 可以实现对注册实例打入来自cmdb标签， 实现基于cmdb标签的负载均衡功能， 赋予业务同机房调度， 同set调度， 基于自己定义的标签进行流量分发的能力。

tars服务框架融合nacos为注册中心​

通过nacos-sync这个中间件，将tars中的注册数据实时同步到nacos中，实现秒级同步tars中实例的变化， 同时提供高可用的集群方案；部署在国内外的nacos注册中心，满足业务就近注册服务，同时本地的服务会通过nacos-sync同步到其他集群，满足业务跨区域服务调用的需求。

负载均衡层解到nacos config做配置管理​

国内外流量接入层位于全球各地， 配置的推送服务遇到比较大的挑战。 nacos config通过部署3地的配置服务集群，国内外流量接入层可以就近拉取配置，解决使用国内单节点svn服务的的速度问题。同时通过使用集群方案和本地文件缓存机制保证配置服务的高可用， 解决之前svn的单点问题。

未来计划​

虎牙后续会继续在nacos上持续投入，今后的内部service mesh，容器服务注册场景发力。

虎牙中间件团队深入共建Nacos​

虎牙中间件团队也深入参与了Nacos生态的构建，核心成员张波、周建、李志鹏参与构建了包括Nacos的核心同步组件Nacos-sync、Nacos的DNS-F模块，把虎牙的业务模型和生产部署经验也共建到Nacos生态中,在过程当中，张波、周建、李志鹏成为了Nacos的核心Committer，是Nacos重要的社区成员。

Authors: 何煦

上篇作为 Nacos 5W1H 系列文章的开篇，从“What” 讲述了 Nacos 配置管理能帮我们解决的问题：以简单、优雅、高效的方式管理配置，实现配置的动态变更，大大降低运维成本。

本文将围绕“Where”，讲述 Nacos 配置管理的三个典型的应用场景：

• 数据库连接信息
• 限流阈值和降级开关
• 流量的动态调度

数据库连接信息

曾经有朋友跟我聊过一个问题，“业务飞速发展，团队越来越大，人员流动也相对频繁起来，怎么才能更好的保证数据的安全性，不被泄露呢？”。他提到这样一个场景，公司创立初期，服务后端的代码都是他一行一行码出来的，当时只有他一个人，后端与数据库的连接配置信息也就直接放置在项目的配置文件中。他使用的是 Spring Boot 框架，配置信息就是存放在 application.properties 中，使用 Spring 的 profile 属性保证不同环境连接不同的数据库。如下所示：

生产环境：application-prod.properties

spring.datasource.url=生产环境的数据库连接地址
spring.datasource.username=生产环境的数据库用户账号
spring.datasource.password=生产环境的数据库用户密码

开发环境：application-dev.properties

spring.datasource.url=开发环境的数据库连接地址
spring.datasource.username=开发环境的数据库用户账号
spring.datasource.password=开发环境的数据库用户密码

测试、预发环境也是类似。这种将数据库连接信息直接放置在配置文件中，跟着项目代码一起通过 Git 管理，的确是有蛮大的数据泄露的风险。试想，一个新来不久的小伙伴，他一当要投入研发工作，有 Git Pull 代码的权限之后，代表他可能就拥有了直接操作线上数据库的权限了。当时的我给他建议可以通过以下几个方面去降低数据风险：

• 将数据库连接信息等敏感配置从项目中剥离；
• 数据库增加 IP 白名单连接限制；
• 最小权限原则：每个账号只配置所必需的权限，避免删表删库等高危操作；
• 定期修改数据库账号、密码。

回想起来，我当时给的建议并没有完全解决他的问题，甚至还带来了其他一些问题。例如，上述的第一点，“将敏感配置从项目剥离”，剥离出来的敏感配置存放到哪里？怎么管理这些配置呢？也许，你会想到，存放到应用部署机器的环境变量或某个文件中。不，一样有风险，说不定哪天开发同学必须得登录上机器排查问题，就有泄露的风险，总之，得尽可能地做到在整个开发流程都不会有任何泄露的风险。应用中可能不只是连接一个数据源，分库分表的情况，不同数据存储（如 MySQL / Redis / Elasticsearch 等）的情况，还有，其他更多敏感配置项，配置数据的增多会给管理带来不便。

另外，“定期修改数据库账号、密码”，修改后我能怎么方便快捷的下发到所有应用程序中呢？既然是敏感配置，其变更也会带来不少的风险，我需要能先到小量的几台机器验证，保证对业务无影响，我再全部下发到其他所有的机器上去，是否还得有“灰度发布”的功能呢？账号密码修改下发后，应用出现异常，影响到业务了，我要怎么快速地回滚呢？是否还得有“版本控制”、“快速回滚”的功能呢？不是所有的开发同学都有权限能修改敏感配置信息，是否还需要有“权限管控”的功能？对敏感配置的任何操作都应该被记录，是否还需要有“变更审计”的功能呢？

现在，我有了更好的建议：使用 Nacos 配置管理模块，将敏感配置信息都存放到 Nacos 中。Nacos 配置管理，其中一个立身之本就是为敏感配置保驾护航。它提供上述场景所需的功能，通过命名空间区分不同环境（开发、测试、预发、生产），通过“版本控制”保证变更可追溯，通过“快速回滚”保证错误变更时影响最小，通过的“灰度发布”功能保障配置安全平稳地变更，还有更多更全面功能（权限管控、变更审计等）即将支持。

那么，怎么将敏感配置项目的配置文件中迁移到 Nacos 中呢？下面以 Spring Boot 连接 MySQL 为例：

1. 添加依赖

<dependency>
    <groupId>com.alibaba.boot</groupId>
    <artifactId>nacos-config-spring-boot-starter</artifactId>
    <version>${latest.version}</version>
</dependency>

注意 Spring Boot 1.x 使用 nacos-config-spring-boot-starter 0.1.x 版本，Spring Boot 2.x 使用 nacos-config-spring-boot-starter 0.2.x 版本。

2. 在 application.properties 中添加 Nacos 连接配置

nacos.config.server-addr=127.0.0.1:8848

这里是简单的示例，在实际生产中，还需配置 Nacos 命名空间信息（区分环境）、鉴权信息（如 AccessKey、SecretKey 等，即将支持的权限访问控制）。而 Nacos 配置模块对应的阿里云产品 ACM，借助于 ECS 实例 RAM 角色，最终能到达连 AccessKey、SecretKey 都不需要填写的目的。

3. 添加 @NacosPropertySource 注解

@SpringBootApplication
@NacosPropertySource(dataId = "mysql.properties")
public class SpringBootMySQLApplication {

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

4. 在本地启动的 Nacos 控制台上新增 dataId 为 mysql.properties 的配置，配置内容为 MySQL 连接配置信息：

通过这四个简单的步骤，就将 MySQL 连接信息从原来的 application.properties 迁移到 Nacos 的，让 Nacos 将敏感配置管控起来，大大降低数据泄露的风险。同时，Nacos 配置管理提供的“统一管控”、“版本控制”、“快速回滚”等强大的功能也为其运维管理带来极大的便利。

完整示例代码请参看：https://github.com/nacos-group/nacos-examples/tree/master/nacos-spring-boot-example/nacos-spring-boot-config-mysql-example

限流阈值和降级开关

限流、降级，众所周知，是在开发高并发系统过程中需要考虑的两大关键点，是运行时保护系统的两大利器。限流阈值和降级开关，最终是抽象为一个个的配置项，要想实现运行时的动态调整阈值和开关的启停，将这些配置项存放到 Nacos 的配置模块中最适合不过了。

在今年 8 月的时候，阿里巴巴开源了 Sentinel，以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。在阿里巴巴内部，Nacos 跟 Sentinel 就是多年携手相伴，砥砺前行的好机油，为双 11 等各种大促立下了功劳，也为剁手党提供了良好的购物体验。

下面就以 Sentinel 流控为例，演示如果通过 Nacos 来做到运行时的动态控制流量：

1. 添加依赖

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-core</artifactId>
    <version>${latest.version}</version>
</dependency>
<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-datasource-extension</artifactId>
    <version>${latest.version}</version>
</dependency>
<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-datasource-nacos</artifactId>
    <version>${latest.version}</version>
</dependency>
<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>fastjson</artifactId>
    <version>${latest.version}</version>
</dependency>

2. 模拟并发请求

final class RunTask implements Runnable {
    @Override
    public void run() {
        while (!stop) {
            Entry entry = null;
            try {
                entry = SphU.entry(resourceName);
                // token acquired, means pass
                pass.addAndGet(1);
            } catch (BlockException e1) {
                block.incrementAndGet();
            } catch (Exception e2) {
                // biz exception
            } finally {
                total.incrementAndGet();
                if (entry != null) {
                    entry.exit();
                }
            }

            Random random2 = new Random();
            try {
                TimeUnit.MILLISECONDS.sleep(random2.nextInt(50));
            } catch (InterruptedException e) {
                // ignore
            }
        }
    }
}

3. 配置 Nacos 连接信息与 dataId 等，并将其设置为 Sentinel 的数据源

public class NacosDynamicFlowDemo {

    private static final String KEY = "TestResource";

    public static void main(String[] args) {
        final String remoteAddress = "localhost";
        final String groupId = "DEFAULT_GROUP";
        final String dataId = "com.alibaba.nacos.demo.flow.rule";

        ReadableDataSource<String, List<FlowRule>> flowRuleDataSource = new NacosDataSource<>(remoteAddress, groupId, dataId,
            source -> JSON.parseObject(source, new TypeReference<List<FlowRule>>() {}));
        FlowRuleManager.register2Property(flowRuleDataSource.getProperty());
        
        // Assume we config: resource is `TestResource`, initial QPS threshold is 5.
        FlowQpsRunner runner = new FlowQpsRunner(KEY, 1, 10000);
        runner.simulateTraffic();
        runner.tick();
    }
}

4. 在本地启动的 Nacos 控制台中新建 dataId 为 com.alibaba.nacos.demo.flow.rule 的流控配置

5. 运行 NacosDynamicFlowDemo，你会看到如下标准输出信息

6. 再到 Nacos 控制台修改刚刚新建的流控配置，将限流阈值 count 的值修改为 1.0，完整的标准输出信息如下

以上示例演示了如何通过 Nacos + Sentinel 实现动态流量控制的能力，核心就是用到了 Nacos 配置模块“动态推送”的能力。原理是 sentinel-datasource-nacos 集成了 nacos-client ，其与 nacos-server 维持着连接，当用户在 Nacos 控制台进行配置变更时，nacos-server 会快速地将该配置的最新内容推送到 nacos-client 中，Sentinel 一拿到最新的流控配置，就转换了流控策略，如示例将流控阈值调整为 1.0，限制为更少的流量进入系统的业务处理流程。

完整示例代码请参看：https://github.com/nacos-group/nacos-examples/tree/master/nacos-sentinel-example

流量的动态调度

业务发展壮大到一定的规模，单一的集群已经承载不了全部的用户请求，需要将用户的流量分流到不同的集群上。当然，更进一步的方案是：不同的集群位于不同的区域，这样，除了缓解业务处理的压力，也给系统带来容灾的能力。

比如，某电商系统有 1 亿用户量，将系统的流量按照用户的 ID 进行切分，ID 为 1-1000W 的用户请求分发到区域 A 的集群 a 上，ID 为 10001W-2000W 的用户请求流量分发到区域 B 的集群 b 上，以此类推，最终将所有用户的请求流量打散到 10 个不同区域的集群上，同时，每个集群冗余了一些系统资源。当区域 A 的机房发生不可抗的灾难（如地震）时，我们需要有动态调度流量的能力，最好能秒级得将流量从区域 A 调度到另外可用的区域的集群上。

这正是 Nacos 配置管理大有作为的地方，将用户 ID 的分片和对应的路由规则存放在 Nacos 的中，配合统一接入层等的组件，就能将流量打散到各个集群上，进而让系统能承载更大的流量，以更好的支撑业务的发展。另外，将其存放与 Nacos 中，也就具备了配置“动态化”的能力，一旦某区域出现基础设施无法及时恢复的问题时，只需在 Nacos 的控制台上修改 ID 分片的路由规则，就能将有问题的区域流量快速切换到其他可用的区域上，保障对业务几乎无损。Nacos 在阿里内部能做到秒级推送到十万级别机器上的推送效率。

总结

本文为 Nacos 5W1H 系列文章的第二篇，围绕“Where”，讲述了 Nacos 配置管理的几个典型的应用场景：数据库连接信息、限流阈值和降级开关、流量的动态调度。其实还有更多更大胆的应用场景，如“大数据实时计算算法调整”、“异地容灾多活”、“应用业务场景动态推送”等等，可以参看 Nacos 的阿里云产品 ACM 的使用场景 。Nacos 配置管理模块，将敏感配置收拢管控起来，极大降低数据泄露等风险，并且提供如“动态推送”、“版本控制”、“快速回滚”等功能，保障了敏感配置的变更安全平稳的执行。

在限流与降级的场景，通过一个示例，为大家演示了如何通过 Nacos + Sentinel 实现流量的动态控制，这也是 Nacos 配置管理的一个十分典型的应用场景。降级也一样，大促高峰期间将某个非关键的系统组件进行关闭，在过了高峰期后再开启，这个也是可以通过 Nacos 的“动态推送”的功能来实现。

总之，只要系统涉及到了“敏感的配置”、“动态的配置”，都应该考虑将配置放入到 Nacos 中，让 Nacos 管控起来。

authors: 叶志远

一.前言​

Nacos是阿里巴巴开源的致力于服务发现与管理、动态配置管理，以及动态DNS服务的中间件，目前已发布至0.5.0版本，除了与Spring Cloud更加紧密结合以外，还丧心病狂地支持JDK11。如果您目前的项目碍于Eureka的性能，而又缺乏成本引进Consul，那么Nacos是您最好的选择。好了，回到正题，在上周许进搞了一个使用Nacos实现Spring Cloud Gateway的动态路由，让我们直观地感受到了Nacos的无缝接入如丝般顺滑，作为Spring Cloud中网关的始祖Zuul，自然也需要这一贴心赋能。

二.Spring Cloud Zuul动态路由实现思路​

在社区书籍《重新定义Spring Cloud实战》中第8章4小节，详细剖析了Zuul的路由配置表加载以及刷新原理，其大致思想就是重写SimpleRouteLocator类的locateRoutes()方法，同时实现RefreshableRouteLocator接口，方法体引用父类的doRefresh()方法。在书中使用DB作为配置存放的仓库，如今有更为强大的Nacos，只需要将之前读取DB的逻辑换成读取Nacos即可。美中不足的是，由于Nacos还需进一步完善，目前对Spring Cloud中的事件支持还不是很完美，动态刷新只能依靠Zuul的内部逻辑。

三.具体实现​

1.在zuul-server中添加Nacos的配置​

    <dependency>
        <groupId>com.alibaba.nacos</groupId>
        <artifactId>nacos-client</artifactId>
        <version>0.4.0</version>
    </dependency>

2.读取Nacos配置信息核心代码​

@Component
public class PropertiesAssemble{

    public Map<String, ZuulRoute> getProperties() {
        Map<String, ZuulRoute> routes = new LinkedHashMap<>();
        List<ZuulRouteEntity> results = listenerNacos("zuul-server","zuul_route");
        for (ZuulRouteEntity result : results) {
            if (StringUtils.isBlank(result.getPath())
                    /*|| org.apache.commons.lang3.StringUtils.isBlank(result.getUrl())*/) {
                continue;
            }
            ZuulRoute zuulRoute = new ZuulRoute();
            try {
                BeanUtils.copyProperties(result, zuulRoute);
            } catch (Exception e) {
            }
            routes.put(zuulRoute.getPath(), zuulRoute);
        }
        return routes;
    }

    private List<ZuulRouteEntity> listenerNacos (String dataId, String group) {
        try {
            Properties properties = new Properties();
            properties.put(PropertyKeyConst.SERVER_ADDR, "localhost:8848");
            ConfigService configService = NacosFactory.createConfigService(properties);
            String content = configService.getConfig(dataId, group, 5000);
            System.out.println("从Nacos返回的配置：" + content);
            //注册Nacos配置更新监听器，用于监听触发
//            configService.addListener(dataId, group, new Listener()  {
//                @Override
//                public void receiveConfigInfo(String configInfo) {
//                    System.out.println("Nacos更新了！");
//
//                }
//                @Override
//                public Executor getExecutor() {
//                    return null;
//                }
//            });
            return JSONObject.parseArray(content, ZuulRouteEntity.class);
        } catch (NacosException e) {
            e.printStackTrace();
        }
        return new ArrayList<>();
    }
}

目前的demo写得比较简单，直接将Nacos的默认地址与端口写了进来，Nacos对于配置的管理有两个坐标，一是dataId，二是group，本demo中笔者将其分别命名为"zuul-server","zuul_route"。

3.Zuul动态刷新路由实现​

这部分可以查看demo地址：https://github.com/SpringCloud/spring-cloud-zuul-nacos，具体就不赘述。

四.演示​

1.从Nacos github地址pull源码，配置环境​

这里需要在IDEA中添加启动参数-Dnacos.standalone=true

2.启动Nacos，配置Zuul路由信息​

启动Nacos后，在浏览器输入http://localhost:8848/nacos/index.html便会跳转到如下页面： 点击配置列表，单击右侧的+号图标，便可以新增一项配置，由于这里已经添加好了，就直接看信息：

3.启动zuul-server，从Nacos加载路由信息测试​

启动Zuul后，console中出现如下信息： 在浏览器输入http://localhost:5555/baidu,出现如下效果，直接跳转到目标地址： 我们现在将Nacos中的配置修改一下，将http://github.com/Lovnx换成http://www.baidu.com，修改后直接发布： 我们会在console看到： 在浏览器输入http://localhost:5555/baidu,出现如下效果：

------------------->>>DEMO源码​

Authors: 马昕曦、张龙、邢学超

阿里巴巴微服务开源项目Dubbo Nacos于本周发布 v0.6版本，该版本主要在支持了 Dubbo的服务注册与发现和配置管理、支持docker 部署提供了官方的docker镜像、优化Nacos 控制台的国际化框架并且Nacos的集成测试效率也大大优化。

千呼万唤始出来，Dubbo的注册中心和配置中心​

Nacos 从 v0.6 版本开始，支持 Dubbo 注册中心和配置中心，同样作为阿里巴巴开源的重量级别产品，两个产品在阿里巴巴集团的内部内部实现就有千丝万缕的联系。

Dubbo服务框架​

作为rpc服务框架，一方面注重的是极其短的时延rt，保证整体的调用高效，并且另一方面保证良好的用户体验，保证用户使用舒适并且有良好的扩展性。Dubbo在这两方面做的都非常的优秀，也因为良好的拓展性，被业内广泛使用。Dubbo的普及度以及欢迎程度之高，通过2w+的github仓库star关注度就可见一斑。

Nacos 和 Dubbo 一脉相承的基因​

但阿里巴巴技术体系下有如此高效的rpc服务框架，但到底是什么支撑了阿里巴巴庞大的服务集群呢。众所周知阿里巴巴集团有着恐怖的集群规模，每年阿里巴巴集团的天猫双11全球购物狂欢节都会有人瞎掉下巴的交易规模，2018年的双11当天承载了2135亿的销售额。但作为技术人员，最关心的是峰值。如果细心的从业者应该看到了一个指标，2018年天猫承载了交易创建峰值达49.1万笔/秒。举个例子，北京鸟巢体育馆最大承载用户量9万1千人，49.1w交易每秒交易，意味着5个鸟巢体育馆的满座的观众推着购物车，同时在一秒冲过天猫淘宝的结算台，这种压力可想而知。但背后的承载这么大规模的服务集群的，和阿里巴巴Dubbo的内部使用框架HSF，对应的ConfigServer，而这正是Nacos的前身之一。Nacos 发布的0.6版本正是宣布和Dubbo完美集成，也就宣布阿里巴巴在大规模集群的经验将随着Nacos、Dubbo、Sentinel等分享出来，贡献给开源社区。

Dubbo融合Nacos​

Nacos 作为 Dubbo 生态系统中重要的注册中心基础设施，其中 dubbo-registry-nacos 是 Dubbo 融合 Nacos 注册中心的桥梁，它基于 Dubbo 强大的注册中心 SPI 以及 Nacos Naming 服务，提供实时的服务注册和发现。目前 dubbo-registry-nacos 处于 preview 阶段，最新的发布版本为 0.0.2，已测试最新的 Dubbo 以及 Dubbo OPS，推荐开发人员使用最新的 Dubbo 2.6.5 以及 Nacos 0.6.1 ，确保享受最佳体验。如果您现在正在使用 Zookeeper 或者 Redis 作为注册中心的话，迁移到 Nacos 的部分也非常简单，以 Zookeeper 为例：

• 场景一：外部化配置

调整前的配置：

## Zookeeper registry address
dubbo.registry.address = zookeeper://127.0.0.1:2181

调整后的配置：

## Nacos registry address
dubbo.registry.address = nacos://127.0.0.1:8848

• 场景二：XML 配置驱动

调整前的配置：

<!-- 使用 Zookeeper 注册中心 -->
<dubbo:registry address="zookeeper://127.0.0.1:2181" />

调整后的配置：

<!-- 使用 Nacos 注册中心 -->
<dubbo:registry address="nacos://127.0.0.1:8848" />

调整完毕后，先确保 Nacos Server 已启动，再重启您的 Dubbo 应用，随后您在 Nacos 控制台 “服务列表” 中就能看到注册信息：

如果您对 Dubbo 与 Nacos 整合敢兴趣，不妨访问项目主页了解更多详情，地址为：

• Dubbo Nacos Registry：https://github.com/dubbo/dubbo-registry-nacos
• Apache Dubbo：https://github.com/apache/incubator-dubbo

如果您在使用的过程中遇到了任何问题和有任何建言，请将在 https://github.com/dubbo/dubbo-registry-nacos/issues 中进行讨论。

容器大行其道，Nacos 支持 Docker 容器化​

在容器大行其道的今天，支持容器化已经成为必然，Docker作为容器化大多数人的选择，Nacos 在v0.6 版本宣布 支持Docker化部署，并且提供出官方镜像，并且会在预计在下几个版本中支持k8s部署。

如何通过Docker部署​

本地需要确定已经按照了Docker，如果没有安装，请参考 https://docs.docker.com/install/。安装之后这时就可以快速的从远程拉去镜像，拽起一个单机版本的Nacos，体验一下。 简单粗暴，运行以下命令：

docker run --name nacos-standalone -e MODE=standalone -p 8848:8848 nacos/nacos-server:latest

操作试例如下：

另一种应用方式，docker-compose编排方式，可以参照以下命令：

1. git clone 项目 并且进入项目根目录

git clone https://github.com/nacos-group/nacos-docker.git
cd nacos-docker

2. 启动

• 单机启动

docker-compose -f example/standalone.yaml up

• 集群启动

docker-compose -f example/cluster-hostname.yaml up 

这时你的Nacos就已经启动起来，你就可以访问http://localhost:8848/nacos/index.html体验Nacos的功能了。

配置管理功能体验​

服务发现功能体验​

蓬勃发展的 Nacos 社区​

DISS is cheap, show me your hand 比吐槽更重要的是搭把手，参与社区一起发展Nacos

• 作为用户关注和加入 Nacos 社区

Nacos 社区正在蓬勃发展，截止到发文为止，Nacos 短短几个月已经有5个微信群，其中4个已满员，1个QQ群，1个钉钉群，关注 Nacos 的社区人数已经近3000人，在 Nacos 群里跟 “道（基）友” 切磋技术，交流经验，招聘交友，抢抢红包...不亦乐乎。

要加入 Nacos 微信社区，你可以通过扫下面的“超哥”的微信二维码，让“超哥” 帮你拉入 “Nacos社区微信交流群”

• 作为代码贡献者加入 Nacos 社区

从Nacos用户发展而成贡献者顺理成章，而Nacos开发团队也确实在日趋壮大，从开始的只有4个代码contributor发展到目前的24个，随着阿里巴巴其他团队成员如 @小马哥 等人，虎牙直播的 @张波 @周健 团队等人，nacos-docker-k8s 贡献者 @张龙，前端的主要贡献者饿了么 @王彦民，Spring Cloud中文社区创立者 @许进 等的陆续加入，相信未来Nacos社区的力量未来会越来越强大。

而社区也正在计划在合适的时机上，将在Nacos官网 nacos.io 中添加团队介绍页，将大家正式公布于众，欢迎大家加入Nacos社区，贡献社区。用Apache的话说，“社区高于代码”!

新人时刻 - "什么是Nacos？"​

还不知道什么是Nacos? 没关系，在github上star一下跟程序猿兄弟打个招呼吧!!

Nacos 是阿里巴巴于7月份新开源的项目，Nacos的主要愿景是期望通过提供易用的 动态服务发现、服务配置管理、服务共享与管理 的基础设施，帮助用户在云原生时代更好的构建、交付、管理自己的微服务平台。

github项目地址在 这里

更多与 Nacos 相关的开源项目信息​

• Nacos
• Dubbo Registry Nacos
• Nacos DNS-F
• Nacos Docker
• Nacos Spring Project
• Nacos Spring Boot
• Spring Cloud Alibaba
• Dubbo
• Sentinel
• Spring Cloud
• Nepxion Discovery
• Spring Cloud Gateway Nacos

Authors: 坤宇，敦谷

阿里巴巴微服务开源项目Dubbo Nacos于本周发布 v0.5.0 版本，该版本主要在 DNS-based Service Discovery，支持 TTL，支持 Java 11，优化Nacos产品用户体验，与Spring Cloud Gateway的集成等方面做了演进。

发布 DNS-F，支持 DNS-based Service Discovery​

为了进一步降低微服务多语言生态、异构系统、Kubernetes体系的服务注册与发现的实现成本，Nacos v0.5.0 发布了一款基于CoreDNS的 DNS-F客户端，通过 DNS-F 支持将注册在Nacos上的服务以DNS域名的方式暴露出接入点，让三方应用方便的查阅、发现与集成。

DNS-F 不同于Nacos的 Client SDK/API 服务发现模式，DNS-F 提供独立于应用进程的Agent, 通过拦截并代理主机应用的域名解析请求，让Nacos处理服务发现对应域名的数据动态推送更新、健康检查、异常节点下线等、同时Nacos UI提供统一的服务发现域名管理视图 (UI域名管理部分，v0.5.0暂未开放)。

在Nacos的立项之初，提供动态的基于 DNS 协议的服务发现能力就是其核心的三大功能之一，之所以Nacos要提供DNS-SD，主要旨在帮助用户解决三个方面的问题:

• 为Kubernetes以及应用的服务发现提供统一解决方案

应用微服务体系（如Spring Cloud）+ Kubernetes已经逐渐成为新的组合，通过前者解决应用架构问题，通过后者解决微服务部署及运维的成本问题，但是在服务发现这一块，毫无疑问，Kubernetes体系内的服务发现方案无论是SkyDNS，KubeDNS还是CoreDNS，一直都是基于DNS的，但是像Spring Cloud则是基于像Eureka,zookeeper这样的服务发现方案，这种方案的异化和沟鸿给用户统一服务发现和服务管理方案带来了巨大的挑战。

Nacos DNS-F 目前开源提供的版本，是在CoreDNS的基础上提供了Nacos的plugin nacos-coredns-plugin, 这样初步打通了CoreDNS与Nacos服务, 这种实现方式为未来Nacos进一步打通Kubernetes集群内部的服务发现与应用服务发现（如Spring Cloud)提供了通路，为Nacos在未来帮助应用以统一的视图管理Kubernetes内部及应用自身的服务及域名提供了基础，从而帮助用户简化基于kubernetes体系的微服务平台的构建与管理。

• 帮助用户消除耦合到厂商私有服务发现API上的风险

很不幸的说，到目前为止，服务发现迄今仍然没有标准协议，市面上的服务发现的解决方案有很多，仅在Java Spring生态中，就有zookeeper，consul，eureka，nacos等解决方案可以用，更不用说在其它的语言和框架中了，Nacos通过提供 DNS-F，可以让用户更容易地实现以DNS协议为基础的服务发现（即DNS-SD），而DNS协议是一个成熟的标准协议，基于DNS做服务发现，不仅可以有效的帮助用户消除耦合到厂商私有服务发现API上的风险，方便未来的迁移，也有利于服务提供方以更标准的和易理解的方式暴露自己的服务，从而更易于被不同的应用方发现和集成。

• 支持异构系统及多语言生态的服务发现

在一个中大型企业中，传统企业架构要升级为云原生微服务架构，遗留系统和异构系统的服务注册与发现无疑是必须首要解决的问题。另外采用微服务架构的一大承诺收益点也在于每个微服务本身可以独立选择更合适的语言栈，但是到目前为止没有个一个服务发现产品能提供各种语言客户端SDK的100%的完全覆盖，以zookeeper为例子，zookeeper质量比较好的客户端仅有java和c的客户端，那么非java和c两个语言体系的服务和系统就很难通过zookeeper来注册与发现，而DNS天然是各种语言都支持的，一般使用DNS做服务发现对应用的侵入非常的小，非常适合遗留应用或者异构应用往新的微服务平台上的迁移。

阿里巴巴基于DNS-F的DNS-SD生产实践​

以阿里巴巴为例，基于DNS-F模式的服务发现已经是阿里巴巴生产环境中的最重要服务发现方式之一，不同于外界对于阿里巴巴的印象，在像阿里妈妈，高德，优酷，搜索等这样的业务中，存在大量的重要的非Java语言体系的业务系统提供的服务，而基于DNS-F的DNS-SD解决方案，则在发现，打通和勾连这些异构服务的过程中起到了举足轻重的作用。

距离阿里巴巴内部发布的第一个python版本的DNS-F客户端已经过去5个年头，python版本的DNS-F客户端在生产上的整体装机使用量，对所有VIPServer各语言客户端的占比已经超过 1/3,可见其在内部应用之广泛，而不用绑定在私有的VIPServer API上, 业务从LVS/VIP，SLB等网关式(Server-based SD)服务发现方案迁移过来时对业务侵入小，也是众多业务线愿意优先考虑DNS-F客户端的首要原因。

DNS 协议需要继续演进​

DNS协议本身是为www而生，并非为服务发现而生，所以在协议上，用在服务发现场景下DNS依然有不少的小瑕疵需要在未来从协议层面解决，比如DNS缓存TTL收敛的问题，比如操作系统以及各语言对SRV Record字段的支持问题,DNS包大小限制的问题等等，但随着Kubernetes以及微服务体系在各行业的深入应用，可以说DNS协议已经有为服务发现场景做进一步向前演进的必要，这方面阿里巴巴&Nacos会做持续的探索和推进。

支持 Java 11​

9月25日，Oracle 官方宣布 Java 11正式发布，不同于Java 9以及10，这是继 Java 8 之后的首个长期支持版本，Java 11 在诸如 ZGC，TLS 1.3，新的算法密钥协议，Lambda局部变量语法支持，Standardize HTTP Client API等不少方面做了改进，确实值得关注。

关于 Nacos 支持 Java 11, 这里有一个有趣的花絮,本来Nacos没有计划在近期的版本支持Java 11,因为Nacos团队考虑到 Java 8 依然是生产上的主流(参见JVM生态报告, 报告显示 79% 的 Java 开发者使用 Java 8 作为生产环境的主要平台), 但是Spring Cloud 大神 @Josh Long 在准备尝试和给全世界演示 Nacos 的时候，居然在 Java 11 上跑不起来，于是他毅然的给Nacos提了个 issue Please support Java 11.

划重点~ github上给Nacos提issue是实现你的需求和想法的最佳手段!

Nacos支持Java 11, 主要是指2个方面的支持

• Nacos 支持运行在Java 11上
• 将Nacos源码开发及构建环境升级到Java 11

现在Nacos的状态是2方面都已经支持 Java 11。

使用Nacos实现Spring Cloud Gateway的动态路由​

要实现微服务架构，微服务网关必不可少，Nacos 社区目前正在努力跟 Spring Cloud 的微服务网关做更多的打通与集成，Spring Cloud 中文社区创建者,《重新定义Spring Cloud实战》的作者 @许进 与近期贡献了如何基于Spring Cloud Gateway与Nacos实现动态路由能力的示例，github 地址在这里，毫无疑问，Spring Cloud Gateway作为所有请求流量的入口，在实际生产环境中为了保证高可靠和高可用，尽量避免重启,需要实现Spring Cloud Gateway 动态路由配置，等到这块足够成熟，会将其包含在Nacos的官方推荐实现中。

TTL & Health Status Aggregation​

在Nacos之前的几个版本中，用户往往会在使用过程中产生疑惑，为什么注册的实例已经下线(宕掉)了，但是依然可以在Nacos控制台上看到实例的信息。这源于SpringCloud以及Dubbo等服务体系中，Eureka或者Zookeeper都有自动注销实例的能力，而且将自动注销作为注册中心的默认行为。但其实当服务的实例下线(宕掉)之后，注册中心有两种可能的行为，一个是将这个实例从服务下的实例列表中剔除出去，一个是保留该实例，只将实例状态置为不健康。Eureka和Zookeeper等注册中心，其实也支持持久化的实例注册，而Nacos只是将这种持久化的注册设成了默认的行为。

Nacos的服务发现模块，是基于内部的VIPServer演化而来。在VIPServer的主要场景中，服务是以域名的方式通过控制台注册到VIPServer的，并且VIPServer非常注重服务级别的元数据信息的定义带来的灵活“软负载”流量调度的能力，所以首要选择的是服务及实例的元数据的持久性存储，弱化了服务的提供端持续向VIPServer服务端发送心跳的能力，所以前期并没有将VIPServer 上报和汇聚实例健康状态的功能放出来。之前版本的服务实例的健康检查，必须由VIPServer服务端来主动发起来完成。但是如Nacos开源之初规划的那样，Nacos会同时支持两种模式

对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos 提供了心跳上报模式和服务端主动探测2种健康检查模式。

所以随着Nacos 0.5.0 版本的发布，我们很高兴的宣布，Nacos已经正式支持基于TTL的服务实例自动注销功能。这个功能一部分是响应社区关于TTL功能的需求，更重要的一部分，这也是Nacos服务发现自然演进的一个方向。

从 0.5.0 版本开始，用户通过客户端SDK注册的实例，将默认开启TTL功能，实例会默认每5秒向服务端发送一次心跳，如果Nacos服务端15秒内没有收到实例的心跳，则会将实例置为不健康，如果30秒没有收到心跳，则会将直接将实例删除。Nacos的TTL功能，补充了Nacos作为注册中心在处理实例下线的另一种行为，通过灵活可动态配置的参数，用户还可以根据实际的应用场景任意切换使用这两种行为中的一种。

Nacos的TTL功能虽然还处在实验性质，主要有以下特色：

• 进一步无缝融入SpringCloud生态和Dubbo生态

Nacos在最初的规划中，就已经计划能够帮助存量用户做无缝平滑迁移。而无缝平滑迁移除了注册中心的功能的完整性，体验、性能、一些重要的认知也能够从老注册中心接续过来。例如Eureka作为Spring Cloud里的主流注册中心，其默认行为就是会在没有收到实例心跳90秒后，将实例自动注销。而 Dubbo 里用的比较多的Zookeeper，也会使用临时节点，依托于Session超时时间来实现TTL功能。这这两种场景中，服务实例的注册基本都是通过服务提供端(Provider)使用注册中心客户端来完成的。Nacos目前已经提供了Spring Cloud体系的服务发现的完整解决方案，同时对Dubbo的适配和支持也会在最近的版本中释放出来。

• 服务级别"元数据(metadata)"不会自动注销

Nacos支持服务、集群和实例多级别的元数据信息，与服务实例可以被自动注销相对的，服务本身的元数据信息不能随着服务的下线而丢失,因为这些元数据通常是在创建服务时有人为设定上去的（例如负载均衡策略，权重规则，保护阈值等）。这意味着同一个服务的实例的上上下下，再注册上来的时候，应该依然保有服务原来设定的相关的元数据信息。

在Eureka或者Consul中，由于并不支持服务级别设定任何元信息，因此当实例都临时下线时，整个服务也就查询不到任何存在过的痕迹了。而服务级别的元信息作为Nacos的一个非常重要的特色功能，未来会基于此开放一系列流量控制类的特色功能，都决定了Nacos服务本身的元数据信息不能随着服务的下线而丢失，另一方面，在客户端注册实例时，不允许提交服务级别的元信息，这样也保证了单个实例的注册或者注销不会影响服务级别的配置。我们提供了控制台来对服务元数据进行便捷的创建和编辑。

• 将HSF的注册中心ConfigServer融入Nacos

在阿里巴巴集团内部，著名的HSF的注册中心ConfigServer支持的就是长连接注册模式(renew&TTL)，因此当长连接断开时，自然而然的就会将实例注销掉。为了支持未来将HSF一些优秀的特性迁移和输出到Dubbo上，Nacos会逐渐将ConfigServer的核心能力融入到Nacos当中，而TTL则也是这个事情的基础。

而同时，Nacos非常看中产品在云上的适用性，在公有云上，因为用户往往注册到注册中心的IP是一个VPC的外部IP，因为公有云安全策略的限制，注册中心一般是不允许主动发起到VPC内的连接来做健康检查的，只能通过客户端上报心跳的模式来检查健康状态，也只有在客户端上报的模式下，才能启用自动注销功能。Nacos此次的TTL功能，很好的衔接了公有云和内部ConfigServer输出的需求，为后续的融合做好了初步的准备。

Spring Cloud for Alibaba with Nacos​

就像 SpringOne Platform 2018 大会上 Spring 开发者 @Roy Clarkson 和 @Ollie Hughes 在 《Cloud-Native Java with Spring Cloud Services》 (YouTube视频地址) 演讲中阐述的那样，采用微服务设计模式，首要的就是选择 “External Configuration” “Service Registry” “Circuite Breaker” 的实现，而 Spring Cloud for Alibaba 这个项目则旨在通过将阿里巴巴在服务化以及阿里云上基于Aliware支撑各行业的微服务产品打包在一个stack里，给你提供开发支撑大规模微服务应用系统的一站式解决方案, 正如项目所述:

“The Spring Cloud Alibaba project, consisting of Alibaba’s open-source components and several Alibaba Cloud products, aims to implement and expose well known Spring Framework patterns and abstractions to bring the benefits of Spring Boot and Spring Cloud to Java developers using Alibaba products.”

随着 Spring Cloud for Alibaba 0.2.0 的发布，Nacos Configuration, Nacos Service Discovery 和 Sentinel Circuite Breaker 都已一网而聚之。

想了解如何在Spring Cloud中快速开始使用 Nacos 做配置中心和服务发现，可以点击这里。

持续优化用户体验​

正如Nacos团队在开源立项之初发下的宏愿，Nacos希望通过未来团队的持续努力，能给Nacos贴上希望的标签，而追求产品的极致易用性永远是Nacos团队的核心关注点之一，Nacos 0.5.0 版本就社区近期反馈较多的的一些体验问题做了积极的修复和优化，这其中包括前端UI的优化，启动状态信息展示的优化,性能调优等等，

#177 Console supports registering new empty service and delete empty service. #222 print more nacos server start status info in start.log. #251 Console Editor Optimization. #254 DataId and group are required in historical version and listener query. #258 Remove the Balloon of DataId/Group.

更多的优化和release信息见 nacos github

蓬勃发展的 Nacos 社区​

DISS is cheap, show me your hand 比吐槽更重要的是搭把手，参与社区一起发展Nacos

• 作为用户关注和加入 Nacos 社区

Nacos 社区正在蓬勃发展，截止到发文为止，Nacos 短短几个月已经有5个微信群，其中4个已满员，1个QQ群，1个钉钉群，关注 Nacos 的社区人数已经近3000人，在 Nacos 群里跟 “道（基）友” 切磋技术，交流经验，招聘交友，抢抢红包...不亦乐乎。

要加入 Nacos 微信社区，你可以通过扫下面的“超哥”的微信二维码，让“超哥” 帮你拉入 “Nacos社区微信交流群”

• 作为代码贡献者加入 Nacos 社区

从Nacos用户发展而成贡献者顺理成章，而Nacos开发团队也确实在日趋壮大，从开始的只有4个代码contributor发展到目前的24个，随着阿里巴巴其他团队成员如 @小马哥 等人，虎牙直播的 @张波 @周健 团队等人，nacos-docker-k8s 贡献者 @张龙，前端的主要贡献者饿了么 @王彦民，Spring Cloud中文社区创立者 @许进 等的陆续加入，相信未来Nacos社区的力量未来会越来越强大。

而社区也正在计划在合适的时机上，将在Nacos官网 nacos.io 中添加团队介绍页，将大家正式公布于众，欢迎大家加入Nacos社区，贡献社区。用Apache的话说，“社区高于代码”!

新人时刻 - "什么是Nacos？"​

还不知道什么是Nacos? 没关系，在github上star一下跟程序猿兄弟打个招呼吧!!

Nacos 是阿里巴巴于7月份新开源的项目，Nacos的主要愿景是期望通过提供易用的 动态服务发现、服务配置管理、服务共享与管理 的基础设施，帮助用户在云原生时代更好的构建、交付、管理自己的微服务平台。

github项目地址在 这里

更多与 Nacos 相关的开源项目信息​

• Nacos
• Nacos DNS-F
• Nacos Docker
• Nacos Spring Project
• Nacos Spring Boot
• Spring Cloud Alibaba
• Dubbo
• Sentinel
• Spring Cloud
• Nepxion Discovery
• Spring Cloud Gateway Nacos

I. 活动任务列表​

• 阅读官网文案，找官网bug, 给中、英文官网提建设性建议
• 阅读中英文档，找文档bug, 给中、英文档改善提建议（尤其是关注英文翻译不好的地方，因为英文都是我们程序员自己撸的）
• 尝试下代码 ->编译打包 -> 启动Nacos server -> 停止Nacos server流程，提出改进意见
• 尝试配置以及启动多节点 Nacos 集群模式任务，提改进意见
• 尝试使用Nacos Java SDK, 给Java SDK提改进建议
• 尝试使用Nacos Open API，给OpenAPI提改进建议
• 尝试根据《如何贡献Nacos文档 TODO》试一下 贡献流程，给贡献者流程提建议
• 给Nacos提需求、发展计划、想法和要求等

II. 活动参与方式​

• 扫描 “超哥” 微信2微码，让超哥帮助加入 “Nacos社区交流群”

  

• 选择I 中的一个或者多个体验任务

• 发现问题或者BUG之后，按照III中的《问题Report方式》，发一个相应的 github issue, 并指派给 @ github账号xuechaos

III. 问题Report方式​

• 流程说明 TODO

IV. 奖励方式​

• 我们正在为参与并作出突出贡献的小伙伴定制一些小礼品，会考虑快递给过程中有突出贡献的小伙伴
• 礼物虽轻，但希望能表达对你们的帮助的感激之情的万一

V. 其它说明​

• 我们不确定每个建议最后都会被采用，但是我们尽量会跟您沟通我们基于何种考虑，您的建议我们最后没有采用
• 尽量通过邮件列表或者report issue的方式，而不是在微信群里report问题，以便将我们的沟通过程文档化和更容易沉淀

Nacos 被CNCF 纳入landscape大图。​