Apollo分布式配置中心简单概述

Apollo分布式配置中心

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

一、概览

1.1 什么是配置

应用程序在启动时需要读取一些配置信息，这些配置信息伴随着应用程序的整个生命周期。可以举例说明，例如：数据库连接参数、启动参数等。

配置主要有以下几个特点：

• 独立于程序的只读变量
• 伴随着应用的整个生命周期
• 可以有多种加载方式
  • 配置文件，例如xml文件，yaml文件，properties文件，基于数据库的配置等
  • 环境变量，启动参数等等
• 配置需要治理
  • 配置的权限配置，不可能让任何人都有权限去配置，不同的角色具有不同的权限可以拥有不同的配置
  • 不同环境也需要不同的配置，不同的集群【如不同的数据中心】也需要有不同的配置

1.2 什么是配置中心

传统单体应用有一些潜在缺陷，如 随着规模的扩大

• 部署效率降低
• 团队协作效率差
• 系统可靠性变差
• 维护困难
• 新功能上线周期长

为了解决上述问题，出现了微服务这种架构。

但是微服务架构也带来了服务【应用】配置的问题。当系统从一个单体应用被拆分成分布式系统上一个个服务节点后，配置文件也必须跟着迁移【分割】，这样配置就分散了。

所以出现了一个配置中心服务，专门为其他服务提供配置文件服务。

总的来说，配置中心就是一种统一管理各种应用配置的基础服务组件

一个合格的配置中心应该满足下列要求：

• 配置项容易读取和修改
• 添加新配置简单直接
• 支持对配置的修改的检视以把控风险
• 可以查看配置修改的历史纪录
• 不同部署环境支持隔离

二、Apollo简介

2.1 市面上主流的配置中心

1. Disconf 2014年7月百度开源的配置管理中心，目前已不再维护更新
2. Spring Cloud Config 属于Spring Cloud的生态组件，可以和Spring Cloud无缝整合
3. Apollo 2016年5月，携程开源的配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景
4. Nacos 2018年6月，阿里开源的配置中心，也可以做DNS和RPC的服务发现

2.2 配置中心的对比

功能点	Spring Cloud Config	Apollo	Nacos
配置实时推送	支持(Spring Cloud Bus)	支持(HTTP长轮询1s内)	支持(HTTP长轮询1s内)
版本管理	支持(Git)	支持	支持
配置回滚	支持(Git)	支持	支持
灰度发布	支持	支持	不支持
权限管理	支持(依赖Git)	支持	不支持
多集群	支持	支持	支持
多环境	支持	支持	支持
监听查询	支持	支持	支持
多语言	只支持Java	主流语言，提供了Open API	主流语言，提供了Open API
配置格式校验	不支持	支持	支持
单机读(QPS)	7（限流所致）	9000	15000
单机写(QPS)	5（限流所致）	1100	1800
3节点读(QPS)	21（限流所致）	27000	45000
3节点写(QPS)	5（限流所致）	3300	5600

2.3 Apollo特性

• Apollo包含 服务端 和 客户端 两部分
• 服务端基于Spring Boot和Spring Cloud开发，打包后可直接运行，不需要额外的Tomcat等应用容器
• Java客户端不依赖任何框架，能够运行于所有Java运行时环境

……

三、阿波罗快速入门

3.1 执行流程

3.2 工作原理

各模块的职责

• Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端
• Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面）
• Eureka提供服务注册和发现，为了简单起见，目前Eureka在部署时和Config Service是在一个JVM进程中的
• Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳
• 在Eureka之上架了一层Meta Server用于封装Eureka的服务发现接口
• Client通过域名访问Meta Server获取Config Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Client侧会做load balance、错误重试
• Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Portal侧会做load balance、错误重试
• 为了简化部署，我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中

执行流程

1. Apollo启动后，Config/Admin Service会自动注册到Eureka服务注册中心，并定期发送保活心跳。
2. Apollo Client和Portal管理端通过配置的Meta Server的域名地址经由Software Load Balancer（软件负载均衡器）进行负载均衡后分配到某一个Meta Server
3. Meta Server从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka Client
4. Meta Server获取Config Service和Admin Service（IP+Port）失败后会进行重试
5. 获取到正确的Config Service和Admin Service的服务信息后，Apollo Client通过Config Service为应用提供配置获取、实时更新等功能；Apollo Portal管理端通过Admin Service提供配置新增、修改、发布等功能

3.3 核心概念

1. application（应用）：实际使用配置的应用，Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置，关键字：AppId
2. environment（环境）：配置对应的环境，Apollo客户端在运行时需要知道当前应用处于哪个环境，从而可以去获取应用的配置，关键字：env
3. cluster（集群）：一个应用下不同实例的分组，比如典型的可以安装数据中心分，把上海机房的应用实例分为一个集群，把北京机房的应用实例分为另一个集群。关键字：Cluster
4. namespace（命名空间）：一个应用下不同配置的分组，可以简单地把namespace类比为文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC配置文件，应用自身的配置文件等，关键字：namespaces

四、总结

Apollo是配置中心，在一般的开发部门中，由运维人员给开发者分配系统权限，开发者不得添加用户、分配权限或发布配置，这些操作涉及商业管理，所以由运维人员统一发布和管理。所以一般情况下，开发者只需要注重配置中心中的各种配置，然后依据配置的内容，将其集成于自己管理的项目当中即可