Apollo配置中心（一）架构演进

笔者在工作中遇到如下问题，随着程序功能越多，配置文件不断增加，一些功能的开关、服务器地址、接口地址、不同环境的一些配置文件不同，这些在每次发布不同环境、更新项目时都比较繁琐，后来学习微服务时接触到了Spring Cloud Config配置中心，用了一段时间发现比之前方便不少，但是还是比较繁琐和麻烦，而且功能还达不到生产级，只能小规模场景下使用，在中大规模企业场景下不建议采用。后来了解到携程Apollo配置中心，Apollo支持完善的管理界面，支持多环境，配置变更实时生效，权限和配置审计等多种生产级功能，而且在携程到微服务架构体系中也运用了这个，在国内众多互联网公司也有落地案例，就开始去接触了解。最后结合工作和学习的一些经验分享给大家Apollo的入门使用和一些走过的坑，本篇文章主要介绍了Apollo架构体系、Apollo运行原理、Apollo配置中心概念、特性简单介绍。

部分资料来源：

携程Apollo配置中心架构深度解析：https://www.cnblogs.com/davidwang456/articles/9154260.html

Apollo配置中心简单介绍：https://blog.csdn.net/Michael_HM/article/details/79412461

推荐博客：

Apollo架构体系、Apollo运行原理、Apollo配置中心简单介绍：https://blog.csdn.net/zjh_746140129/article/details/86179522

Linux下配置安装Apollo、Centons下配置安装Apollo：https://blog.csdn.net/zjh_746140129/article/details/86179601

Spring Boot项目整合Apollo配置中心：https://blog.csdn.net/zjh_746140129/article/details/86361168

Spring boot项目整合apollo错误：for env UNKNOWN from com.ctrip.framework.apollo.internals.DefaultMetaServer

1. Apollo简介

Apollo（阿波罗）是携程框架部研发并开源的一款生产级的配置中心产品，它能够集中管理应用在不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

Apollo目前在国内开发者社区比较热，在Github上有超过5k颗星，在国内众多互联网公司有落地案例，可以说Apollo是目前配置中心产品领域Number1的产品，其成熟度和企业级特性要远远强于Spring Cloud体系中的Spring Cloud Config产品。

Apollo采用分布式微服务架构，它的架构有一点复杂，Apollo的作者宋顺虽然给出了一个架构图，但是如果没有一定的分布式微服务架构基础的话，则普通的开发人员甚至是架构师也很难一下子理解。

2. Apollo架构和模块

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

ConfigService

• 提供配置获取接口
• 提供配置推送接口
• 服务于Apollo客户端

AdminService

• 提供配置管理接口
• 提供配置修改发布接口
• 服务于管理界面Portal

Client

• 为应用获取配置，支持实时更新
• 通过MetaServer获取ConfigService的服务列表
• 使用客户端软负载SLB方式调用ConfigService

Portal

• 配置管理界面
• 通过MetaServer获取AdminService的服务列表
• 使用客户端软负载SLB方式调用AdminService

2.2 三个辅助服务发现模块

Eureka

• 用于服务发现和注册
• Config/AdminService注册实例并定期报心跳
• 和ConfigService住在一起部署

MetaServer

• Portal通过域名访问MetaServer获取AdminService的地址列表
• Client通过域名访问MetaServer获取ConfigService的地址列表
• 相当于一个Eureka Proxy
• 逻辑角色，和ConfigService住在一起部署

NginxLB

• 和域名系统配合，协助Portal访问MetaServer获取AdminService地址列表
• 和域名系统配合，协助Client访问MetaServer获取ConfigService地址列表
• 和域名系统配合，协助用户访问Portal进行配置管理

3. 架构剖析

3.1 Apollo架构V1

如果不考虑分布式微服务架构中的服务发现问题，Apollo的最简架构如下图所示：

1. nfigService是一个独立的微服务，服务于Client进行配置获取。
2. Client和ConfigService保持长连接，通过一种拖拉结合(push & pull)的模式，实现配置实时更新的同时，保证配置更新不丢失。
3. AdminService是一个独立的微服务，服务于Portal进行配置管理。Portal通过调用AdminService进行配置管理和发布。
4. ConfigService和AdminService共享ConfigDB，ConfigDB中存放项目在某个环境的配置信息。
5. ConfigService/AdminService/ConfigDB三者在每个环境(DEV/FAT/UAT/PRO)中都要部署一份。
6. Portal有一个独立的PortalDB，存放用户权限、项目和配置的元数据信息。Protal只需部署一份，它可以管理多套环境。

3.2 Apollo架构V2

为了保证高可用，ConfigService和AdminService都是无状态以集群方式部署的，这个时候就存在一个服务发现问题：Client怎么找到ConfigService？Portal怎么找到AdminService？为了解决这个问题，Apollo在其架构中引入了Eureka服务注册中心组件，实现微服务间的服务注册和发现，更新后的架构如下图所示：

1. Config/AdminService启动后都会注册到Eureka服务注册中心，并定期发送保活心跳。
2. Eureka采用集群方式部署，使用分布式一致性协议保证每个实例的状态最终一致。

3.3 Apollo架构V3

我们知道Eureka是自带服务发现的Java客户端的，如果Apollo只支持Java客户端接入，不支持其它语言客户端接入的话，那么Client和Portal只需要引入Eureka的Java客户端，就可以实现服务发现功能。发现目标服务后，通过客户端软负载(SLB，例如Ribbon)就可以路由到目标服务实例。这是一个经典的微服务架构，基于Eureka实现服务注册发现+客户端Ribbon配合实现软路由，如下图所示：

