携程apollo（不得不提Apollo）

摘要

Apollo是由携程技术团队开源的一款分布式配置中心，它能够集中管理不同环境、不同集群的配置，当配置修改以后可以实时推送到服务端。如果客户端监听服务端数据配置发生变化，可以实时监听到那些配置进行了修改，然后更新内存中的配置数据，使得配置数据实时生效。

一、基于application.properties或者yaml方式配置的缺点

配置中心是微服务项目中必不可少的部分。各个服务模块都需要不同的配置文件，比如：数据库配置、缓存配置、常量配置。在使用SpringBoot框架的时候，我们都知道可以使用application.properties或者yaml方式配置。并且，SpringBoot提供的约定机制，可以使得开发环境、测试环境、线上环境的配置分开，这种方式基本可以满足我们的使用场景。但是，这种配置方式也存在这明显的缺点：

由于配置数据直接写在配置文件中，一些敏感的数据可能暴露出去，例如：数据库的密码、第三方SDK公钥秘钥等。这些敏感数据暴露出去可能存在安全风险。

配置文件以单个文件形式存在，所以无法进行权限管理。但是，对于像数据库连接信息等配置，尤其是牵扯到财务数据的数据库信息，对于普通开发人员应该是不可见的，由专门的DBA去维护。

application.properties或者yaml方式配置，当需要修改一个属性的时候，通常需要启动服务才能生效，不能做到热加载。

二、阿波罗（Apollo）特性

为了解决基于配置的缺点，我们就需要一款独立的配置中心，这就是本文要讲的核心：阿波罗（Apollo）配置中心。

Apollo是由携程技术团队开源的一款分布式配置中心，它能够集中管理不同环境、不同集群的配置，当配置修改以后可以实时推送到服务端，如果客户端监听服务端数据配置发生变化，可以实时监听到那些配置进行了修改，然后更新内存中的配置数据，使得配置数据实时生效。

Apollo服务端基于SpringBoot和Spring Cloud开发，所以，多于Java项目来说，非常容易集成。Apollo的主要特性有：

Apollo提供了一个友好的后台管理系统，在这个系统中开发人员可以统一管理不同环境、不同集群的配置。例如：开发环境、测试环境、线上环境的不同配置，可以统一在这个后台进行管理。如下图所示：

针对不同的环境可以设置不同的集群，集群通过apollo.cluster参数来区分。

基于配置文件的配置方式，最大的缺陷就是动态加载的问题。Apollo支持动态加载，当用户在管理系统修改了配置以后，客户端可以实时接收到最新的配置并刷新数据。

Apollo中修改每一个配置以后，都需要发布才能生效，并且每一次发布都对应一个版本号。如果用户进行了了错误的操作，可以方便的回滚，如下图所示：

Apollo提供了完善的权限管理，无相应权限的人员是无法进行修改数据或者发布数据的，如下图所示：

Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。

配置方式支持xml, json、application、yml等格式，还有一些使用方如DAL，不仅有特定的格式，而且对输入的值也需要进行校验后方可保存，如检查数据库、用户名和密码是否匹配。对于这类应用，Apollo支持应用方通过开放接口在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制。

提供了Java客户端，非常容易集成。支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便应用使用。

三、SpringBoot集成Apollo

前文已经讲过，Apollo提供了晚上的Java SDK，很容易接入。本节主要讲SpringBoot项目中如何接入Apollo。

客户端加载配置主要流程是：服务启动以后，连接Apollo，根据当前项目的AppId和当前环境以及集群都属性去Apollo服务端加载配置数据到内存中，后续业务中使用到所有的配置数据都是统一从内存加载。

通过客户端监听服务端数据变化，可以实现动态加载。当客户端监听到Apollo服务端数据有变化，重新刷新内存数据。

四、结论

本文主要讲解了SpringBoot项目中原生配置方式的缺陷，而Apollo分布式配置中心正好可以弥补这种缺陷。同时，Apollo提供良好的API，方便开发者在项目中集成使用。所以，如果项目中有大量的配置文件需求，不妨选择使用Apollo，可以为项目带来很大的便利。