侧边栏壁纸
博主头像
林雷博主等级

斜月沉沉藏海雾，碣石潇湘无限路

  • 累计撰写 132 篇文章
  • 累计创建 47 个标签
  • 累计收到 3 条评论
标签搜索

目 录CONTENT

文章目录
SpringCloud

16、Apollo配置中心

林雷
林雷
2021-03-19 / 0 评论 / 0 点赞 / 3,768 阅读 / 14,126 字

一 Apollo介绍

Apollo（阿波罗）是携程框架部研发并开源的一款生产级的配置中心产品，它能够集中管理应用在不同环境、不同集群的配置，配置修改后能实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

1.1 Apollo配置中心设计

1.1.1 总体设计

1.1.1.1 基础模型

如下图所示：
image-1a46c339

  • 用户在配置中心对配置进行修改并发布
  • 配置中心通知Apollo客户端有配置更新
  • Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用

1.1.1.2 架构模块

如下图所示：
image-89eb4be5

  • Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端
  • Admin Service提供配置的修改、发布等功能，服务对象时Apollo Portal（管理界面）
  • Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳
  • 在Eureka之上还有一层Meta Server用于封装Eureka的服务发现接口
  • Client通过域名访问Meta Server获取Config Service服务列表（IP+Port），然后直接通过IP+Port访问服务，同时在Client侧会做负载均衡、错误重试
  • 为了简化部署，实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM中

1.1.1.3 各模块概要介绍

1.1.1.3.1 Config Service

  • 提供配置获取接口

  • 提供配置更新推送接口（基于Http long polling）

    • 服务端使用Spring DeferredResult实现异步化，从而大大增加长连接数量
    • 目前使用tomcat embed默认配置是最多10000个连接

  • 接口服务对象时Apollo客户端

1.1.1.3.2 Admin Service
  • 提供配置管理接口
  • 提供配置修改、发布等接口
  • 接口服务对象是Portal
1.1.1.3.3 Meta Server
  • Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port）
  • Client通过域名访问Meta Server获取Config Service服务列表）（IP+Port）
  • Meta Server从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka Client
  • 增设一个Meta Server的角色主要是为了封装服务发现的细节，对Portal和Client而言，永远通过一个Http接口获取Admin Service和Config Service的服务信息，而不需要关系背后实际的服务注册和发现组件
  • Meta Server只是一个逻辑角色，在部署时和Config Service是在一个JVM进程中的，所以IP、端口和Config Service一致
1.1.1.3.4 Eureka
  • 基于Eureka和Spring Cloud Netflix提供服务注册和发现
  • Config Service和Admin Service会向Eureka注册服务，并保持心跳
  • 目前Eureka在部署时和Config Service是在一个JVM进程中的
1.1.1.3.5 Portal
  • 提供Web界面供用户管理配置
  • 通过Meta Server获取Admin Service服务列表）（IP + Port），通过IP+Port访问服务
  • 在Portal侧做负载均衡、错误重试
1.1.1.3.6 Client
  • Apollo提供的客户端程序，为应用提供配置获取、实时更新等功能
  • 通过Meta Server获取Config Service服务列表（IP+Port），通过IP+Port访问服务
  • 在Client侧做负载均衡、错误重试

1.1.2 服务端设计

在配置中心中，一个重要的功能就是配置发布后实时推送到客户端。如下图所示：
image-0f095355-1652174634731

  1. 用户在Portal操作配置发布
  2. Portal调用Admin Service的接口操作发布
  3. Admin Service发布配置后，发送ReleaseMessage给各个Config Service
  4. Config Service收到ReleaseMessage后，通过对应的客户端

1.1.2.1 发送ReleaseMessage的实现方式

Admin Service在配置发布之后，需要通知所有的Config Service有配置不发，从而Config Service可以通知对应的客户端来拉取最新的配置。如下图所示：
image-0f095355

从概念上来说，这是一个典型的消息使用场景，Admin Service作为producer发出消息，各个Config Service作为consumer消费消息。通过一个消息组件（Message Queue）就能很好的实现Admin Service和Config Service解耦。

Apollo为了减少外部依赖，没有采用外部的消息中间件，而是通过数据库实现的一个简单的消息队列。

