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

一、《十万级用户》【业务背景】假设你现在正在一个创业公司担任 CTO因为微信工作生活娱乐不区分已经发生了很多次将敏感信息发错人甚至发错群的尴尬事件了你司 CEO 决定做一款 IM 工具为了区别微信和 QQ 大众化的 IM 需 求你们公司主打安全 IM这款产品的竞争力如下 主打私密聊天严格控制私密好友的数量而不是像微信一样买个菜都可能要加个微信【公司背景】1. 技术团队大约10个人后端6个前端2个Android 2个iOS 还没有2. 后端 Java 为主大部分是 P6~P73. 后端具备 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小时•发送消息 TPS2000万/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/spark1. 功能强大可扩展性强2. 较复杂数据分析师不会用clickhouse1. 兼容 SQL维护使用简单2. 性能强劲OLAP 分析平台根据当前的业务发展、选择ClickHouse6.存储架构计算架构高可用架构汇总如下表》三、《千万用户》【业务背景】经过2年的努力业务发展达到一个新的高度很快就要迈上千万日活大关了你作为公司 CTO前瞻性地预判到 业务发展给技术带来了挑战于是准备启动架构演进。【公司背景变化】1. 技术团队从30人增长到100人覆盖完整的技术栈包括大数据、风控安全等2. 由于公司的业务发展良好证明了业务模式业内已经有几家竞争对手出现了3.增加群聊功能每个私密群聊限制人数为5人4. 增加支付功能用于2个私聊用户之间转账或者红包【写在前面的话】日活千万用户量、复杂度远远要比百万日活用户量要大、如果在百万的架构基础上通过扩展服务器的方式实现、其计算架构、存储架构、缓存架构会发生瓶颈、所以需要对业务划分域、每个域对应多个子域或子业务所以总体架构需要演变为分级机构。【业务域划分】【分级架构思路】【计算架构】【高可用架构】高可用架构、设计了两种架构同城双活 异地双活可以根据用户分布范围来定。【架构汇总】四、《亿级用户》【业务背景】经过N年的努力公司的 IM 业务已经跻身业界前三已经超过6000万用户作为创业功臣的你此时正享受成功带来的喜悦。虽然业务发展势头良好你以为可以高枕无忧了但“革命尚未成功同志仍需努力”业务的发展带来了新的技术挑战。【公司背景变化】1. 技术团队增长到上千人IM 业务分了很多业务线2. 很多外部企业想合作3. 以前老板说“钱和人不是问题”现在老板一看成本就觉得是大问题。【亿级业务由域划分业务线】【总体架构思路】【分区架构思路】【架构汇总】