关于java:Spring-Boot-集成-Apollo-配置中心真香真强大

作者：超级小豆丁

起源：http://www.mydlq.club/article…

因为 Apollo 概念比拟多，刚开始应用比较复杂，最好先过一遍概念再入手实际尝试应用。

随着程序性能的日益简单，程序的配置日益增多，各种性能的开关、参数的配置、服务器的地址……对程序配置的期望值也越来越高，配置批改后实时失效，灰度公布，分环境、分集群治理配置，欠缺的权限、审核机制……

在这样的大环境下，传统的通过配置文件、数据库等形式曾经越来越无奈满足开发人员对配置管理的需要。因而 Apollo 配置核心应运而生！

Apollo（阿波罗）是携程框架部门研发的开源配置管理核心，可能集中化治理利用不同环境、不同集群的配置，配置批改后可能实时推送到利用端，并且具备标准的权限、流程治理等个性。

部署简略
灰度公布
版本公布治理
提供开放平台 API
客户端配置信息监控
提供 Java 和.Net 原生客户端
配置批改实时失效（热公布）
权限治理、公布审核、操作审计
对立治理不同环境、不同集群的配置

如下即是 Apollo 的根底模型：

(1)、用户在配置核心对配置进行批改并公布
(2)、配置核心告诉 Apollo 客户端有配置更新
(3)、Apollo 客户端从配置核心拉取最新的配置、更新本地配置并告诉到利用

Apollo 反对 4 个维度治理 Key-Value 格局的配置：

application (利用)
environment (环境)
cluster (集群)
namespace (命名空间)

(1)、application

Apollo 客户端在运行时须要晓得以后利用是谁，从而能够依据不同的利用来获取对应利用的配置。
每个利用都须要有惟一的身份标识，能够在代码中配置 app.id 参数来标识以后利用，Apollo 会依据此指来分别以后利用。

(2)、environment

在理论开发中，咱们的利用常常要部署在不同的环境中，个别状况下分为开发、测试、生产等等不同环境，不同环境中的配置也是不同的，在 Apollo 中默认提供了四种环境：

FAT（Feature Acceptance Test）：功能测试环境
UAT（User Acceptance Test）：集成测试环境
DEV（Develop）：开发环境
PRO（Produce）：生产环境

在程序中如果想指定应用哪个环境，能够配置变量 env 的值为对应环境名称即可。

(3)、cluster

一个利用下不同实例的分组，比方典型的能够依照数据中心分，把上海机房的利用实例分为一个集群，把北京机房的利用实例分为另一个集群。
对不同的集群，同一个配置能够有不一样的值，比如说下面所指的两个北京、上海两个机房设置两个集群，两个集群中都有 mysql 配置参数，其中参数中配置的地址是不一样的。

(4)、namespace

一个利用中不同配置的分组，能够简略地把 namespace 类比为不同的配置文件，不同类型的配置寄存在不同的文件中，如数据库配置文件，RPC 配置文件，利用本身的配置文件等。

相熟 SpringBoot 的都晓得，SpringBoot 我的项目都有一个默认配置文件 application.yml，如果还想用多个配置，能够创立多个配置文件来寄存不同的配置信息，通过指定 spring.profiles.active 参数指定利用不同的配置文件。这里的 namespace 概念与其相似，将不同的配置放到不同的配置 namespace 中。

Namespace 分为两种权限，别离为：

public（公共的）： public 权限的 Namespace，能被任何利用获取。
private（公有的）： 只能被所属的利用获取到。一个利用尝试获取其它利用 private 的 Namespace，Apollo 会报“404”异样。

Namespace 分为三种类型，别离为：

公有类型： 公有类型的 Namespace 具备 private 权限。例如 application Namespace 为公有类型。
公共类型： 公共类型的 Namespace 具备 public 权限。公共类型的 N amespace 相当于游离于利用之外的配置，且通过 Namespace 的名称去标识公共 Namespace，所以公共的 Namespace 的名称必须全局惟一。
关联类型（继承类型）： 关联类型又可称为继承类型，关联类型具备 private 权限。关联类型的 Namespace 继承于公共类型的 Namespace，将外面的配置全副继承，并且能够用于笼罩公共 Namespace 的某些配置。

