业务背景

经过公司上下努力，IM 业务蒸蒸日上，数据增长很快，用户活跃数量在短短1年多的时间里面已经上升到60多万了，很快就要迈上百万大关了，你作为公司 CTO，前瞻性的预判到业务发展给技术带来了挑战，于是准备启动架构演进。

【公司背景变化】

1. 技术团队从10人增长到30人，后端18个，前端4个，Android4个，iOS 4个。

2. 公司招聘了2名增长黑客数据分析师，希望能够从数据里面挖掘更多用户痛点和需求。

业务基本场景

1. 每个用户都会通过算法生成非对称的公钥和私钥；

2. 用户发送的消息会通过公钥加密，接收用户的消息使用自己的私钥解密；

3. 只能创建一对一聊天；

4. 聊天消息“阅后即焚”，最多只保留60分钟；

5. 无需使用手机号注册；

6. 每个用户最多20个好友；

7. 增加群聊功能，每个私密群聊限制人数为5人。

总体架构思路

来自老板的两大挑战应对技巧

挑战1：纳尼，这么快就要架构演进？

1. 说明当时的业务不确定性；

2. 说明当时的技术团队规模；

3. 演进的驱动力是业务快速发展；

4. 业务快速发展是老板的英明。

挑战2：为什么不直接做千万或者亿级架构，这样不就可以一劳永逸了么？

1. 团队规模（“30~100人，按照百万规模设计最好”）；

2. “得加钱”：直接设计千万级别架构要很多钱（多机房、异地多活等）；

3. 业务规模可以预测，但是业务复杂度不太好预测（例如：会不会支持比特币支付？）

百万用户规模存储性能估算

【注册】

百万用户注册信息。

【登录】

百万注册用户，每天活跃用户有40%，登录时读取用户信息是每天40万QPS。

【加好友】

每个活跃用户最多20个好友，好友关系数 40万 * 20 = 800万数据。

【聊天】

假设每个活跃用户每天向5位好友发送100条消息，则消息数量为：40万

* 5 * 100 = 2亿，且数据当天基本都被删除了，所以写入 + 读取 + 删除 =

6亿。

【群聊】

假设活跃用户中有10%的用户发起群聊，平均每人每天2个，每个群聊每

天200条消息。

• 消息写入：40万 * 10% * 2（群聊） * 200（消息） = 1600万数据；

• 消息删除次数：等于消息写入数量；

• 消息读取量：1600万 * 5（每个群最多5人） = 8000万/天。

存储架构设计

百万用户规模计算性能估算

【注册】

每日新注册用户不到1万，可以忽略。

【登录】

虽然 IM 是比较活跃的产品，但由于是全新的产品，我们假设百万注册用户，每天活跃用户有40%，假设登录时间集中在早晚4小时，登录 TPS 均值：40万 / 14400 = 30。

【加好友】

每个活跃用户最多20个好友，好友关系数 40万 * 20 = 800万数据，按照1年内来计算，TPS 可以忽略不计。

计算架构之负载均衡

计算架构之负载均衡 - 架构重构

计算架构之缓存架构

可扩展架构设计 - 微服务拆分

高可用架构设计 - 同城双中心

大数据架构设计

架构要解决的核心复杂度

十万：快速验证（核心需求）

百万：快速扩展（辅助需求）

十万用户架构 vs 百万用户架构