Java实战｜SpringBoot整合Apollo实现分布式配置中心-一一网

这是我参与更文挑战的第15天，活动详情查看：更文挑战

前言：

应用程序在启动和运行的时候往往需要读取一些配置信息，配置基本上伴随着应用程序的整个生命周期，比如：数据库连接参数、启动参数等。对于分布式配置中心相比大家都不陌生了，如比较典型的一些Spring Cloud Config，Nacos，以及我们今天的主角Apollo，随着业务越来越复杂，越来越庞大，我们的系统需要进行一些服务化拆分，导致模块骤增，随之而来配置文件管理难度也随之增加，所以采用一个配置集中管理的中间件是非常有必要的。

配置中心：

配置的特点：

配置对于程序是只读的，程序通过读取配置来改变自己的行为，但是程序不应该去改变配置；
配置贯穿于应用的整个生命周期，应用在启动时通过读取配置来初始化，在运行时根据配置调整行为，如启动时需要读取服务的端口号、系统在运行过程中需要读取定时策略执行定时任务等。
配置需要治理同一份程序在不同的环境(开发，测试，生产)、不同的集群(如不同的数据中心)经常需要有不同的配置，所以需要有完善的环境、集群配置管理

什么是配置中心：

在分布式服务架构中，当系统从一个单体应用，被拆分成分布式系统上一个个服务节点后，配置文件也必须跟着迁移 (分割)，这样配置就分散了，不仅如此，分散中还包含着冗余；而配置中心将配置从各应用中剥离出来，对配置进行统一管理，应用自身不需要自己去管理配置。

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

为什么需要配置中心：

随着程序功能的日益复杂，程序的配置日益增多，各种功能的开关、参数的配置、服务器的地址大量模块使用各自的配置，可能导致运维繁琐、管理混乱、各个节点配置文件不一致对配置的期望也越来越高，配置修改后实时生效，灰度发布，版本管理，环境区分，完善的权限、审核机制等

在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求，所以配置中心的地位尤为重要；

Apollo：

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

图片.png

Apollo包括服务端和客户端两部分：
服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有较好的支持。

官方文档

特点：

统一管理不同环境、不同集群的配置
配置修改实时生效(热发布)
版本发布管理
灰度发布
权限管理、发布审核、操作审计
客户端配置信息监控
提供Java和.Net原生客户端
提供开放平台API
部署简单

部署地址官方文档写的特别详细直接拉代码部署就ok：
架构地址

开发：
SpringBoot在代码里使用直接使用@Value("${someKeyFromApollo:someDefaultValue}")就可以；

服务端POM依赖：

<dependency>
    <groupId>com.ctrip.framework.apollo</groupId>
    <artifactId>apollo-client</artifactId>
    <version>1.1.2</version>
</dependency>
复制代码

application.properties：

# 与配置中心的AppId一致
app.id=wechat-java
# 默认情况下meta server和config service是部署在同一个JVM进程
apollo.meta=http://localhost:8080/
apollo.cacheDir=/var/run/apollo-cache
# 集成到Spring Boot
apollo.bootstrap.enabled = true

复制代码

记得在在springboot启动类开启Apollo配置，添加注解 @EnableApolloConfig