Apollo 客户端会把从服务端获取到的配置在本地文件系统缓存一份，用于在遇到服务不可用，或网络不通的时候，仍然能从本地复原配置，不影响利用失常运行。

本地缓存门路默认位于以下门路，所以请确保 /opt/data 或 C:\opt\data\ 目录存在，且利用有读写权限。

Mac/Linux： /opt/data/{appId}/config-cache
Windows： C:\opt\data{appId}\config-cache

本地配置文件会以上面的文件名格局搁置于本地缓存门路下：

1{appId}+{cluster}+{namespace}.properties

上图简要形容了 Apollo 客户端的实现原理

客户端和服务端放弃了一个长连贯，从而能第一工夫取得配置更新的推送。
客户端还会定时从 Apollo 配置核心服务端拉取利用的最新配置。
这是一个 fallback 机制，为了避免推送机制生效导致配置不更新
客户端定时拉取会上报本地版本，所以个别状况下，对于定时拉取的操作，服务端都会返回 304 – Not Modified
定时频率默认为每 5 分钟拉取一次，客户端也能够通过在运行时指定 apollo.refreshInterval 来笼罩，单位为分钟。
客户端从 Apollo 配置核心服务端获取到利用的最新配置后，会保留在内存中。
客户端会把从服务端获取到的配置在本地文件系统缓存一份在遇到服务不可用，或网络不通的时候，仍然能从本地复原配置。
应用程序从 Apollo 客户端获取最新的配置、订阅配置更新告诉。

配置更新推送实现

后面提到了 Apollo 客户端和服务端放弃了一个长连贯，从而能第一工夫取得配置更新的推送。长连贯实际上咱们是通过 Http Long Polling 实现的，具体而言：

客户端发动一个 Http 申请到服务端
服务端会放弃住这个连贯 60 秒
如果在 60 秒内有客户端关怀的配置变动，被放弃住的客户端申请会立刻返回，并告知客户端有配置变动的 namespace 信息，客户端会据此拉取对应 namespace 的最新配置
如果在 60 秒内没有客户端关怀的配置变动，那么会返回 Http 状态码 304 给客户端
客户端在收到服务端申请后会立刻从新发动连贯，回到第一步
思考到会有数万客户端向服务端发动长连，在服务端咱们应用了 async servlet(Spring DeferredResult) 来服务 Http Long Polling 申请。

上图简要形容了 Apollo 的总体设计，咱们能够从下往上看：

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 侧会做 load balance 谬误重试
Portal 通过域名拜访 Meta Server 获取 Admin Service 服务列表（IP+Port），而后间接通过 IP+Port 拜访服务，同时在 Portal 侧会做 load balance、谬误重试
为了简化部署，咱们实际上会把 Config Service、Eureka 和 Meta Server 三个逻辑角色部署在同一个 JVM 过程中

配置核心作为根底服务，可用性要求十分高，上面的表格形容了不同场景下 Apollo 的可用性：

场景	影响	降级	起因
某台 config service 下线	无影响		Config service 无状态，客户端重连其它 config service
所有 config service 下线	客户端无奈读取最新配置，Portal 无影响	客户端重启时, 能够读取本地缓存配置文件
某台 admin service 下线	无影响		Admin service 无状态，Portal 重连其它 admin service
所有 admin service 下线	客户端无影响，portal 无奈更新配置
某台 portal 下线	无影响		Portal 域名通过 slb 绑定多台服务器，重试后指向可用的服务器
全副 portal 下线	客户端无影响，portal 无奈更新配置
某个数据中心下线	无影响		多数据中心部署，数据齐全同步，Meta Server/Portal 域名通过 slb 主动切换到其它存活的数据中心

接下来咱们将创立一个 Apollo 的客户端我的项目，援用 Apollo 来实现配置动静更新，不过在此之前咱们须要提前进入 Apollo Portal 界面，在外面提前创立一个我的项目并在其配置一个参数，不便后续客户端引入该配置参数，测试是否能动态变化。

