Nacos-总结

 第1章  引入

【引入部分主要内容】

 1 介绍微服务中服务注册与发现、配置管理存在的问题是什么？

 2 介绍nacos是什么？ 能做什么 ？

问题1： 微服务中配置文件的问题 ？

        每个微服务都有配置文件，用于存放一些服务运行中可能需要修改的参数，例如：环境变化需要调整的参数：服务的地址、数据库的连接信息等。配置文件就时对这些参数的统一整合管理，实现不用修改代码就能改变服务相关功能的能力。

          一般的开发中，一个服务需要包含多个环境（开发、测试、生产）的配置文件，目的是实现环境的隔离，每个环境使用的配置一般是不同的，特别是数据存储的中间件：数据库、redis等，环境隔离保证互相不干扰。在一个微服务的架构中，配置文件会随着服务数量的增多而变得越来越多，这些配置文件是相对分散的。配置文件的管理和维护成为问题。

 存在的问题：

• 配置文件的数量会随着服务的增加持续的递增；
• 单个配置文件无法区分多个运行环境；
• 配置文件内容无法动态更新，需要重启服务更新的配置才能生效

---> 配置中心 

配置中心解决了什么？

• 统一的配置文件管理
• 提供统一标准的接口，服务根据标准接口自行的拉取配置
• 支持动态的更新配置到所有的服务

业界常见的配置中心

• Appllo
• Disconf
• SpringCloud Config
• Nacos

---

问题2：微服务注册与发现的问题？

• 维护服务信息困难
• 服务健康状态不可知
• 负载均衡和容错处理复杂

---> 注册中心

注册中心解决了什么？

• 动态的服务注册发现
• 服务的健康监测
• 负债均衡

业界常见的注册中心：

---

第2章   Nacos

简介

1 是什么？

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service的首字母简称，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。

2 能做什么 ？

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

---

概念

---

 基础架构

---

Nacos的领域模型

• Nacos Config数据模型

Nacos 数据模型 Key 由三元组唯一确定, Namespace默认是空串，公共命名空间（public），

分组默认是 DEFAULT_GROUP。

• NameSpace可以区分不同的环境：开发、测试、生产环境
• Group 可用于对一个环境中的配置进行分类
• DateId 具体到某一个配置文件

一般生产环境与开发测试环境是各自部署一套nacos，保证生产环境不受影响

Namespace 的设计就是用来进行资源隔离的，在进行配置资源的时候可从以下两个角度来看：

1. 从单个租户的角度来看，我们要配置多套环境的配置，可以根据不同的环境来创建 Namespace 。比如开发环境、测试环境、线上环境，创建对应的 Namespace（dev、test、prod），Nacos 会自动生成对应的 Namespace Id 。如果同⼀个环境内想配置相同的配置，可以通过Group 来区分。如下图所示：

• 从多个租户的角度来看，每个租户都可以有自己的命名空间。可以为每个用户创建⼀个命名空间，并给用户分配对应的权限，比如多个租户（zhangsan、lisi、wangwu），每个租户都想有⼀套自己的多环境配置，也就是每个租户都想配置多套环境。可以给每个租户创建⼀个 Namespace （zhangsan、lisi、wangwu）。同样会生成对应的 Namespace Id。然后使用 Group 来区分不同环境的配置。如下图所示：

Nacos 存储配置有几个比较重要的表分别是:

• config_info 存储配置信息的主表，里面包含 dataId、groupId、content、tenantId、encryptedDataKey 等数据。
• config_info_beta 灰度测试的配置信息表，存储的内容和 config_info 基本相似。有⼀个 beta_ips 字段用于客户端请求配置时判断是否是灰度的 ip。
• config_tags_relation 配置的标签表，在发布配置的时候如果指定了标签，那么会把标签和配置的关联信息存储在该表中。
• his_config_info 配置的历史信息表，在配置的发布、更新、删除等操作都会记录⼀条数据，可以做多版本管理和快速回滚。

服务注册中心的领域模型

一般会在南方和北方分别部署一个数据中心，保证同一个数据中心的请求相应很快

---

第3章  整合使用nacos

版本选择

版本说明 · alibaba/spring-cloud-alibaba Wiki · GitHub

springboot整合nacos的代码实操

• 服务注册与发现

下单扣减存库

代码演示

• 配置中心

演示配置中心基本使用：

        从配置中心获取配置，配置动态更新

演示配置中心进阶使用：

    1  实现开发、测试、生产多环境配置的动态切换

    2  实现同一个服务在不同环境中有相同的配置管理

配置文件的命名：

不同环境的配置文件的命名是有规范的: 服务名-环境名.yaml

通用配置命名：服务名.yaml，实现同一个服务在不同环境下的共享的配置

  3  实现不同的服务有共享的配置管理

方法1：

方法2：

优先级：

[服务名]-[spring.profile.active].yaml  >   [服务名].yaml   > nacos拓展配置  > nacos共享配置

naocs各配置文件的优先级？

《后端程序猿 · Nacos 配置优先级&动态刷新》_nacos配置文件的执行顺序-CSDN博客

---

第4章  nacos的模型、原理

