Apollo简介
Apollo(阿波罗)是携程框架部门研发的开源配置管理中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性。
Apollo支持4个维度管理Key-Value格式的配置:
- application (应用)
- environment (环境)
- cluster (集群)
- namespace (命名空间)
同时,Apollo基于开源模式开发,开源地址:https://github.com/ctripcorp/apollo
总的来看,Apollo和Nacos相对于Spring Cloud Config的生态支持更广,在配置管理流程上做的更好。Apollo相对于Nacos在配置管理做的更加全面,Nacos则使用起来相对比较简洁,在对性能要求比较高的大规模场景更适合。但对于一个开源项目的选型,项目上的人力投入(迭代进度、文档的完整性)、社区的活跃度( issue的数量和解决速度、Contributor数量、社群的交流频次等),这些因素也比较关键,考虑到Nacos开源时间不长和社区活跃度,所以从目前来看Apollo应该是最合适的配置中心选型。
Apollo(阿波罗)是携程框架部门研发的分布式配置中心,能够集中化管理应用的不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。
Apollo包括服务端和客户端两部分︰
服务端基于Spring Boot和Spring Cloud开发,打包后可以直接运行,不需要额外安装Tomcat等应用容器。
Java客户端不依赖任何框架,能够运行于所有Java运行时环境,同时对Spring/Spring Boot环境也有较好的支持。
Apollo特性
正是基于配置的特殊性,所以Apollo从设计之初就立志于成为一个有治理能力的配置发布平台,目前提供了以下的特性:
统一管理不同环境、不同集群的配置
- Apollo提供了一个统一界面集中式管理不同环境(environment)、不同集群(cluster)、不同命名空间(namespace)的配置。
- 同一份代码部署在不同的集群,可以有不同的配置,比如zookeeper的地址等
- 通过命名空间(namespace)可以很方便地支持多个不同应用共享同一份配置,同时还允许应用对共享的配置进行覆盖
配置修改实时生效(热发布)
- 用户在Apollo修改完配置并发布后,客户端能实时(1秒)接收到最新的配置,并通知到应用程序
版本发布管理
- 所有的配置发布都有版本概念,从而可以方便地支持配置的回滚
灰度发布
- 支持配置的灰度发布,比如点了发布后,只对部分应用实例生效,等观察一段时间没问题后再推给所有应用实例
权限管理、发布审核、操作审计
- 应用和配置的管理都有完善的权限管理机制,对配置的管理还分为了编辑和发布两个环节,从而减少人为的错误。
- 所有的操作都有审计日志,可以方便地追踪问题
客户端配置信息监控
- 可以在界面上方便地看到配置在被哪些实例使用
提供Java和.Net原生客户端
- 提供了Java和.Net的原生客户端,方便应用集成
- 支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties,方便应用使用(需要Spring 3.1.1+)
- 同时提供了Http接口,非Java和.Net应用也可以方便地使用
提供开放平台API
- Apollo自身提供了比较完善的统一配置管理界面,支持多环境、多数据中心配置管理、权限、流程治理等特性。不过Apollo出于通用性考虑,不会对配置的修改做过多限制,只要符合基本的格式就能保存,不会针对不同的配置值进行针对性的校验,如数据库用户名、密码,Redis服务地址等
- 对于这类应用配置,Apollo支持应用方通过开放平台API在Apollo进行配置的修改和发布,并且具备完善的授权和权限控制
部署简单
- 配置中心作为基础服务,可用性要求非常高,这就要求Apollo对外部依赖尽可能地少
- 目前唯一的外部依赖是MySQL,所以部署非常简单,只要安装好Java和MySQL就可以让Apollo跑起来
- Apollo还提供了打包脚本,一键就可以生成所有需要的安装包,并且支持自定义运行时参数
Apollo架构
核心概念
1,application(应用)
实际使用配置的应用,Apollo客户端在运行时需要知道当前应用是谁,从而可以去获取对应的配置。
关键字:appld
2,environment(环境)
配置对应的环境,Apollo客户端在运行时需要知道当前应用处于哪个环境,从而可以去获取应用的配置
关键字:env
3,cluster(集群)
一个应用下不同实例的分组,比如典型的可以按照数据中心分,把北京机房的应用实例分为一个集群,把西安的应用实例分为另一个集群
关键字:cluster
4,namespace(命名空间)
一个应用下不同配置的分组,可以简单的把namespace类比为文件,不同类型的配置存放在不同的文件中,如数据库配置文件,RPC配置文件,应用自身的配置文件等。
关键字:namespace
关系图:
项目管理:
基础设置:
1,部门管理
Apollo默认部门有两个,要增加自己的部门,可在系统参数中修改:
管理员工具--》系统参数--》key中搜索organizations--》配置部门信息--》保存
2,用户管理
添加用户:管理员工具--》用户管理--》添加新用户
创建项目
添加项目,填写基本项目信息
删除项目
管理员工具--》删除应用--》应用AppID--》查询后删除应用
配置管理
添加发布配置项
新增配置--》填写信息--》提交--》发布
修改配置
找到对应配置项,点击修改--》修改为需要的值,点击提交--》发布配置
删除配置
找到需要删除的配置项,点击深处--》确认删除后,点击发布
添加namespace(相当于一个配置文件)
进到项目--》左下角添加namespace--》创建namespace(取名,确定共有私有)
回到首页,可以看见新添加的namespace,然后可以在namespace里添加配置
(可以以文本的形式添加配置)
公共配置:
1,添加公共namespace
在项目开发中,有一些配置可能是通用的,我们可以通过把这些通用的配置放到公共的namespace中,这样其他的项目要使用时可以直接添加需要的namespace。
1.新建common-template项目
2.添加公共namespace:spring-boot-http
点击文本快速添加配置信息--》发布
3.其他项目关联公共namespace
选择其他项目---》添加namespace---》关联公共namespace
公共namespace的信息其他项目不能改原件,但可以做覆盖修改做个性化。
查看用命名空间查看
集群管理
添加集群
左下角添加集群--》取集群名,选择环境--》提交
新增的集群会默认创建本应用的私有namespace
集群同步配置
同步过来的项目需要手动点击发布
读取配置
读取某个集群的配置,需要启动应用时指定具体的应用,环境和集群
发布配置原理
主要流程:
1.用户在Portal操作配置发布。
2.Portal调用Admin Service的接口操作发布
3.Admin Service 发布配置后,发送ReleaseMessage给各个Config Service
4.Config Service 收到ReleaseMessage后,通知对应的客户端
发送ReleaseMessage
Apollo会在数据库里创建一个ReleaseMessage的表存储发布配置的消息
Apollo通过数据库是西安了一个简单的消息队列
具体实现方法如下:
1.Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录,消息内容就是配置发布的Appled+Cluster+Namespace
2.Config Service有一个线程会每秒扫描一次ReleaseMessage表,看看是否有新的消息记录
3.Config Service如果发现有新的消息记录,那么就会通知到所有的消息监听器
4.NotificationControllerV2得到配置发布的Appld+Cluster+Namespace后,会通知对应的客户端
Config Service通知客户端
具体实现方法:
1.客户端会发起一个Http请求到Config Service
2.如果没有结果的话,不会立即返回,而是把请求挂起。由于这是个长连接(长连接占用网络资源)因此在服务端采用了async servlet异步的方式来回应请求
3.如果60秒内没有客户端关心的配置发布,那么返回http状态码304给客户端
4.如果有客户关心的配置发布,客户端拿到namespace信息后会主动获取namespace下的配置信息
客户端读取设计:
客户端会定时从Apollo配置中心服务端拉去应用的最新配置(五分钟拉取一次)