目录
一：Nacos注册中心
1. 认识和安装Nacos
2. Nacos快速入门
3. Nacos服务分级存储模型
①Nacos服务分级存储模型
②NacosRule负载均衡
③根据权重负载均衡
4. Nacos环境隔离
二：Nacos和Eureka的对比
tips：前些天突然发现了一个巨牛的人工智能学习网站，通俗易懂，风趣幽默，忍不住分享一下给大家，感兴趣的同学可以进行学习人工智能学习网站
一：Nacos注册中心
前面已经讲解了Eureka注册中心，接下来就学习一下Nacos注册中心！实际上Nacos还能作为配置中心，后面会详细叙述！
| Dubbo | SpringCloud | SpringCloudAlibaba | |
| 注册中心 | zookeeper、Redis | Eureka、Consul | Nacos、Eureka |
| 服务远程调用 | Dubbo协议 | Feign（http协议） | Dubbo、Feign |
| 配置中心 | 无 | SpringCloudConfig | SpringCloudConfig、Nacos |
| 服务网关 | 无 | SpringCloudGateway、Zuul | SpringCloudGateway、Zuul |
| 服务监控和保护 | dubbo-admin，功能弱 | Hystix | Sentine |
1. 认识和安装Nacos
Nacos阿里巴巴的产品（需要下载、安装、启动），现在是SpringCloud中的一个组件。相比Eureka（Spring已经集成了）功能更加丰富，在国内受欢迎程度较高！Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台，在SpringCloud Alibaba中，我们使用nacos进行服务的注册发现、服务的配置管理。
第一步：下载安装包
在Nacos的GitHub页面，提供有下载链接，可以下载编译好的Nacos服务端或者源代码：
GitHub主页：https://github.com/alibaba/nacos
GitHub的Release下载页：https://github.com/alibaba/nacos/releases
第二步：解压、配置
本次采用1.4.1.版本的Nacos，解压后目录如下：
Nacos的默认端口是8848，如果你电脑上的其它进程占用了8848端口，请先尝试关闭该进程。 当然也可以修改Nacos的默认端口，在conf目录的application.properties中
第三步：启动
Nacos的启动非常简单，进入bin目录，结构如下
打开cmd，执行以下命令进行启动
startup.cmd -m standalone # 单机启动
第四步：访问登录
在浏览器输入地址：http://127.0.0.1:8848/nacos即可：
账号密码都是nacos：登录后的页面
2. Nacos快速入门
Nacos的使用步骤和Eureka的使用步骤基本不变，把原来的Eureka配置Nacos即可！
第一步：在cloud-demo父工程中添加spring-cloud-alilbaba-dependices的管理依赖
回顾：Eureka是在cloud-demo父项目下创建了一个子项目eureka-server：进行eureka-server依赖的引入，启动类上加@EnableEurekaServer注解，application.yaml中配置端口号、服务器名称、服务器地址！
背景：我们知道SpringCloud是微服务的一站式解决方案，是众多组件的集合，而因为SpringCloud中几乎所有的组件使用的都是Netflix公司的产品，其中大部分已经进入了停止更新或者维护阶段。我们需要一些别的组件来代替它们，基于此，SpringCloud Alibaba诞生了，其中Nacos就是其中一员，所以我们需要先引入SpringCloudAlibaba依赖。
<!--引入SpringCloudAlibaba依赖-->
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-alibaba-dependencies</artifactId><version>2.2.6.RELEASE</version><type>pom</type><scope>import</scope>
</dependency>第二步： 注释掉原来order-service和user-service的关于eureka依赖，添加nacosy依赖
注：服务提供者和服务消费者引入的依赖都是nacos-discovery依赖
<!--nacos客户端依赖 -->
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>第三步：修改user-service 和 order-service中的application.yml文件，注释eureka地址，添加nacos地址（服务器名称还用原来的）
# nacos服务端地址
spring:cloud: nacos:server-addr: localhost:8848第四步：启动并测试
3. Nacos服务分级存储模型
①Nacos服务分级存储模型
场景：假设现在某个功能user-service有多个实例，之前都是两层的概念：一个服务可以有多个实例！但是把所有实例都部署在一个机房，不安全，所以把多个实例放入多个机房中部署。Nacos服务分级存储模型就是引入了这样的概念，把同在同一个机房的实例成为一个集群；所以对于Nacos模型：一级是服务、往下是集群、最后是实例。
服务跨集群调用问题
注：服务调用尽可能选择本地集群的服务，跨集群调用延迟较高；本地集群不可访问时，再去访问其它集群！
服务集群属性
回到Nacos控制台查看此时的集群属性：default（表示没有）
如何设置服务集群的属性？在user-service原有的配置中增加discovery属性
spring:cloud: nacos:server-addr: localhost:8848 # nacos服务端地址discovery: cluster-name: HZ # 配置集群名称，也就是机房位置，例如：HZ，杭州此时uservice-service准备3个实列：UserApplication---8081、UserApplication1---8082、UserApplication2---8083；先按照上述的配置启动UserApplication---8081和UserApplication1---8082；然后把上述的集群名称改为SH后在启动UserApplication2---8083
给order-service也加入集群属性
spring:cloud: nacos:server-addr: localhost:8848 # nacos服务端地址discovery: cluster-name: HZ # 配置集群名称②NacosRule负载均衡
前面已经分析了要尽可能的使用本地的集群，不去跨域访问；所以此时就测试连续访问三次会不会全部访问的是HZ集群，不访问SH集群？
运行结果： 还是轮循访问，没有优先访问本地的；此时要修改负载均衡（原来默认的就是轮循调度）！
在order-service中设置负载均衡的IRule为NacosRule，这个规则优先会寻找与自己同集群的服务：
user-service:ribbon:NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则 此时再次连续访问三次：
优先访问本地的集群，在本地集群的基础上【随机】方式负载均衡！
那如果此时本地服务HZ都停掉了呢？
本地服务找不到，会跨集群访问，也能访问成功，但是会收到警告！
总结
①优先选择同集群服务实例列表；
②本地集群找不到提供者，才去其它集群寻找，并且会报警告；
③确定了可用实例列表后，再采用随机负载均衡挑选实例；
③根据权重负载均衡
实际部署中会出现这样的场景：
服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求；Nacos提供了权重配置来控制访问频率，权重值一般是0-1之间的，权重越大则访问频率越高！
第一步：在Nacos控制台可以设置实例的权重值，首先选中实例后面的编辑按钮
第二步：将权重设置为0.1，测试可以发现8081被访问到的频率大大降低
思考：当权重为0时有什么用？
实际上当权重为0时，服务器就完全不会被访问；当我们做版本升级时可以先设置为权重0，去访问其它服务器，版本升级结束，在设置权重为很小的一个值，放进来极少的客户进行测试；测试没问题在进行广泛的升级服务！
总结
①Nacos控制台可以设置实例的权重值，0~1之间；
②同集群内的多个实例，权重越高被访问的频率越高；
③权重设置为0则完全不会被访问；
4. Nacos环境隔离
Nacos首先是一个注册中心，还是一个数据中心；所以Nacos在做数据和服务的管理，会有一个环境隔离的概念。
环境隔离-namespace
①Nacos中服务存储和数据存储的最外层都是一个名为namespace（命名空间）的东西，用来做最外层隔离；
②namespace内部会有一个group属性(组)，同一个命名空间的多个实例还可以分组；业务相关性比较高的就可以放到同一个组；
③组内就是具体的服务，服务下面就是集群，集群下面就是实例；
实际上在Nacos控制台上有一个默认的命名空间public，我们原先的实例都是放到这个组里的
需求：把order-service放到一个新的命名空间里
第一步：Nacos控制台上创建namespace，用来隔离不同环境
第二步：填写一个新的命名空间信息
第三步：保存后会在控制台看到这个命名空间的id
注：id可以不填写，根据UUID自动生成即可
第四步：修改application.yml文件，添加namesapce命名空间
spring:cloud: nacos:server-addr: localhost:8848 # nacos服务端地址discovery:cluster-name: SH # 集群namespace: e70e8b60-ea7e-40e0-a995-0b714190f7bd # 填写ID ,命名空间
第五步： 重启order-service后，再来查看控制台
public命名空间：
dev命名空间：
第六步：此时访问order-service，因为命名空间namespace不同，会导致找不到user-service
浏览器找不到服务：
注：实际上是有三个服务user-service在public的，但是order-service在dev，不同的命名空间之间无法访问（前面我们学习的不同集群是可以访问的，只是会报警告）！
控制台会报错：
总结：
①每个命名空间namespace都有唯一id；
②服务设置命名空间namespace时要写id而不是名称；
③不同命名空间namespace下的服务互相不可见；
二：Nacos和Eureka的对比
截止到现在我们已经学习了两个注册中心：Eureka和Nacos，下面就进行对比学习一下！
细节：前面我们创建的是类默认都是临时实例
从执行过程分析Eureka和Nacos的异同
同
①无论是Eureka还是Nacos当服务提供者启动时，都会把信息提交给注册中心，注册中心把这些信息保存下来；
②当消费者需要时会找注册中心去定时拉取；实际上这个拉取的动作不是每一次都要做，服务消费者会把拉取到的信息缓存到一个列表当中（每隔30秒重新拉取一次）；
③消费者拿到服务列表之后，负载均衡挑选一个后远程调用提供者；
异
第一个差别：服务提供者的健康监测，Nacos会把服务提供者划分为：临时实例和非临时实列。对于临时实列采用心跳进行检测（这点是和Eureka保持一致，但是频率不一样，nacos会慢一点），发现挂了就进行剔除；对于非临时实列Nacos不会要求进行心跳，Nacos进行主动询问，发现挂了会标记不健康了，等待恢复、不会剔除。
第二个差别：消费者的拉取服务，Eureka采用的定时拉取（每隔30秒），不能做到及时更新；Nacos会主动推送变更消息，Eureka采用的是pull，而Nacos是pull+push的结合；如果Nacos发现有服务挂了会立刻推送push给消费者，及时去更新。
服务注册到Nacos时，可以选择注册为临时或非临时实例，通过下面的配置来设置：
spring:cloud: nacos:server-addr: localhost:8848 # nacos服务端地址discovery:cluster-name: SH # 集群namespace: e70e8b60-ea7e-40e0-a995-0b714190f7bd #填写ID，指定命名空间ephemeral: false #设置为非临时实例①默认的是临时实列，此时关闭order-service，这个服务会被干掉
②修改epemeral为false，修改为非实例，此时关闭服务
不会被剔除，等待恢复！
总结
1. Nacos与eureka的共同点
①都支持服务注册和服务拉取；
②都支持服务提供者心跳方式做健康检测；
2. Nacos与Eureka的区别
①Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式；临时实例心跳不正常会被剔除，非临时实例则不会被剔除。Eureka采用的就是心跳检测，不正常直接被剔除。
②Nacos支持服务列表变更的消息推送模式，服务列表更新更及时，是拉取和推送的结合。Eureka只是单纯的拉取，不能及时更新。
③Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式。
注：AP/CP模式是指在分布式系统中，数据的 可用性 和 一致性 是不可兼得的，因此需要在可用性和一致性之间做出权衡。其中A（Availability）可用性、C（Consistency）一致性、P（Partition tolerance）分区容错性。
