现实场景
传统应用打包部署, 会在不同的环境配置不同的包, 如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的亮点
1. 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
今日推荐阅读文章精选推荐
咨询工作加微信
扫描二维码
欢迎自荐和推荐, 需要的微信推送简历!
请猛戳下面二维码了解更多