配置管理

一、Config简介在微服务系统中，服务较多，相同的配置：如数据库信息、缓存、参数等，会出现在不同的服务上，如果一个配置发生变化，需要修改很多的服务配置。spring cloud提供配置中心，来解决这个场景问题。 系统中的通用配置存储在相同的地址：GitHub,Gitee,本地配置服务等，然后配置中心读取配置以restful发布出来，其它服务可以调用接口获取配置信息。二、配置服务端1、项目结构 核心注解：@EnableConfigServer2、核心依赖<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-server</artifactId></dependency>3、核心配置文件这里注意读取文件的配置 active ：native，读取本地配置；active ：git，读网络仓库配置；server: port: 9001spring: application: name: config-server-9001 profiles: # 读取本地 # active: native # 读取Git active: git cloud: config: server: native: search-locations: classpath:/config git: # 读取的仓库地址 uri: https://gitee.com/cicadasmile/spring-cloud-config.git # 读取仓库指定文件夹下 search-paths: /cloudbaseconfig # 非公开需要的登录账号 username: password: label: master4、读取配置内容不同的环境读取的结果不同。 info: date: 20190814 author: cicada sign: develop version: V1.0三、配置客户端1、核心依赖<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-config</artifactId></dependency>2、核心配置文件在上面的配置中心，配置读取Git资源，所以这里的配置也就是读取Git资源。 server: port: 8001spring: application: name: config-client-8001 profiles: active: dev cloud: config: # 读取本地配置 --------------------------- #uri: http://localhost:9001 ## 读取策略：快速失败 #fail-fast: true ## 读取的文件名：无后缀 #name: client-8001 ## 读取的配置环境 #profile: dev # client-8001-dev.yml # ---------------------------------------- # github上的资源名称 ----------------------- name: client-8001 # 读取的配置环境 profile: dev label: master # 本微服务启动后,通过配置中心6001服务，获取GitHub的配置文件 uri: http://localhost:9001 # ----------------------------------------3、测试接口@RestControllerpublic class ClientController { @Value("${info.date}") private String date ; @Value("${info.author}") private String author ; @Value("${info.sign}") private String sign ; @Value("${info.version}") private String version ; /** * 获取配置信息 */ @RequestMapping("/getConfigInfo") public String getConfigInfo (){ return date+"-"+author+"-"+sign+"-"+version ; }}四、基于Eureka配置上面的模式，通过服务中心，直接获取配置。下面把注册中心Eureka加进来。 ...

