13小节：通过Apollo实现线程池参数配置

作者：程序员马丁

note

Ragent AI —— 从 0 到 1 纯手工打造企业级 Agentic RAG，拒绝 Demo 玩具！AI 时代，助你拿个offer。

通过 Apollo 实现线程池参数配置，元数据信息：

什么是线程池oneThread：https://t.zsxq.com/5GfrN
代码仓库：https://gitcode.net/nageoffer/onethread —— 申请项目权限参考上述线程池项目链接
章节难度：★★☆☆☆ - 中等
视频地址：本章节内容简单，无

内容摘要：本章节讲解了 Apollo 配置中心的基本原理、核心特性、适用场景，并结合实际项目分析了 Apollo 与 Nacos 在配置管理中的优劣对比。最后，通过一个示例展示了如何基于 apollo-spring-boot-starter 快速实现配置变更监听与动态刷新线程池配置的落地实现。

课程目录如下所示：

前言
什么是 Apollo？
Apollo vs Nacos
Apollo 如何完成配置监听？
文末总结

前言

如果大家只关注 oneThread 动态线程池的核心功能，而使用的是 Nacos 配置中心，则本章节内容可作为参考阅读，不强依赖。两者使用方式虽然不同，但监听配置变更的核心思想完全一致。

马哥，你在前面章节已经用 Nacos 实现了动态线程池配置刷新，为什么还要讲 Apollo？

这是个很好的问题。答案很简单：我们做的是基础组件开发，不是仅应用单个项目的。

在真实的业务系统中，用户的基础设施环境往往是多样化的 —— 有的公司用 Nacos，有的用 Apollo，还有的可能使用 Consul、Zookeeper、Etcd 甚至自研配置中心。这就要求我们构建的组件具备良好的可插拔能力，可以适配不同的配置中心，按需选择、灵活集成。

因此，Apollo 的支持并不是“重复造轮子”，而是对动态线程池组件能力边界的延伸，让用户可以无感集成到任意配置体系下的项目中。

什么是 Apollo？

1. 基础介绍

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

服务端基于 SpringBoot 和 SpringCloud 开发，打包后可以直接运行，不需要额外安装 Tomcat 等应用容器。

Java客户端不依赖任何框架，能够运行于所有 Java 运行时环境，同时对 Spring/SpringBoot 环境也有较好的支持。

正是基于配置的特殊性，所以 Apollo 从设计之初就立志于成为一个有治理能力的配置发布平台，目前提供了以下的特性：

统一管理不同环境、不同集群的配置：
- Apollo 提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
- 同一份代码部署在不同的集群，可以有不同的配置，比如 zookeeper 的地址等。
- 通过命名空间（namespace）可以很方便地支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖。
配置修改实时生效（热发布）：用户在 Apollo 修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序。
版本发布管理：所有的配置发布都有版本概念，从而可以方便地支持配置的回滚。
灰度发布：支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例。
配置项的全局视角搜索：
- 通过对配置项的 key 与 value 进行的模糊检索，找到拥有对应值的配置项在哪个应用、环境、集群、命名空间中被使用。
- 通过高亮显示、分页与跳转配置等操作，便于让管理员以及 SRE 角色快速、便捷地找到与更改资源的配置值。
权限管理、发布审核、操作审计
- 应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。
- 所有的操作都有审计日志，可以方便地追踪问题。
客户端配置信息监控：可以在界面上方便地看到配置在被哪些实例使用。
提供 Java 和 .Net 原生客户端：
- 提供了 Java 和 .Net 的原生客户端，方便应用集成。
- 支持 Spring Placeholder, Annotation 和 Spring Boot 的 ConfigurationProperties，方便应用使用（需要Spring 3.1.1+）。
- 同时提供了 Http 接口，非 Java 和 .Net 应用也可以方便地使用。
提供开放平台API：
- Apollo 自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。不过 Apollo 出于通用性考虑，不会对配置的修改做过多限制，只要符合基本的格式就能保存，不会针对不同的配置值进行针对性的校验，如数据库用户名、密码，Redis 服务地址等。
- 对于这类应用配置，Apollo 支持应用方通过开放平台 API 在 Apollo 进行配置的修改和发布，并且具备完善的授权和权限控制。
部署简单：
- 配置中心作为基础服务，可用性要求非常高，这就要求 Apollo 对外部依赖尽可能地少。
- 目前唯一的外部依赖是 MySQL，所以部署非常简单，只要安装好 Java 和 MySQL 就可以让 Apollo 跑起来。
- Apollo 还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数。

2. Apollo at a glance

2.1 基础模型

如下即是 Apollo 的基础模型：

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

2.2 界面概览

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

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

3. 架构设计

3.1 总体设计

上图简要描述了 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 进程中。

3.2 客户端设计

上图简要描述了 Apollo 客户端的实现原理：

客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。
客户端还会定时从 Apollo 配置中心服务端拉取应用的最新配置。
- 这是一个 fallback 机制，为了防止推送机制失效导致配置不更新；
- 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回 304 - Not Modified；
- 定时频率默认为每 5 分钟拉取一次，客户端也可以通过在运行时指定 System Property: apollo.refreshInterval 来覆盖，单位为分钟。
客户端从 Apollo 配置中心服务端获取到应用的最新配置后，会保存在内存中。
客户端会把从服务端获取到的配置在本地文件系统缓存一份。在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置。
应用程序从 Apollo 客户端获取最新的配置、订阅配置更新通知。

