Nacos配置中心模块详解

409次阅读  |  发布于3年以前

配置中心

业务上的配置,功能开关,服务治理上对弱依赖的降级,甚至数据库的密码等,都可能用到动态配置中心。

在没有专门的配置中心组件时,我们使用硬编码、或配置文件、或数据库、缓存等方式来解决问题。

硬编码修改配置时需要重新编译打包,配置文件需要重启应用,数据库受限于性能,缓存丧失了及时性。

可能都不完美,但能从中总结出配置中心的需求,相对来说还是比较明确:

目前使用最多的配置中心可能是携程开源的Apollo,还有Spring Cloud Config、阿里开源的Nacos、百度的Disconf等。

Nacos配置中心

NacosNaming and Configuration Service的缩写,从名字上能看出它重点关注的两个领域是Naming即注册中心和Configuration配置中心。

本文讲解nacos的配置中心的架构设计和实现原理,基于2.0.0版本(注:2.0.0版本与1.x版本区别较大)

Nacos调试环境搭建

git clone --depth=1 https://github.com/alibaba/nacos.git

Nacos配置模型

namespace + group + dataId 唯一确定一个配置

客户端启动流程

请求模型

从gRPC的proto文件能看出请求与返回的定义比较统一

message Metadata {
  string type = 3;
  string clientIp = 8;
  map<string, string> headers = 7;
}

message Payload {
  Metadata metadata = 2;
  google.protobuf.Any body = 3;
}

service Request {
  // Sends a commonRequest
  rpc request (Payload) returns (Payload) {
  }
}

com.alibaba.nacos.api.config.ConfigService中可以找到所有配置中心能使用的接口

重点关注这几个接口:

变更推送

采取推拉结合的方式,既保证时效性,又保证数据一致性

数据存储

Nacos配置中心的数据存储支持内嵌的derby数据库,也支持外部数据库mysql,内嵌数据库主要是为了单机测试时使用。

其中上文提及的publishConfigCas的实现是利用了数据库update ${table} set ${xx}=${zz} where md5=${old_md5}来实现,如果已经这条数据被变更,则这次publish会失败。

灰度和回滚

当勾选灰度发布时可填写灰度的ip进行推送,不在灰度列表内的ip则不会接受到变更推送,并且灰度和正式是区分开的。

灰度的实现是记录下了每次的发布,回滚到指定版本即可。

结语

本文从背景出发,结合Nacos配置中心的各个重要模块进行了一一解释,能够从整体上对Nacos的配置中心有一个把握。期望后续能对Nacos注册中心进行分析介绍。


Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8