前言在看正文之前，我想请你回顾一下自己待过的公司都是怎么管理配置的，我想应该会有以下几种方式：1、硬编码没有什么配置不配置的，直接写在代码里面，比如使用常量类优势：对开发友好，开发清楚地知道代码需要用到什么配置劣势：涉及秘钥等敏感配置直接暴露给开发人员，不安全；如果想修改配置必须重新发版，比较麻烦2、外部化配置文件Spring项目经常会在resoures目录下放很多配置文件，各个环境对应不同的配置文件，通过SVN管理优势：配置文件外部化，支持多环境配置管理，修改配置只需重启服务，无需发版劣势：系统庞大时，配置文件很多，多人开发，配置格式不统一，维护麻烦；敏感配置不需要暴露给开发人员，降低风险，但开发经常要和运维沟通怎么修改配置，沟通不恰当容易引发生产事故；而且，如果应用部署在多台机器，对运维来说，修改配置也是非常头疼的事情（当然也可以引入NFS系统来解决一部分问题）3、数据库配置信息存储在数据库中，灵活修改优势：可以灵活管理配置，无需重启服务劣势：界面不友好，配置没有版本管理，一旦出现问题，回滚或定位问题都比较麻烦；此外，数据库必须要保证高可用，避免因此而造成生产故障4、配置中心微服务基础架构体系中的一个不可或缺的基础组件优势：集中化管理，敏感配置可控；多版本存储，方便追溯；界面友好，修改配置一键发布；即使面对多集群也能从容应对，十分淡定劣势：引入组件，增加系统风险；如果是中途切换成配置中心，也会增加研发接入成本；配置中心也需要保证高可用，否则容易造成大面积影响以上几种管理配置文件的方式，我想都会有公司在用，不要因为配置中心有诸多优点，就盲目引进项目中，我觉得应该遵守以下两个原则：做人做事，要知道自己几斤几两释义：没深入研究过的技术，就不要随便拿到公司项目中来试水啦，恐怕到时候坑够你填的，要不然就是你有信心玩得转它。杀只鸡而已，你拿牛刀来做甚？释义：小团队小项目选择简单的配置管理方式就好了，要什么配置中心，纯属没事找事。总而言之，我们必须从实际出发，实事求是，选择适合自己的技术栈。关于为什么需要有配置中心，我推荐一篇文章给你看，讲得比较透彻：《微服务架构为什么需要配置中心？》另外，我觉得对开发本身来说，是宁愿自己管理自己代码的配置的，交给运维总是会有各种各样的问题，至于敏感配置，说实话，开发人员要真想做点“坏事”，那拦得住吗？但是，从公司的角度来讲，把服务器的配置管理交给运维同事是符合常理的，系统需要稳定且安全地运行，这是对客户的负责，从这一方面去思考，这么做是合情合理的。Okay，我就啰嗦到这里吧，下面正式介绍Nacos作为配置中心是怎么使用的。Nacos 结合 Spring添加 maven 依赖：<dependency> <groupId>com.alibaba.nacos</groupId> <artifactId>nacos-spring-context</artifactId> <version>${nacos-spring-context.version}</version></dependency>使用 @EnableNacosConfig 开启 Nacos Spring 的配置管理功能@Configuration@EnableNacosConfig(globalProperties = @NacosProperties(serverAddr = “127.0.0.1:8848”))@NacosPropertySource(dataId = “nacos.spring.config”, autoRefreshed = true)public class NacosConfig {}其中：@Configuration：Spring的注解，配置应用上下文@EnableNacosConfig：Nacos的注册，启用 Nacos Spring 的配置管理服务@NacosProperties：全局和自定义Nacos属性的统一注解@NacosPropertySource：加载数据源globalProperties：全局 Nacos 属性serverAddr：Nacos Server服务器地址dataId：配置的数据集IDautoRefreshed：是否开启配置动态更新再写一个Controller类，来验证Nacos的配置管理功能，代码如下：package com.learn.nacos;import com.alibaba.nacos.api.annotation.NacosInjected;import com.alibaba.nacos.api.config.ConfigService;import com.alibaba.nacos.api.config.annotation.NacosValue;import com.alibaba.nacos.api.exception.NacosException;import org.springframework.http.HttpStatus;import org.springframework.http.ResponseEntity;import org.springframework.stereotype.Controller;import org.springframework.web.bind.annotation.RequestMapping;import org.springframework.web.bind.annotation.RequestMethod;import org.springframework.web.bind.annotation.RequestParam;import org.springframework.web.bind.annotation.ResponseBody;@Controller@RequestMapping(value = “config”)public class NacosConfigController { @NacosInjected private ConfigService configService; @NacosValue(value = “${useLocalCache:false}”, autoRefreshed = true) private boolean useLocalCache; @RequestMapping(value = “/get”, method = RequestMethod.GET) @ResponseBody public boolean get() { return useLocalCache; } @RequestMapping(method = RequestMethod.GET) @ResponseBody public ResponseEntity<String> publish(@RequestParam String dataId, @RequestParam(defaultValue = “DEFAULT_GROUP”) String group, @RequestParam String content) throws NacosException { boolean result = configService.publishConfig(dataId, group, content); if (result) { return new ResponseEntity<String>(“Success”, HttpStatus.OK); } return new ResponseEntity<String>(“Fail”, HttpStatus.INTERNAL_SERVER_ERROR); }}该Controller类提供了两个HTTP接口读取配置：http://127.0.0.1:8080/config/get发布配置：http://127.0.0.1:8080/config?dataId=XXX&content=XXX发布配置还可以通过 Nacos Open API：curl -X POST “http://127.0.0.1:8848/nacos/v1/cs/configs?dataId=XXX&group=XXX&content=XXX 发布配置，你也可以用Postman工具模拟POST请求进行配置发布，我这里主要是为了方便验证问题，采用了这种方式。在验证之前，请先确保 Nacos Server 已经启动，Nacos Server 的安全及启动方式详见：《Nacos系列：欢迎来到Nacos的世界！》启动Tomcat，观察Console控制台20:50:13.646 [RMI TCP Connection(5)-127.0.0.1] WARN com.alibaba.nacos.spring.core.env.AnnotationNacosPropertySourceBuilder - There is no content for NacosPropertySource from dataId[nacos.spring.config] , groupId[DEFAULT_GROUP] , properties[{encode=${nacos.encode:UTF-8}, namespace=${nacos.namespace:}, contextPath=${nacos.context-path:}, endpoint=${nacos.endpoint:}, serverAddr=${nacos.server-addr:}, secretKey=${nacos.secret-key:}, accessKey=${nacos.access-key:}, clusterName=${nacos.cluster-name:}}].20:50:17.825 [RMI TCP Connection(5)-127.0.0.1] INFO com.alibaba.nacos.spring.context.event.LoggingNacosConfigMetadataEventListener - Nacos Config Metadata : dataId=‘nacos.spring.config’, groupId=‘DEFAULT_GROUP’, beanName=‘nacosConfig’, bean=‘null’, beanType=‘class com.learn.nacos.NacosConfig’, annotatedElement=‘null’, xmlResource=‘null’, nacosProperties=’{serverAddr=127.0.0.1:8848, encode=UTF-8}’, nacosPropertiesAttributes=’{encode=${nacos.encode:UTF-8}, namespace=${nacos.namespace:}, contextPath=${nacos.context-path:}, endpoint=${nacos.endpoint:}, serverAddr=${nacos.server-addr:}, secretKey=${nacos.secret-key:}, accessKey=${nacos.access-key:}, clusterName=${nacos.cluster-name:}}’, source=‘org.springframework.core.type.classreading.AnnotationMetadataReadingVisitor@66e4d430’, timestamp=‘1550753413647’我们先通过http://127.0.0.1:8080/config?dataId=nacos.spring.config&content=useLocalCache=true发布一个dataId为nacos.spring.config且配置内容为useLocalCache=true的配置集，观察Nacos控制台的变化再通过http://127.0.0.1:8080/config/get读取配置然后在Nacos控制台将useLocalCache的值改为false，并发布配置再次访问http://127.0.0.1:8080/config/getNacos 结合 Spring Boot添加 Starter 依赖：<dependency> <groupId>com.alibaba.boot</groupId> <artifactId>nacos-config-spring-boot-starter</artifactId> <version>0.2.1</version></dependency>注意：版本 0.2.x.RELEASE 对应的是 Spring Boot 2.x 版本，版本 0.1.x.RELEASE 对应的是 Spring Boot 1.x 版本。在application.properties中添加如下配置信息：nacos.config.server-addr=127.0.0.1:8848添加NacosConfigApplication启动类@SpringBootApplication@NacosPropertySource(dataId = “nacos.springboot.config”, autoRefreshed = true)public class NacosConfigApplication { public static void main(String[] args) { SpringApplication.run(NacosConfigApplication.class, args); }}如果你看过我的上一篇文章：《Nacos系列：基于Nacos的注册中心》，那么你应该知道 Spring Boot 实现方式和 Spring 的没太大差别，所以我就不再细说了，请参考我的源码示例或者官网资料学习。这里说下我在学习过程中遇到的一个问题，在application.properties添加配置文件的时候，不小心将nacos.config.server-addr写成了nacos.discovery.server-addr，结果启动项目时，一直报错：ERROR 9028 — [ main] o.s.b.d.LoggingFailureAnalysisReporter : ——APPLICATION FAILED TO START——Description:client error: invalid param. nullAction:please check your client configuration刚开始一直找不到原因，后面跟着官网代码示例复核，才发现是配置问题导致的，呵呵哒，自己给自己挖坑。后语我挺喜欢Nacos的，既然做服务发现和管理，又能做配置管理，这两者本质没多大区别，Nacos把这两者统一起来，一举两得，我觉得没什么不好，要不然你引入了Zookeeper作为注册中心，还要引入Apollo作为配置中心，无端增加学习成本。就像之前听音乐，我一般用网易云音乐就好，后面因为搞了版权的事，不得不下载了虾米和QQ音乐，我就听个歌而已，手机里装了三个APP，你说，这叫什么事儿？示例源码Nacos + Spring ：learn-nacos-spring-configNacos + Spring Boot ： learn-nacos-springboot-config代码已上传至码云和Github上，欢迎下载学习GiteeGithub参考资料微服务架构为什么需要配置中心？Nacos Spring 快速开始Nacos Spring Boot 快速开始SpringBoot使用Nacos配置中心Spring Cloud Alibaba基础教程：使用Nacos作为配置中心 ...