我这里是部署到 Kubernetes 中，通过 NodePort 形式暴露出一个端口，关上这个地址登录 Apollo：

用户名：apollo
密码：admin

在登录后创立我的项目时，抉择部门默认只能抉择 Apollo 自带的测试部门 1 与测试部门 2 两个选项。

开始这真让人迷糊，原来 Apoloo 没有批改或新增部门信息的治理节目，只能通过批改数据库，来新增或者批改数据，这里关上 Portal 对月的数据库中的表 ApolloPortalDB 批改 key 为 organizations 的 value 的 json 数据，改成本人对于的部门信息。

批改完数据库部门信息后，从新登录 Apollo Portal，而后创立我的项目，这时候抉择部门能够看到曾经变成咱们本人批改后的部门信息了，抉择咱们自定义部门，而后设置利用 ID 为 apollo-test，利用名为 apollo-demo。

创立实现后进入配置管理界面：

创立一个配置参数，不便后续 Apollo 客户端我的项目引入该参数，进行动静配置测试。

设置 key 为 test value 为 123456 而后设置一个备注，保留。

创立实现后能够看到配置管理节目新增了一条配置。

接下来咱们将此配置通过公布按钮，进行公布。

这里创立一个 SpringBoot 我的项目，引入 Apollo 客户端来来实现与 Apollo 配置核心服务端交互。最新 Spring Boot 系列教程举荐看这个：

https://github.com/javastacks…

 1
 2<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 3         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 4    <modelVersion>4.0.0modelVersion>
 5
 6    <parent>
 7        <groupId>org.springframework.bootgroupId>
 8        <artifactId>spring-boot-starter-parentartifactId>
 9        <version>2.1.8.RELEASEversion>
10    parent>
11
12    <groupId>club.mydlqgroupId>
13    <artifactId>apollo-demoartifactId>
14    <version>0.0.1version>
15    <name>apollo-demoname>
16    <description>Apollo Demodescription>
17
18    <properties>
19        <java.version>1.8java.version>
20    properties>
21
22    <dependencies>
23        <dependency>
24            <groupId>org.springframework.bootgroupId>
25            <artifactId>spring-boot-starter-webartifactId>
26        dependency>
27        <dependency>
28            <groupId>com.ctrip.framework.apollogroupId>
29            <artifactId>apollo-clientartifactId>
30            <version>1.4.0version>
31        dependency>
32    dependencies>
33
34    <build>
35        <plugins>
36            <plugin>
37                <groupId>org.springframework.bootgroupId>
38                <artifactId>spring-boot-maven-pluginartifactId>
39            plugin>
40        plugins>
41    build>
42
43project>

在 application.yml 配置文件中增加上面参数，这里简略介绍下 Apollo 参数作用：

apollo.meta： Apollo 配置核心地址。
apollo.cluster： 指定应用某个集群下的配置。
apollo.bootstrap.enabled： 是否开启 Apollo。
apollo.bootstrap.namespaces： 指定应用哪个 Namespace 的配置，默认 application。
apollo.cacheDir=/opt/data/some-cache-dir： 为了避免配置核心无奈连贯等问题，Apollo 会主动将配置本地缓存一份。
apollo.autoUpdateInjectedSpringProperties： Spring 利用通常会应用 Placeholder 来注入配置，如 ${someKey:someDefaultValue}，冒号后面的是 key，冒号前面的是默认值。如果想敞开 placeholder 在运行时自动更新性能，能够设置为 false。
apollo.bootstrap.eagerLoad.enabled： 将 Apollo 加载提到初始化日志零碎之前，如果设置为 false，那么将打印出 Apollo 的日志信息，然而因为打印 Apollo 日志信息须要日志先启动，启动后无奈对日志配置进行批改，所以 Apollo 不能治理利用的日志配置，如果设置为 true，那么 Apollo 能够治理日志的配置，然而不能打印出 Apollo 的日志信息。

 1# 利用配置
 2server:
 3  port: 8080
 4spring:
 5  application:
 6    name: apollo-demo
 7
 8#Apollo 配置
 9app:
