现实场景
传统应用打包部署, 会在不同的环境配置不同的包, 如Local环境, Dev环境, 测试环境, UAT环境, 生产环境分别制作不同的发布包,
每个包里环境特定配置.每一次部署都要修改配置文件, 提交审核代码, 才能打包, 非常的不方便. 相信很多朋友和我一样碰到过这种问题. 如果是共用环境, 由于环境问题, 经常会导致一个甚至多个team成员处于pending状态.
痛点:
配置散乱格式不统一
有的用properties, 有的用xml 或 yml 等, 还有存在DB里, 团队倾向自己造轮子, 反正是五花八门,
主要采用本地静态文件, 配置修改麻烦
配置修改一般需要经过一个较长的测试发布周期, 在分布式环境下, 当服务实例很多的时候, 修改配置费时费力
容易引发生产事故
在发布的时候将测试环境配置带到生产上,这种示例屡见不鲜.
配置缺乏安全审计和版本控制
谁改的配置? 改了什么? 什么时候改的? 天哪谁知道改了配置影响别人的什么服务? 出了问题及时回滚吧.
由此分布式配置中心应运而生, 现在市面上开源的配置中心有
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的亮点
- configService
提供配置获取接口
提供配置推送接口
服务于Apollo客户端
2.AdminService
提供配置管理接口
提供配置修改发布接口
无语管理界面Portal
3.Client
为应用获取配置,支持实时更新
通过MetaServer获取ConfigService服务列表
使用客户端软负载 SLB方式调用ConfigService
4.Portal
配置管理界面
通过MetaServer获取AdminService的服务列表
使用客户端软负载SLB方式调用AdminService
三个辅助服务模块
Eureka
用于服务发现和注册
Config/AdminService注册实例并定期汇报心跳
和ConfigService住在一起部署
MetaServer
Portal通过域名访问MetaServer获取AdminService的地址列表
Client通过域名访问MeT啊Server获取ConfigService地址列表
逻辑角色和ConfigService在一起部署
NginxLB
和域名系统配合,协助Portal访问MetaServer获取AdminService地址列表
和域名系统配合,协助Client访问MetaServer获取ConfigService地址列表
和域名系统配合,协助用户访问Portal进行配置管理
有些概念不是一下子就能明白的, 需要在实际项目中遇见后才会思考这类问题如何去解决, apoll给了我们一个很好的方案
功能特性:
静态配置管理
动态配置管理
统一管理,不同环境不同配置
配置缓存
配置校验
配置生效时效
配置更新推送
配置定时拉取
用户权限管理
授权, 审计,审核
配置版本管理
配置合规检测
实例配置监控
灰度发布
告警通知
依赖关系
Demo环境:
http://106.12.25.204:8070/ 账号/密码:apollo/admin
参考文献:
https://blog.csdn.net/z960339491/article/details/80667559
今日推荐阅读文章精选推荐
为什么要做接口测试
JMeter数据库操作
Jmeter接口测试-正则表达式
JMeter中文返回乱码
Jmeter接口测试-参数化
JMeter接口测试-基础
测试-感想