Apollo 分布式配置中心：基于 Rainbond 云原生平台的一键部署与多环境管理实战指南
【免费下载链接】apolloApollo is a reliable configuration management system suitable for microservice configuration management scenarios.项目地址: https://gitcode.com/gh_mirrors/apoll/apollo
导读
本文面向不熟悉 Kubernetes、容器化等底层技术的开发者与运维人员，讲解如何借助开源云原生应用管理平台 Rainbond，以"应用模版 + 图形化界面"的方式一键安装高可用 Apollo 配置中心集群，并在 Rainbond 拓扑视图中完成环境变量、配置文件挂载与 Service Mesh 出口网络治理插件等日常配置。读完本文，你将掌握 Apollo 在 Rainbond 上的完整部署链路、PRO环境的默认初始化方式，以及如何通过实例伸缩与"追加环境"两个高级特性，构建统一 Portal 管控的多环境（如DEV、PRO）配置管理体系，同时理解这些操作背后对应的 Apollo 源码实现原理。
一、背景：为什么用 Rainbond 部署 Apollo
Rainbond 是一款易于使用的开源云原生应用管理平台。借助 Kubernetes 和容器化技术，它将故障自愈、弹性伸缩等自动化运维能力赋能给用户的业务，同时内置原生 Service Mesh 微服务框架，并与 Spring Cloud、Dubbo 等其他微服务框架有良好的整合体验。
Apollo（本仓库 apollo）是一个适用于微服务配置管理场景的可靠分布式配置中心。二者在用户群体上高度重合：大量 Rainbond 用户同时也是 Apollo 用户。对于这类用户而言，手动编排 Config Service、Admin Service、Portal 三组件的容器、数据库与网络关系成本较高，而 Rainbond 团队将 Apollo 制作成可一键部署的应用模版，供开源用户免费下载安装，极大降低了 Apollo 集群的部署负担。当前该安装方式支持1.9.2与2.0.1两个版本，默认集成一套PRO环境，如需其他环境可参见本文"高级特性"章节。
1.1 什么是应用模版
应用模版是面向 Rainbond 云原生应用管理平台的安装包。无论业务系统多么复杂，应用模版都会将其抽象成为一个应用，裹挟着应用内所有组件的镜像、配置信息以及所有组件之间的关联关系一并安装起来。对 Apollo 而言，一个应用模版即包含：
Apollo-portal、Apollo-config、Apollo-admin三个核心组件的镜像；- 各组件间的依赖/连接关系（如 Portal 依赖 Config）；
- 默认环境变量与配置文件挂载项（如
APOLLO_PORTAL_ENVS=pro）； - 内置的数据库组件（如
ApolloPortalDB、ApolloConfigDB）。
安装时只需选择目标团队、集群与应用，Rainbond 便会按照模版描述的依赖顺序自动拉起整套集群。
二、前提条件
开始安装前，请确认满足以下条件：
| 前提 | 说明 |
|---|---|
| 已部署 Rainbond 云原生应用管理平台 | 例如使用快速体验版本，可在个人 PC 环境中以"启动一个容器"的代价运行完整平台 |
| 可连接到互联网 | 安装过程中需要拉取 Apollo 应用模版及组件镜像；内置"开源应用商店"需要联网访问 |
注意：本文描述的是应用商店一键安装路径，区别于仓库中另一篇 quick-start.md（手动部署）与 quick-start-docker.md（Docker 快速开始），Rainbond 路径完全基于图形化界面，无需编写 YAML。
三、快速开始：一键安装 Apollo 集群
3.1 访问内置的开源应用商店
登录 Rainbond 控制台后：
- 点击左侧导航栏的应用市场标签页；
- 在页面中切换到开源应用商店标签页；
- 在搜索框输入关键词apollo，即可检索到 Apollo 应用模版。
3.2 一键安装与参数说明
点击 Apollo 右侧的安装按钮进入安装页面，填写信息后点击确定即开始安装，页面会自动跳转到拓扑视图。安装表单中主要选择项及其含义如下：
| 选择项 | 说明 |
|---|---|
| 团队名称 | 用户自建的工作空间，以命名空间隔离 |
| 集群名称 | 选择 Apollo 被部署到哪一个 Kubernetes 集群 |
| 选择应用 | 选择 Apollo 被部署到哪一个应用，应用中包含若干有关联的组件 |
| 应用版本 | 选择 Apollo 的版本，目前可选版本为 1.9.2、2.0.1 |
等待几分钟后，Apollo 集群即安装完成并运行起来。安装完成后，拓扑视图中会出现Apollo-portal-2.0.1、Apollo-config-2.0.1、Apollo-admin-2.0.1三个核心组件以及配套的数据库组件。
提示：这里的三个组件名对应 Apollo 的三个服务——Portal（管理界面）、Config Service（配置下发）与 Admin Service（配置管理）。在仓库源码中，Config Service 与 Admin Service 的默认服务端口分别定义在 configservice.properties（
server.port=8080）与 adminservice.properties（server.port=8090），这也是后续配置插件域名时"只写域名、不写端口"仍能精确访问到对应服务的原因之一。
3.3 测试：验证 PRO 环境就绪
访问组件Apollo-portal-2.0.1提供的默认域名，即可登录 Apollo 控制台。登录后在"系统信息"页面中，验证PRO环境已经就绪（默认安装即附带PRO环境）。
3.4 配置：环境变量、配置文件与插件
在 Rainbond 中，可基于图形化界面对 Apollo 集群进行配置，主要包括环境变量、配置文件挂载、插件配置三个方面：
（1）环境变量
在不同组件的页面 →环境配置中，可自定义环境变量。例如Apollo-portal-2.0.1默认添加了：
APOLLO_PORTAL_ENVS=pro该变量用于定义当前 Portal 纳管的环境列表。其背后的实现位于 PortalConfig.java：portalSupportedEnvs()读取配置项apollo.portal.envs（默认值为FAT, UAT, PRO），逐一Env.addEnvironment(envName)注册为 Portal 可管理的环境。Rainbond 模版通过环境变量注入APOLLO_PORTAL_ENVS后，Spring 的配置绑定机制会将其映射到该配置项，从而控制 Portal 展示与操作的环境集合。
（2）配置文件挂载
在不同组件的页面 →环境配置中，可以为组件设置配置文件，通过挂载覆盖容器内默认配置：
Apollo-portal-2.0.1挂载/apollo-portal/config/apollo-env.properties，用于定义不同环境的meta server 地址；Apollo-config-2.0.1挂载/apollo-configservice/config/application-github.properties，用于声明当前环境 config 与 admin 的服务地址（即服务注册与发现信息）。
apollo-env.properties的解析逻辑在 DefaultPortalMetaServerProvider.java 中实现：Portal 启动时依次从配置文件（键以.meta结尾）、操作系统环境变量（键以_meta结尾）、系统属性（键以_meta结尾）中加载所有环境的 meta 地址，低优先级先加入、高优先级覆盖，最终构建Env -> metaServerAddress映射。该文件中的典型键格式为<ENV>.meta=http://apollo-config-<env>:8080。环境名在 Env.java 中会统一转换为大写，并将PROD归一为PRO、FWS归一为FAT，因此大小写混用的环境名也能被正确识别。
而application-github.properties对应仓库中的 apollo-configservice/src/main/resources/application-github.properties 与 apollo-adminservice/src/main/resources/application-github.properties。以 config 组件为例，其中通过占位符方式声明数据源并引用服务地址相关配置（如spring.datasource.url = ${spring_datasource_url}等）。需要特别说明的是：在 Rainbond 的 Service Mesh 网络模型中，组件之间的调用由插件定义域名完成，因此该文件中的服务地址通常写成apollo-config-<env>、apollo-admin-<env>这类域名形式而非 IP:端口。
（3）插件配置（出口网络治理）
在 Rainbond 中，通过为Apollo-portal-2.0.1、Apollo-config-2.0.1安装出口网络治理插件来定义下游调用地址，这是一种 Service Mesh 微服务治理的实现方式：通过定义下游服务的域名，来访问下游服务的指定端口。例如：
- 在
Apollo-portal-2.0.1的插件中，访问Apollo-config-2.0.18080 端口的域名为apollo-config-pro； - 这也是上文配置文件中"只定义域名、不需要定义端口"的原因——端口映射关系由插件统一管理。
从源码角度理解这一设计：Apollo 的服务发现默认依赖 Eureka，但在 Kubernetes/Rainbond 场景下，application-kubernetes.properties 等 profile 会显式关闭 Eureka 与 Spring Cloud Discovery（apollo.eureka.server.enabled=false、eureka.client.enabled=false、spring.cloud.discovery.enabled=false），转由平台层的服务发现（如 KubernetesDiscoveryService.java）通过apollo.config-service.url、apollo.admin-service.url等配置解析下游地址。Rainbond 的出口网络治理插件正是替代了这层服务发现职责，将域名解析到目标组件端口。
四、高级特性
4.1 实例数量伸缩（集群化部署）
Apollo 配置中心所包含的Apollo-portal-2.0.1、Apollo-config-2.0.1、Apollo-admin-2.0.1三个组件均使用 Deployment 控制器部署，通过 Rainbond 内置的 Service Mesh 微服务框架实现服务发现与通信。因此这三个组件均可以一键扩展多个实例，实现集群化部署与高可用。
以Apollo-portal-2.0.1为例：
- 进入组件页面；
- 点击伸缩；
- 修改实例数量；
- 点击设置生效。
Rainbond 会自动完成新实例的负载均衡与服务发现注册，无需修改任何 Apollo 配置。Config Service 与 Admin Service 同样可按此方式扩容，以满足高并发配置拉取场景下的吞吐需求。
4.2 追加环境（如新增 DEV 环境）
Apollo 配置中心支持对接多套环境，并使用统一的 Portal 页面进行管理。基于 Rainbond 一键安装而来的 Apollo 集群默认附带PRO环境。下面演示如何在 Rainbond 场景中追加一套DEV环境。假设在DEV环境中，通过apollo-config-dev、apollo-admin-dev分别访问Apollo-config-Dev、Apollo-admin-Dev组件。
步骤 1：部署一套新的 Apollo 集群并调整拓扑
再部署一套 Apollo 集群，并去除新集群中的Apollo-portal-2.0.1与ApolloPortalDB组件（新环境无需独立 Portal）。为便于管理，将Apollo-config-2.0.1、Apollo-admin-2.0.1组件改名为Apollo-config-Dev、Apollo-admin-Dev，然后添加旧集群Apollo-portal-2.0.1到这两个新组件的依赖。
注意：该步骤会触发连接信息环境变量冲突的情况，请记得为
Apollo-config-Dev、Apollo-admin-Dev组件的对内端口重新定义名字（例如apollo-config-dev、apollo-admin-dev），避免依赖注入时连接信息键名冲突。
步骤 2：修改 config 组件的服务地址配置文件
在环境配置页面，修改Apollo-config-Dev的配置文件/apollo-configservice/config/application-github.properties，将 config 与 admin 的服务地址修改为预期值（即本环境中两个组件的对内访问域名，形如apollo-config-dev、apollo-admin-dev）。
步骤 3：配置出口网络治理插件域名
分别进入Apollo-config-Dev与Apollo-portal-2.0.1的插件页面，为其出口网络治理插件修改配置。Rainbond 内置的微服务框架通过设定的域名（Domains）定义下游服务的访问地址：
- 以
Apollo-portal-2.0.1为例，需要配置到Apollo-config-Dev、Apollo-admin-Dev的访问域名（如apollo-config-dev、apollo-admin-dev）； - 配置完成后点击更新配置，
Apollo-portal-2.0.1即可通过apollo-config-dev这个域名访问到Apollo-config-Dev； - 同理，
Apollo-config-Dev需要配置到Apollo-admin-Dev的访问域名，配置完成后更新配置。
步骤 4：修改 Portal 配置以纳入 DEV 环境
修改Apollo-portal-2.0.1的配置来加入新的DEV环境，分两步：
修改环境变量
APOLLO_PORTAL_ENVS的值，加入dev环境，例如：APOLLO_PORTAL_ENVS=pro,dev修改配置文件
/apollo-portal/config/apollo-env.properties，写入dev环境的 meta 地址，例如：dev.meta=http://apollo-config-dev:8080
完成后更新Apollo-portal-2.0.1组件，使所有配置生效。最后查看系统信息，验证DEV环境加入完成。
原理说明：环境变量
APOLLO_PORTAL_ENVS对应 PortalConfig.java 中的apollo.portal.envs配置，决定 Portal 纳管哪些环境；而apollo-env.properties中dev.meta键则由 DefaultPortalMetaServerProvider.java 读取（键以.meta结尾），为DEV环境提供 meta server 地址。二者缺一不可：前者让 Portal 展示该环境，后者让 Portal 能访问该环境的 config 服务。
五、总结
通过 Rainbond 应用模版，用户可以完全避开 Kubernetes YAML 编写与组件编排，在图形化界面中完成 Apollo 高可用集群的部署、配置与扩容：
- 部署：开源应用商店搜索
apollo→ 一键安装，默认附带PRO环境； - 配置：通过环境变量（
APOLLO_PORTAL_ENVS）、配置文件挂载（apollo-env.properties、application-github.properties）与出口网络治理插件完成组件间通信定义； - 高可用：三个核心组件基于 Deployment + Service Mesh 可一键横向扩容；
- 多环境：通过部署第二套集群（去掉 Portal 与 PortalDB）、修改 config 服务地址、配置插件域名、更新 Portal 环境变量与 meta 文件四个步骤，即可将
DEV等新环境纳入统一 Portal 管理。
这一部署路径与仓库中的 英文版文档 互为对照，也可结合 分布式部署指南 与 部署架构 进一步理解 Apollo 各组件之间的通信模型。对于希望深入了解 Portal 环境解析与 meta 地址加载机制的读者，建议直接阅读 DefaultPortalMetaServerProvider.java 与 Env.java 的完整实现。
【免费下载链接】apolloApollo is a reliable configuration management system suitable for microservice configuration management scenarios.项目地址: https://gitcode.com/gh_mirrors/apoll/apollo
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