10  id: apollo-test                            #利用 ID
11apollo:
12  cacheDir: /opt/data/                       #配置本地配置缓存目录
13  cluster: default                           #指定应用哪个集群的配置
14  meta: http://192.168.2.11:30002            #DEV 环境配置核心地址
15  autoUpdateInjectedSpringProperties: true   #是否开启 Spring 参数自动更新
16  bootstrap:                                
17    enabled: true                            #是否开启 Apollo
18    namespaces: application                  #设置 Namespace
19    eagerLoad:
20      enabled: false                         #将 Apollo 加载提到初始化日志零碎之前

写一个 Controller 类来输入 test 变量的值，应用了 Spring 的 @Value 注解，用于读取配置文件中的变量的值，这里来测试该值，我的项目启动后读取到的变量的值是设置在 application 配置文件中的默认值，还是近程 Apollo 中的值，如果是 Apollo 中配置的值，那么再测试在 Apollo 配置核心中扭转该变量的值后，这里是否会产生变动。

 1import org.springframework.beans.factory.annotation.Value;
 2import org.springframework.web.bind.annotation.GetMapping;
 3import org.springframework.web.bind.annotation.RestController;
 4
 5@RestController
 6public class TestController {
 7
 8    @Value("${test: 默认值}")
 9    private String test;
10
11    @GetMapping("/test")
12    public String test(){
13        return "test 的值为:" + test;
14    }
15}

SpringBoot 我的项目启动类。

 1import org.springframework.boot.SpringApplication;
 2import org.springframework.boot.autoconfigure.SpringBootApplication;
 3
 4@SpringBootApplication
 5public class Application {
 6
 7    public static void main(String[] args) {8        SpringApplication.run(Application.class, args);
 9    }
10
11}

因为自己的 Apollo 是部署在 Kubernetes 环境中的，JVM 参数中必须增加两个变量：

env： 利用应用 Apollo 哪个环境，例如设置为 DEV 就是指定应用开发环境，如果设置为 PRO 就是制订应用生产环境。

apollo.configService： 指定配置核心的地址，跳过 meta 的配置，在测试时指定 meta 地址无成果。如果 Apollo 是部署在 Kubernetes 中，则必须设置该参数为配置核心地址，如果 Apollo 不是在 Kubernetes 环境中，能够不设置此参数，只设置 meta 参数即可。个别状况下，configService 和 meta 值统一。

如果是在 Idea 中启动，能够配置启动参数，加上：

1-Dapollo.configService=http://192.168.2.11:30002 -Denv=DEV

如果是 java 命令启动程序，须要 JVM 加上:

1$ java -Dapollo.configService=http://192.168.2.11:30002 -Denv=DEV -jar apollo-demo.jar

留神：下面 env 指定的环境，要和 apollo.meta 指定 Config 地址的环境统一，例如 -Denv=DEV 即应用开发环境，那么 apollo.meta=http://xxx.xxx.xxx:8080 这个 url 的 Config 也是开发环境下的配置核心服务，而不能是 PRO 或者其它环境下的配置核心。

启动下面的测试用例，而后输出地址 http://localhost:8080/test 查看：

1test 的值为:123456

能够看到应用的是 Apollo 中配置的 test 参数的值 123456，而不是默认的值。

批改 Apollo 配置核心参数 test 值为 666666，而后再次公布。

公布实现后再次输出地址 http://localhost:8080/test 查看：

1test 的值为:666666

能够看到示例利用中的值曾经扭转为最新的值。

回滚实现后状态将变为未公布状态，则时候输出地址 http://localhost:8080/test 查看：

1test 的值为:123456

能够看到曾经回滚到之前的 test 配置的值了。

这里咱们将 JVM 参数中 Apollo 配置核心地址成心改错：

1-Dapollo.configService=http://192.168.2.100:30002 -Denv=DEV

而后输出地址 http://localhost:8080/test 能够看到值为：

1test 的值为:123456