Nacos Config动态刷新机制

流程图

注册中心原理

为啥用UDP协议？

基于UDP协议推送更新，优点是：

1 不可靠，但是速度快；

2 不需要建立长连接，在注册中心这个场景中，服务的消费者数量肯定是要大于服务提供者的，当服务消费者数量很多时，当服务列表更新时，如果建立TCP长连接，那nacos的性能肯定是不行的

3 怎么解决不可靠的问题，第4步中会主动拉取服务列表，可解决UDP不可靠的问题；

Nacos高并发支撑异步任务与内存队列剖析 

一个消息队列，服务提供者注册时将消息放入队列，有一个监听线程在监听队列的消息变化，监听到队列中对外消息变化，就会更新服务列表并发送服务的消息变更

这里的异步读写队列，监听消息变更，快速更新列表，保证了服务注册与发现的高性能

Nacos的注册表防止多节点并发读写

多节点是指同一个服务的多个节点

服务注册表是一个ConcurrentHashMap

Map的结构如下：

---

Nacos的CP模式和AP模式

nacos支持CP模式、AP模式

CAP理论

• C：一致性
• A：可用性
• P：分区容错性

    三选二特性

 

分布式共识算法 Raft： 

• Leader(领导者)
• Follower(跟随者)
• Candidate(候选人)

选举Leader

Raft 分布式共识算法动画演示

---

第5章  插件

nacos支持通过SPI的方式注入相关插件，实现鉴权、配置加密、多数据源等功能。

Nacos在跨DC部署中的应用

【跨DC调用的场景】  异地多中心，服务调用延迟时间长

解决方案：将Nacos与CMDB打通，实现同城就近的服务调用，降低调用延迟

CMDB是什么

• Configuration Management Database
• 企业存放与机器设备、应用、服务等基础设施的元数据
• 机器ip、主机名、机房、应用等
• 提供给运维或者监控平台使用这些数据进行展示和运维操作

CMDB的相关概念

• Entity可以指一个IP、应用或者服务，包含很多的属性
• Entity Type不限定在IP、应用，也可以根据业务自定义
• LABEL定义为一个描述Entity属性的K-V键值对
• Entity Event当实体属性发生变化时发出的消息

Nacos与CMDB整合

【代码演示】

---

多数据源插件

Nacos从2.2.0版本开始,可通过SPI机制注入多数据源实现插件,并在引入对应数据源实现后,便可在Nacos启动时通过读取application.properties配置文件中spring.datasource.platform配置项选择加载对应多数据源插件.本文档详细介绍一个多数据源插件如何实现以及如何使其生效。

注意: 目前多数据源插件处于Beta测试阶段,其API及接口方法定义可能会在后续版本升级而有较大修改，请注意您的插件适用版本。

插件化实现

在原来的Config模块中，所有的SQL操作的执行是通过直接使用JdbcTemplate执行固定SQL语句的形式，使得SQL语句与业务逻辑高度耦合，并且只支持Derby与MySQL两种数据源，原有Config模块架构如下。

现在的多数据源插件通过SPI机制，将SQL操作按照数据表进行抽象出多个Mapper接口，Mapper接口的实现类需要按照不同的数据源编写对应的SQL方言实现; 现在插件默认提供Derby以及MySQL的Mapper实现，可直接使用；而其他的数据源则需要用户使用数据源插件进行加载，其改造后架构图如下。

如何使用

1. 用户查询当前Nacos是否支持所需数据源，Nacos默认提供Derby以及MySQL的实现，若暂未支持可参考下面插件编写者如何开发步骤开发插件自己使用或贡献；
2. 在application.properties配置文件中将spring.datasource.platform修改为对应的数据源名称，并配置数据源相关参数；
3. 然后编译运行则可支持此数据源；

插件编写者如何开发

1. 引入nacos-datasource-plugin依赖
2. 实现com.alibaba.nacos.plugin.datasource.mapper包下数据表对应Mapper接口中的特殊SQL方法，主要是涉及分页等方言差别，可参考com.alibaba.nacos.plugin.datasource.impl下Derby以及MySQL的实现，只需实现对应接口即可。接口与表对应关系如下：

数据库表	Mapper
config_info_aggr	ConfigInfoAggrMapper
config_info_beta	ConfigInfoBetaMapper
config_info	ConfigInfoMapper
config_info_tag	ConfigInfoTagMapper
config_tags_relation	ConfigTagsRelationMapper
his_config_info	HistoryConfigInfoMapper

1. 编写SPI配置文件，其名字为com.alibaba.nacos.plugin.datasource.mapper.Mapper，写入实现Mapper接口的类，可参考config模块中Derby与MySQL配置文件。
2. 插件使用者则可以通过依赖此插件，达到实现对应数据源操作的效果
3. 编译运行

如何编译

编译插件之前需要先编译nacos并安装至本地仓库.

1. git clone git@github.com:alibaba/nacos.git
2. cd nacos && mvn -B clean package install -Dmaven.test.skip=true

若出现revision变量无法解析,请更新maven至最新版本

1. git clone #{对应数据源插件实现Git地址}
2. mvn install