通过本教程的前两篇：《Spring Cloud Alibaba基础教程：使用Nacos实现服务注册与发现》《Spring Cloud Alibaba基础教程：支持的几种服务消费方式（RestTemplate、WebClient、Feign）》我们已经学会了，如何利用Nacos实现服务的注册与发现。同时，也介绍了在Spring Cloud中，我们可以使用的几种不同编码风格的服务消费方式。接下来，我们再来一起学习一下Nacos的另外一个重要能力：配置管理。简介Nacos除了实现了服务的注册发现之外，还将配置中心功能整合在了一起。通过Nacos的配置管理功能，我们可以将整个架构体系内的所有配置都集中在Nacos中存储。这样做的好处，在以往的教程中介绍Spring Cloud Config时也有提到，主要有以下几点：分离的多环境配置，可以更灵活的管理权限，安全性更高应用程序的打包更为纯粹，以实现一次打包，多处运行的特点（《云原声应用的12要素》之一）Nacos的配置管理模型与淘宝开源的配置中心Diamond类似，基础层面都通过DataId和Group来定位配置内容，除此之外还增加了很多其他的管理功能。快速入门下面我们通过一个简单的例子来介绍如何在Nacos中创建配置内容以及如何在Spring Cloud应用中加载Nacos的配置信息。创建配置第一步：进入Nacos的控制页面，在配置列表功能页面中，点击右上角的“+”按钮，进入“新建配置”页面，如下图填写内容：其中：Data ID：填入alibaba-nacos-config-client.propertiesGroup：不修改，使用默认值DEFAULT_GROUP配置格式：选择Properties配置内容：应用要加载的配置内容，这里仅作为示例，做简单配置，比如：didispace.title=spring-cloud-alibaba-learning创建应用第一步：创建一个Spring Boot应用，可以命名为：alibaba-nacos-config-client。第二步：编辑pom.xml，加入必要的依赖配置，比如：<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.0.5.RELEASE</version> <relativePath/> <!– lookup parent from repository –></parent><dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Finchley.SR1</version> <type>pom</type> <scope>import</scope> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-alibaba-dependencies</artifactId> <version>0.2.1.RELEASE</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies></dependencyManagement><dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.18.2</version> <optional>true</optional> </dependency></dependencies>上述内容主要三部分：parent：定义spring boot的版本dependencyManagement：spring cloud的版本以及spring cloud alibaba的版本，由于spring cloud alibaba还未纳入spring cloud的主版本管理中，所以需要自己加入dependencies：当前应用要使用的依赖内容。这里主要新加入了Nacos的配置客户端模块：spring-cloud-starter-alibaba-nacos-config。由于在dependencyManagement中已经引入了版本，所以这里就不用指定具体版本了。可以看到，这个例子中并没有加入nacos的服务发现模块，所以这两个内容是完全可以独立使用的第三步：创建应用主类，并实现一个HTTP接口：@SpringBootApplicationpublic class TestApplication { public static void main(String[] args) { SpringApplication.run(TestApplication.class, args); } @Slf4j @RestController @RefreshScope static class TestController { @Value("${didispace.title:}") private String title; @GetMapping("/test") public String hello() { return title; } }}内容非常简单，@SpringBootApplication定义是个Spring Boot应用；还定义了一个Controller，其中通过@Value注解，注入了key为didispace.title的配置（默认为空字符串），这个配置会通过/test接口返回，后续我们会通过这个接口来验证Nacos中配置的加载。另外，这里还有一个比较重要的注解@RefreshScope，主要用来让这个类下的配置内容支持动态刷新，也就是当我们的应用启动之后，修改了Nacos中的配置内容之后，这里也会马上生效。第四步：创建配置文件bootstrap.properties，并配置服务名称和Nacos地址spring.application.name=alibaba-nacos-config-clientserver.port=8001spring.cloud.nacos.config.server-addr=127.0.0.1:8848注意：这里必须使用bootstrap.properties。同时，spring.application.name值必须与上一阶段Nacos中创建的配置Data Id匹配（除了.properties或者.yaml后缀）。第五步：启动上面创建的应用。2019-01-27 18:29:43.497 INFO 93597 — [ main] o.s.c.a.n.c.NacosPropertySourceBuilder : Loading nacos data, dataId: ‘alibaba-nacos-config-client.properties’, group: ‘DEFAULT_GROUP'2019-01-27 18:29:43.498 INFO 93597 — [ main] b.c.PropertySourceBootstrapConfiguration : Located property source: CompositePropertySource {name=‘NACOS’, propertySources=[NacosPropertySource {name=‘alibaba-nacos-config-client.properties’}]}在启动的时候，我们可以看到类似上面的日志信息，这里会输出应用程序要从Nacos中获取配置的dataId和group。如果在启动之后，发现配置信息没有获取到的时候，可以先从这里着手，看看配置加载的目标是否正确。第六步：验证配置获取和验证动态刷新用curl或者postman等工具，访问接口: localhost:8001/test，一切正常的话，将返回Nacos中配置的spring-cloud-alibaba-learning。然后，再通过Nacos页面，修改这个内容，点击发布之后，再访问接口，可以看到返回结果变了。同时，在应用的客户端，我们还能看到如下日志：2019-01-27 18:39:14.162 INFO 93597 — [-127.0.0.1_8848] o.s.c.e.event.RefreshEventListener : Refresh keys changed: [didispace.title]在Nacos中修改了Key，在用到这个配置的应用中，也自动刷新了这个配置信息。参考资料Nacos官方文档Nacos源码分析代码示例本文示例读者可以通过查看下面仓库的中的alibaba-nacos-config-client项目：Github：https://github.com/dyc87112/SpringCloud-Learning/Gitee：https://gitee.com/didispace/SpringCloud-Learning/如果您对这些感兴趣，欢迎star、follow、收藏、转发给予支持！以下专题教程也许您会有兴趣Spring Boot基础教程Spring Cloud基础教程 ...

