架构实战营模块 2 课后作业

一、朋友圈高性能方案-整体架构

二、朋友圈整体架构图-单机房示意图

三、朋友圈架构设计-设计理由

1、APP/PC 端查看朋友圈时最时效性要求不高，可从最近的 CDN 中查询。

2、入口流量分不同的负载均衡，避免入口流量相互影响，一类负载均衡给朋友圈应用系统，一类负载均衡给对象存储（主要存储视频、图片及附件类）。

3、朋友圈服务器做成无状态，支持横向扩展，做成集群模式。

4、考虑到朋友圈的信息对事务要求不高，而且数据量会比较大，选择文档型数据库 MongoDB，弱 Schema 比较匹配朋友圈数据存储格式，同时 MongoDB 自带分布式，支持副本集提升读能力，支持分片提升写能力，可横向扩展。

5、针对查看朋友圈信息，对时效性要求并没那么高，可选择缓存（CDN 缓存 + Redis 分布式缓存）。针对 Redis 分布式缓存选择 Redis Cluster（因通信开销的原因，Redis Cluster 集群的规模限制在 500 个实例左右，如果超过这个体量，需要考虑使用 twemproxy 或 Codis 这类基于代理的集群架构）。

5、针对视频、图片、附件这类非文字类选择存储在 MinIO(对象存储)中，这类信息上传后将返回的唯一 Key 值随应用数据一起上送朋友圈应用系统并存储至 MongoDB 中。选择 MinIO 的原因：支持横向扩展且与云对象存储兼容如 AWS S3 云存储，切换及使用成本都非常低且满足存储大量文件的要求， 一个字：香。