阅读 185

Java实战|SpringBoot整合Apollo实现分布式配置中心

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

前言:

应用程序在启动和运行的时候往往需要读取一些配置信息,配置基本上伴随着应用程序的整个生命周期,比如:数 据库连接参数、启动参数等。对于分布式配置中心相比大家都不陌生了,如比较典型的一些Spring Cloud ConfigNacos,以及我们今天的主角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

ok!今日分享到此结束,希望可以对大家有帮助,明天我们写一下详细整合流程,有不对的地方希望大家可以提出来的,共同成长;

整洁成就卓越代码,细节之中只有天地

文章分类
后端
文章标签