千万用户规模 IM 架构设计

业务背景

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

【公司背景变化】

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

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

业务基本场景

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

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

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

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

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

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

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

实际的总体架构思路 – 分级架构(1/2)

总体架构思路 – 分级架构(2/2)

1. 不同架构师的职责有什么区别？

总架构师的核心职责：1. 划分业务域；2. 基础技术平台完善。

业务域架构师的核心职责：1. 划分业务域内的微服务；2. 按照用户规模设计架构。

2. 感觉总架构师要运维、测试、大数据都要懂，这个怎么做到的？

每个技术域需要一个人负责，但总架构师确实每个领域都要懂一些（技术广度）。

例如：全链路压测什么时候实现？用什么方案？需要总架构师一起决策。

3. 各个业务域内的架构，总架构师是不是不需要关注？

基本上是的，除非某个域问题很多，例如线上质量问题、开发效率问题等。

4. 业务域划分是总架构师划分就可以了么？

实际上是由老板、业务方、总架构师一起讨论确定的，不单是一个技术决策，还是一个权力决策。

业务域划分

基础技术的“四化建设”

1.规范化:统一的各类规范

1. 日志规范；2. 开发框架；3. RPC 框架；4. 接口规范；5. 代码管理规范。

2.平台化：基于规范实现的统一平台

1. 测试平台；2. 运维平台；3. 大数据平台。

3.自动化：统一平台自动实现各类功能

1. 接口自动化测试；2. 全链路压测；3. 故障自动分析。

4.可视化：状态、功能、操作等可视化

1. 系统状态可视化；2. 任务管理可视化；3. 任务执行可视化。

基础技术的“四个核心平台“

运维平台

1. 配置；2. 部署；3. 监控；4. 应急

测试平台

1. 用例管理；2. 资源管理；3. 任务管理；4. 数据管理。

存储平台

1. SQL 平台；2. NoSQL 平台；3. 小文件存储；4. 大文件存储。

大数据平台

1. 离线处理；2. 在线处理；3. 推荐系统。

计算架构 – 单机房内负载均衡

计算架构之缓存架构

高可用架构设计1 – 同城双活

高可用架构设计2 – 异地双活

架构要解决的核心复杂度

百万用户架构 vs 千万用户架构

	十万用户	百万用户	千万用户	演进
存储架构	MySQL 主备 Redis 主备	MySQL 主备 Redis cluster	存储平台	存储系统 → 存储平台
计算架构	2台 Nginx 负载均衡三级缓存	2台 Nginx/LVS 负载均衡三级缓存	F5 + Nginx 负载均衡三级缓存	Nginx/LVS → F5
可扩展架构	单体/2个服务	拆分为5个服务微服务核心基础设施	业务域	微服务 → 业务域
高可用	MySQL 主备跨机房复制，只保证基础数据不丢失	同城双中心	同城双活/异地双活	同城双中心 → 同城双活/异地多活
大数据架构		ClickHouse	大数据平台	ClickHouse → 大数据平台
架构本质复杂度	快速验证（核心需求）	快速扩展（辅助需求）	全面完善（基础技术）	需求 → 技术