Apollo - 概述

内容

Apollo

Apollo - A reliable configuration management system

https://github.com/ctripcorp/apollo

Apollo（阿波罗）是携程框架部门研发的分布式配置中心，，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

Apollo包括服务端和客户端两部分：

服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。

Java客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有较好的支持。

什么是配置

既然Apollo定位于配置中心，那么在这里有必要先简单介绍一下什么是配置。

应用程序在，配置基本上伴随着应用程序的整个生命周期，比如：数据库连接参数、启动参数等。

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

  • 配置是独立于程序的只读变量
    • 配置首先是独立于程序的，同一份程序在不同的配置下会有不同的行为；
    • 其次，配置对于程序是只读的，程序通过读取配置来改变自己的行为，但是程序不应该去改变配置；
    • 常见的配置有：DB Connection Str、Thread Pool Size、Buffer Size、Request Timeout、Feature Switch、Server Urls等。
  • 配置伴随应用的整个生命周期
    • 配置贯穿于应用的整个生命周期，应用在启动时通过读取配置来初始化，在运行时根据配置调整行为。比如：启动时需要读取服务的端口号、系统在运行过程中需要读取定时策略执行定时任务等。
  • 配置可以有多种加载方式
    • 常见的有程序等
  • 配置需要治理
    • 权限控制
      • 由于配置能改变程序的行为，不正确的配置甚至能引起灾难，所以对配置的修改必须有比较完善的权限控制
    • 不同环境、集群配置管理：
      • ，所以需要有完善的环境、集群配置管理
    • 框架类组件配置管理
      • 还有一类比较特殊的配置 - 框架类组件配置，比如CAT客户端的配置。
      • 虽然这类框架类组件是由其他团队开发、维护，但是运行时是在业务实际应用内的，所以本质上可以认为框架类组件也是应用的一部分。
      • 这类组件对应的配置也需要有比较完善的管理方式。

什么是配置中心

传统单体应用存在一些潜在缺陷：

  • 随着规模的扩大，部署效率降低，团队协作效率差，系统可靠性变差，维护困难，新功能上线周期长等。

因此，迫切需要一种新的架构去解决这些问题，而微服务（ microservices ）架构正是当下一种流行的解法。

  • 不过，解决一个问题的同时，往往会诞生出很多新的问题，所以微服务化的过程中伴随着很多的挑战，其中一个挑战就是有关服务（应用）配置的。
  • 当系统从一个单体应用，，如下图：

配置文件冗余

配置中心。

  • 应用自身既不需要去添加管理配置接口，也不需要自己去实现配置的持久化，更不需要引入“定时任务”以便降低运维成本。
  • 总得来说，配置中心就是一种统一管理各种应用配置的基础服务组件。

在系统架构中，配置中心是整个微服务基础架构体系中的一个组件，如下图，它的功能看上去并不起眼，无非就是配置的管理和存取，但它是整个微服务架构中不可或缺的一环。

配置中心

集中管理配置，那么就要将应用的配置作为一个单独的服务抽离出来了，同理也需要解决新的问题，比如：版本管理（为了支持回滚），权限管理等。

总结一下，在传统巨型单体应用纷纷转向细粒度微服务架构的历史进程中，配置中心是微服务化不可缺少的一个系统组件，在这种背景下中心化的配置服务即配置中心应运而生，一个合格的配置中心需要满足：

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

主流配置中心

目前市面上用的比较多的配置中心有：

  1. Disconf

    2014年7月百度开源的配置管理中心，专注于各种「分布式系统配置管理」的「通用组件」和「通用平台」, 提供统一的「配置管理服务」。目前已经不再维护更新。

  2. Spring Cloud Config

    2014年9月开源，Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。

  3. Apollo

    2016年5月，携程开源的配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

  4. Nacos

    2018年6月，阿里开源的配置中心，也可以做DNS和RPC的服务发现。

功能特性对比

由于Disconf不再维护，下面主要对比一下Spring Cloud Config、Apollo和Nacos。

功能点Spring Cloud ConfigApolloNacos
配置实时推送支持(Spring Cloud Bus)支持(HTTP长轮询1s内)支持(HTTP长轮询1s内)
版本管理支持(Git)支持支持
配置回滚支持(Git)支持支持
灰度发布支持支持不支持
权限管理支持(依赖Git)支持不支持
多集群支持支持支持
多环境支持支持支持
监听查询支持支持支持
多语言只支持Java主流语言，提供了Open API主流语言，提供了Open API
配置格式校验不支持支持支持
单机读(QPS)7(限流所致)900015000
单击写(QPS)5(限流所致)11001800
3节点读(QPS)21(限流所致)2700045000
3节点写(QPS)5限流所致()33005600

Apollo特性

Apollo作为一个有治理能力的配置发布平台，目前提供了以下的特性：

  • 统一管理不同环境、不同集群的配置
    • Apollo提供了一个统一界面集中式管理。
    • 同一份代码部署在不同的集群，可以有不同的配置，比如zookeeper的地址等
    • 通过
  • 配置修改实时生效（热发布）
    • 用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序
  • 版本发布管理
    • 所有的配置发布都有版本概念，从而可以方便地支持配置的回滚
  • 灰度发布
    • 支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例
  • 权限管理、发布审核、操作审计
    • 应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了两个环节，从而减少人为的错误。
    • 所有的操作都有审计日志，可以方便地追踪问题
  • 客户端配置信息监控
    • 可以在界面上方便地看到配置在被哪些实例使用
  • 提供Java和.Net原生客户端
    • 提供了Java和.Net的原生客户端，方便应用集成
    • 支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便应用使用（需要Spring 3.1.1+）
    • 同时提供了Http接口，非Java和.Net应用也可以方便地使用
  • 提供开放平台API
    • Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。不过Apollo出于通用性考虑，不会对配置的修改做过多限制，只要符合基本的格式就能保存，不会针对不同的配置值进行针对性的校验，如数据库用户名、密码，Redis服务地址等
    • 对于这类应用配置，Apollo支持应用方通过开放平台API在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制
  • 部署简单
    • 配置中心作为基础服务，可用性要求非常高，这就要求Apollo对外部依赖尽可能地少
    • 目前唯一的外部依赖是MySQL，所以部署非常简单，只要安装好Java和MySQL就可以让Apollo跑起来
    • Apollo还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数

核心概念

  1. application (应用)

    • 实际使用配置的应用，Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置。

    • 关键字：appId

  2. environment (环境)

    • 配置对应的环境，Apollo客户端在运行时需要知道当前应用处于哪个环境，从而可以去获取应用的配置
    • 关键字：env

  3. cluster (集群)

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

    • 关键字：cluster

  4. namespace (命名空间)

    • 一个应用下不同配置的分组，可以简单地把namespace类比为文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC配置文件，应用自身的配置文件等

    • 关键字：namespaces

它们的关系如下图所示：

关系图

Last Updated:
Contributors: klc407073648