architecture-paradigm-pipeline

流水线（管道与过滤器）范式

何时采用此范式

• 当数据必须流经一系列固定的离散转换时，例如 ETL 作业、流式分析或 CI/CD 流水线。
• 当需要复用各个处理阶段时，无论是单独复用，还是将瓶颈阶段与其他阶段分开扩容。
• 当阶段之间的故障隔离是关键要求时。

何时不应采用

• 交互式请求/响应系统（请使用 archetypes:architecture-paradigm-client-server）
• 必须共享可变状态的阶段，因为此模式无法表达这种情况

采用步骤

1. 定义过滤器：设计每个阶段（过滤器），使其执行单一且定义明确的转换。每个过滤器都必须有明确的输入和输出数据架构。
2. 通过管道连接：使用“管道”连接过滤器，管道可通过流、消息队列或内存通道实现。验证这些管道支持背压和缓冲。
3. 保持过滤器无状态：尽可能将过滤器设计为无状态。任何必需的状态都应持久化到外部，或在流水线边界进行管理。
4. 为每个阶段添加监控：为每个过滤器实现监控，以跟踪延迟、吞吐量和错误率等关键指标。
5. 协调部署：设计部署策略，以便每个阶段都能单独横向扩展并独立升级。

关键交付成果

• 一份架构决策记录（ADR），记录过滤器、选定的管道技术、错误处理策略以及用于重放数据的工具。
• 一套针对每个过滤器的契约测试，以及覆盖具有代表性的端到端流水线执行的集成测试。
• 用于展示各阶段关键绩效指标（KPI）的可观测性仪表板。

风险与缓解措施

• 单阶段瓶颈：
  • 缓解措施：为各个过滤器实现自动扩缩容。如果某个过滤器持续成为瓶颈，请考虑将其拆分为更细粒度的子流水线。
• 阶段间架构漂移：
  • 缓解措施：在共享代码库中集中管理架构定义，并在 CI/CD 流程中强制执行兼容性测试，以防止引入破坏性变更。
• 背压失效：
  • 缓解措施：进行严格的负载测试，模拟高流量场景。验证缓冲、重试逻辑和背压机制在压力下能否按预期运行。

具体组件

此范式的实现通常包含的工具和抽象的术语。不属于依赖项，也不是 tools: 前置元数据。

• stream-processor：执行过滤器的运行时（例如 Flink、Apache Beam、Faust）
• message-queue：过滤器之间的持久化管道（例如 Kafka、RabbitMQ、内存通道）
• data-validator：在每个过滤器的输入和输出处检查架构

退出标准

• ADR 记录流水线中的每个过滤器、选定的管道技术、错误处理策略（DLQ、重试次数、死信路由）以及数据重放机制。
• 每个过滤器都有覆盖其输入和输出架构的契约测试；相邻过滤器之间的架构漂移会由 CI 兼容性检查发现。
• 在流水线升级到生产环境之前，已配置可观测性仪表板，展示各阶段的延迟、吞吐量和错误率。
• 负载测试验证背压和缓冲机制能在达到预期峰值吞吐量的 2 倍时防止数据丢失。