Nacos

目录

概况

配置样例

特性

总体功能

基础架构

组件架构

数据模型

服务分级模型

服务逻辑隔离模型

实例

注册中心原理

配置中心原理

数据一致性

负载均衡

健康检查

集群扩展性

利弊

---

概况

官方文档：https://nacos.io/en-us/

Spring Cloud Alibaba Git：https://github.com/alibaba/spring-cloud-alibaba

Git：https://github.com/alibaba/nacos

服务端可以在官网下载安装

客户端pom：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
  <version>2.2.1.RELEASE</version>
</dependency>
<--配置中心管理-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
  <version>2.2.1.RELEASE</version>
</dependency>

配置样例

spring:
  main:
    allow-bean-definition-overriding: true
  application:
    name: @project.artifactId@
  profiles:
    active: @profile.active@
  cloud:
    nacos:
      config:
        server-addr: 10.45.50.xxx:8848
        file-extension: yml
        namespace: ${nacos.namespace}
        shared-configs:
          - dataId: common.yml
            refresh: true
          - dataId: redis.yml
            refresh: false
          - dataId: mysql.yml
            refresh: true
          - dataId: rabbitmq.yml
            refresh: false
        enabled: true
        username: ${nacos.username}
        password: ${nacos.password}
      discovery:
        username: ${nacos.username}
        password: ${nacos.password}
        server-addr: ${nacos.ip}:${nacos.port}
        namespace: ${nacos.namespace}
        metadata: # 元数据，用于权限服务实时获取各个服务的所有接口
          management.context-path: ${server.servlet.context-path:}${spring.mvc.servlet.path:}${management.endpoints.web.base-path:}
          grayversion: cp3

客户端注解：@EnableDiscoveryClient

特性

• 服务发现和服务健康监测
• 动态配置服务
• 动态DNS服务
• 服务及其元数据管理

总体功能

Nacos注册中心分为server与client，server采用Java编写，为client提供注册发现服务与配置服务。而client可以用多语言实现，client与微服务嵌套在一起，nacos提供sdk和openApi集成。

基础架构

组件架构

数据模型

服务分级模型

服务逻辑隔离模型

用户账号对应的可能是一个企业或者独立的个体，这个数据一般情况下不会透传到服务注册中心。一个用户账号可以新建多个命名空间，每个命名空间对应一个客户端实例，这个命名空间对应的注册中心物理集群是可以根据规则进行路由的，这样可以让注册中心内部的升级和迁移对用户是无感知的，同时可以根据用户的级别，为用户提供不同服务级别的物理集群。再往下是服务分组和服务名组成的二维服务标识，可以满足接口级别的服务隔离。

实例

可分为临时实例和持久化实例。在定义上区分临时实例和持久化实例的关键是健康检查的方式。临时实例使用客户端上报模式，而持久化实例使用服务端反向探测模式。临时实例需要能够自动摘除不健康实例，而且无需持久化存储实例，那么这种实例就适用于类 Gossip 的协议。右边的持久化实例使用服务端探测的健康检查方式，因为客户端不会上报心跳，那么自然就不能去自动摘除下线的实例。

注册中心原理

服务注册的策略的是每5秒向nacos server发送一次心跳，心跳带上了服务名，服务ip，服务端口等信息。同时 nacos server也会向client 主动发起健康检查，支持tcp/http检查。如果15秒内无心跳且健康检查失败则认为实例不健康，如果30秒内健康检查失败则剔除实例。

配置中心原理

数据一致性

• 一种是基于 Leader 的非对等部署的单点写一致性
• 一种是对等部署的多写一致性

Nacos 因为要支持多种服务类型的注册，并能够具有机房容灾、集群扩展等必不可少的能力，在 1.0.0 正式支持 AP 和 CP 两种一致性协议并存。1.0.0 重构了数据的读写和同步逻辑，将与业务相关的 CRUD 与底层的一致性同步逻辑进行了分层隔离。然后将业务的读写（主要是写，因为读会直接使用业务层的缓存）抽象为 Nacos 定义的数据类型，调用一致性服务进行数据同步。在决定使用 CP 还是 AP 一致性时，使用一个代理，通过可控制的规则进行转发。

负载均衡

Nacos 试图做的是将服务端负载均衡与客户端负载均衡通过某种机制结合起来，提供用户扩展性，并给予用户充分的自主选择权和轻便的使用方式

健康检查

Nacos 既支持客户端的健康检查，也支持服务端的健康检查，同一个服务可以切换健康检查模式。支持TCP 端口探测和 HTTP 接口返回码探测。

TTL 的机制，Nacos 目前支持临时实例使用心跳上报方式维持活性，发送心跳的周期默认是 5 秒，Nacos 服务端会在 15 秒没收到心跳后将实例设置为不健康，在 30 秒没收到心跳时将这个临时实例摘除。

集群扩展性

• 一种是和 Eureka 一样的 AP 协议的部署，这种模式只支持临时实例，并支持机房容灾。
• 一种是支持持久化实例的 CP 模式，这种情况下不支持双机房容灾。

对于多机房容灾、异地多活、多数据中心方案。如Nacos-Sync 组件来做数据中心之间的数据同步，每个数据中心的 Nacos 集群都会有多个数据中心的全量数据。

Nacos-Sync

//TODO

利弊

• 利：功能强大，图形化，可动态修改配置
• 弊：目前没有大规模的开源应用，还在持续开发中，有一定风险