流处理框架对比 = 重量级 vs 轻量级

解决什么问题：不知道该选 Kafka Streams 还是简单消费者—— 重量级框架功能强但运维重，轻量级框架简单但功能弱。

业务问题

真实场景

场景 1：实时订单统计

需求：
  - 每分钟统计订单数
  - 按地区分组
  - 实时仪表板展示

选项 A：Kafka Streams（重量级）
  - 强大算子（窗口/聚合/join）
  - 状态管理内置
  - 但需要 Streams cluster
  
选项 B：简单消费者 + Redis（轻量级）
  - 自己实现窗口
  - 自己管理状态
  - 但简单、灵活

Bellemare Ch 11/12 原话：

"Heavyweight frameworks... Spark and Flink... Lightweight frameworks... leverage the event broker and the container management system."

失败模式

失败模式	后果
过度工程	用重量级做简单事
低估运维	重量级部署困难
低估功能	轻量级做不到复杂逻辑

控制论视角

Ch 4 §4.6："反馈环路复杂度匹配" + Ch 6 §6.3："解耦"

重量级 = 控制律内置（自带 cluster）
轻量级 = 控制律外置（依赖 broker + CMS）

选择 = 业务复杂度 vs 运维复杂度

核心概念

重量级 vs 轻量级

维度	重量级	轻量级
Cluster	独立	无
状态管理	框架内置	broker + CMS
算子能力	强	中
部署复杂度	高	低
学习曲线	陡	平缓
性能	高	中
伸缩	框架	CMS

重量级框架

例子：Kafka Streams / Flink / Spark Streaming / Google Dataflow

特征：
  - 自带 cluster 管理
  - 状态管理自动化
  - 容错自动化
  - 复杂算子（窗口/join/聚合）

适用：
  - 大规模数据
  - 复杂流处理（多 join/窗口）
  - 低延迟（毫秒级）
  - 状态大的服务

不适用：
  - 简单 ETL
  - 小规模
  - 快速迭代

轻量级框架

例子：BPC / 简单消费者库

特征：
  - 无独立 cluster
  - 状态管理靠 broker（changelog）
  - 扩缩容靠 CMS（K8s）
  - 框架只负责业务逻辑

适用：
  - 简单转换
  - 快速迭代
  - 小到中等规模

不适用：
  - 复杂算子需求
  - 大状态
  - 极低延迟

决策矩阵

决策树：
  1. 业务算子复杂度？
     - 简单（filter/map） → 轻量级
     - 复杂（join/窗口/聚合） → 重量级
  2. 状态大小？
     - < 1GB → 轻量级
     - > 10GB → 重量级
  3. 延迟要求？
     - > 100ms → 轻量级
     - < 10ms → 重量级
  4. 团队熟悉度？
     - 熟悉 K8s → 轻量级
     - 熟悉 Flink → 重量级

工程实践

实战 1：何时升级到重量级

触发条件：
  - 业务开始有 join/窗口需求
  - 状态增长到 GB 级
  - 延迟要求 < 100ms
  - 团队有 Flink 经验
  
路径：
  1. 先用 BPC 实现简单版本
  2. 业务复杂后引入 Kafka Streams
  3. 进一步复杂后升级 Flink

实战 2：避免常见错误

错误 1：一开始就用重量级
  - 部署复杂、调试困难
  - 业务还没想清楚
  - 改架构代价大

错误 2：用轻量级做复杂事
  - 自己实现窗口/聚合
  - 容易出 bug
  - 性能差

错误 3：混用
  - 部分服务用 Flink，部分用 BPC
  - 运维负担

反模式 vs 正模式

反模式	正模式
一开始就 Flink	先 BPC → 按需升级
BPC 做 join	用 Kafka Streams
状态在应用内存	状态在 RocksDB/外部 DB
无 changelog	启用 changelog

性能指标

维度	重量级	轻量级
部署时间	数小时-数天	数分钟
运维复杂度	高	低
延迟（p99）	< 100ms	< 500ms
吞吐	> 100K/s	< 50K/s

边界判断

何时用重量级

• 复杂流逻辑
• 大状态
• 低延迟
• 大规模数据

何时用轻量级（默认）

• 简单转换
• 中小规模
• 快速迭代
• 团队不熟悉重量级

何时升级/降级

当前	升级到	触发条件
轻量级	重量级	业务复杂
重量级	轻量级	业务简单化

关键洞察

1. 重量级是"专业工具"，轻量级是"通用工具"——选择看场景。
2. 不要过度工程——80% 场景轻量级足够。
3. 演进路径——轻量级 → 重量级 是自然升级。
4. 运维成本常被低估——重量级需要专门团队。
5. 与 cybernetics 同构——重量级 = 内置控制律（自带 cluster），轻量级 = 外置控制律（依赖 broker）。