Apollo特性

Apollo特性

基于配置的特殊性，所以Apollo从设计之初就立志于成为一个有治理能力的配置发布平台，目前提供了以下的特性：

（1）统一管理不同环境、不同集群的配置

1.Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。

2.同一份代码部署在不同的集群，可以有不同的配置，比如zookeeper的地址等

3.通过命名空间（namespace）可以很方便地支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖

（2）配置修改实时生效（热发布）

用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序

（3）版本发布管理

所有的配置发布都有版本概念，从而可以方便地支持配置的回滚

（4）灰度发布

支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例

（5）权限管理、发布审核、操作审计

1.应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。

2.所有的操作都有审计日志，可以方便地追踪问题

（6）客户端配置信息监控

可以在界面上方便地看到配置在被哪些实例使用

（7）提供Java和.Net原生客户端

1.提供了Java和.Net的原生客户端，方便应用集成
2.支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便应用使用（需要Spring 3.1.1+）
3.同时提供了Http接口，非Java和.Net应用也可以方便地使用

（8）提供开放平台API

1.Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。不过Apollo出于通用性考虑，不会对配置的修改做过多限制，只要符合基本的格式就能保存，不会针对不同的配置值进行针对性的校验，如数据库用户名、密码，Redis服务地址等

2.对于这类应用配置，Apollo支持应用方通过开放平台API在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制

基础模型

1.用户在配置中心对配置进行修改并发布。

2.配置中心通知Apollo客户端有配置更新。

3.Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用。

架构模块

如果我们把Apollo配置中心服务端展开的话，架构图如下：

Portal服务：提供Web界面供用户管理配置，通过MetaServer获取AdminService服务列表（IP+Port），通过IP+Port访问AdminService服务。

Client：实际上就是我们创建的SpringBoot项目，引入ApolloClient的maven依赖，为应用提供配置获取、实时更新等功能。

Meta Server：从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka Client。主要是为了封装服务发现的细节，对Portal和Client而言，永远通过一个Http接口获取Admin Service和Config Service的服务信息，而不需要关心背后实际的服务注册和发现组件。Meta Server只是一个逻辑角色，在部署时和Config Service是在一个JVM进程中的，所以IP、端口和Config Service一致。

Eureka：注册中心。Config Service和Admin Service会向Eureka注册服务。为了简单起见，目前Eureka在部署时和Config Service是在一个JVM进程中的。

Config Service：提供配置获取接口。提供配置更新推送接口(基于Http long polling)。服务对象为Apollo客户端(Client)。

Admin Service：提供配置管理接口。提供配置发布、修改等接口。服务对象为Portal。

配置发布后的实时推送设计

上面讲完各个角色的用途，那这些角色是怎么配合一起工作的呢，我们来看一张图：

上图简要描述了配置发布的大致过程：

1.用户在Portal操作配置发布。
2.Portal调用Admin Service的接口操作发布。
3.Admin Service发布配置后，发送ReleaseMessage给各个Config Service。
4.Config Service收到ReleaseMessage后，通知对应的客户端(Client)。

关键点在于AdminService发送ReleaseMessage给ConfigService，这一步是如何异步发送的呢，一般异步发送我们很容易想到消息队列，但是实际上我们在安装部署时并没有使用到消息队列。

答案在于：

Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录，消息内容就是配置发布的AppId+Cluster+Namespace。
然后Config Service有一个线程会每秒扫描一次ReleaseMessage表，看看是否有新的消息记录。
Config Service如果发现有新的消息记录，那么就会通知到所有的消息监听器，监听器得到配置发布的AppId+Cluster+Namespace后，会通知对应的客户端。

在实现上，考虑到Apollo的实际使用场景，以及为了尽可能减少外部依赖，我们没有采用外部的消息中间件，而是通过数据库实现了一个简单的消息队列。----来自官网

高可用

Apollo为了实现高可用，服务端使用了Eureka作为注册中心，这一点在官网也有谈到。

除此之外，客户端也做了高可用的一些架构设计，比如本地文件缓存。

这个缓存文件默认就放在C:\opt\data\apollo-demo\config-cache路径下：

这个文件的作用是，在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置。