您知道十万级用户到亿级用户系统架构是如何演进的吗？

一、《十万级用户》

【业务背景】

假设你现在正在一个创业公司担任 CTO，因为微信工作生活娱乐不区分，已经发生了很多次将敏感信息发错人甚至发错群的尴尬事件了！你司 CEO 决定做一款 IM 工具，为了区别微信和 QQ 大众化的 IM 需 求，你们公司主打安全 IM，这款产品的竞争力如下： 主打私密聊天，严格控制私密好友的数量，而不是像微信一样，买个菜都可能要加个微信

【公司背景】

1. 技术团队大约10个人，后端6个，前端2个，Android 2个，iOS 还没有；

2. 后端 Java 为主，大部分是 P6~P7；

3. 后端具备 MySQL、微服务、Redis 等开发使用经验；

4. 后端没有大数据和推荐相关经验。

1.存储架构设计==》

【存储性能估算】

功能	数据量
注册	十万用户注册信息
登录	虽然 IM 是比较活跃的产品，但由于是全新的产品，我们假设十万注册用户，每天活跃用户有40%，登录每天4万
加好友	每个活跃用户最多20个好友，好友关系数 4万 * 20 = 80万 关系数据
聊天	假设每个活跃用户每天向5位好友发送100条消息，则消息数量为：4万 * 5 * 100 = 2000万，且数据当天基本都被删除了， 所以写入、读取、删除次数都可以估算为 2000万 。

【存储架构设计如下】

2.计算架构设计==》

【计算性能估算】

功能	数据量
注册	1年达到十万用户注册，注册 TPS 很低。
登录	虽然 IM 是比较活跃的产品，但由于是全新的产品，我们假设十万注册用户，每天活跃用户有40%，假设登录时间集中在早晚4小时，登录 TPS 均值：4万 / 14400 = 3。
加好友	每个活跃用户最多20个好友，好友关系数 4万 * 20 = 80万数据，按照1年内来计算，TPS 可以忽略不计。
聊天	假设每个活跃用户每天向5位好友发送100条消息，则消息数量为：4万 * 5 * 100 = 2000万; 假设每天集中在早中晚3个时间段6小时内（早上1小时中午1小时晚上4小时）； • 发送消息 TPS：2000万/（3600*6）≈ 1000； • 读取消息 QPS = 发送消息 TPS，删除消息 TPS ≈ 发送消息 TPS

【计算架构之负载均衡】

3.可扩展架构设计==》

选择方案1或者方案2都行，方案3拆得过细，反而增加了系统内部复制度，日志的链路追踪，服务降级、熔断、分布式事务都大大增加了内部复杂度、所以微服务不是拆得越细越好，要符合业务发展才是最好的解决方案！

4.高可用架构设计==》

 附：MySQL主备夸机房复制就行、Redis不用做夸机房复制、因为储存数据有有效期的。

5.存储架构&计算架构&高可用架构汇总如下表==》

二、《百万用户》

【业务背景】

经过公司上下努力，IM 业务蒸蒸日上，数据增长很快，用户活跃数量在短短1年多的时间里面已经上升到60多万了，

很快就要迈上百万大关了，你作为公司 CTO，前瞻性的预判到业务发展给技术带来了挑战，于是准备启动架构演进。

【公司背景变化】

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

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

1.存储架构设计==》

功能	数据量
注册	100万用户注册信息
登录	百万注册用户，每天活跃用户有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万/天。

 

注意：这里redis 用到分片、为啥不用数据读写分离、因为数据量都过亿了、需要通过分片进行数据分布式存储！

2.计算架构设计==》

功能	数据量
注册	每日新注册用户不到1万，可以忽略
登录	虽然 IM 是比较活跃的产品，但由于是全新的产品，我们假 设百万注册用户，每天活跃用户有40%，假设登录时间集 中在早晚4小时，登录 TPS 均值：40万 / 14400 = 30
加好友	每个活跃用户最多20个好友，好友关系数 40万 * 20 = 800 万数据，按照1年内来计算，TPS 可以忽略不计
聊天	假设每个活跃用户每天向5位好友发送100条消息，则消息数量为： 40万 * 5 * 100 = 2亿，假设每天集中在早中晚3个时间段6小时内 （早上1小时中午1小时晚上4小时），TPS 计算为：2亿/（3600*6） * 3（发+收+删） ≈ 30000
群聊	假设活跃用户中有10%的用户发起群聊，平均每人每天2个，每个群 聊每天200条消息，时间段分布和聊天场景一样。 • 消息写入和删除次数：40万 * 10% * 2 *200 * 2（写+删） / （3600*6） = 1600 TPS； • 消息读取量：1600 TPS * 5（每个群最多5人） = 8000 QPS

如何用户从100万涨到300万、1000万以内、那么需要做架构演进、Nginx替换Lvs原因参见：Lvs & Nginx 对比？_Thomas.Sir的博客-优快云博客

3.可扩展架构设计==》

4.高可用架构设计==》

5.大数据架构设计==》

技术选型	选择理由
hadoop/spark	1. 功能强大，可扩展性强；2. 较复杂数据分析师不会用；
clickhouse	1. 兼容 SQL，维护使用简单；2. 性能强劲，OLAP 分析平台

根据当前的业务发展、选择ClickHouse

 

6.存储架构&计算架构&高可用架构汇总如下表==》

三、《千万用户》

【业务背景】

经过2年的努力，业务发展达到一个新的高度，很快就要迈 上千万日活 大关了，你作为公司 CTO，前瞻性地预判到 业务发展给技术带来了挑战，于是准备启动 架构演进 。

【公司背景变化】

1. 技术团队 从30人增长到100人 ，覆盖完整的技术栈，包括大数据、风控安全等；

2. 由于公司的业务发展良好，证明了业务模式，业内已经有几家竞争对手出现了；

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

4. 增加支付功能，用于2个私聊用户之间转账或者红包；

【写在前面的话】

日活千万用户量、复杂度远远要比百万日活用户量要大、如果在百万的架构基础上通过扩展服务器的方式实现、其计算架构、存储架构、缓存架构会发生瓶颈、所以需要对业务划分域、每个域对应多个子域或子业务，所以总体架构需要演变为分级机构。

【业务域划分】 

【分级架构思路】

【计算架构】

 

【高可用架构】

高可用架构、设计了两种架构：同城双活 && 异地双活，可以根据用户分布范围来定。

 

 

【架构汇总】

 

四、《亿级用户》

【业务背景】

经过N年的努力，公司的 IM 业务已经跻身业界前三，已经超过6000万用户，作为创业功臣的你，此时正享受成功带来的喜悦。虽然业务发展势头良好，你以为可以高枕无忧了，但“革命尚未成功，同志仍需努力”，业务的发展带来了新的技术挑战。

【公司背景变化】

1. 技术团队 增长到上千人 ，IM 业务分了很多业务线；

2. 很多外部企业想合作；

3. 以前老板说“钱和人不是问题”，现在老板一看成本就觉得是大问题。

【亿级业务由域划分业务线】

 

【总体架构思路】

 【分区架构思路】

 【架构汇总】