您知道十万级用户到亿级用户系统架构是如何演进的吗？
一、《十万级用户》
【业务背景】
假设你现在正在一个创业公司担任 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的博客-CSDN博客
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. 以前老板说“钱和人不是问题”，现在老板一看成本就觉得是大问题。
【亿级业务由域划分业务线】
【总体架构思路】
【分区架构思路】
【架构汇总】