一、什么是Nacos？

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

Nacos vs Spring Cloud

• Nacos = Spring Cloud Eureka + Spring Cloud Config

• Nacos 可以与 Spring, Spring Boot, Spring Cloud 集成，并能代替 Spring Cloud Eureka, Spring Cloud Config。

• 1.通过 Nacos Server 和 spring-cloud-starter-alibaba-nacos-config 实现配置的动态变更。

• 2.通过 Nacos Server 和 spring-cloud-starter-alibaba-nacos-discovery 实现服务的注册与发现。

二、Nacos主要提供以下四大功能：

• 1.服务发现与服务健康检查

  • Nacos使服务更容易注册自己并通过DNS或HTTP接口发现其他服务。Nacos还提供服务的实时健康检查，以防止向不健康的主机或服务实例发送请求。

• 2.动态配置管理

  • 动态配置服务允许您在所有环境中以集中和动态的方式管理所有服务的配置。Nacos消除了在更新配置时重新部署应用程序和服务的需要，这使配置更改更加高效和灵活。

• 3.动态DNS服务

  • Nacos支持加权路由，使您可以更轻松地在数据中心的生产环境中实施中间层负载平衡，灵活的路由策略，流量控制和简单的DNS解析服务。它可以帮助您轻松实现基于DNS的服务发现，并防止应用程序耦合到特定于供应商的服务发现API。

• 4.服务和元数据管理

  • Nacos提供易于使用的服务仪表板，可帮助您管理服务元数据，配置，kubernetes DNS，服务运行状况和指标统计。

三、Nacos作为注册中心

1.先在官网上下载nacos中间件 下面教程有启动步骤

• https://nacos.io/zh-cn/docs/quick-start.html

2.程序启动默认占用的端口是8848（珠穆朗玛峰的高度）
我们可以对端口进行修改，用编辑器打开bin目录下的startup.cmd文件 添加一行代码
set "JAVA_OPT=%JAVA_OPT% --server.port=9090
端口号就改成9090了，如图1所示：

还可以在conf文件下的application.properties中添加

server.port=9090

来修改端口，也可以在该文件下指定数据源，方法和springboot中配置一样（单机模式模式下默认连接的是javaDB），该文件夹下 nacos-logback.xml自然是修改nacos日志输出规则的。

如果是0.3.0版本 启动后访问下面这个地址：

http://127.0.0.1:8848/nacos/index.html

会有一个图形化界面，如图2所示：

这个配置管理项便是nacos的注册中心服务端了，下面还有一个服务管理，是nacos注册中心 图形化界面的服务端，以后做介绍。启动成功后我们就可以开始写我们的java代码了。

3.先新建一个springboot项目，添加如下依赖

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
  <version>0.2.0.RELEASE</version>
</dependency>

在resource目录下加入 bootstrap.properties文件 并添加配置中心相关信息
bootstrap.properties：

#服务名
spring.application.name=nacos-config-example
# 配置中心url
spring.cloud.nacos.config.server-addr=127.0.0.1:8848

相应的application.properties的内容写到配置中心里面去，如图3、图4所示：


在项目启动时就会去配置中心去读取配置信息（本地的配置文件application.properties还能用，但优先级低于配置中心的配置）
如果你不想用nacos提供的控制台，nacos也提供了java开发服务端的sdk和api,我们可以用sdk开发配置中心服务端，用java代码去操作配置中心,sdk的文档可参看官方文档。

Nacos与eureka注册中心对比

阿里的nacos : 性能最好

1.他同时支持AP和CP模式,他根据服务注册选择临时和永久来决定走AP模式还是CP模式,
2.他这里支持CP模式对于我的理解来说,应该是为了配置中心集群,因为nacos可以同时作为注册中心和配置中心,
3.因为他的配置中心信息是保存在nacos里面的,假如因为nacos其中一台挂掉后,还没有同步配置信息,就可能发生配置不一致的情况.,
  配置中心的配置变更是服务端有监听器,配置中心发生配置变化,然后服务端会监听到配置发生变化,从而做出改变

eureka+spring cloud config:

1.性能也不差,对于服务数量小于上千台来说,性能没有问题
2.eureka: 可以做注册中心,完全AP,支持注册中心之间的节点复制,同时支持服务端同时注册多个注册中心节点, 所以不存节点信息不一致的情况
3.config: 单独服务,是从git仓库拉取配置信息,然后服务端从config服务里面拉取配置信息缓存到本地仓库， 这里配置的变更比较麻烦,他需要结合bus组件,同时约束了只能用rabbitmq和kafka来进行通知服务端进行配置变更。
  但是保证了数据的一致性,因为他的配置信息在git仓库上,git仓库只有一个,就会数据一致      

Nacos与apollo配置中心对比

比对结论：

初步结论为：使用Nacos代替Eureka和apollo，主要理由为：
相比与Eureka：

• (1)Nacos具备服务优雅上下线和流量管理（API+后台管理页面），而Eureka的后台页面仅供展示，需要使用api操作上下线且不具备流量管理功能。
• (2)从部署来看，Nacos整合了注册中心、配置中心功能，把原来两套集群整合成一套，简化了部署维护
• (3)从长远来看，Eureka开源工作已停止，后续不再有更新和维护，而Nacos在以后的版本会支持SpringCLoud+Kubernetes的组合，填补 2 者的鸿沟，在两套体系下可以采用同一套服务发现和配置管理的解决方案，这将大大的简化使用和维护的成本。同时来说,Nacos 计划实现 Service Mesh，是未来微服务的趋势
• (4)从伸缩性和扩展性来看Nacos支持跨注册中心同步，而Eureka不支持，且在伸缩扩容方面，Nacos比Eureka更优（nacos支持大数量级的集群）。
• (5)Nacos具有分组隔离功能，一套Nacos集群可以支撑多项目、多环境。

相比于apollo

• (1) Nacos部署简化，Nacos整合了注册中心、配置中心功能，且部署相比apollo简单，方便管理和监控。
• (2) apollo容器化较困难，Nacos有官网的镜像可以直接部署，总体来说，Nacos比apollo更符合KISS原则
• (3)性能方面，Nacos读写tps比apollo稍强一些

结论：使用Nacos代替Eureka和apollo

四、Nacos其他特性

1.Nacos Sync的价值

• NacosSync是一个支持多种注册中心的同步组件,基于Spring boot开发框架,数据层采用Spring Data JPA,遵循了标准的JPA访问规范,支持多种数据源存储,默认使用Hibernate实现,更加方便的支持表的自动创建更新
• 使用了高效的事件异步驱动模型, 支持多种自定义事件,使得同步任务处理的延时控制在3s,8C16G的单机能够支持6K的同步任务
• NacosSync除了单机部署,也提供了高可用的集群部署模式,NacosSync是无状态设计,将任务等状态数据迁移到了数据库,使得集群扩展非常方便
  抽象出了Sync组件核心接口,通过注解对同步类型进行区分,使得开发者可以很容易的根据自己需求,去扩展不同注册中心,目前已支持的同步类型:
  • Nacos数据同步到Nacos
  • Zookeeper数据同步到Nacos
  • Nacos数据同步到Zookeeper
  • Eureka数据同步到Nacos
  • Consul数据同步到Nacos

系统模块架构

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

2.DNS - F 的技术价值
Nacos提供DNS-F功能
DNS-F落地的技术价值

• 填补了内部微服务业务没有全局动态调度能力的空白
• 解决了服务端棉铃挑战：时延大、解析不准、故障牵引慢
• 支持服务端多种调度需要
• 加速外部域名解析
• 服务故障牵引秒级生效
• 提供专线流量牵引能力