实现方式如下：

  • Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录，消息内容就是配置发布的AppId+Cluster+Namespace，具体请看DatabaseMessageSender
  • Config Service有一个线程会每秒扫描一次ReleaseMessage表，看看是否有新的消息记录，具体请看ReleaseMessageScanner
  • Config Service如果发现有新的消息记录，那么就会通知到所有的消息监听器（ReleaseMessageListener），如NotificationControllerV2，消息监听器的注册过程可以查看ConfigServiceAutoConfiguration
  • NotificationControllerV2得到配置发布的AppId+Cluster+Namespace后，会通知对应的客户端

1.1.2.2 Config Service通知客户端的实现方式

NotificationControllerV2在得知有配置发布后通知客户端的实现方式如下：

  • 客户端会发起一个Http请求到Config Service的notifications/v2接口，也就是NotificationControllerV2，具体请看RemoteConfigLongPollService
  • NotificationControllerV2不会立即返回结果，而是通过Spring DeferredResult把请求挂起
  • 如果在60秒内没有该客户端关系的配置发布，那么会返回Http状态码304给客户端
  • 如果有该客户端关心的配置发布，NotificationController会调用DeferredResult的setResult方法，传入有配置变化的namespace信息，同时该请求会立即返回。客户端从返回的结果中获取到配置变化的namespace后，会立即请求Config Service获取该namespace的最新配置。

1.1.3 客户端设计

如下图所示：
image-c774842c

  • 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。（通过Http Long Polling实现）

  • 客户端还会定时从Apollo配置中心服务端拉取应用的最新配置

    • 这是一个fallback机制，为了防止推送机制失效导致配置不更新
    • 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304
    • 定时频率默认为5分钟拉取一次，客户端也可以通过在运行时指定System Property：apollo.refreshInterval来覆盖，单位为分钟

  • 客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中

  • 客户端会把从服务端获取到的配置在本地文件系统缓存一份

  • 在遇到服务不可用时，或网络不通时，依然能从本地恢复配置

  • 应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知

1.2 Apollo配置中心介绍

1.2.1 基本使用概览

1.2.1.1 基础模型

如下图所示：
image-1a46c339-1652174071372

  • 用户在配置中心对配置进行修改并发布
  • 配置中心通知Apollo客户端有配置更新
  • Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用

1.2.1.2 界面概览

如下图所示：
image-dc2b8702

上图是Apollo配置中心中一个项目的配置首页：

  • 在页面左上方的环境列表模块展示了所有的环境和集群，用户可以随时切换
  • 页面中央展示了两个namespace的配置信息，默认按照表格模式展示、编辑。用户可以切换到文本模式，以文件形式查看、编辑
  • 页面上可以方便进行发布、回滚、灰度、授权、查看更改历史和发布历史等操作

1.2.1.3 添加/修改配置项

用户可以通过配置中心界面方便的添加/修改配置项，如下图所示：
image-cac92ed4
image-8d310eb2

1.2.1.4 发布配置

通过配置中心发布配置：
image-18c82c60
image-79cba28f

1.2.1.5 客户端获取配置（Java API样例）

配置发布后，就能在客户端获取到了，以Java为例，获取配置的示例代码如下：

Config config = ConfigService.getAppConfig();
Integer defaultRequestTimeout = 200;

Integer requestTimeout = config.getIntProperty("requestTimeout", defaultRequestTimeout);

1.2.1.6 客户端监听配置变化

在某些场景下，应用还需要在配置变化时获得通知，比如数据库连接的切换等，所以Apollo还提供了监听配置变化的功能，Java示例代码如下：

Config config = ConfigService.getAppConfig();
config.addChangeListener(new ConfigChangeListener() {
    @Override
    public void onChange(ConfigChangeEvent changeEvent) {
        for (String key : changeEvent.changedKeys()) {
            ConfigChange change = changeEvent.getChange(key);
            System.out.println(String.format("Found change - key: %s, oldValue: %s, newValue: %s, changeType: %s", change.getPropertyName(), change.getOldValue(), change.getNewValue(), change.getChangeType()));
        }
    }
});

1.2.1.7 Spring集成样例

Apollo和Spring可以很方便地集成，只需要标注**@EnableApolloConfig**后就可以通过@Value获取配置信息了：

@Configuration
@EnableApolloConfig
public class AppConfig {}

@Component
public class SomeBean {
    @Value("${request.timeout:200}")
    private int timeout;
}