能够看到显示的值并不是咱们定义的默认值，而还是 Apollo 配置核心配置的 test 参数的值。思考到因为 Apollo 会在本地将配置缓存一份，呈现下面起因，预计是缓存失效。当客户端不能连贯到 Apollo 配置核心时候，默认应用本地缓存文件中的配置。

下面咱们配置了本地缓存配置文件寄存地址为“/opt/data/”，接下来进入缓存目录，找到对应的缓存配置文件，删除缓存配置文件后，重启利用，再次输出地址查看：

1test 的值为: 默认值

删除缓存配置文件后，能够看到输入的值为本人定义的默认值。

这里咱们进入 Apollo 配置核心，删除之前创立的 test 参数，而后公布。

而后再次关上地址 http://localhost:8080/test 查看：

1test 的值为: 默认值

能够看到显示的是应用程序中设置的默认值。

在 Apollo 中，配置能够依据不同的环境划分为 Dev（开发）、Prod（生产）等环境，又能依据区域划分为不同的 Cluster（集群），还能依据配置参数作用性能的不同划分为不同的 Namespace（命名空间），这里探索下，如何应用上述能力。

（1）、Apollo 配置核心 PRO 环境增加参数

关上 Apollo 配置核心，环境列表点击 PRO 环境，而后新增一条配置，和之前例子中参数保持一致，都为 test 参数，创立实现后公布。

而后批改下面的示例我的项目，将配置参数指定为 PRO 环境:

（2）、示例我的项目批改 application.yml 配置文件

把 apollo.meta 参数改成 RPO 的配置核心地址

1......
2
3apollo:
4  meta: http://192.168.2.11:30005            #RPO 环境配置核心地址
5
6......

（3）、示例我的项目批改 JVM 参数

把 apollo.configService 参数改成 PRO 配置核心地址，env 参数的值改为 PRO。

1-Dapollo.configService=http://192.168.2.11:30005 -Denv=PRO

（4）、启动示例我的项目察看后果

启动示例我的项目，而后接着输出地址 http://localhost:8080/test 查看信息：

1test 的值为:abcdefg

能够看到曾经改成生成环境配置，所以在理论我的项目中，如果要更换环境，须要批改 JVM 参数 env（如果 Apollo 部署在 Kubernetes 环境中，还须要批改 apollo.configService 参数），和批改 application.yml 配置文件的参数 apollo.meta 值。

（1）、创立两个集群

例如在开发过程中，常常要将利用部署到不同的机房，这里别离创立 beijing、shanghai 两个集群。

（2）、两个集群都配置同样的参数不同的值

在两个集群 beijing 与 shanghai 中，都对立配置参数 test，并且设置不同的值。

（3）、示例我的项目 application.yml 批改集群配置参数, 并启动我的项目察看后果

指定集群为 beijing:

1......
2
3apollo:
4  cluster: beijing                      #指定应用 beijing 集群
5
6......

启动示例我的项目，而后接着输出地址 http://localhost:8080/test 查看信息：

1test 的值为:Cluster-BeiJing

能够看到用的是 beijing 集群的配置

指定集群为 shanghai:

1......
2
3apollo:
4  cluster: shanghai                      #指定应用 shanghai 集群
5
6......

启动示例我的项目，而后接着输出地址 http://localhost:8080/test 查看信息：

1test 的值为:Cluster-ShangHai

能够看到用的是 shanghai 集群的配置

（1）、创立两个命名空间

命名空间有两种，一种是 public（公开），一种是 private 公有，公开命名空间所有我的项目都能读取配置信息，而公有的只能 app.id 值属于该利用的能力读取配置。

这里创立 dev-1 与 dev-2 两个公有的命名空间，用于测试。

（2）、两个集群都配置同样的参数不同的值

在两个命名空间中，都对立配置参数 test，并且设置不同的值，设置完后公布。

（3）、示例我的项目 application.yml 批改命名空间配置参数, 并启动我的项目察看后果

指定命名空间为 dev-1:

1......
2
3apollo:
4  bootstrap:
5    namespaces: dev-1                   #设置 dev-1 命名空间
6
7......

启动示例我的项目，而后接着输出地址 http://localhost:8080/test 查看信息：