3.4 Apollo架构V4

在携程，应用场景不仅有Java，还有很多遗留的.Net应用。Apollo的作者也考虑到开源到社区以后，很多客户应用是非Java的。但是Eureka(包括Ribbon软负载)原生仅支持Java客户端，如果要为多语言开发Eureka/Ribbon客户端，这个工作量很大也不可控。为此，Apollo的作者引入了MetaServer这个角色，它其实是一个Eureka的Proxy，将Eureka的服务发现接口以更简单明确的HTTP接口的形式暴露出来，方便Client/Protal通过简单的HTTPClient就可以查询到Config/AdminService的地址列表。获取到服务实例地址列表之后，再以简单的客户端软负载(Client SLB)策略路由定位到目标实例，并发起调用。

现在还有一个问题，MetaServer本身也是无状态以集群方式部署的，那么Client/Protal该如何发现MetaServer呢？一种传统的做法是借助硬件或者软件负载均衡器，例如在携程采用的是扩展后的NginxLB（也称Software Load Balancer），由运维为MetaServer集群配置一个域名，指向NginxLB集群，NginxLB再对MetaServer进行负载均衡和流量转发。Client/Portal通过域名+NginxLB间接访问MetaServer集群。

引入MetaServer和NginxLB之后的架构如下图所示：

3.5 Apollo架构V5

V4版本已经是比较完成的Apollo架构全貌，现在还剩下最后一个环节：Portal也是无状态以集群方式部署的，用户如何发现和访问Portal？答案也是简单的传统做法，用户通过域名+NginxLB间接访问MetaServer集群。

所以V5版本是包括用户端的最终的Apollo架构全貌，如下图所示：

4. 结论

1. 宋顺的视角是一个从上往下的俯视视角，而我的是一个侧面视角。
2. ConfgService/AdminService/Client/Portal是Apollo的四个核心微服务模块，相互协作完成配置中心业务功能，Eureka/MetaServer/NginxLB是辅助微服务之间进行服务发现的模块。
3. Apollo采用微服务架构设计，架构和部署都有一些复杂，但是每个服务职责单一，易于扩展。另外，Apollo只需要一套Portal就可以集中管理多套环境(DEV/FAT/UAT/PRO)中的配置，这个是它的架构的一大亮点。
4. 服务发现是微服务架构的基础，在Apollo的微服务架构中，既采用Eureka注册中心式的服务发现，也采用NginxLB集中Proxy式的服务发现。

5. Spring Cloud Config和Apollo对比

这张图也算是综合对比了spring cloud config,netflix archaius, ctrip apollo, disconf, hawk 等配置中心的功能点。综合比较下来携程Apollo更具有优势。

6. Apollo配置中心基本概念、特性

配置是独立于程序的只读变量

• 配置首先是独立于程序的，同一份程序在不同的配置下会有不同的行为。
• 其次，配置对于程序是只读的，程序通过读取配置来改变自己的行为，但是程序不应该去改变配置。
• 常见的配置有：DB Connection Str、Thread Pool Size、Buffer Size、Request Timeout、Feature Switch、Server Urls等。

配置伴随应用的整个生命周期

• 配置贯穿于应用的整个生命周期，应用在启动时通过读取配置来初始化，在运行时根据配置调整行为。

配置可以有多种加载方式

• 配置也有很多种加载方式，常见的有程序内部hard code，配置文件，环境变量，启动参数，基于数据库等

配置需要治理

• 权限控制，由于配置能改变程序的行为，不正确的配置甚至能引起灾难，所以对配置的修改必须有比较完善的权限控制不同环境、集群配置管理
• 同一份程序在不同的环境（开发，测试，生产）、不同的集群（如不同的数据中心）经常需要有不同的配置，所以需要有完善的环境、集群配置管理
• 框架类组件配置管理，还有一类比较特殊的配置 - 框架类组件配置，比如CAT客户端的配置。虽然这类框架类组件是由其他团队开发、维护，但是运行时是在业务实际应用内的，所以本质上可以认为框架类组件也是应用的一部分。这类组件对应的配置也需要有比较完善的管理方式。

6.1 Apollo配置中心特性

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

• Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
• 同一份代码部署在不同的集群，可以有不同的配置，比如zk的地址等
• 通过命名空间（namespace）可以很方便的支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖

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

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

版本发布管理

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

灰度发布

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

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

• 应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。
• 所有的操作都有审计日志，可以方便的追踪问题

客户端配置信息监控

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

提供Java和.Net原生客户端

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

提供开放平台API

• Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。
• 不过Apollo出于通用性考虑，对配置的修改不会做过多限制，只要符合基本的格式就能够保存。
• 在我们的调研中发现，对于有些使用方，它们的配置可能会有比较复杂的格式，而且对输入的值也需要进行校验后方可保存，如检查数据库、用户名和密码是否匹配。
• 对于这类应用，Apollo支持应用方通过开放接口在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制

部署简单

• 配置中心作为基础服务，可用性要求非常高，这就要求Apollo对外部依赖尽可能地少
• 目前唯一的外部依赖是MySQL，所以部署非常简单，只要安装好Java和MySQL就可以让Apollo跑起来
• Apollo还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数

7. Apollo配置中心运行流程

• 用户在配置中心对配置进行修改并发布
• 配置中心通知Apollo客户端有配置更新
• Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用

8. Apollo后台管理界面