1.2.2 深入使用

1.2.2.1 核心概念

  • application
    • 这个很好理解，就是实际使用配置的应用，Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置
    • 每个应用都需要有唯一的身份表示：appId，需要在客户端配置
  • environment
  • 配置对应的环境，Apollo客户端在运行时需要知道当前应用处于哪个环境，从而可以获取应用的配置
  • 环境和代码无关，同一份代码部署在不同的环境就应该能够获取到不同环境的配置
  • 所以环境默认是通过读取机器上的配置（server.properties中的env属性）指定的
  • cluster
  • 一个应用下不同实例的分组，比如典型的可以按照数据中心分，把上海机房的应用实例分为一个集群，把北京机房的应用实例分为另一个集群
  • 对不同的cluster，同一个配置可以有不一样的值，比如zookeeper地址
  • 集群默认是读取机器上的配置（server.properties中的idc属性）指定的
  • namespace
  • 一个应用下不同配置的分组，可以简单把namespace类比为文件，不同类型的配置放在不同的文件中，如数据库配置文件，RPC配置文件，应用自身的配置文件等
  • 应用可以直接读取到公共组件的配置namespace，比如DAL、RPC等
  • 应用也可以通过继承公共组件的配置namespace来对公共组件的配置做调整，如DAL的初始数据库连接数

1.2.2.2 自定义Cluster

比如我们有应用在A数据中心和B数据中心都有部署，那么如果希望两个数据中心的配置不一样的话，我们可以通过新建cluster来解决。

1.2.2.2.1 新建Cluster

新建Cluster只有项目的管理员才有权限，管理员可以在页面左侧看到“添加集群”按钮：
image-5955c8dd

点击后就进入到集群添加页面，一般情况可以按照数据中心来划分集群，比如SHAJQ、SHAOY等，不过也支持自定义集群，比如可以为A机房的某一台机器和B机房的某一台机器创建一个集群，使用一套配置：
image-3c193f32

1.2.2.2.2 在Cluster中添加配置并发布

集群添加成功后，就可以为该集群添加配置了，添加配置上面已经介绍过了，不在赘述。

1.2.2.2.3 指定应用实例所属的Cluster

Apollo会默认使用应用实例所在的数据中心作为Cluster，所以如果两者一致的话，不需要配置。如果cluster和数据中心不一致的话，那么就需要通过System Property方式来指定运行时cluster：

  • -Dapollo.cluster=SomeCluster
  • apollo.cluster为全小写

1.2.2.3 自定义Namespace

如果应用有公共组件供其他应用使用，就需要通过自定义namespace来实现公共组件的配置。

1.2.2.3.1 新建Namespace

以hermes-producer为例，需要先新建一个namespace，新建namespace只有项目的管理员才有权限，管理员可以在页面左侧看到“添加Namespace”按钮：
image-7b6145bd

点击后就进入namespace添加页面，Apollo会把应用所属的部门作为namespace的前缀：
image-e11379c6

1.2.2.3.2 关联到环境和集群

Namespace创建完，需要窜则在哪些环境和集群下使用：
image-836d1b96

1.2.2.3.3 在Namespace中添加配置项

接下来在这个创建的namespace下添加配置项：
image-5bf6789d

添加完成后就能在FX.Hermes.Producer的namespace看到这个配置：
image-2d2ffa7b

1.2.2.3.4 发布namespace的配置

image-2881627b

1.2.2.3.5 客户端获取Namespace配置

对自定义namespace的配置获取，稍有不同，需要程序传入namespace的名字。Java示例代码如下：

Config config = ConfigService.getConfig("FX.Hermes.Producer");
Integer defaultSenderBatchSize = 200;
Integer senderBatchSize = config.getIntProperty("sender.batchsize", defaultSenderBatchSize);
1.2.2.3.6 客户端监听Namespace配置变化

Java示例代码如下：

Config config = ConfigService.getConfig("FX.Hermes.Producer");
config.addChangeListener(new ConfigChangeListener() {
    @Override
    public void onChange(ConfigChangeEvent changeEvent) {
        System.out.println("changes for namespace " + changeEvent.getNamespace());
        for (String key : changeEvent.changedKeys()) {
            ConfigChange change = changeEvent.getChange(key);
            System.out.println(String.format("Found change - key: %s, oldValue: %s, newValue: %s. changeType: %s", change.getPropertyName(), change.getOldValue(), change.getNewValue(), change.getChangeType()));
        }
    }
});
1.2.2.3.7 Spring集成样例
@Configuration
@EnableApolloConfig("FX.Hermes.Producer")
public class AppConfig{}