1test 的值为:dev-1 Namespace

能够看到用的是 dev-1 命名空间的配置

指定命名空间为 dev-2:

1......
2
3apollo:
4  bootstrap:
5    namespaces: dev-2                   #设置 dev-1 命名空间
6
7......

启动示例我的项目，而后接着输出地址 http://localhost:8080/test 查看信息：

1test 的值为:dev-2 Namespace

能够看到用的是 dev-2 命名空间的配置

自己的 Apollo 和 SpringBoot 利用个别都是基于 Kubernetes 部署的，所以这里简略介绍下，如何在 Kubernetes 环境下部署 SpringBoot 利用且应用 Apollo 作为配置核心。

这里我的项目仍旧应用下面的示例，不过首先要将其编译成 Docker 镜像，不便后续部署到 Kubernetes 环境下。

（1）、执行 Maven 编译

首先执行 Maven 命令，将我的项目编译成一个可执行 JAR。

1$ mvn clean install

（2）、筹备 Dockerfile

创立构建 Docker 镜像须要的 Dockerfile 文件，将 Maven 编译的 JAR 复制到镜像外部，而后设置两个变量，别离是：

JAVA_OPTS： Java JVM 启动参数变量，这里须要在这里加一个时区参数。
APP_OPTS： Spring 容器启动参数变量，不便后续操作时能通过此变量配置 Spring 参数。

Dockerfile：

