微服务相关配套之Apollo

Apollo（阿波罗）是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。

几种config-server的对比

目前我们使用的config-server是基于spring cloud自带的config组件, 简单够用, 但和市面上的其他配置中心比起来还是弱了点, 以下是一个简单的比对:

Apollo中的一些概念

Apollo中依赖四个维度来确定一个配置文件, 从大到小依次是：application, env, cluster, namespace;

对于一套系统, Apollo的理解是这样的:  一个完整的科技团队, 是要面对多个环境(env)的, 比如开发环境测试环境线上环境, 而对于大公司而言, 环境可能会横跨多个数据中心, 所以每个环境中又可以划分为多个集群(cluster), 每个集群中运行着一系列的应用(Application), 对于应用来说, 他里面的代码可以抽象出很多组件, 比如负责处理业务逻辑的业务组件, 负责监控系统数据的监控组件, 负责埋点处理的埋点组件等等, 这些组件并不一定是同一个团队开发的, 比如业务开发团队负责业务组件, 基础架构团队负责监控组件, 数据分析团队负责埋点组件等, 将这些团队的配置文件整合到一起是一个费时费力又很容易出错的过程, 所以Apollo引入了一个namespace的概念, 每个组件的配置文件放在不同的namespace中, 各读各的, 互不干涉

以上是Apollo中引入的一些概念, 但实际上对于我们的应用场景而言, 这些维度并不是非常契合.

Apollo中还有一个release的概念, 修改了的配置, 并不是立即生效的, 只会在release即点了发布按钮只会生效, 甚至可以通过一些手段, 修改和发布的权限是独立的, 甚至可以通过配置, 要求修改和发布必须不能是同一个人, 达到强制review的效果;

Apollo的使用

与Spring boot的集成
1, 在pom中增加依赖;
2, 使用EnableApolloConfig注解, 开启Apollo;
3, 在配置文件中增加一些内容

 

Apollo的一些高级特性

Apollo的client增加了一些注解来简化配置项相关的操作

其中引入的ApolloConfigChangeListener, 可以监听配置项的变化, 对于一些需要加载或者需要预处理的配置型非常有用, 但有一个问题是, ApolloConfigChangeListener需要在定义时指定namespace, 对于我们这种namespace作为参数传入的场景, 需要再搞一搞,

我们使用中的一些变通

Apollo原生的四个维度, 对于规模比较大的, 跨数据中心的场景比较好使, 对于我们而言, 因为我们从Spring cloud的config-server阶段就只使用了两个维度来确定一个配置文件: Application和profile, 所以一下子切换到四个维度来划分配置, 对我们而言有点麻烦, 另外Apollo中的env这个维度使用也很不方便, 如果想要管理多个环境, 那么需要在每个环境中部署一套Meta Service, Config Service和Admin Service, 已经对应的数据库, 再另外部署一套Apollo Portal来管理这些环境, 还是比较麻烦的, 而且对于我们这种规模来说, 这样部署带来的收益并不多.

于是就因陋就简, 顺着之前config-server的思路, 将Apollo中的namespace对应我们之前的profile, 这样对于我们应用的切换和实际的管理操作, 代价都比较小, 

另外一个意外的好处是, Apollo提供的openapi中, 缺少对env和cluster做操作的api, 但操作namespace的api还是比较完善的, 所以对于我们的旧的配置数据迁移, 和批量改配置文件, 就可以通过api来操作, 节省人力

参考资料

Apollo在GitHub上的文档非常详尽, 甚至还有源码的解读

GitHub地址:  https://github.com/ctripcorp/apollo

Apollo的设计: https://github.com/ctripcorp/apollo/wiki/Apollo%E9%85%8D%E7%BD%AE%E4%B8%AD%E5%BF%83%E8%AE%BE%E8%AE%A1