@Component
public class SomeBean {
     /** timeout的值会自动更新 */
    @Value("${request.timeout:200}")
    private int timeout;
}

二 部署

官方的Github上有多种部署方式（Quick Start或者Docker方式部署Quick Start）、分布式部署等。我在这里就只介绍分布式部署的Docker部署了。

2.1 准备工作

2.1.1 运行时环境

  • 服务端基于Spring Boot，理论上支持所有Linux发行版
  • JDK1.8
  • MySQL，要求5.6.5+版本
  • 如果基于Docker的话，以上环境都可以不用，但是系统需要Docker引擎

2.1.2 网络策略

分布式部署的时候，apollo-configservice和apollo-adminservice需要把自己的IP和端口注册到Meta Server（apollo-configservice本身）。

Apollo客户端和Portal会从Meta Server获取服务的地址（IP+端口），然后通过服务地址直接访问。

需要注意的是，apollo-configservice和apollo-adminservice是基于内网设计的，所以出于安全考虑，不要将apollo-configservice和apollo-adminservice直接暴露在公网。

所以如果实际部署的机器有多块网卡（如docker），或者存在某些网卡的IP是Apollo客户端和Portal无法访问，就需要在apollo-configservice和apollo-adminservice中做相关配置来解决连通性问题。

2.1.2.1 忽略某些网卡

可以分别修改apollo-configservice和apollo-adminservice的start.sh，通过JVM System Property传入-D参数，也可以通过系统环境变量传入，如下是把docker0和veth开头的网卡在注册到Eureka时忽略掉。

通过JVM参数配置示例：

-Dspring.cloud.inetutils.ignoredInterfaces[0]=docker0
-dspring.cloud.inetutils.ignoredInterfaces[1]=veth.*

获取环境变量配置示例：

SPRING_CLOUD_INETUTILS_IGNORED_INTERFACES[0]=docker0
SPRING_CLOUD_INETUTILS_IGNORED_INTERFACES[1]=veth.*

2.1.2.2 指定要注册的IP

可以分别修改apollo-configservice和apollo-adminservice的startup.sh，通过JVM传入-D参数，也可以通过系统环境变量传入，如下，是指定注册的IP为1.2.3.4

通过JVM参数配置示例：

-Deureka.instance.ip-address=1.2.3.4

通过系统环境变量配置示例：

EUREKA_INSTANCE_IP_ADDRESS=1.2.3.4

2.1.2.3 指定要注册的URL

可以分别修改apollo-configservice和apollo-adminservice的startup.sh，通过JVM传入-D参数，也可以通过系统环境变量传入。如下示例是会指定注册的URL为http://1.2.3.4:8080

JVM参数配置示例：

-Deureka.instance.homePageUrl=http://1.2.3.4:8080
-Deureka.instance.preferIpAddress=false

通过系统环境变量配置示例：

EUREKA_INSTANCE_HOME_PAGE_URL=http://1.2.3.4:8080
EUREKA_INSTANCE_PREFER_IP_ADDRESS=false

2.2 Docker部署

Apollo的唯一依赖是数据库，所以需要先把数据库准备好，然后根据实际情况进行部署。

2.2.1 创建数据库并导入表

Apollo服务端共需要两个数据库：ApolloPortalDB和ApolloConfigDB。

需要注意的是ApolloPortalDB只需要在生产环境部署一个即可，而ApolloConfigDB需要在每个环境部署一套。

SQL文件可以在其GitHub上下载：https://github.com/ctripcorp/apollo/tree/master/scripts/sql

2.2.2 部署Apollo Config Service

Apollo 1.7.0版本开始默认上传Docker镜像到Docker Hub。

获取镜像：

docker pull apolloconfig/apollo-configservice

启动镜像：

