apollo配置中心

1. Apollo

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

Apollo支持4个维度管理Key-Value格式的配置：

• application (应用)
• environment (环境)
• cluster (集群)
• namespace (命名空间)

2. Cluster

一个应用下不同实例的分组，比如典型的可以按照数据中心分，把A机房的应用实例分为一个集群，把B机房的应用实例分为另一个集群。

3. Namespace

一个应用下不同配置的分组。 请参考Apollo核心概念之“Namespace”

Namespace是配置项的集合，类似于一个配置文件的概念。

4.四个核心模块及其主要功能

1. ConfigService

提供配置获取接口

提供配置推送接口

服务于Apollo客户端

2.AdminService

提供配置管理接口

提供配置修改发布接口

服务于管理界面Portal

3.Client

为应用获取配置，支持实时更新

通过MetaServer获取ConfigService的服务列表

使用客户端软负载SLB方式调用ConfigService

4.Portal

配置管理界面

通过MetaServer获取AdminService的服务列表

使用客户端软负载SLB方式调用AdminService

5.三个辅助服务发现模块

Eureka

用于服务发现和注册

Config/AdminService注册实例并定期报心跳

和ConfigService住在一起部署

MetaServer

Portal通过域名访问MetaServer获取AdminService的地址列表

Client通过域名访问MetaServer获取ConfigService的地址列表

相当于一个Eureka Proxy

逻辑角色，和ConfigService住在一起部署

NginxLB

和域名系统配合，协助Portal访问MetaServer获取AdminService地址列表

和域名系统配合，协助Client访问MetaServer获取ConfigService地址列表

和域名系统配合，协助用户访问Portal进行配置管理

接入Apollo？

请参考Apollo使用指南

我有多个应用需要使用同一份配置，Apollo是否能支持？

Apollo是支持的。请参考Apollo使用指南中的四、多个AppId使用同一份配置

Apollo相比于Spring Cloud Config有什么优势？

Spring Cloud Config的精妙之处在于它的配置存储于Git，这就天然的把配置的修改、权限、版本等问题隔离在外。通过这个设计使得Spring Cloud Config整体很简单，不过也带来了一些不便之处。

下面尝试做一个简单的小结：

| 功能点

|

Apollo

|

Spring Cloud Config

|

备注

| |

配置界面

|

一个界面管理不同环境、不同集群配置

|

无，需要通过git操作

|   | |

配置生效时间

|

实时

|

重启生效，或手动refresh生效

|

Spring Cloud Config需要通过Git webhook，加上额外的消息队列才能支持实时生效

| |

版本管理

|

界面上直接提供发布历史和回滚按钮

|

无，需要通过git操作

|   | |

灰度发布

|

支持

|

不支持

|   | |

授权、审核、审计

|

界面上直接支持，而且支持修改、发布权限分离

|

需要通过git仓库设置，且不支持修改、发布权限分离

|   | |

实例配置监控

|

可以方便的看到当前哪些客户端在使用哪些配置

|

不支持

|   | |

配置获取性能

|

快，通过数据库访问，还有缓存支持

|

较慢，需要从git clone repository，然后从文件系统读取

|   | |

客户端支持

|

原生支持所有Java和.Net应用，提供API支持其它语言应用，同时也支持Spring annotation获取配置

|

支持Spring应用，提供annotation获取配置

|

Apollo的适用范围更广一些

|

转载于:https://my.oschina.net/u/3729326/blog/3102363