极客时间—架构实战营—第九期—模块二作业

一、朋友圈性能复杂度分析

首先，我们对朋友圈的功能进行拆分，可得到主要包括：“发朋友圈”， “看朋友圈”和 “朋友圈交互（点赞和评论）” 三个主要功能。

其次，我们确定系统的性能指标，通过搜索找到微信朋友圈在 2015 年的性能数据，数据引用自：https://mp.weixin.qq.com/s/O1jeKn4fDyrSj8opWFS4aQ （微信朋友圈技术之道：三个人的后台团队与每日十亿的发布量）。

性能指标如下：

在 2015 年 7 月，朋友圈日发表量 10 亿次，日浏览量 100 亿次，峰值时是平时流量的 5 倍；同时假设每个朋友圈状态平均有 10 次交互（点赞和评论），得以下性能复杂度分析图：

二、架构设计

我们按照模块二第五节的性能复杂度架构设计方法论，结合上述的分析，对朋友圈不同的功能进行高性能架构设计。

2.1、发朋友圈

架构设计如下：

设计理由：

单机面：计算高性能暂时不涉及无需考虑；存储高性能部分我们采用分库分表的 MySQL 集群来存储朋友圈数据（元数据），朋友圈本身内容采用 MongoDB 存储。

集群面：计算高性能采用负载均衡即可，发朋友圈无需再拆分；存储高性能则采用 MySQL 分库分表和 MongoDB 集群的方案

2.2、看朋友圈

架构设计如下：

设计理由：

单机面：计算高性能缓存模型部分，我们采用 Redis 集群来缓存热点朋友圈，应对“明星分手时”单个状态超大访问量的场景；存储高性能部分我们采用 Redis 集群+MongoDB 集群的两级存储方式。

集群面：计算高性能采用负载均衡，看朋友圈无法再拆分；存储高性能如上所示，采用 Redis 集群+MongoDB 集群的方案

2.3、朋友圈交互（点赞+评论）

架构设计如下：

设计理由：

单机面：计算高性能暂时不涉及无需考虑；存储高性能部分我们采用分库分表的 MySQL 集群来存储朋友圈互动记录，评论（互动）本身采用 MongoDB 存储。

集群面：计算高性能采用负载均衡即可，朋友圈互动不再拆分任务；存储高性能采用 MySQL 分库分表和 MongoDB 集群的方案

2.4、整体架构

综上所述，朋友圈的整体架构图如下所示：（ps:存在一个对称的机房做双活高可用）

三、总结

以上即为朋友圈的“发朋友圈”，“看朋友圈”和“朋友圈交互”三个功能架构设计方案。

相比于聊天和支付功能，朋友圈功能在微信中属于优先级不是那么高的功能点，极端情况下可以忍受一定程度的不及时、相应慢甚至一段时间内不可用，故其高可用性在此不做分析和设计。