企业官网建设流程全解析

• 消息队列
• 后端
• 流处理

Apache Pulsar 官方将整套集群封装为 DC/OS 的 Marathon Application Group 交付，本文以 deploy-dcos.md 为骨架，完整讲解如何在 DC/OS（基于 Apache Mesos 的数据中心操作系统）上一条命令拉起包含 BookKeeper、broker、Prometheus/Grafana 的 Pulsar 集群，并演示端到端生产消费验证与卸载流程。读完本文，你将掌握 DC/OS 环境下的 Pulsar 部署命令、各组件组（BookKeeper / broker / 监控）的验证方法，以及如何在真实 DC/OS 集群上运行 Java 客户端验证消息收发。

DC/OS 与 Apache Pulsar：Marathon 应用组承载分布式消息系统

DC/OS（DataCenterOperatingSystem，数据中心操作系统）是一种分布式操作系统，用于在 Apache Mesos 之上部署和管理应用程序与系统。Apache Pulsar 在 DC/OS 中以Marathon Application Group（应用组）的形式提供——Marathon 应用组允许把多个相关联的应用作为一组可管理的集合统一运行、扩缩容与删除，恰好契合 Pulsar 集群由多个异构组件（存储节点、消息代理、监控组件）组成的拓扑结构。

在进入部署之前，先明确 DC/OS 部署所涉及的 Pulsar 核心角色（详细术语表见 reference-terminology.md）：

• Bookie：BookKeeper 单台服务器的名字，本质上是 Pulsar 的存储服务器，负责以 append-only 的 Ledger 结构持久化消息；
• Broker：Pulsar 集群中的无状态组件，运行 HTTP 服务（REST 管理接口与 topic lookup）和 dispatcher（处理所有消息传输的异步 TCP 服务器），消息数据端口默认监听 6650（见 broker.conf 中brokerServicePort=6650）；
• ZooKeeper：由 DC/OS 自带提供，承担 Pulsar 的元数据存储职责。

部署前准备：版本、集群与资源配置

要在一套 DC/OS 环境中运行 Pulsar，需要满足以下前提条件：

• DC/OS 版本1.9 或更高；
• 一个至少包含三个 agent 节点的 DC/OS 集群；
• 已安装DC/OS CLI 命令行工具；
• 获取 Pulsar 官方的PulsarGroups.json配置文件（Marathon 应用组定义文件），可使用 curl 下载：

$ curl -O https://raw.githubusercontent.com/apache/pulsar/master/deployment/dcos/PulsarGroups.json

DC/OS 管理的 Mesos 集群中每个节点至少需要满足以下资源规格：

如果集群资源不足或更高配，可以直接修改PulsarGroups.json中的资源配额定义，使其与 DC/OS 集群实际可用资源匹配。

一条命令拉起集群：dcos marathon group add

获取PulsarGroups.json后，即可通过 DC/OS 命令行接口部署整个 Pulsar 集群：

$ dcos marathon group add PulsarGroups.json

该命令会以三个应用组的形式在 Docker 容器中部署完整的 Pulsar 集群：

1. bookkeeper 组：3 个 bookie（每个 agent 节点 1 个 bookie），外加 1 个bookie recovery（自动恢复）实例；
2. brokers 组：3 个 Pulsar broker（每个节点 1 个 broker），外加 1 个 admin 实例；
3. monitory 组：1 个 Prometheus 实例和 1 个 Grafana 实例。

运行 DC/OS 时，集群中已经有一个 ZooKeeper 运行在master.mesos:2181，因此无需再单独安装或启动 ZooKeeper，Pulsar 的 bookie 与 broker 会直接复用该地址完成元数据协调。

命令执行后，打开 DC/OS 的 GUI 界面（本示例中地址为http://m1.dcos），点击Services标签页，即可看到多个应用正处于部署过程中。

验证 BookKeeper 组：bookie 与自动恢复

在父级pulsar组下点击进入bookkeeper子组，即可监控 BookKeeper 集群的部署状态。

此时 3 个 bookie 的状态应显示为绿色，表示 bookie 已成功部署并正在运行。你可以点击进入任意 bookie 实例查看更详细的信息，例如 bookie 的运行日志。

若想通过 ZooKeeper 查看 BookKeeper 的注册信息，可访问http://m1.dcos/exhibitor（DC/OS 自带的 Exhibitor 界面）。在本示例中，available目录下可以看到 3 个 bookie 的注册节点——这意味着 BookKeeper 集群已经完成选主并进入可用状态。

从源码层面看，bookie 是 Pulsar 存储层 Apache BookKeeper 的服务端（相关存储概念如 Ledger 的定义见 reference-terminology.md），DC/OS 的 bookkeeper 组同时部署的 bookie recovery 实例则负责在 bookie 故障后自动执行 ledger 修复，这是 Pulsar 数据高可用的关键机制。

验证 broker 组：负载均衡与 managed-ledgers

与 BookKeeper 组类似，点击brokers子组即可查看 Pulsar broker 的运行状态。

3 个 broker 全部变为绿色即表示部署成功。同样可以点入每个 broker 实例查看运行日志。

通过 Exhibitor 的 Web UI 也可以查看 broker 集群在 ZooKeeper 中的注册信息。本示例中可以看到loadbalance（负载均衡）和managed-ledgers（受管 ledger 元数据）目录已经创建，说明 broker 已经完成初始化并向 ZooKeeper 注册了自身的负载均衡与 ledger 管理状态。这些目录正是 Pulsar broker 无状态扩展与 BookKeeper 存储协作的元数据基础：managed-ledgers记录 topic 到 ledger 的映射，loadbalance记录 broker 之间的负载分布。

