apollo（阿波罗）

前言 应用程序在运行的时候往往需要依赖一些配置信息进行逻辑运算，而且这些配置基本上伴随着应用程序的整个生命周期。 一般来说配置是独立于程序代码的的只读变量。应用程序去读取配置来改变自己的行为，但是其不能改变配置，而是交由其他入口完成修改这一动作。 故配置需要进行管理，同一个应用在不同的部署环境（开发、测试、预生产、生产）经常需要不同的配置，所以需要有便捷、完善的配置管理流程去进行管理。 代码配置管理的演变 开端 最开始的配置是如何编写及放置的呢？ 当然是代码写到哪里，配置就加到哪里，这是最早期和顺手的做法，如下图。 （图中的提示语其实就是一个配置项） 这种做法最大的弊端就是：1、不能复用，一次修改，处处修改；2、不能按照不同环境所需进行调整。所以，此处应当进行抽离。 分工 逻辑代码一类，配置项一类，把配置内容进行抽离，独立放置到一个文件中，就是我所说的分工。既然配置项独立出一个文件了，那么后面的按环境加载就好办了。 一般来说，会对不同环境的配置文件使用不同的前缀进行命名，然后相应环境机器上也会有相关的一个环境变量供程序读取，读取后依靠这个环境变量进行按需加载配置文件就好了。 优点： 1、与项目关联紧密； 缺点： 1、更新及发布麻烦，需要修改代码； 2、缺失权限管理，安全性低； 3、不同应用项目配置不能共用； 4、配置零散，分散在各个项目代码中； 分权 按照前一个（分工

前言 应用程序在运行的时候往往需要依赖一些配置信息进行逻辑运算，而且这些配置基本上伴随着应用程序的整个生命周期。 一般来说配置是独立于程序代码的的只读变量。应用程序去读取配置来改变自己的行为，但是其不能改变配置，而是交由其他入口完成修改这一动作。 故配置需要进行管理，同一个应用在不同的部署环境（开发、测试、预生产、生产）经常需要不同的配置，所以需要有便捷、完善的配置管理流程去进行管理。 代码配置管理的演变 开端 最开始的配置是如何编写及放置的呢？ 当然是代码写到哪里，配置就加到哪里，这是最早期和顺手的做法，如下图。 （图中的提示语其实就是一个配置项） 这种做法最大的弊端就是：1、不能复用，一次修改，处处修改；2、不能按照不同环境所需进行调整。所以，此处应当进行抽离。 分工 逻辑代码一类，配置项一类，把配置内容进行抽离，独立放置到一个文件中，就是我所说的分工。既然配置项独立出一个文件了，那么后面的按环境加载就好办了。 一般来说，会对不同环境的配置文件使用不同的前缀进行命名，然后相应环境机器上也会有相关的一个环境变量供程序读取，读取后依靠这个环境变量进行按需加载配置文件就好了。 优点： 1、与项目关联紧密； 缺点： 1、更新及发布麻烦，需要修改代码； 2、缺失权限管理，安全性低； 3、不同应用项目配置不能共用； 4、配置零散，分散在各个项目代码中； 分权 按照前一个（分工

简介 Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。 Apollo和Spring Cloud Config对比 通过对比，可以看出，生成环境中 Apollo 相比 Spring Cloud Config 更具有优势一些。 安装 Apollo 配置中心 搭建教程 参照 https://github.com/ctripcorp/apollo/wiki/Quick-Start 搭建 Apollo 配置中心，文档写的很清楚，这里就赘述了。 查看样例配置 搭建完成并启动后，访问 http://localhost:8070 ，界面如下。 输入用户名 apollo，密码 admin 后登录后，点击SampleApp进入配置界面。 与 Spring Boot 整合使用 创建一个springboot项目，主要代码如下。 pom.xml 添加 Apollo 客户端的依赖，为了编码方便引入commons-lang3。 < dependency > < groupId > com.ctrip.framework.apollo </ groupId > < artifactId > apollo-client </ artifactId > < version