1.Nacos安装部署
1.1 下载安装
nacos官网提供了安装部署教程，其下载链接指向github官网，选择合适版本即可。如访问受阻可直接使用以下最新稳定版压缩包：，后续我们也可能会更改为其他版本做更多测试。
公司一般会采用最新版落后几个版本的稳定版当做生产版本，避免一些新特性引发的未知问题。
1.2 启动
● window请直接进入路径：cd nacos/bin后双击startup.sh启动，或按照下述指令启动
cd nacos/bin
startup.cmd -m standalone
● linux或mac进入路径：nacos/bin/，cmd控制台执行
cd nacos/bin
sh startup.sh -m standalone
注意：如存在端口冲突，可至路径：nacos/conf/application.properties 中修改后启动
注意：nacos存储路径不可有中文。如遇启动异常，
● mac可至路径：nacos/logs/start.out 查看具体错误信息
● windows可至路径：nacos/logs/nacos.log 查看具体错误信息，正常启动日志如下
1.3 访问
成功启动后访问如下地址：http://localhost:8848/nacos/#/login，默认用户名/密码：nacos/nacos
2.整合Nacos注册中心
2.1 依赖导入
父工程新增spring-cloud-alibaba依赖
com.alibaba.cloud
spring-cloud-alibaba-dependencies
2.2.6.RELEASE
pom
import
因为Spring-cloud-alibaba自身也是集成了多个组件，所以这里只需引入alibaba大管家即可
子工程去除eureka依赖
注意order-service、user-service均需删除
子工程新增spring-cloud-alibaba-nacos依赖
注意：不同于父工程，是nacos-discovery，order-service、user-service均需添加
com.alibaba.cloud
spring-cloud-starter-alibaba-nacos-discovery
至此，三个工程pom如下(eureka相关工程无需操作)：
● 父pom：
● user-service pom：
● order-service pom：
2.2 配置文件修改注册中心
子工程均去除eureka注册配置，均新增nacos配置
spring:
cloud:
nacos:
server-addr: localhost:8848 #nacos服务地址
至此，两个业务工程application.yml如下(eureka相关工程无需操作)：
● order-service：
● user-service：
2.3 启动工程并验证
启动应用后访问Nacos会发现服务已完成注册
如启动遇到工程仍存在Eureka依赖，可尝试重新编译整个工程，或手动删除target文件夹后再启动
3.Nacos服务分级模型
不同于Zookeeper没有针对服务发现设计数据模型，它的数据是以一种更抽象的树形K-V组织的，因此理论上可以存储任何语义的数据。而Eureka或Consule都做到了实例级别的数据扩展，这能满足大多数场景但无法满足大规模和多环境的服务数据存储。Nacos经过多年经验后提炼出上述模型，其特点在于：服务-集群-实例三层模型，可以满足所有场景下的数据存数和管理。
通过设置不同的集群所在参数，可以保证相同集群间优先调用，减少网络开销。当本地集群服务无法拉取时，再去跨集群调用。对于此工程我们只需要设置提付提供者集群参数：
cloud:
nacos:
server-addr: localhost:8848 # nacos服务地址
discovery:
cluster-name: HZ # 声明集群名称杭州
此时访问Nacos会发现其增加了集群属性发生变化，原为：Default
为模拟多集群场景，此时我们复制一个新的userApplicatio3启动类，具体操作步骤如下：
● 复制一个新的userApplicatio3启动类，设置其启动端口：-Dserver.port=8083
● 更改配置文件集群属性为GZ（注意不要停userApplication、userApplication2，否则原注册信息会失效）
● 启动userApplication3并访问nacos
此时查看Nacos服务信息会发现，已经有了两个集群信息。
此时我们就完成Nacos分级模型的验证，在实际的工作、生产环境中，一般来说服务都是同集群部署，不需要开发人员声明式感知服务所在集群信息。
4.NacosRule负载均衡策略
修改oder-service集群属性、负载均衡策略，调整为如下：
注意：此时需要将OrderApplication中的代码声明式负载均衡策略注释或删除（约定大于配置），否则失效
cloud:
nacos:
server-addr: localhost:8848 #nacos服务地址
discovery:
cluster-name: HZ # 声明集群名称杭州
userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
ribbon:
NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则
此时重启应用后会发现orderservice集群属性存在变化：
访问oder-service服务会发现其优先匹配HZ集群的userApplication、userApplication2。
上面我们提到优先调用本集群的服务，当本集群服务实例不存在时会考虑跨集群调用，故我们停掉userApplication、userApplication2，再做一次访问会发现访问正常，同时请求日志打到userApplication3。
5.Nacos权重控制
基于上一章节的负载均衡算法，我们可以了解到：存在部分机器性能更优，此时该机器理应得到更多的流量分配，nacos通过设置服务权重解决这一问题，权重越大访问评率越高，配置页面如下：
编辑后再次访问服务，会发现流量产生明细变化。如权重设置为0对于服务调用方等同于服务下线。
6.Nacos环境隔离
日常开发过程中，我们一般会有dev、test、poc、prod等多个环境，同一个服务不同环境之间因存在代码不一致问题肯定需要做隔离调度，Nacos通过namespace解决此问题，配置页面如下，我们新增一个dev：
增加完成后列表发生变化如下：
我们尝试在order-service中增加namespace，并重启服务再次访问，注意：namespace后字符串为上图ID
cloud:
nacos:
server-addr: localhost:8848 #nacos服务地址
discovery:
cluster-name: HZ # 声明集群名称杭州
namespace: 06e5f1a5-9ecb-438a-aae0-b434073bb973 # 命名空间
此时会因不在同一命名空间导致无法访问（因userservice暴露服务时未声明namespace，默认public）
我们修改user-service的配置文件，增加namespace，并重启服务再次访问会发现服务恢复正常
7.Nacos临时实例与持久化实例
Nacos在定义上区分临时实例和持久化实例，其主要区分关键是健康检查的方式。
● 临时实例：客户端上报模型，能够自动摘除不健康实例，无需持久化实例存储
● 持久实例：服务端反省探测模式，客户端因不上报心跳故不会自动摘除下线实例
在大中型公司，两种类型一般都会使用，基础的组件如数据库、缓存等往往不能上报心跳，这种类型的服务在注册时就需要作为持计划实例注册。而上层的业务服务，如微服务或Dubbo服务，服务的Provider端支持添加心跳，此时就可以使用临时实例的注册方式。
其配置文件配置如下：
cloud:
nacos:
server-addr: localhost:8848 # nacos服务地址
discovery:
cluster-name: HZ # 声明集群名称杭州
namespace: 06e5f1a5-9ecb-438a-aae0-b434073bb973 # 命名空间
ephemeral: false # 设置为非临时实例
8.Nacos更多总结分析
，如无法访问可链接至：https://kdocs.cn/l/ccGuOOfpPjFv，图片展示如下：
9.总结
本节从Nacos安装、运行到具体规则配置，带领读者们深度参与了Nacos日常使用场景，Nacos作为注册中心可以优雅替换Eureka也离不开SpringCloud Alibaba的开源贡献。作为国内主流的配置、注册中心，Nacos在国内多数微服务公司都有使用，感兴趣的可以阅读一下本节推荐资料，笔者整理归纳在本文第8章节。
Nacos除了能够实现服务注册发现(AP)，此外还有个重要特性：配置管理(CP)，我们将在下一章节展开学习。
思考问题
● Nacos是什么？解决了什么问题？
● Nacos是如何优雅替换Eureka的？
● Nacos实现的是客户端，还是服务端负载均衡？
● Nacos如何实现注册中心?
10.推荐阅读资料
● Nacos白皮书：
