1.nacos简介
1.1 描述
Nacos 是一个集服务发现、服务配置_、服务元数据及流量管理于一体的管理中心，能帮助我们更好的发现、配置和管理微服务:
Nacos 支持几乎所有主流类型的“服务”的发现、配置和管理：
Kubernetes Service ,
gRPC & Dubbo RPC Service ,
Spring Cloud RESTful Service
1.2 生态图
1.3 架构图及名词解释
命名空间（Namespace）
用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离，例如开发测试环境和生产环境的资源（如配置、服务）隔离等。
配置管理 (Configuration Management)
系统配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动。
配置项 (Configuration Item)**
一个具体的可配置的参数与其值域，通常以 param-key=param-value 的形式存在。例如我们常配置系统的日志输出级别（logLevel=INFO|WARN|ERROR） 就是一个配置项。
配置集 (Configuration Set)
一组相关或者不相关的配置项的集合称为配置集。在系统中，一个配置文件通常就是一个配置集，包含了系统各个方面的配置。例如，一个配置集可能包含了数据源、线程池、日志级别等配置项。
配置集 ID（Data ID）
Nacos 中的某个配置集的 ID。配置集 ID 是组织划分配置的维度之一。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。Data ID 通常采用类 Java 包（如 com.taobao.tc.refund.log.level）的命名规则保证全局唯一性。此命名规则非强制。
配置分组（Group）
Nacos 中的一组配置集，是组织配置的维度之一。通过一个有意义的字符串（如 Buy 或 Trade ）对配置集进行分组，从而区分 Data ID 相同的配置集。当您在 Nacos 上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景：不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。
配置快照 (Configuration Snapshot)
Nacos 的客户端 SDK 会在本地生成配置的快照。当客户端无法连接到 Nacos Server 时，可以使用配置快照显示系统的整体容灾能力。配置快照类似于 Git 中的本地 commit，也类似于缓存，会在适当的时机更新，但是并没有缓存过期（expiration）的概念。
服务名（Service Name）
服务提供的标识，通过该标识可以唯一确定其指代的服务。
服务注册中心（Service Registry）
存储服务实例和服务负载均衡策略的数据库。
服务发现（Service Discovery）
在计算机网络上，（通常使用服务名）对服务下的实例的地址和元数据进行探测，并以预先定义的接口提供给客户端进行查询。
元信息（Metadata）
Nacos数据（如配置和服务）描述信息，如服务版本、权重、容灾策略、负载均衡策略、鉴权配置、各种自定义标签 (label)，从作用范围来看，分为服务级别的元信息、集群的元信息及实例的元信息。
应用（Application）
用于标识服务提供方的服务的属性。
服务分组（Service Group）
不同的服务可以归类到同一分组。
虚拟集群（Virtual Cluster）
同一个服务下的所有服务实例组成一个默认集群, 集群可以被进一步按需求划分，划分的单位可以是虚拟集群。
权重（Weight）
实例级别的配置。权重为浮点数。权重越大，分配给该实例的流量越大。
健康检查（Health Check）
以指定方式检查服务下挂载的实例 (Instance) 的健康度，从而确认该实例 (Instance) 是否能提供服务。根据检查结果，实例 (Instance) 会被判断为健康或不健康。对服务发起解析请求时，不健康的实例 (Instance) 不会返回给客户端。
健康保护阈值（Protect Threshold）
为了防止因过多实例 (Instance) 不健康导致流量全部流向健康实例 (Instance) ，继而造成流量压力把健康 健康实例 (Instance) 压垮并形成雪崩效应，应将健康保护阈值定义为一个 0 到 1 之间的浮点数。当域名健康实例 (Instance) 占总服务实例 (Instance) 的比例小于该值时，无论实例 (Instance) 是否健康，都会将这个实例 (Instance) 返回给客户端。这样做虽然损失了一部分流量，但是保证了集群的剩余健康实例 (Instance) 能正常工作.
2.为啥用他做注册中心呀?
2.1 cap是啥?
cap
Consistency:一致性,某个节点的写操作结果队后面通过其他节点的读操作课件
如果更新数据后,并发访问情况下可立即感知该更新,称为强一致性
若在之后的一段时间后(通常该段时间不固定),一定可以感知该更新,称为最终一致性
availability:任何一个没有发生故障的节点,必须在有限的时间内返回合理的结果.和HA(高可用性不一样)
partition tolerance:部分节点宕机或者无法与其他节点通信时,各分区间还可以保持
分布式系统的功能.要求至少一个分区可以提供服务的.
分布式系统中一致性,可用性,分区容忍性最多可同时满足两个.
一般分区容忍性都要求有保证,因此很多时候是在一致性和可用性之间有一个权衡.
如果保证CP:
1.如果硬要保证一致性的话,如果n1和n2之间网络不通,最终无法保证规定时间内返回合理的结果
AP:如果保证合理的时间返回指定的结果,网络通信故障就无法无法保证一致性.
2.2 consule/Eureka/nacos 类比
eureka
应用内/外：直接集成到应用中，依赖于应用自身完成服务的注册与发现，
ACP原则：遵循AP（可用性+分离容忍）原则，有较强的可用性，服务注册快，但牺牲了一定的一致性。
版本迭代：目前已经不进行升级
集成支持：只支持SpringCloud集成
访问协议：HTTP
雪崩保护：支持雪崩保护
上手：容易
consul
应用内/外：属于外部应用，侵入性小
ACP原则：遵循CP原则（一致性+分离容忍） 服务注册稍慢，由于其一致性导致了在Leader挂掉时重新选举期间真个consul不可用。
版本迭代：目前仍然进行版本迭代
集成支持：支持SpringCloud K8S集成
访问协议：HTTP/DNS
雪崩保护：不支持雪崩保护
上手：复杂一点
nacos
应用内/外：属于外部应用，侵入性小
ACP原则：通知遵循CP原则（一致性+分离容忍） 和AP原则（可用性+分离容忍）
版本迭代：目前仍然进行版本迭代
集成支持：支持Dubbo 、SpringCloud、K8S集成
访问协议：HTTP/动态DNS/UDP
雪崩保护：支持雪崩保护
上手：极易，中文文档，案例，社区活跃
3.上手步骤
3.1安装nacos服务
3.2 实现服务发现/讲解配置参数
spring.cloud.nacos.discovery.heart-beat-interval:
nacos客户端向服务端发送心跳的时间间隔，默认5s
注,若在3次心跳的间隔时间(默认15s)内服务端没有接受到该实例的心跳请求,则认为该实例不健康,该实例将无法被消费。如果再次经历3次心跳的间隔时间，服务端接受到该实例的请求，那么会立刻将其设置外健康，并可以被消费，若未接受到，则删除该实例的注册信息。推荐配置为5s，如果有的业务线希望服务下线或者出故障时希望尽快被发现，可以适当减少该值。
spring.cloud.nacos.discovery.heart-beat-timeout:
服务端没有接受到客户端心跳请求就将其设为不健康的时间间隔，默认为15s
注：推荐值该值为15s即可，如果有的业务线希望服务下线或者出故障时希望尽快被发现，可以适当减少该值。
spring.cloud.nacos.discovery.namespace:
命名空间ID，Nacos通过不同的命名空间来区分不同的环境，进行数据隔离，服务消费时只能消费到对应命名空间下的服务。
spring.cloud.nacos.discovery.naming-load-cache-at-start:
默认为false。客户端在启动时是否读取本地配置项(一个文件)来获取服务列表
注：推荐该值为false，若改成true。则客户端会在本地的一个文件中保存服务信息，当下次宕机启动时，会优先读取本地的配置对外提供服务。
spring.cloud.nacos.discovery.register-enabled:
该项目是否向注册中心注册服务，默认为true
注：如果服务从注册中心只消费服务，没有对外提供服务，那么该值可设置为false，可减少客户端线程池的创建，无需向服务端发送心跳请求，提高性能。
spring.cloud.nacos.discovery.server-addr
spring.cloud.nacos.discovery.watch-delay:
默认为30s。默认为true,客户端在启动时会创建一个线程池，该线程定期去查询服务端的信息列表，该请求不会立刻返回，默认等待30s，若在30s内，服务端信息列表发生变化，则该请求立刻返回，通知客户端拉取服务端的服务信息列表，若30s内，没有变化，则30s时该请求返回响应，客户端服务列表不变，再次发生该请求。
注：推荐该值为30s即可，无需修改
spring.cloud.nacos.discovery.watch.enabled:
默认为true,默认为true,客户端在启动时会创建一个线程池，该线程定期去查询服务端的信息列表，该请求不会立刻返回，默认等待30s，若在30s内，服务端信息列表发生变化，则该请求立刻返回，通知客户端拉取服务端的服务信息列表，若30s内，没有变化，则30s时该请求返回响应，客户端服务列表不变，再次发生该请求。
注:推荐该功能为true，这是nacos类似长连接推送服务变化的功能，不要关闭
spring.cloud.nacos.discovery.weight:
nacos支持服务端基于权重的负载均衡，该值默认为1 注:建议该值保持默认即可，因为代码可能会部署到不同的服务器上.
3.3 实现服务发现/讲解配置参数
-
导入jar包: compile group: 'com.alibaba.cloud', name: 'spring-cloud-starter-alibaba-nacos-config', version: '2.1.2.RELEASE'; -
建立配置文件bootstrap.yml:如下:
3.在config服务端界面创建要读取的yml文件: xscyl-commom.yml xscyl-user.yml
4.在项目启动的时候添加上自动刷新
@RefreshScope
5.启动项目即可,就可从远程读取配置了
重要配置说明;
cloud:
nacos:
config:
# 启动监控的端口的ip地址和端口
server-addr: 10.15.5.32:8848
#dataID
file-extension: yml
# 命名空间,用于不同配置的分区割离
namespace: xscyl-dev
#通过此参数可以配置多个服务共享的data-id
shared-configs[0]:
data-id: xscyl-common.yml
refresh: true
#通过此参数可以配置服务独有的参数
extension-configs[0]:
data-id: xscyl-product.yml
refresh: true
#默认utf-8
encode:
#配置对应的组,默认为DEFAULT_GROUP
group:
# 客户端获取配置的超时时间
timeout:
endpoint:
# Nacos Server 对外暴露的 context path
context-path:
# 配置成nacos集群名称
cluster-name:
# 长轮询的超时时间
config-long-poll-timeout:
# 长轮询的重试次数
max-retry:
# 监听器首次添加时拉取远端配置,false
enable-remote-sync-config:
#默认客户端远程缓存目录{user.home/nacos/config}
3.原理简介
3.1什么是长轮询?
客户端发起一个请求到服务端，服务端收到客户端的请求后，并不会立刻响应给客户端，而是先把这个请求hold住，然后服务端会在hold住的这段时间检查数据是否有更新，如果有，则响应给客户端，如果一直没有数据变更，则达到一定的时间（长轮训时间间隔）才返回。
3.2服务注册与订阅完整流程.
Nacos 客户端进行服务注册有两个部分组成，一个是将服务信息注册到服务端，另一个是像服务端发送心跳包.
Nacos 客户端进行服务订阅时也有两部分组成，一个是不断从服务端查询可用服务实例的定时任务，
另一个是不断从已变服务队列中取出服务并通知 EventListener 持有者的定时任务.
3.3 服务配置中心原理
1.服务配置中心原理
客户端:
1.客户端是通过一个定时任务来检查自己监听的配置项的数据的，
一旦服务端的数据发生变化时，
2.客户端将会获取到最新的数据，并将最新的数据保存在一个 CacheData 对象中，
3.然后会重新计算 CacheData 的 md5 属性的值，此时就会对该 CacheData 所绑定的 Listener
触发 receiveConfigInfo 回调。
4.由此客户端获取到最新的数据
考虑到服务端故障的问题,客户端将最新数据获取后会保存在本地的.
客户端发起长轮训请求，
服务端收到请求以后，先比较服务端缓存中的数据是否相同，
如果不通，则直接返回
如果相同，则通过schedule延迟29.5s之后再执行比较
为了保证当服务端在29.5s之内发生数据变化能够及时通知给客户端，
服务端采用事件订阅的方式来监听服务端本地数据变化的事件，
一旦收到事件，则触发DataChangeTask的通知，并且遍历allStubs队列中的ClientLongPolling,把结果写回到客户端，就完成了一次数据的推送
如果 DataChangeTask 任务完成了数据的 “推送” 之后，
ClientLongPolling 中的调度任务又开始执行了怎么办呢？很简单
,只要在进行 “推送” 操作之前，
先将原来等待执行的调度任务取消掉就可以了，这样就防止了推送操作写完响应数据之后，调度任务又去写响应数据，这时肯定会报错的。所以，在ClientLongPolling方法中，最开始的一个步骤就是删除订阅事件
所以总的来说，Nacos采用推+拉的形式，来解决最开始关于长轮训时间间隔的问题。当然，30s这个时间是可以设置的，而之所以定30s，应该是一个经验值。
514
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
