1、配置中心的诞生

用编程语言编写应用项目时，一般都会有项目的配置文件。比如用 java 编写项目，有一个 properties 的配置文件，会把一些配置信息写入到该文本文件中，例如数据库相关的配置信息.

这也体现了软件设计的一个原则： 关注点分离 。把代码和配置信息相分离.

​ （单体应用项目配置文件） 。

在单体应用项目中，这个配置文件一般都是静态的文本文件。项目比较小时，配置信息不是很多、变动也少，这时使用静态配置文件足矣。修改了配置后，重启一下应用就可以了.

随着项目的发展壮大，业务增多，用户增多，功能增多，原来的大单体应用项目会慢慢的拆分为多个独立的应用项目，然后向着微服务架构发展演变.

​ （大单体应用拆为为各个独立应用） 。

这样，随着大单体项目拆分为一个一个独立应用项目时，配置文件也会跟着项目迁移，每个项目都有自己的配置文件，配置文件变得分散.

假如业务要增加一个功能，而实现这个功能需要协调多个项目开发，并修改各自配置时，就需要到一个一个项目上去修改配置，然后重启应用以使配置生效.

这样做是可行的，但是有没有可以改进的地方？让配置修改更加高效，而不需要一个文件一个文件去修改，这样太低效了.

能不能把这些配置信息集中存储在一个地方，修改时只需在一个地方修改，然后动态分发给相应的应用项目？当然可以，这就是 配置中心 .

随着多个项目向着微服务架构的进化，应用项目分拆为更多的小服务，由各种服务来给应用项目提供功能，服务越多，配置信息也越多，配置中心也需要更多功能才能满足需求，配置中心也会向着分布式配置管理中心进化.

2、静态配置文件的问题

在业务量比较小的单体应用中，静态文本配置文件使用是没有大的问题。但是随着业务逐渐发展壮大，对大单体拆分为多个应用，就会产生一些问题:

• 配置文件分散，修改起来比较麻烦
• 配置生效不及时，修改后需要重启应用以使配置生效
• 多环境配置，无法区分多个配置环境，比如开发的环境，测试的环境，预发布的环境，生产的环境
• 各种配置信息多，难以管理，比如分布式限流的配置信息，各种监控的配置信息等等配置
• 配置信息无法回滚，没有类似版本控制功能的话，就无法进行回滚

等等各种问题.

3、配置中心功能

上面是静态配置文件最初出现的问题，后面随着应用的拆分、随着业务功能越来越多，对配置的功能要求也逐渐变多:

• 版本管理功能，配置的发布有版本功能可支持回滚，也进行信息回溯
• 配置信息回滚
• 灰度发布功能，支持功能灰度发布
• 集中统一管理，对多环境配置信息管理，比如开发、测试、生产等各种环境的配置信息
• 实时生效，修改完后及时下发给对应的应用，应用可以进行热更新配置，不用重启应用
• 集群功能，有集群功能，能扩容，能容灾，高可用
• UI界面管理

等等功能.

配置中心的这些功能，解决了静态配置文件出现的问题，而且还新增了很多额外的功能.

4、开源配置中心

有很多开源的软件可以作为配置中心使用，比如下面这些:

• Apollo
• Nacos
• ETCD
• Consul
• k8s ConfigMap

当然还有很多其他的，比如 Spring Cloud Config，Disconf，Zookeeper 等.

下面介绍下 Apollo 分布式配置中心.

5、Apollo分布式配置中心

Apollo（阿波罗）介绍

​ （来源： https://github.com/apolloconfig/apollo/ apollo github） 。

Apollo（阿波罗）是一款 可靠的分布式配置管理中心 ，诞生于携程框架研发部，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景.

服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器.

背景:

随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、参数的配置、服务器的地址…… 。

对程序配置的期望值也越来越高：配置修改后实时生效，灰度发布，分环境、分集群管理配置，完善的权限、审核机制…… 。

在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。Apollo配置中心应运而生！ 。

--- 来自 Apollo 官网 。

Apollo 功能特性

• 统一管理不同环境、不同集群的配置
• 配置修改实时生效（热发布）
• 版本发布管理
• 灰度发布
• 权限管理、发布审核、操作审计
• 客户端配置信息监控
• 多种客户端，并提供Java和.Net原生客户端
• 提供开放平台API
• UI 界面管理

更多信息请查看文档： https://www.apolloconfig.com/#/zh/design/apollo-introduction 。

架构设计

Apollo基础模型

1. 用户在配置中心对配置进行修改并发布
2. 配置中心通知Apollo客户端有配置更新
3. Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用

架构模块

五个主要核心模块:

• Config Service 。

  • 提供配置的读取、推送等功能
  • 服务对象是Apollo客户端

• Admin Service 。

  • 提供配置的修改、发布等功能
  • 服务对象是Apollo Portal（管理界面）

• Meta Server 。

  • Meta Server用于封装Eureka的服务发现接口

• Client 。

  • 实时获取配置信息
  • 通过访问 Meta Server 获取 Config Service 服务列表
  • 在Client侧会做load balance、错误重试

• Portal 。

  • 配置管理界面 UI
  • 通过 Meta Server 获取 Admin Service 服务列表
  • 在 Portal侧会做 load balance、错误重试

以上信息和图片来源： https://www.apolloconfig.com/#/zh/design/apollo-design 。

Apollo部署

这部分请查看部署文档： https://www.apolloconfig.com/#/zh/deployment/quick-start 。

Apollo文档

开源地址和文档:

• https://www.apolloconfig.com/#/zh/README 中文文档
• https://github.com/apolloconfig/apollo/ 开源地址

6、参考

• https://github.com/apolloconfig/apollo/
• https://www.apolloconfig.com/#/zh/
• https://github.com/alibaba/nacos
• https://github.com/etcd-io/etcd
• https://github.com/hashicorp/consul
• https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/

最后此篇关于微服务架构学习与思考(13)：分布式配置中心的文章就讲到这里了,如果你想了解更多关于微服务架构学习与思考(13)：分布式配置中心的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。