现实场景html
传统应用打包部署, 会在不一样的环境配置不一样的包, 如Local环境, Dev环境, 测试环境, UAT环境, 生产环境分别制做不一样的发布包,git
每一个包里环境特定配置.每一次部署都要修改配置文件, 提交审核代码, 才能打包, 很是的不方便. 相信不少朋友和我同样碰到过这种问题. 若是是共用环境, 因为环境问题, 常常会致使一个甚至多个team成员处于pending状态.github
痛点:正则表达式
配置散乱格式不统一spring
有的用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
参考文献:
http://www.javashuo.com/article/p-fvmevrup-kg.html
今日推荐阅读文章精选推荐
咨询工做加微信
扫描二维码
欢迎自荐和推荐, 须要的微信推送简历!
请猛戳下面二维码了解更多