docker run -p 8080:8080 -e EUREKA_INSTANCE_IP_ADDRESS=192.168.10.3 -e SPRING_DATASOURCE_URL="jdbc:mysql://192.168.10.3:3306/apolloconfigdb?characterEncoding=utf8" -e SPRING_DATASOURCE_USERNAME=root -e SPRING_DATASOURCE_PASSWORD=123456 -d -v /application/logs/apollo-configservice:/opt/logs --name apollo-configservice apolloconfig/apollo-configservice

2.2.3 部署Apollo Admin Service

获取镜像：

docker pull apolloconfig/apollo-adminservice

启动镜像：

docker run -p 8090:8090 -e SPRING_DATASOURCE_URL="jdbc:mysql://192.168.10.3:3306/apolloconfigdb?characterEncoding=utf8" -e SPRING_DATASOURCE_USERNAME=root -e SPRING_DATASOURCE_PASSWORD=123456 -d -v /application/logs/apollo-adminservice:/opt/logs --name apollo-adminservice apolloconfig/apollo-adminservice

2.2.4 部署Apollo Portal

获取镜像：

docker pull apolloconfig/apollo-portal

启动镜像：

docker run -p 8070:8070 -e SPRING_DATASOURCE_URL="jdbc:mysql://192.168.10.3:3306/apolloportaldb?characterEncoding=utf8" -e SPRING_DATASOURCE_USERNAME=root -e SPRING_DATASOURCE_PASSWORD=123456 -e APOLLO_PORTAL_ENVS=dev,pro -e DEV_META=http://192.168.10.3:8080 -e PRO_META=http://192.168.10.3:8080 -d -v /application/logs/apollo-portal:/opt/logs --name apollo-portal apolloconfig/apollo-portal
  • APOLLO_PORTAL_ENVS：可选配置，对应ApolloPortalDB中的apollo.portal.envs配置项，如果没有在数据库中配置的话，可以通过此环境变量配置
  • DEV_META/PRO_META：可选配置。配置对应环境的Meta Service地址，以${ENV}_META命名，如果在ApolloPortalDB库中配置了apollo.portal.meta.services配置，则以数据库为准。

启动容器成功后，可以正常访问就表示没有问题了。

2.3 服务端配置说明

2.3.1 调整ApolloPortalDB配置

配置项统一存储在ApolloPortalDB.ServerConfig表中，也可以通过 管理员工具 - 系统参数 页面进行配置

2.3.1.1 apollo.portal.envs：可支持的环境列表

默认值是dev，如果portal需要管理多个环境的话，以逗号分隔即可（大小写不敏感），如：

DEV,FAT,UAT,PRO

修改完需要重启生效。

需要注意以下几点：

  • 一套Portal可以管理多个环境，但是每个环境都需要独立部署一台Config Service，Admin Service和ApolloConfigDB
  • 只在数据库添加环境是不起作用的，还需要为apollo-portal添加新增环境对应的meta server（后面介绍）

2.3.1.2 apollo.portal.meta.servers：各环境Meta Service列表

Apollo Portal需要在不同的环境访问不同的meta service（apollo-configservice）地址，所以需要提供这些信息。例如：

{
    "DEV":"http://1.1.1.1:8080",
    "FAT":"http://apollo.fat.xxx.com",
    "UAT":"http://apollo.uat.xxx.com",
    "PRO":"http://apollo.xxx.com"
}

修改完需要重启生效。

2.3.1.3 organizations：部门列表

Portal中新建APP都需要选择部门，所以需要在这里配置可选的部门信息。例如：

[{"orgId":"TEST1","orgName":"样例部门1"},{"orgId":"TEST2","orgName":"样例部门2"}]

2.3.1.4 superAdmin：Portal超级管理员

超级管理员拥有的所有权限，需要谨慎设置。默认是apollo（默认用户）。

2.3.1.5 consumer.token.salt

如果会使用开放平台API的话，可以设置一个token salt，如果不适用，可以忽略。

2.3.1.6 wiki.address

portal上“帮助”链接的地址，默认是Apollo github的wiki首页，可自行设置。

2.3.1.7 admin.createPrivateNamespace.switch

是否允许项目管理员创建private namespace，true允许，false不允许。

2.3.1.8 emergencyPublish.supported.envs

配置允许紧急发布的环境列表，多个env以英文逗号分隔。

当config service开启一次发布只能有一个人修改开关（namespace.lock.switch）后，一次配置发布只能是一个人修改，另一个人发布。为了避免紧急情况时无法发布配置，可以配置此项允许某些环境可以操作紧急发布，即同一个人可以修改并发布配置。

