百万量级的架构设计

【业务背景】:

1.挑选的商品是在各大电商平台上畅销和好评的商品进行销售,但是商品种类不超过 20 个,并且到目前为止只有 10 品类

2.本次 6.18 的秒杀活动选择了 1000 个充电宝以及 10 台 iPhone12 作为秒杀的商品

3.百万用户中正常有 50%的用户活跃在交易平台上

4.交易必须保证万无一失

1. 以下是业务背景的架构图 :

在该架构中，已经大致表明了本业务系统中常用的微服务的种类

2. 接下来是关于总体架构的一种思路

考虑到该系统的复杂性已经日后该架构演化的需要，预留出日后架构演化的空间

3.下图是根据不同的等级进行业务域的划分如下

该图就是对不同的业务进行划分. 并且将这些业务分给 P8 或者其他的业务架构师进行负责并且实现其中的微服务

4.以下是根据业务域进行的一种划分

因为当用户数量到到百万级别以后,大概率会有 VIP 用户, 因此在业务域进行划分时需要体现这一部分的用户

5.基础技术的"建设"方式 :

规范化 :

日志统一格式输出的规范

使用成熟的开发框架进行开发

使用成熟的 RPC 框架进行各个微信服务的访问

最终代码管理规范

引入 git 等成熟的代码管理软件

平台化 :

具有统一的测试平台

具有统一的运维平台

可以考虑引入大数据平台作为后台统一的数据处理中心

自动化 :

测试引入自动化测试工具

故障自动分析并进行处理全链路压测

可视化:

系统人物执行维护可视化

系统人物管理可视化

6.接下来是是本系统的存储架构的设计如下 :

首先估算一下该系统的用户数以及聊天数 :

【注册】

在本系统中有百万用户的信息数据

【登录】

百万注册用户,每天活跃用户有 50%登录并且活跃在该系统上

【群聊】

本系统暂时不支持群聊

【聊天】 :

在这里假设每个活跃的用户每天向 5 位好友发送 100 条消息,则消息的数量为 50 万 * 5 * 100 = 2.5 亿,而且数据当天

都会被立即删除,所以写入 + 读取 + 删除= 7.5 亿

7.接下来，我们看一下总体架构的负载均衡的设计 :

由于该系统中每日活跃用户数有百万级别 ， 因此在该架构师引入 F5 以及 Nginx 进行分流。后台则采用服务器集群的方式减轻请求压力

8. 我们这里在看一下该系统所采用的缓存架构 :

该架构引如 APP 缓存主要用于减轻前台用户请求的压力,而引入分布式缓存和 Web 容器缓存主要为了加快 Web 服务器以及后台服务器的响应时间

9.微服务拆分，该系统中微服务的拆分如下:

10.这里引入同城双活的部署模式,参照如下 :

而且每日在线的人数仅仅百万级别，所以这个采用同城双活的部署方案就可以保障数据的安全，解决目前的架构需求，如果日后有需要，则需要将该架构模式演进