1FROM openjdk:8u222-jre-slim
2VOLUME /tmp
3ADD target/*.jar app.jar
4RUN sh -c 'touch /app.jar'
5ENV JAVA_OPTS="-Duser.timezone=Asia/Shanghai"
6ENV APP_OPTS=""7ENTRYPOINT ["sh","-c","java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar $APP_OPTS"]

（3）、构建 Docker 镜像

执行 Docker Build 命令构建 Docker 镜像。

1$ docker build -t mydlqclub/springboot-apollo:0.0.1 .

（1）、创立 SpringBoot 且应用 Apollo 配置核心的 Kubernetes 部署文件

这里创立 Kubernetes 下的 SpringBoot 部署文件 apollo-demo-example.yaml。在之前 Dockerfile 中设置了两个环境变量，JAVA_OPTS 与 APP_OPTS。其中 JAVA_OPTS 变量的值将会作为 JVM 启动参数，APP_OPTS 变量的值将会作为利用的配置参数。所以，这里咱们将 Apollo 配置参数搁置到变量中，这样一来就能够不便批改与保护 Apollo 的配置信息。

在上面配置的环境变量参数中，设置的配置核心地址为 http://service-apollo-config-server-dev.mydlqclub:8080，这是因为 Apollo 部署在 K8S 环境中，且能够应用域名形式拜访，service-apollo-config-server-dev 是利用的 Service 名称，mydlqcloud 是 K8S 下的 Namespace 名称。

springboot-apollo.yaml

 1apiVersion: v1
 2kind: Service
 3metadata:
 4  name: springboot-apollo
 5spec:
 6  type: NodePort
 7  ports:
 8    - name: server
 9      nodePort: 31080
10      port: 8080
11      targetPort: 8080
12    - name: management
13      nodePort: 31081
14      port: 8081
15      targetPort: 8081
16  selector:
17    app: springboot-apollo
18---
19apiVersion: apps/v1
20kind: Deployment
21metadata:
22  name: springboot-apollo
23  labels:
24    app: springboot-apollo
25spec:
26  replicas: 1
27  selector:
28    matchLabels:
29      app: springboot-apollo
30  template:
31    metadata:
32      name: springboot-apollo
33      labels:
34        app: springboot-apollo
35    spec:
36      restartPolicy: Always
37      containers:
38        - name: springboot-apollo
39          image: mydlqclub/springboot-apollo:0.0.1
40          imagePullPolicy: Always
41          ports:
42            - containerPort: 8080
43              name: server
44          env:
45            - name: JAVA_OPTS
46              value: "-Denv=DEV"
47              ## 留神批改此处的 mydlqcloud 为你本人的 Namespace 名称
48            - name: APP_OPTS
49              value: "
50                     --app.id=apollo-demo
51                     --apollo.bootstrap.enabled=true
52                     --apollo.bootstrap.eagerLoad.enabled=false
53                     --apollo.cacheDir=/opt/data/
54                     --apollo.cluster=default
55                     --apollo.bootstrap.namespaces=application
56                     --apollo.autoUpdateInjectedSpringProperties=true
57                     --apollo.meta=http://service-apollo-config-server-dev.mydlqcloud:8080    
58                     "
59          resources:
60            limits:
61              memory: 1000Mi
62              cpu: 1000m
63            requests:
64              memory: 500Mi
65              cpu: 500m

（2）、部署 SpringBoot 利用到 Kubernetes

-n：创立利用到指定的 Namespace 中。

1$ kubectl apply -f springboot-apollo.yaml -n mydlqcloud

下面的利用配置了 NodePort 端口，能够通过此端口拜访 Kubernetes 集群内的利用接口，自己 Kubernetes 集群地址为 192.168.2.11 且 NodePort 端口为 31081，所以浏览器拜访地址 http://192.168.2.11:31081/test 来测试接口，显示：

1test 的值为:123456

能够看到能通过 Apollo 获取参数值，此文章到此结束。

近期热文举荐：

1.1,000+ 道 Java 面试题及答案整顿 (2021 最新版)

2. 终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！

3. 阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！

4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！

5.《Java 开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞 + 转发哦！

关于java:Spring-Boot-集成-Apollo-配置中心真香真强大

1、背景

2、简介

3、特点

4、根底模型

5、Apollo 的四个维度

6、本地缓存

7、客户端设计

8、总体设计

9、可用性思考

Apollo 配置核心创立我的项目与配置

1、登录 Apollo

2、批改与减少部门数据

3、创立一个我的项目

4、创立一个配置参数

创立 Apollo 客户端测试项目

1、Maven 增加 Apollo 依赖

2、配置文件增加参数

3、创立测试 Controller 类

4、创立启动类

5、JVM 启动参数增加启动参数

启动我的项目进行测试

1、测试是否可能获取 Apollo 中设置的值

2、测试当 Apollo 中批改参数值后客户端是否能及时刷新

3、测试当 Apollo 执行配置回滚操作时客户端是否能及时扭转

4、测试当不能拜访 Apollo 时客户端的变动

5、测试当 Apollo 中将参数删除后客户端的变动

对 Apollo 的 Cluster、Namespace 进行探索

1、不同环境下的配置

2、不同集群下的配置

3、不同命名空间下的配置

Kubernetes 的 SpringBoot 利用应用 Apollo 配置核心

1、构建 Docker 镜像

2、Kubernetes 部署示例利用

3、测试部署的利用接口

Just My Socks（注册教程内含优惠码）

关于java:Spring-Boot-集成-Apollo-配置中心真香真强大

1、背景

2、简介

3、特点

4、根底模型

5、Apollo 的四个维度

6、本地缓存

7、客户端设计

8、总体设计

9、可用性思考

Apollo 配置核心创立我的项目与配置

1、登录 Apollo

2、批改与减少部门数据

3、创立一个我的项目

4、创立一个配置参数

创立 Apollo 客户端测试项目

1、Maven 增加 Apollo 依赖

2、配置文件增加参数

3、创立测试 Controller 类

4、创立启动类

5、JVM 启动参数增加启动参数

启动我的项目进行测试

1、测试是否可能获取 Apollo 中设置的值

2、测试当 Apollo 中批改参数值后客户端是否能及时刷新

3、测试当 Apollo 执行配置回滚操作时客户端是否能及时扭转

4、测试当不能拜访 Apollo 时客户端的变动

5、测试当 Apollo 中将参数删除后客户端的变动

对 Apollo 的 Cluster、Namespace 进行探索

1、不同环境下的配置

2、不同集群下的配置

3、不同命名空间下的配置

Kubernetes 的 SpringBoot 利用应用 Apollo 配置核心

1、构建 Docker 镜像

2、Kubernetes 部署示例利用

3、测试部署的利用接口

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）