配置中心化

现实场景

传统应用打包部署, 会在不同的环境配置不同的包, 如Local环境, Dev环境, 测试环境, UAT环境, 生产环境分别制作不同的发布包,

每个包里环境特定配置.每一次部署都要修改配置文件, 提交审核代码, 才能打包, 非常的不方便. 相信很多朋友和我一样碰到过这种问题. 如果是共用环境, 由于环境问题, 经常会导致一个甚至多个team成员处于pending状态.

痛点:

1.配置散乱格式不统一

有的用properties, 有的用xml 或 yml 等, 还有存在DB里, 团队倾向自己造轮子, 反正是五花八门

2.主要采用本地静态文件, 配置修改麻烦

配置修改一般需要经过一个较长的测试发布周期, 在分布式环境下, 当服务实例很多的时候, 修改配置费时费力

3.容易引发生产事故

在发布的时候将测试环境配置带到生产上,这种示例屡见不鲜.

4.配置缺乏安全审计和版本控制

谁改的配置? 改了什么? 什么时候改的? 天哪谁知道改了配置影响别人的什么服务? 出了问题及时回滚吧.

由此分布式配置中心应运而生, 现在市面上开源的配置中心有

1.Spring出品: Spring-cloud/Spring-cloud-config

https://github.com/spring-cloud/spring-cloud-config

2.蚂蚁金服专家发起:Disconf https://github.com/knightliao/disconf

3.携程出品: Apollo https://github.com/ctripcorp/apollo/

今天和大家聊的是第三个由上海携程出品的开源分布式配置中心Apollo, 名字非常的高大上叫阿波罗(让人联想起了美国登月计划)

从github的Star上可以判断,受用户关注度远超前两个, 达到了1.7W+颗星, 并且还在快速的增长. https://starcharts.herokuapp.com/ctripcorp/apollo

随着应用程序配置日益增多复杂, 各种功能开关, 参数配置, 服务器地址等对于应用配置的期望也越来越高, 配置修改后实施生效, 灰度发布, 分环境, 分集群管理, 完善权限机制, 审核机制等.在这样的大背景下,传统的静态配置文件,数据库等方式已经越来越无法满足配置管理的需求.

Apollo的亮点

1. configService

提供配置获取接口

提供配置推送接口

服务于Apollo客户端

2.AdminService

提供配置管理接口

提供配置修改发布接口

无语管理界面Portal

3.Client

为应用获取配置,支持实时更新

通过MetaServer获取ConfigService服务列表

使用客户端软负载 SLB方式调用ConfigService

4.Portal

配置管理界面

通过MetaServer获取AdminService的服务列表

使用客户端软负载SLB方式调用AdminService

三个辅助服务模块

1.Eureka

用于服务发现和注册

Config/AdminService注册实例并定期汇报心跳

和ConfigService住在一起部署

2.MetaServer

Portal通过域名访问MetaServer获取AdminService的地址列表

Client通过域名访问MeT啊Server获取ConfigService地址列表

逻辑角色和ConfigService在一起部署

3.NginxLB

和域名系统配合，协助Portal访问MetaServer获取AdminService地址列表

和域名系统配合，协助Client访问MetaServer获取ConfigService地址列表

和域名系统配合，协助用户访问Portal进行配置管理

有些概念不是一下子就能明白的, 需要在实际项目中遇见后才会思考这类问题如何去解决, Apollo给了我们一个很好的方案

功能特性:

1. 静态配置管理

2. 动态配置管理

3. 统一管理,不同环境不同配置

4. 配置缓存

5. 配置校验

6. 配置生效时效

7. 配置更新推送

8.配置定时拉取

9.用户权限管理

10. 授权, 审计,审核

11. 配置版本管理

12. 配置合规检测

13. 实例配置监控

14. 灰度发布

15. 告警通知

16. 依赖关系

Demo环境:

http://106.12.25.204:8070/ 账号/密码:apollo/admin

参考文献:

https://blog.csdn.net/z960339491/article/details/80667559