架构实战营模块二命题作业

分析微信朋友圈的高性能复杂度

分述于架构分析，架构设计及设计理由

架构分析：

需求

微信朋友圈

不若聊天的功能

不是用户一对一，是一对多

发布之后，有权限的人可浏览，可点赞和评论，所以也是双向

但不用时实。

复杂度分析

来自课堂上老师的架构设计复杂度模型

微信朋友圈的分布应该在左上，业务和质量相对于整个微信来说是单纯的

可用、性能、扩展的要求不似有金钱交易的业务之高

以手机的微信菜单为例：

「我」 发朋友圈 ⇒写 (存储高性能，多人同发好友圈，特别是发图片或是影片)

「通知」 刷朋友圈⇒写 (计算高性能)

「发现」 读朋友圈 ⇒读 (存储高性能)

"评论"⇒写/读 (存储高性能)

"点赞"⇒写 (计算高性能)

「我」 读 我发的朋友圈⇒读 (应该没有高性能的问题)

"搜寻" (朋友圈)⇒读 (计算高性能，存储高性能，要能找到多年已封存的资料) (集群)

架构设计

复杂度模型

单机无法满足高性能

存储的特性刚发布时较热，访问热度随着时间递减。

存储时间需要较长，性能需求不高。

单机房

多机房

设计理由

朋友圈应该是读多写少，所以可以考虑读写分离

因为影片播放或是图片读取的效能需求远较文字为高

所以可以分表分库，将不同类型的文件用不同的架构存储使得性能提升

减少卡顿的次数，不至于影响业务失败，但影响的是用户的体验

微信朋友圈的业务较单纯，本可独立于聊天或支付业务。

但整个微信的服务人数、流量和需求考虑到高可用和可扩展应需要多机房，

朋友圈可依赖微信聊天的架构使用多机房。