broker 对外提供消息服务的端口默认是 6650（brokerServicePort=6650），HTTP 管理接口默认 8080（webServicePort=8080），这些默认值定义于 broker.conf，后续客户端连接会用到 6650 端口。

监控组：Prometheus 与 Grafana

monitory组由 Prometheus 和 Grafana 两个实例组成，为集群提供指标采集与可视化。

Prometheus

点击prom实例可以获取 Prometheus 的访问端点，本示例为192.168.65.121:9090。访问该端点可看到 Prometheus 自带的 Dashboard，其中http://192.168.65.121:9090/targets页面会列出所有被抓取的采集目标——本示例中所有 bookie 和 broker 都已出现在 targets 列表中，说明指标抓取链路已打通。

Grafana

点击grafana实例可以获取 Grafana 的访问端点，本示例为192.168.65.121:3000。访问该端点即可进入 Grafana 仪表盘，Pulsar 的指标（如消息吞吐、延迟、积压等）会以可视化图表呈现。

端到端验证：在 DC/OS 上运行 Producer 与 Consumer

集群就绪后，可以通过一个简单的 Java 客户端示例验证 Pulsar 在 DC/OS 上真正工作。

克隆并准备 Pulsar Java 教程

从 Pulsar 社区提供的教程仓库中克隆示例代码：

$ git clone https://github.com/streamlio/pulsar-java-tutorial

该仓库包含一个简单的 Pulsar consumer 和 producer（更详细的信息见仓库 README）。

修改 SERVICE_URL 指向 DC/OS 中的 broker

将ConsumerTutorial.java与ProducerTutorial.java两个文件中的SERVICE_URL从默认的pulsar://localhost:6650改为：

pulsar://a1.dcos:6650

其中pulsar://a1.dcos:6650是 broker 服务端点：a1.dcos是运行了 broker 的 DC/OS 客户端 agent 主机名（也可以用该 client agent 的 IP 地址直接替换），6650即上文提到的 broker 消息服务端口。每个 broker 实例的端点详情都可以从 DC/OS GUI 中获取。

调整消息数量并编译

教程示例中 producer 默认只发送 10 条消息，为了方便观察，将ProducerTutorial.java的 main 方法中的消息数量从 10 改为 10000000，随后编译项目：

$ mvn clean package

运行 consumer 与 producer

分别执行以下命令启动 consumer 和 producer：

# 运行 consumer $ mvn exec:java -Dexec.mainClass="tutorial.ConsumerTutorial" # 运行 producer $ mvn exec:java -Dexec.mainClass="tutorial.ProducerTutorial"

运行后通过 DC/OS GUI 即可观察到 producer 持续生产消息、consumer 持续消费消息。这里依赖的正是 Pulsar 客户端基于二进制协议与 broker 的 6650 端口通信（见 client.conf 中brokerServiceUrl=pulsar://localhost:6650/的默认形态，DC/OS 场景只需把 localhost 换成 agent 主机名）。

查看 Grafana 指标输出

在 producer 与 consumer 运行期间，打开 Grafana 即可看到实时的运行指标——包括消息生产/消费速率、积压量等，用于直观验证消息链路吞吐。

卸载 Pulsar

随时可以通过以下两种方式关闭并卸载 DC/OS 上的pulsar应用：

1. 通过 DC/OS GUI：在 Pulsar 组的右侧点击操作菜单并选择Delete；
2. 通过命令行：

$ dcos marathon group remove /pulsar

Marathon 应用组的删除语义会递归地停止并清理组内所有应用（bookie、broker、监控实例），实现一次性完整下线。

结合仓库源码：镜像、端口与配置注入机制

DC/OS 部署中的容器镜像与配置逻辑在仓库中均有对应实现，理解它们有助于在PulsarGroups.json中做更细粒度的定制：

• 镜像选择：DC/OS 部署默认使用apachepulsar/pulsar镜像；如果希望在部署中启用全部内置 Pulsar IO connector（如各类 source/sink），则应改用apachepulsar/pulsar-all镜像，后者已内置打包所有内置 connector。Pulsar 镜像的构建定义见 docker/pulsar/Dockerfile 与 docker/pulsar-all/Dockerfile。
• 配置注入：从 docker/pulsar/scripts/ 下的脚本（如apply-config-from-env.py、apply-config-from-env-with-prefix.py、gen-yml-from-env.py）可以推断，镜像启动时会通过环境变量批量改写 broker/standalone 等配置文件——这正是 Marathon 应用组定义中通过env字段按实例定制 broker、bookie 参数的底层机制，也是PulsarGroups.json中各组配置生效的原理。
• 端口默认值：broker 消息端口 6650、HTTP 端口 8080 的默认定义位于 broker.conf；代理（proxy）的 6650 服务端口见 proxy.conf。在 DC/OS 中修改这些端口时，需要同时同步调整PulsarGroups.json中的容器端口映射与客户端SERVICE_URL。

综上，DC/OS 为 Apache Pulsar 提供了一条高度自动化的交付路径：以 Marathon 应用组统一编排 BookKeeper、broker 与监控组件，复用 DC/OS 内置 ZooKeeper，配合镜像环境变量注入实现参数化配置。掌握本文的部署、验证、端到端联调与卸载流程，即可在生产环境中快速复制出一套可观测、可运维的 Pulsar 集群。

• 消息队列
• 后端
• 流处理