微服务之配置中心ConfigKeeper

在黑少微服务（http://www.httpshop.com/） 架构中，配置中心是必不可少的基础服务。本文将深度分析配置中心的核心内容，错过2018.10.28「Spring Cloud中国社区北京站沙龙」的同学可以从本文中收获现场的分享内容。

背景

微服务+容器架构后，为了方便动态更新应用配置，需要把配置文件放到应用执行包之外的配置中心，这样一来，一个可执行包就可以在不同的环境下运行，大幅度降低包的版本管理成本，也可以有效控制docker镜像的版本管理成本。传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。对程序配置的期望值也越来越高：配置修改后实时生效，分环境、分集群管理配置，完善的权限、审核机制等等。于是便诞生了ConfigKeeper。

ConfigKeeper是随行付架构部基于Spring Cloud研发的分布式配置中心，与Spring Boot、Spring Cloud应用无缝兼容。 虽然Spring Cloud 已经为我们提供了基于git或mongodb等实现的配置中心，但是这些方案实现都过于简单，没有达到实际可用的标准。比如：没有提供统一的管理页面，不便于操作和使用；没有权限管理功能；没有数据验证功能等等。但Spring Cloud Config的核心技术还是可以为我们所用，没有必要重新造轮子。

定制原因

市面上已经有几款比较成型的配置中心，大家耳熟能详的携程Apollo和百度Disconf，而我们的配置中心底层是基于Spring Cloud Config模块进行扩展的，首先来看看Apollo、Spring Cloud Config、ConfigKeeper的功能差异：

image
除了上述之外，还有以下其他功能特性：

开发人员最习惯的就是在文件中修改配置，管理页面上提供「舒适」的富文本编辑框；

全局配置约定，比如多个项目共享的配置，比如短信地址等采取约定大于配置。全局配置<应用配置；

配置校验，文本修改高亮对比修改内容，防止低级错误等；

架构设计

有史以来最简单的配置中心。使用数据库保存配置是因为微服务拆分粒度相对比较细，使用的配置也会相对比较少，所以使用数据库表就够保存，流程如下：

1. 用户先去配置中心 添加、修改配置；

2. 应用启动时:（Spring boot应用向配置中心客户端获取配置、然后缓存配置到本地内存及本地文件缓存、应用根据配置进行启动；）

3. 不停机更新配置（调用Spring Cloud的RefreshEndpoint、通过RefreshEndpoint刷新配置）

4. 使用前后端分离架构，如果需要重新设计管理界面，也可以使用自己习惯的技术实现

image
设计的初心

通过讲解管理后台功能，理解我们当初出于什么原因为什么要这么设计？能解决哪些问题？设计时的考虑点有哪些?通过前面的阅阅读，已知ConfigKeeper有以下核心功能：

image
“权限管理

为什么要有权限管理？

对于企业级应用来说，权限管理是必不可以一个需求；

通过权限管理隔离数据，保证数据的安全性，避免误操作；

在微服务比较多情况下，也可以通过权限自动过滤出我们所关心的服务，不需要再自己手动过滤，减少不必要的操作，可以提高工作效率；

image
这个权限系统是我们最初设计的，我们内部现在使用了一个统一的权限系统。为了降低管理成本，我们也开发了微服务管理平台，将配置中心，注册中心，网关管理后台等一系列基础服务都接入到此平台来管理，并通过此平台统一进行权限管理；

我们使用开源系统越多，那么需要管理的账号就会越多，如果团队比较大的话，会增加非常大的管理成本。

“多环境管理

配置中心的部署比较灵活，支持多环境集中式管理。但是随行付内部，为了隔离生产环境，我们分开部署了两套配置中心，一套负责开发环境、测试环境、准生产环境的配置管理，另一套负责生产环境的配置管理。当然开发工程师可以选择使用本地配置，不强制开发者环境与配置中心强关联。(只要考虑开发人员众多，需求同步进行)

image
“