微信朋友圈业务复杂度分析

业务复杂度

朋友圈功能分为发朋友圈和浏览朋友圈两部分

浏览朋友圈和发朋友圈业务复杂度都比较低，业务复杂性较低

业务中涉及到图片及视频的发布，浏览等

质量复杂度

高性能

朋友圈作为国民级应有，粗略估计日活大概在 5~6 亿左右。

按照 5 亿来计算，5E/86400 约等于 6K/s

这个 QPS 对于任何应用来说都是不低的，并且在早晚，周末节假日、热点事件的时候访问量会有明显的峰值出现，预测 QPS 会达到 5W+/s

尤其可见，微信朋友圈质量复杂度之一便是高性能

高可用

作为一款国民级应用，每时每刻都有用户在使用朋友圈，服务可用性的要求是比较高的，毕竟用户进入朋友圈发现不能浏览是比较不能接受的，但是可以接受不是实时的朋友圈。

但是时效性可以有一定的延迟，某个用户发布朋友圈之后，别的用户不需要马上就能浏览到，因为其他用户并不知道有人是否发布了朋友圈，在一定时间内可以感知到就可以满足

通过以上分析，朋友圈业务对于时效性要求不是特别高，但是对于服务可用性的要求会比较高。服务可用性也可以通过一些其他手段来解决，比如缓存，保证用户进入朋友圈功能正常使用就可以了。底层服务是否正常关注度并不是十分重要。

可扩展

朋友圈目前已经是国民级应用，未来用户量上升空间并不会特别明显，可扩展方面主要关注瞬时流量爆发，是否可以快速部署提升性能，不至于被瞬时流量打垮。

业务功能比较简单也比较成熟，并且也不太可能出现大的功能或者新的业务功能。

发朋友圈架构设计

1. 用户发送朋友首先通过 DNS 解析到距离自己最近的一个负载均衡集群节点

2. 业务服务集群部署，使用容器化部署，方便快速扩缩容，业务高峰来临的时候可以自行扩展，峰值过后可以自行缩容，避免资源浪费。

3. 峰值大量用户同时发送朋友圈会导致数据库负载变大，引入 MQ 消息队列减少数据库写入压力，写入可以慢，但是不能影响读。

4. 下图是 DNS 解析，并不是 CDN，误写

浏览朋友圈架构设计

1. 浏览朋友圈对于发朋友圈来说，请求量会更大，更多的用户的行为是浏览。

2. 朋友圈特点是发布之后不会再变更，并且用户浏览的都是最近发送的，所以可以通过 CDN 来缓存新发布朋友的视频及图片，文字等，这样大部分请求不会被真正打到服务器上

3. CDN 缓存只能缓存一部分最新的，毕竟微信用户量太大了，按照时间先后顺序 redis 可以缓存一部分，redis 使用集群架构。这样绝大部分的请求都被拦截到了数据库之前。

4. 浏览时间更久的 redis 中没有缓存的可以请求数据库进行加载，毕竟大部分用户只会浏览近一段时间的朋友圈内容，更久的关注的用户特别少。

整体微信架构设计

1. 用户发朋友圈的时候，业务服务处理完后，将内容发送至 MQ

2. 数据同步服务接受到消息的时候意味着一定是最新的朋友圈，持久化数据库，同步 CDN 缓存，同步 redis 缓存。

3. 用户浏览朋友圈的时候，首先通过 CDN 请求到最新的朋友圈，用户继续浏览更久前的内容通过 redis 加载，再更久的读取数据从库。

4. 以下架构图只是一个负载均衡到下游的，数据库多主多从架构，redis 集群结构，MQ 同样是集群.