关于 RTP/AVPF 的简单讨论
2025/12/31 16:46:27
本文是「架构师的技术基石」系列的第1-2篇。查看系列完整路线图与所有文章目录：【重磅系列】架构师技术基石全景图：以「增长中台」贯穿16讲硬核实战
当所有功能看起来都相互关联时，划分服务边界的依据不是技术实现的方便，而是业务变化节奏的共鸣与数据亲缘关系的强弱
01 当“单体巨兽”开始低吼
在上一篇文章中，我们与产品团队一起为“智能用户增长中台”绘制了第一张战略草图。团队充满热情，大家都认同这是一个由多个相对独立模块组成的复杂系统。
然而，当真正开始详细设计时，分歧出现了。
后端工程师小李看着模块图提议：“‘用户画像服务’和‘实验分流服务’都重度依赖用户数据，而且QPS都很高，不如合并成一个‘用户核心服务’，减少网络调用，代码也更好组织。”
话音刚落，负责算法的王博士立刻反对：“不行！我们的实验策略迭代非常频繁，几乎每天都要更新规则和模型。如果和相对稳定的画像服务绑在一起，每次发布都要担心影响画像的稳定性。”
数据工程师小张也加入讨论：“还有实时事件处理呢？用户行为事件需要实时更新画像，但实验分流只需要读取快照。它们的读写模式完全不同……”
会议室里的白板上，原本清晰的方框被各种箭头和连线覆盖，大家开始争论哪些功能应该放在一起，哪些应该拆开。
这是每个架构师在系统设计中期都会遭遇的经典困境：当所有功能看起来都相互关联时，如何划分服务边界才是“正确”的？
今天，我将分享一套在多个百万人级系统中验证过的服务边界划分框架。我们将继续沿用“智能用户增长中台”这个案例，看看如何有理有据地做出这些关键决策。
02 一个被忽视的真相：软件变更是有“频率”的
2.1 变更频率错配：最隐蔽的架构毒素
让我们先审视“智能用户增长中台”的几个核心功能模块及其变更特点：
| 功能模块 | 典型变更类型 | 变更频率 | 影响范围 |
|---|---|---|---|
| 用户画像计算 | 算法模型更新、标签规则调整 | 中等（每周/每月） | 影响所有依赖用户特征的下游服务 |
| 实验分流引擎 | 实验规则配置、流量分配调整 | 极高（每天多次） | 仅影响实验参与用户 |
| 内容推荐策略 | 推荐算法、排序规则、过滤条件 | 高（每天/每周） | 影响特定场景的内容曝光 |
| 触达通道适配 | 对接新渠道、协议变更、模板更新 | 低（每月/每季度） | 仅影响特定触达方式 |
| 数据统计看板 | 指标计算逻辑、维度调整 | 中等（每周） | 影响数据分析结果 |
发现关键问题了吗？
实验分流引擎需要每天多次在线更新，而用户画像计算的模型更新可能每周一次。如果将它们放在同一个服务中，每次实验调整都需要重新部署整个“用户核心服务”——这意味着画像计算的稳定性会不必要地承受风险。
这就是变更频率错配：将变化节奏完全不同的功能耦合在一起，导致“牵一发而动全身”。
2.2 “变更共鸣”作为第一分割原则
我们的第一条边界划分原则由此诞生：
将变更频率相似的功能放在同一个服务内，将变更频率差异巨大的功能分离到不同服务。
基于此原则，我们可以立即做出几个关键决策：
实验分流服务必须独立：它的高频变更特性决定了它需要独立的部署流水线、更敏捷的发布策略和专门的监控告警。
用户画像服务独立存在：虽然多个服务依赖它，但其自身变更节奏稳定，适合作为相对稳定的“基础设施”服务。
内容推荐策略可独立或与实验服务合并：两者都有较高的变更频率，且都服务于“给用户展示什么”这一核心决策链条。
03 数据亲缘性：谁和谁“真正”在一起？
3.1 识别真正的数据共同体
变更频率不是唯一考量。让我们从数据视角再次审视这些功能：
从数据流图中可以发现几个关键模式：
- 实验分流、推荐策略、触达决策这三个服务频繁交互，共享用户实时上下文，共同完成“决策链”。
- 用户画像存储被多个服务读取，但写入口单一（实时/批量画像更新）。
- 实验指标和内容效果数据虽然都源于用户行为，但用于完全不同的分析场景。
3.2 “数据亲密程度”作为第二分割原则
我们的第二条边界划分原则是：
将共享相同数据实体、读写模式相似、事务一致性要求相同的功能放在一起；将数据模型独立、访问模式迥异的功能分开。
应用这一原则：
实验分流 + 推荐策略 + 触达决策：这三个服务构成了一条完整的“决策执行链”。它们需要共享用户的实时会话上下文，对延迟极其敏感，可以组成一个“决策服务集群”，甚至可以考虑合并为一个服务或使用进程内调用优化性能。
用户画像服务独立：它管理的是用户的长期状态，数据模型稳定（用户-标签关系），读写模式明确（写少读多），适合独立。
分析看板服务独立：它们处理的是结果数据，面向的是离线分析场景，与实时决策链路完全解耦。
04 团队认知负荷：服务边界要匹配“脑力容量”
4.1 两个警示案例
案例一：某公司将“用户账户服务”和“用户权限服务”合并，因为“它们都处理用户数据”。结果，负责该服务的团队需要同时理解金融级别的账户安全模型和复杂的企业RBAC权限模型，新成员上手需要6个月以上，团队生产力持续低下。
案例二：另一个团队将“订单服务”拆得过细，分成订单创建、订单支付、订单履约等8个微服务。团队5名工程师需要同时维护8个代码库，每天在各种服务间的协调和调试中疲于奔命。
4.2 “认知边界”作为第三分割原则
第三条原则关注人类的心智模型：
一个服务的领域概念应该能在2分钟内向新成员解释清楚；一个团队应该能专注于不超过3个核心服务。
对于我们的增长中台，可以这样划分团队认知边界：
- 团队A（用户理解组）：专注于
用户画像服务，深入理解用户特征工程、标签体系、实时计算。 - 团队B（决策引擎组）：专注于
实验分流服务+推荐策略服务，精通A/B测试理论、推荐算法、实时决策。 - 团队C（触达与效果组）：专注于
触达通道服务+数据看板服务，掌握各渠道技术对接、效果分析、数据可视化。
每个团队都有清晰的关注点，专家可以深耕自己的领域。
05 决策框架：四维评分卡
现在，我们有了一个完整的决策框架。当面临“功能X和Y是否应该放在一起”的问题时，可以使用这个四维评分卡：
| 评估维度 | 问题 | 同服务得分 | 不同服务得分 |
|---|---|---|---|
| 变更频率 | 两者的变更节奏是否相似？ | +2 | 0 |
| 数据亲密度 | 是否共享核心数据实体？读写模式是否相似？ | +2 | -1 |
| 团队认知 | 领域知识是否高度相关？能否被同一团队高效掌握？ | +1 | 0 |
| 性能需求 | 是否对延迟有同样极致的需求？是否需要频繁交互？ | +1 | -1 |
计分规则：计算同服务得分与不同服务得分的差值。如果差值≥2，倾向于合并；如果差值≤-2，倾向于拆分；在中间区间，则根据具体上下文判断。
让我们用这个评分卡评估几个关键决策：
决策1：实验分流 vs 用户画像
- 变更频率：不同（每天多次 vs 每周一次） → 同服务0，不同服务0
- 数据亲密度：实验依赖画像，但画像独立 → 同服务0，不同服务0
- 团队认知：领域知识不同（实验方法论 vs 用户建模）→ 同服务0，不同服务0
- 性能需求：实验需要毫秒级响应，画像查询可接受稍高延迟 → 同服务-1，不同服务+1
- 总分：同服务-1 vs 不同服务+1 →差值-2，明确拆分
决策2：实验分流 vs 推荐策略
- 变更频率：相似（都高） → 同服务+2，不同服务0
- 数据亲密度：高度共享用户实时上下文 → 同服务+2，不同服务-1
- 团队认知：高度相关（都是决策逻辑）→ 同服务+1，不同服务0
- 性能需求：都要求毫秒级响应 → 同服务+1，不同服务-1
- 总分：同服务+6 vs 不同服务-2 →差值+8，强烈建议合并或紧耦合
06 实战：为增长中台划定最终边界
基于以上分析，我们为“智能用户增长中台”划定了最终的服务边界：
智能用户增长中台 ├── 用户画像服务 (独立，变更稳定，数据模型清晰) ├── 决策引擎服务 (合并：实验分流 + 推荐策略 + 触达决策，高频变更，强数据亲和) ├── 触达通道适配服务 (独立，对接外部渠道，变更节奏不同) ├── 实验分析看板服务 (独立，分析导向，数据模型独立) └── 实时事件处理管道 (独立，基础设施性质)每个服务都有明确的：
- 变更节奏：决定了发布策略和部署流水线
- 数据模型：决定了存储选择和API设计
- 团队归属：决定了沟通结构和技术栈选择
- 性能SLA：决定了技术选型和容量规划
07 总结：好的边界让复杂性可控
服务边界划分没有绝对的“正确”答案，但有好坏之分。好的边界：
- 隔离变化：一个领域的变化不会像多米诺骨牌一样波及无关领域
- 匹配认知：让团队能在自己擅长的领域深耕，建立真正的专家经验
- 优化数据流：让高频交互的服务紧耦合，让独立数据的服务松耦合
- 适应演进：当业务需求变化时，能够相对平滑地调整边界，而不是推倒重来
回到最初的问题：“凭什么功能A和B不能放在一个服务里？”现在我们可以回答：当它们的变更节奏、数据生命、团队心智和性能要求存在根本性差异时，强行放在一起就是为未来的技术债务埋下伏笔。
下一次当你面对服务边界的选择时，不妨拿出这份四维评分卡。它不能替你决策，但能帮你理解决策背后的权衡，让架构设计从“我觉得”走向“有依据”。
思考与实践：回顾你当前正在维护的系统，用四维评分卡分析一个你认为可能存在边界问题的服务。如果重新划分，你会如何调整？这样的调整会带来什么好处和成本？