看了上面的描述，相信大家对 Apollo 有了简单认识，如果想学习更多知识，参考 Apollo 官方文档。

Apollo vs Nacos

1. 基础定位

特性	Apollo	Nacos
核心定位	配置中心（Configuration Management）	配置中心 + 服务注册与发现（双核心）
主导方	携程	阿里巴巴
开源时间	2017	2018

2. 功能对比

功能特性	Apollo	Nacos
配置管理	✅ 支持多环境、多集群、灰度、注释等功能	✅ 支持，配置轻量，支持动态刷新
服务注册与发现	❌ 不支持	✅ 支持 DNS+RPC 注册发现
权限与审计	✅ 支持细粒度权限控制、操作日志	⚠️ 支持较弱，社区版权限较简单
多租户/Namespace	✅ 支持，较为完善	✅ 支持，但隔离粒度和隔离机制略弱
灰度发布	✅ 支持灰度配置、灰度规则等	❌ 默认不支持，需要额外接入
控制台体验	✅ 完善，功能细化、可编辑历史配置、权限等	⚠️ 简洁但偏轻量，适合基础使用
历史版本 & 回滚	✅ 支持查看、回滚历史版本	✅ 支持，但功能较简单
持久化存储	✅ 默认基于 MySQL	✅ 默认基于 MySQL，也支持嵌入式

3. 使用场景

Apollo 适合的场景：

企业级配置中心需求，要求权限、审计、版本回滚完善。
配置维度多、业务线多、环境划分复杂。
对灰度发布、配置审计等有强需求。

Nacos 适合的场景：

需要配置管理 + 服务注册一体化解决方案。
微服务治理场景中，希望轻量、快速接入（如 Dubbo/Spring Cloud）。
注册中心与配置中心统一部署场景。

总结对比：

对比维度	Apollo	Nacos
配置管理能力	⭐⭐⭐⭐⭐（功能丰富）	⭐⭐⭐（轻量实用）
服务注册发现	❌	⭐⭐⭐⭐（功能齐全）
控制台体验	⭐⭐⭐⭐（企业级 UI）	⭐⭐（基础可用）
运维复杂度	⭐⭐（需部署多个组件）	⭐⭐⭐⭐（轻量级部署）
灰度与权限	⭐⭐⭐⭐（支持细粒度）	⭐⭐（简单支持）
使用门槛	⭐⭐（需配套 SDK）	⭐⭐⭐⭐（Spring Cloud 快速整合）
社区与生态	⭐⭐⭐⭐	⭐⭐⭐⭐

4. 马哥主观比较

这一章节，马哥不打算从官方文档或功能清单去评比 Apollo 和 Nacos，而是结合自己在项目中接触和落地的实际体验，做一波纯主观、偏实战的横向对比。如果你有不同观点，欢迎评论区一起交流。

我主要从以下几个维度做个简要分析：

架构层面：两者的底层架构其实都已经非常成熟，经历了大规模生产验证。无论选哪一个，稳定性和可用性都无需担心，因此架构本身不构成选型门槛。
功能完备性：就“配置中心”本身而言，Apollo 的功能更偏企业级，在灰度发布、权限控制、版本回滚等方面优势明显，这方面 Nacos 是无法比的，属于被 Apollo 碾压的存在。
集成便利性：但 Nacos 胜在“全能型选手”——服务注册 + 配置中心一体化，对中小项目尤其友好，减少了中间件部署、维护和学习成本，我个人在业务场景中更偏好 Nacos。
代码观感：Apollo 的早期源码风格有较明显的 .NET 影子，比如 m_ 命名前缀等，对于 Java 开发者不太友好；相比之下，Nacos 的代码结构更贴合现代 Java 开发习惯，上手更自然。
社区活跃度：目前来看，Apollo 的发布频率有所下降（23年两个版本，24年一个，25年上半年一个），但我更倾向于理解为“功能趋于稳定”；而 Nacos 因兼具注册中心职能，社区仍较活跃，PMC 主导下 Bug 修复和发版也更持续。

对大多数团队而言，Nacos 已足够满足日常配置需求；但如果你对权限、审计、灰度发布等有更高要求，Apollo 是更合适的选择。两者并非替代关系，而是可按需选型的不同侧重。

Apollo 如何完成配置监听？

如果大家看过 Nacos 的配置监听和参数变更，其实 Apollo 流程是一样的，只是监听逻辑是不同的。

本章节的重点内容集中在模块： apollo-spring-boot-starter。

如果大家想要在项目中使用 Apollo 配置管理，需要在 pom.xml 文件中添加对应的依赖：

<dependency>
    <groupId>com.ctrip.framework.apollo</groupId>
    <artifactId>apollo-client-config-data</artifactId>
</dependency>

从 Apollo 提供的配置中心抽象接口中，我们可以看到其核心方法之一是 addChangeListener，用于注册配置变更监听器。

13小节：通过Apollo实现线程池参数配置

前言