动态调整线程池参数实践(1)

三、Apollo 分布式配置中心

了解完动态化线程池的整体设计与功能架构后，我相信你也可以设计出一款动态线程池组件出来的。下面跟着老周来实践一下动态调整线程池参数，可能不像上面设计的那样那么全面，但会把动态调整线程池参数的核心给实现一下。

不难发现动态化线程池的核心是配置管理，那我们就得找一个分布式配置中心，这里老周用的 Apollo，还有其它的像 Spring Cloud Config、disconf、某些大型互联网公司自研的分布式配置中心等，根据自己的项目情况以及使用场景来选择就行。

3.1 Apollo 总体设计

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

3.1.1 基础模型

如下图即是 Apollo 的基础模型：

1. 用户在配置中心对配置进行修改并发布

2. 配置中心通知 Apollo 客户端有配置更新

3. Apollo 客户端从配置中心拉取最新的配置、更新本地配置并通知到应用

3.1.2 架构模块

上图简要描述了 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 服务端设计

3.2.1 配置发布后的实时推送设计

在配置中心中，一个重要的功能就是配置发布后实时推送到客户端。本文重点分析配置更新推送方式，下面我们简要看一下这块是怎么设计实现的。

上图简要描述了配置发布的大致过程：

1. 用户在 Portal 操作配置发布

2. Portal 调用 Admin Service 的接口操作发布

3. Admin Service 发布配置后，发送 ReleaseMessage 给各个 Config Service

4. Config Service 收到 ReleaseMessage 后，通知对应的客户端

上图的发送 ReleaseMessage 的实现方式详情请往下继续看：

Admin Service 在配置发布后，需要通知所有的 Config Service 有配置发布，从而 Config Service 可以通知对应的客户端来拉取最新的配置。

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

在实现上，考虑到 Apollo