Collector 架构 · 管道其实是一张图

前三个是“数据面”，后两个值得单说：

• connector —— 它同时是某条管道的 exporter 和另一条管道的 receiver。经典用途：spanmetrics connector 从 traces 生成 RED 指标（不用你在应用里再埋一遍！）。这正是“管道是图而不是线”的直接证据——connector 让管道之间连起来，形成了图。
• extension —— 不参与数据流，提供“周边能力”。健康检查端点、认证器、性能分析。把它们独立成一类，是为了让数据面组件保持纯粹——receiver/processor/exporter 只管数据，不管这些横切关注点。

三步走：

1. createNodes —— 把配置里的每个组件变成图的一个节点。同时校验 connector（它连接的两条管道类型对不对）。
2. createEdges —— 按管道配置连边：receiver → processor → processor → exporter。多条管道共用同一个 receiver 时，边会分叉——图就是这么长出来的。
3. buildComponents —— 拓扑排序，然后按反序实例化每个组件。

为什么需要图而不是简单的链表？看几个真实场景：

pipelines:
  metrics/1:
    receivers: [otlp]        # ← 同一个 receiver
    exporters: [prometheus]
  metrics/2:
    receivers: [otlp]        # ← 被两条管道共用 → 扇出!
    exporters: [datadog]
  traces:
    receivers: [otlp]
    exporters: [jaeger, spanmetrics]   # ← connector,输出又流进 metrics 管道

一个 receiver 喂多条管道（扇出）、一个 connector 把 traces 接到 metrics（跨管道）——这已经是一张图了，不是几条独立的线。 用图来建模，这些场景就都是自然的；用链表建模，你得为每个场景打补丁。

启动：从下游往上游（反拓扑序）。停止：从上游往下游（拓扑序）。

管道:  receiver → processor → exporter

启动:  exporter → processor → receiver     ← 反着来!
停止:  receiver → processor → exporter     ← 正着来

为什么必须这样？两条注释各给了理由：

• 启动反着来 —— “ensures that each component's consumer is ready to consume”。如果先启动 receiver，它立刻开始收数据，然后往下游推——但下游的 exporter 还没启动！数据无处可去，要么丢、要么报错。先把下游准备好，再打开水龙头。
• 停止正着来 —— “each component has a chance to drain to its consumer before the consumer is stopped”。先停 receiver（不再进新数据），然后管道里的存量数据可以排空（drain）到下游；如果先停 exporter，那些还在 processor 里排队的数据就没地方去了 → 丢数据。

这是“优雅启停”的教科书实现，而且它的正确性完全依赖拓扑排序——只有知道了组件的依赖顺序，才能反着启、正着停。这就是“为什么要用图”的最硬的理由：不只是为了表达扇出，更是为了能算出正确的启停顺序。

这个模式可以直接偷到别处用：任何“数据流经多个阶段”的系统（消息管道、ETL、流处理），启停顺序都该是这个规律。 很多人写这类系统时随手按配置顺序启停，然后在关闭时莫名其妙丢数据——根因就是这个。

注意 Service.Start 里那个四步顺序——extension 先启动、且在管道就绪后还会被通知一次。这是为了让健康检查这类 extension 能正确反映“管道到底准备好了没”：如果健康检查在管道启动前就返回 OK，k8s 会过早把流量打进来。“先起辅助设施 → 起数据面 → 再告诉辅助设施'可以了'” ——这个三段式在很多服务框架里都能见到。

官方文档点名：“Each component type contains a Factory interface along with its corresponding NewFactory function.”

每类组件都有工厂，新组件通过 NewFactory 注册自己：能处理哪些信号类型（traces/metrics/logs）、默认配置是什么、怎么创建实例。

文档里还提了个关键点：“the Collector uses this interface to give receivers a handle to a nextConsumer - which represents where the receiver will send its data next in its telemetry pipeline.”

nextConsumer 是理解整个数据流的钥匙：每个组件不知道下游是谁，它只拿到一个 consumer 接口，往里塞数据就完事。下游是什么、有几个，由图在构建时注入。 下一章讲 pdata，再下一章讲这个 consumer 接口。

这是依赖注入 + 面向接口的标准实践，也是为什么 Collector 能有几百个社区组件而核心保持稳定——核心只认接口，不认具体实现。这和第 1 部分 Prometheus 的 storage.Appender、Discoverer 接口是完全一样的思路。