这是我参与8月更文挑战的第16天,活动详情查看:8月更文挑战
一、前言
学习:
- 掌握千万用户规模
IM
架构设计关键点- 掌握百万用户规模架构如何演进到千万用户规模架构
架构要解决的核心复杂度:
百万用户架构 vs 千万用户架构:
学习方向:
- 业务背景
- 总体架构思路
- 业务域划分
- 基础技术建设
- 其它架构设计
业务背景:
经过2年的努力, 业务发展达到一个新的高度, 很快就要迈上千万大关了, 你作为公司
CTO
, 前瞻性地预判到业务发展给技术带来了挑战, 于是准备启动架构演进。公司背景变化:
- 技术团队从30人增长到100人, 覆盖完整的技术栈, 包括大数据、风控安全等;
- 由于公司的业务发展良好, 证明了业务模式, 业内已经有几家竞争对手出现了。
业务基本架构:
0. 每个用户都会通过算法生成非对称的公钥和私钥; 0. 用户发送的消息会通过公钥加密,接收用户的消息使用自己的私钥解密; 0. 只能创建一对一聊天;(删除) 0. 聊天消息“阅后即焚”,最多只保留60分钟; 0. 无需使用手机号注册; 0. 每个用户最多20个好友; 0. 增加群聊功能, 每个私密群聊限制人数为5人; 0. 增加支付功能, 用于2个私聊用户之间转账或者红包。
二、总体架构思路
总体架构思路 - 分级架构:
总体架构思路 - 分级架构:
- 不同架构师的职责有什么区别?
总架构师(P9)的核心职责:1. 划分业务域;2. 基础技术平台完善。 业务域架构师(P8)的核心职责:1. 划分业务域内的微服务;2. 按照用户规模设计架构。
- 感觉总架构师要运维、测试、大数据都要懂,这个怎么做到的?
每个技术域需要一个P8的负责,但总架构师确实每个领域都要懂一些(技术广度)。 例如:全链路压测什么时候实现?用什么方案?需要总架构师一起决策。
- 各个业务域内的架构,总架构师是不是不需要关注?
基本上是的,除非某个域问题很多,例如线上质量问题、开发效率问题等。
- 业务域划分是总架构师划分就可以了么?
实际上是由老板、业务方、总架构师一起讨论确定的,不单是一个技术决策,还是一个权力决策。
三、业务域划分
业务域划分粒度:
业务域划分:
四、基础技术建设
基础技术的“四化建设”:
基础技术的“四个核心平台”:
五、其它架构设计
计算架构之负载均衡:
计算架构之缓存架构:
高可用架构设计 - 同城双活:
高可用架构设计 - 异地双活: