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

最新推荐文章于 2024-09-17 16:40:41 发布

fedorafrog

最新推荐文章于 2024-09-17 16:40:41 发布

阅读量501

点赞数

分类专栏： # SpringCloud

原文链接：https://blog.csdn.net/zjh_746140129/article/details/86179522

版权

SpringCloud 专栏收录该内容

32 篇文章 40 订阅

订阅专栏

笔者在工作中遇到如下问题，随着程序功能越多，配置文件不断增加，一些功能的开关、服务器地址、接口地址、不同环境的一些配置文件不同，这些在每次发布不同环境、更新项目时都比较繁琐，后来学习微服务时接触到了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的最简架构如下图所示：

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

3.2 Apollo架构V2

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

Config/AdminService启动后都会注册到Eureka服务注册中心，并定期发送保活心跳。
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. 结论

宋顺的视角是一个从上往下的俯视视角，而我的是一个侧面视角。
ConfgService/AdminService/Client/Portal是Apollo的四个核心微服务模块，相互协作完成配置中心业务功能，Eureka/MetaServer/NginxLB是辅助微服务之间进行服务发现的模块。
Apollo采用微服务架构设计，架构和部署都有一些复杂，但是每个服务职责单一，易于扩展。另外，Apollo只需要一套Portal就可以集中管理多套环境(DEV/FAT/UAT/PRO)中的配置，这个是它的架构的一大亮点。
服务发现是微服务架构的基础，在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客户端的配置。虽然这类框架类组件是由其他团队开发、维护，但是运行时是在业务实际应用内的，所以本质上可以认为框架类组件也是应用的一部分。这类组件对应的配置也需要有比较完善的管理方式。