2.3.1.9 configView.memberOnly.envs

只对项目成员显示配置信息的环境列表，多个env以英文逗号分隔。

2.3.1.10 role.create-application.enabled：是否开启创建项目权限控制

默认为false，所有用户都可以创建项目。如果设置为true，那么只有超级管理员和拥有创建项目权限的账号可以创建项目。

2.3.1.11 role.manage-app-master.enabled：是否开启项目管理员分配权限控制

默认为false，所有项目的管理员可以为项目添加/删除管理员。

2.3.1.12 admin-service.access.tokens：设置apollo-portal访问各环境apollo-adminservice所需的access token

如果对应环境的apollo-adminservice开启了访问控制，那么需要在此配置apollo-portal访问该环境apollo-adminservice所需的access token。否则会访问失败

2.3.2 调整ApolloConfigDB配置

2.3.2.1 eureka.service.url：Eureka服务URL

配置项统一存储在ApolloConfigDB.ServerConfig表中，需要注意每个环境的ApolloConfigDB.ServerConfig都需要单独配置，修改完一分钟实时生效。

不适用于基于Kubernetes原生服务发现场景。

不管是apollo-configservice还是apollo-adminservice都需要向eureka服务注册，所以需要配置eureka服务地址。而apollo-configservice本身就是一个eureka服务，所以需要填入apollo-configservice的地址即可，如有多个，用逗号分隔（不要忘了/eureka后缀）。

例如：

在FAT环境的表中配置为：

http://1.1.1.1:8080/eureka,http://2.2.2.2:8080/eureka

注意，需要填写本环境全部的eureka服务地址，因为eureka需要互相复制注册信息。

2.3.2.2 namespace.lock.switch：一次发布智能有一个人修改开关，用于发布审核

这是一个功能开关，如果为true的话，那么一次配置发布只能是一个人修改，另一个发布。生产环境建议开启此项

2.3.2.3 config-service.cache.enabled：是否开启配置缓存

这是一个功能开关，如果配置为true的话，config service会缓存加载过的配置信息，从而加快后续配置获取性能。

默认为false。

2.3.2.4 item.key.length.limit：配置项key最大长度限制

默认为128

2.3.2.5 item.value.length.limit：配置项value最大长度限制

默认为20000

2.3.2.6 admin-service.access.control.enabled：配置apollo-adminservice是否开启访问控制

适用于1.7.1及以上版本。

默认为false，如果位true，那么apollo-portal就需要正确访问该环境的access token，否则访问会被拒绝

2.3.2.7 admin-service.access.tokens：配置允许访问apollo-adminservice的access token列表

适用于1.7.1及以上版本。

如果该配置项为空，那么访问控制不会生效。如果允许多个token，token之间以英文逗号分隔。

2.4 Java使用

Java使用Apollo上面其实很多都介绍了，使用起来很简单。我这里使用Spring Boot进行介绍。

首先注入相关依赖：

<!-- 引入Apollo配置中心 Start -->

<dependency>
    <groupId>com.ctrip.framework.apollo</groupId>
    <artifactId>apollo-client</artifactId>
    <version>1.8.0</version>
</dependency>

<dependency>
    <groupId>com.ctrip.framework.apollo</groupId>
    <artifactId>apollo-core</artifactId>
    <version>1.8.0</version>
</dependency>

<!-- 引入Apollo配置中心 End -->

然后在配置文件中指定相关参数：

app:
  id: study-apollo
apollo:
  meta: http://192.168.10.3:8080
  bootstrap:
    enabled: true
    eagerLoad:
      enabled: true
  • app.id：指定应用的名称。对应的Apollo中的应用名称
  • apollo.meta：meta地址

指定好以后，使用注解@EnableApolloConfig开启Apollo配置：

@EnableApolloConfig
@SpringBootApplication(scanBasePackages = {"com.bianjf"})
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

然后使用就使用@Value即可。在此不多做介绍了。

0
技术 Java SpringCloud
  1. qrcode alipay
  2. qrcode weixin
版权归属： 林雷
本文链接： http://blog.shangsw.com/archives/articles202103191616135007582html
许可协议： 本文使用《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》协议授权

评论区