一、配置中心的诞生
用编程语言编写应用项目时,一般都会有项目的配置文件。比如用 java 编写项目,有一个 properties 的配置文件,会把一些配置信息写入到该文本文件中,例如数据库相关的配置信息。
这也体现了软件设计的一个原则:关注点分离。把代码和配置信息相分离。
(单体应用项目配置文件)
在单体应用项目中,这个配置文件一般都是静态的文本文件。项目比较小时,配置信息不是很多、变动也少,这时使用静态配置文件足矣。修改了配置后,重启一下应用就可以了。
随着项目的发展壮大,业务增多,用户增多,功能增多,原来的大单体应用项目会慢慢的拆分为多个独立的应用项目,然后向着微服务架构发展演变。
(大单体应用拆为为各个独立应用)
这样,随着大单体项目拆分为一个一个独立应用项目时,配置文件也会跟着项目迁移,每个项目都有自己的配置文件,配置文件变得分散。
假如业务要增加一个功能,而实现这个功能需要协调多个项目开发,并修改各自配置时,就需要到一个一个项目上去修改配置,然后重启应用以使配置生效。
这样做是可行的,但是有没有可以改进的地方?让配置修改更加高效,而不需要一个文件一个文件去修改,这样太低效了。
如何从系统架构角度出发,构建灵活、易扩展的系统,快速应对配置需求的变化。
能不能独立出一个存储配置的系统?能不能把这些配置信息集中存储在一个地方,修改时只需在一个地方修改,然后动态分发给相应的应用项目?当然可以,这就是配置中心。
随着多个项目向着微服务架构的进化,应用项目分拆为更多的小服务,由各种服务来给应用项目提供功能,服务越多,配置信息也越多,配置中心也需要更多功能才能满足需求,配置中心也会向着分布式配置管理中心进化。
二、静态配置文件的问题
在业务量比较小的单体应用中,静态文本配置文件使用是没有大的问题。但是随着业务逐渐发展壮大,对大单体拆分为多个应用,就会产生一些问题:
- 配置文件分散,修改起来比较麻烦
- 配置生效不及时,修改后需要重启应用以使配置生效
- 多环境配置,无法区分多个配置环境,比如开发的环境,测试的环境,预发布的环境,生产的环境
- 各种配置信息多,难以管理,比如分布式限流的配置信息,各种监控的配置信息等等配置
- 配置信息无法回滚,没有类似版本控制功能的话,就无法进行回滚
等等各种问题。
三、配置中心功能
上面是静态配置文件最初出现的问题,后面随着应用的拆分、随着业务功能越来越多,对配置的功能要求也逐渐变多:
- 版本管理功能,配置的发布有版本功能可支持回滚,也进行信息回溯
- 配置信息回滚
- 灰度发布功能,支持功能灰度发布
- 集中统一管理,对多环境配置信息管理,比如开发、测试、生产等各种环境的配置信息
- 实时生效,修改完后及时下发给对应的应用,应用可以进行热更新配置,不用重启应用
- 集群功能,有集群功能,能扩容,能容灾,高可用
- UI界面管理
等等功能。
配置中心的这些功能,解决了静态配置文件出现的问题,而且还新增了很多额外的功能。
四、开源配置中心
有很多开源的软件可以作为配置中心使用,比如下面这些:
- Apollo
- Nacos
- ETCD
- Consul
- k8s ConfigMap
当然还有很多其他的,比如 Spring Cloud Config,Disconf,Zookeeper 等。
下面介绍下 Apollo 分布式配置中心。
五、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基础模型
- 用户在配置中心对配置进行修改并发布
- 配置中心通知Apollo客户端有配置更新
- 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/ 开源地址
六、参考
- 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/
服务器托管,北京服务器托管,服务器租用 http://www.fwqtg.net
机房租用,北京机房租用,IDC机房托管, http://www.fwqtg.net