Release Notes1、在未设置accessToken情况下，非法请求恶意构造配置Key可遍历读取文件漏洞修复；（From：360代码卫士团队）2、项目名正则校验问题修复，项目名中划线分隔，配置点分隔；3、底层HTTP工具类优化；4、RESTFUL 接口格式调整，改为POST请求，兼容大数据量配置请求；5、配置Key合法性校验逻辑优化，非法Key服务端自动过滤，避免阻塞正常配置的查询加载；6、升级pom依赖至较新版本；简介XXL-CONF 是一个轻量级分布式配置管理平台，拥有"轻量级、秒级动态推送、多环境、跨语言、跨机房、配置监听、权限控制、版本回滚"等特性。现已开放源代码，开箱即用。特性1、简单易用: 接入灵活方便，一分钟上手；2、轻量级: 部署简单，不依赖第三方服务，一分钟上手；3、配置中心HA：配置中心支持集群部署，提升配置中心系统容灾和可用性。4、在线管理: 提供配置中心, 通过Web界面在线操作配置数据，直观高效；5、多环境支持：单个配置中心集群，支持自定义多套环境，管理多个环境的的配置数据；环境之间相互隔离；6、多数据类型配置：支持多种数据类型配置，如：String、Boolean、Short、Integer、Long、Float、Double 等；7、跨语言：底层通过http服务（long-polling）拉取配置数据并实时感知配置变更，从而实现多语言支持。8、跨机房：得益于配置中心集群关系对等特性，集群各节点提供幂等的配置服务；因此，异地跨机房部署时，只需要请求本机房配置中心即可，实现异地多活；9、高性能：得益于配置中心的 “磁盘配置” 与客户端的 “LocalCache”，因此配置服务性能非常高；单机可承担大量配置请求；10、实时性: 秒级动态推送；配置更新后, 实时推送配置信息, 项目中配置数据会实时更新并生效, 不需要重启线上机器;11、配置变更监听功能：可开发Listener逻辑，监听配置变更事件，可据此动态刷新JDBC连接池等高级功能；12、最终一致性：底层借助内置广播机制，保障配置数据的最终一致性，从而保证配置数据的同步；13、配置备份: 配置数据同时在磁盘与MySQL中存储和备份，并定期同步， 提高配置数据的安全性;14、多种获取配置方式：支持 “API、 注解、XML占位符” 等多种方式获取配置，可灵活选择使用；15、兼容Spring原生配置：兼容Spring原生配置方式 “@Value”、"${}" 加载本地配置功能；与分布式配置获取方式隔离，互不干扰；16、分布式: 支持多业务线接入并统一管理配置信息，支撑分布式业务场景;17、项目隔离: 以项目为维度管理配置, 方便隔离不同业务线配置;18、高性能: 通过LocalCache对配置数据做缓存, 提高性能;19、客户端断线重连强化：设置守护线程，周期性检测客户端连接、配置同步，提高异常情况下配置稳定性和时效性；20、空配置处理：主动缓存null或不存在类型配置，避免配置请求穿透到远程配置Server引发雪崩问题；21、用户管理：支持在线添加和维护用户，包括普通用户和管理员两种类型用户；22、配置权限控制；以项目为维度进行配置权限控制，管理员拥有全部项目权限，普通用户只有分配才拥有项目下配置的查看和管理权限；23、历史版本回滚：记录配置变更历史，方便历史配置版本回溯，默认记录10个历史版本；24、配置快照：客户端从配置中心获取到的配置数据后，会周期性缓存到本地快照文件中，当从配置中心获取配置失败时，将会使用使用本地快照文件中的配置数据；提高系统可用性；25、访问令牌（accessToken）：为提升系统安全性，配置中心和客户端进行安全性校验，双方AccessToken匹配才允许通讯；文档地址中文文档技术交流社区交流

