IM专题：服务化架构IM系统（3）— 子母号

IM 系统中的 “子母号” 是 C2B 的一类典型应用，即C端用户欲与B端商家进行通信时，B端的母号会为其分配一个子号与C端用户进行聊天。

单纯设计子母号实现方案并不复杂，关键是需要兼容普通的C2C聊天方案，尽量做到方案统一和功能复用。

回顾一下，C2C聊天方案中的消息存储方式（见IM专题：分层架构IM系统（10）—Das领域模型设计）：为了实现消息的定制化需求，采用 “写扩散” 模式对消息进行存储，即用户每发一条消息，站在消息发送方与消息接收方的维度分别存储一条记录，如下图。

用户 uid=101 发送消息 “你好！” 给用户 uid=102，在消息表中存储如上两条记录，通过 direction 字段表征哪个 uid 是发送方或接收方。

这种 “写扩散” 的存储方式，除了可以满足不同用户对同一条消息的不同定制化需求外，更重要的是当数据规模很大需要分表时，以 to_uid 作为分表字段后，同一用户的所有聊天记录会全部落在同一张表中，避免了对所有数据表遍历的低效操作。

子母号消息方案需要与上述方案做到最大化同一，以保证功能逻辑的独立和复用。

分析一下 IM 系统中子母号应用的需求模型，如下图。

子母号应用中有三类用户：C端用户、B端母号、B端子号，假设 C 端用户 uid=101，B 端母号 uid=1000，B端子号分别是 uid=1001，uid=1002，uid=1003。

用户 uid=101与母号 uid=1000通信时，母号根据策略分配一子号 uid=1001 与用户 uid=101 进行聊天。站在用户 uid=101 的角度看，与他聊天的是母号，展示的是母号的头像，但实际是子号 uid=1001 与用户 uid=101 完成的聊天过程；从业务分析来说，这是合理的，B端商家的老板以统一的形象展示在所有 C 端用户面前，当然真正干活的肯定是B端商家老板的员工子号。那么站在子号 uid=1001的角度看，与他聊天的就是用户 uid=101，母号 uid=1000只是对外的。

简单总结一下子母号需求模型：用户 uid=101 的联系人是母号 uid=1000，子号 uid=1001 的联系人是用户 uid=101；母号 uid=1000 是一个虚拟用户，不参与实际聊天，但是 B 端的商家老板，可以通过母号 uid=1000 能查询到其所有的子号与用户的聊天记录（毕竟老板有时会检查工作嘛）。

至此，问题描述就很清晰了：既要满足子母号的需求模型，又要与 C2C 的实现方案保持兼容和统一，子母号实现方案应该如何进行设计呢？

我们先把关键要点列一下：