项目地址单项目的时候只需要一个简单的配置文件即可完成配置管理。假如多个项目多个环境同时配置就会产生非常复杂的配置管理情况。这个时候就需要用到配置中心了，它的原理其实类似于redis缓存这种。不同之处在于配置中心只关注配置，并且有更多的有利于配置的功能。大概的功能如下：同时这些功能也是这次要开发的配置中心需要包含的功能。本次开发的配置中心是基于nodejs的版本。客户端获取配置的方式可以参考协议来开发属于自己的客户端SDK。目前已经提供的是javascript版本。功能设计配置中心的开发是基于nodejs的，这里先看一下大体的流程。从上面可以看到，一个配置中心最主要的功能包括：数据存储。这里使用存储协议匹配多种存储形式。定时任务。这里包含了定时存储和自定义的定时更新任务。web站点。主要是提供一个简单快速的设置配置的方式。心跳检测。使用TCP协议将客户端和配置中心相连，可以监听到配置的改动，及时获取最新的配置内容。开发功能落实到具体的开发上面其实非常简单，很多时候可能只需要一个了解和实践的过程。这里我把大概的思路跟大家捋一下。数据存储存储的目的只有2个：存储用到的配置。这里只是简单的实现了列表、存、取的功能用户登录。本教程目前只实现了本地json文件的读写，如果想要使用MySQL或者Redis等可以自己按照下面的协议实现。init()，存储库的初始化方法。在项目启动的时候会第一时间调用。list()，获取命名空间列表。这里使用命名空间区分不同的配置文件。这里默认使用def来保存第一个文件。all(namespace = “def”)，获取对应命名空间下的配置内容。update(namespace, txt)，更新一个命名空间的所有配置。这里传入的是字符串，保存的也是字符串。get(key, namespace = “def”)，获取对应命名空间下的某个字段的内容。这里需要警惕，配置不一定是json对象的。set(key, val, namespace = “def”)，设置对应命名空间下的某个字段的值。login(user, pwd)，登录判断，目前返回true或者false就可以了。只要是实现了上面协议的存储库就可以无痕替换掉项目的存储方式。定时任务固定的定时任务只有定时存储当前缓存的配置数据。这里一个是为了项目重启的时候能够获得上次保存的配置内容，另外一个也是为了防止程序崩溃的情况下能够不丢失已经保存的数据。程序内容设定了一个状态变量changed，如果有对应的配置变动了，就会将其的状态变更为true。定时保存任务就会在启动的时候讲数据保存在存储库中。自定义定时任务的目的在于设置一个配置结果和定时时间，当时间到了的时候就触发一次更新操作。这个功能实现非常简单，但是对于使用的人来说是一个非常好用的功能。例如：半夜2点定时上线某些产品什么的。。。。在也不需要熬夜等了。这次分享的项目还没有实现这个自定义定时更新功能。在后续的更新中会逐步完善这个功能。web站点web站点就是操作配置的地方。项目默认提供了几个接口用来获取和更新配置。目前使用jQuery实现，界面比较简陋，基础功能已经实现了。这里可以看到最上面是命名空间的标签。下面是添加命名空间。再往下是显示和编辑配置的地方。心跳检测心跳其实才是配置中心的核心内容。它主要的任务就是及时并且快速的通知到客户端配置有更新，需要使用最新的配置。服务端使用nodejs的net.createServer方法创建一个TCP的监听服务，如果客户端连接就会将客户端的连接对象放入对象缓存池。在连接的时候这里做了2件事：给连接对象添加了一个uuid，方便辨认不同的客户端。通知客户端发送验证令牌。这里的逻辑比较简陋，只是简单的验证一下。在连接之后就是心跳检测的过程了。客户端需要定时去更新自己的状态，服务端根据这个请求来更新客户端的最后存在时间，加入超时或者断开连接就代表客户端断线，就会将客户端从对象缓存池中移除。如果web站点更新了对应的配置，服务端会主动发送命名到客户端。命令类似于操作|命名空间|更改值，客户端根据收到的命令触发客户端的配置更新监听并且使用远程api更新客户端的缓存配置。客户端本身会自动更新配置内容，同时提供了一个监听方法便于监听配置的更改。多环境配置在服务端根目录下有一个config目录，这里就是给服务端多环境提供的配置。只需要根据NODE_ENV的值创建对应的文件即可。项目启动的时候会自动根据环境参数使用对应文件的配置。如果你要问客户端的多环境？命名空间已经完全可以实现了。如果要添加更多级的环境参数可以自定义命名空间的命名协议，比如：test.conf1这样的方式即可在不更改主体程序的情况下实现多级配置环境。代价是需要修改web站点的界面。。。。结束语到此一个nodejs版本的轻量级配置中心已经开发完成。如果将上面最开始提到的功能全部完成，这个项目也就不仅仅是一个轻量级的配置中心。它的功能已经完全不亚于其他的开源配置中心了。有兴趣的可以参与进来一起更新最好用的配置中心。项目地址