前言

众所周知，程序员这个群体， 程序员是“加班熬夜党”的主要人群，格子衬衣+人字拖是这个群体标配，“生命不息，加班不止”似乎一种对代码的追求和生活无奈的反讽。

不巧的是，俺也加入了这个群体。工作之余，就是研究如何保住发际线。

自从进入换了一家公司之后，发现节奏整个都变了，技术比较老旧，工作也只是维护 10 多年前的产品。这几年下来，技术没啥进步，反而一直还在退步。痛定思痛之后，还是决定加入「架构师实战营」，跟着华仔来一次架构升级。

进了实战营之后，发现基础真差。很多同学都熟知的各种技术，对我而言仅仅第一次听到。那怎么办，钱都交了，总不能让苗苗班班给我退钱吧。

那就缺什么就补什么，不懂就多问，多查。无他。

所以每次交作业对我而言，都是除了完成作业本身之外，更多是记录自己在查漏补缺的过程。如有偏误，还请同学们多多指教。

架构语言

有点突发奇想，记得刘超老师在讲网络知识的时候说过一个通天塔的故事。

《圣经》中有一个通天塔的故事，大致是说，上帝为了阻止人类联合起来，就让人类说不同的语言。人类没法儿沟通，达不成“协议”，通天塔的计划就失败了。但是千年以后，有一种叫“程序猿”的物种，敲着一种这个群体通用的语言，连接着全世界所有的人，打造这互联网世界的通天塔。

是不是学习架构，也是学习「通天塔」的语言呢？

面对老板，中间干系人，业务，开发团队，向不同的群体，通过架构语言，分别向他们讲述同一个「故事」。把在脑海中创建的「软件想象」，进行推进和落地呢？

【作业要求】

对照模块 2 讲述的复杂度分析方法，分析微信朋友圈的复杂度。

针对各个复杂度，画出你的架构设计方案（无需做备选方案，只需要最终的方案即可）。

给出你的架构方案中关键的设计理由。

3~5 页 PPT 即可，涵盖复杂度分析、架构设计、设计理由。

看到分析朋友圈的复杂度时，有点一惊，因为用得太多，但从来没去思考过朋友圈，越是如此，反而更难分析。越熟悉反而越难。

象限划分

首先对一个系统的复杂度分析，分析业先是分析业务复杂度和质量复杂度。如下图：

• 业务复杂度：指业务本身的复杂度，主要体现在难以理解、难以扩展，例如支付宝、保险、金融等

• 质量复杂度：指的是系统对于高性能、高可用、高扩展等质量要求。

业务复杂度分析

朋友圈这个子系统，业务复杂度高么？

因为从用户角度看，无非就是发朋友圈，查看朋友圈，评论，点赞。业务流程并不长。业务直接的关系也不复杂。所以我认为朋友圈业务复杂度并不高。

质量复杂度分析

那么质量复杂度高么？

大胆猜想一下，微信对于不同的业务，应该也有不同的优先级。

登录 > 支付 > 消息 > 朋友圈 

从个人的使用习惯，支付这个场景优先级肯定高于消息，消息又高于朋友圈。毕竟没有几个人能做到丝毫不在意钱的问题。就算马云爸爸说，房价如葱价，这个只是针对人家那个群体而言。对于普通人来说，钱难赚，生活不易。

消息的优先级又肯定高于朋友圈的优先级。有人对你一对一的发消息，这紧急程度会高于朋友圈的。就正如东东老师，恨不得天天给我发消息。生怕我把她给忘记了。从 go 语言的训练营，到前端的训练营。

但对于朋友圈的信息而言，要是朋友发了，没看到，或者是看不到。虽然不会产生什么大问题。但对于用户体验来说，就是差评了。毕竟使用频率来说，朋友圈在社交领域还是属于高频使用场景。见过一个 95 后小女孩，吃饭的时候，明明朋友圈都没更新。手指还是在不停的拉朋友圈。10 秒拉一次。生怕第一时间错过朋友的动态一样。

仔细分析发现，在朋友圈这个场景对数据一致性要求并不高。迟一点才看到某个好友的朋友圈动态更新，对用户来说并不会带来什么问题。甚至用户也会毫无感知。但总不能发出去的朋友圈，几年之后来一次曾经的回忆时，发现自己还有依稀记忆的照片，找不到了。所以对质量复杂度来说，要求还是高的。

最后对业务和质量的分析，朋友圈应该属于业务低，质量高的等级。对应的架构模式有集群/缓存/Recator/分片/副本...

那么对于朋友圈复杂度分析，主要集中在质量复杂度上面。

质量复杂度分析主要是分析：高性能，高可用，可扩展。下面就继续这 3 方面的分析。

数据收集

巧妇难为无米之炊，要分析质量复杂度，还是得有数据。

一开始主要是分析 TPS 和 QPS。那么这两个数据到底有什么用呢？具体有什么意义呢？（我真是第一次听到这两个指标【尴尬黑人脸】）

这两个数据主要是可以大概明白一个朋友圈系统应该具备一个什么样的负载能力。虽然一切都是估算。但至少能从一个毫无头绪，到能着手分析。

可能从某个角度来说，架构师都是「心中有数」的人。例如常用的数据库的指标数据，各种框架的对比数据，通过数据进行估算量化，根据项目的具体情况进行取舍，初步圈定范围。把模糊的问题，通过数据逐步清晰起来。

找来找去，就找到这个一段话，好像大家都在用。

TPS 和 QPS 分析

因为 1.2 亿用户会发表朋友圈。那么也就是意味着有写数据库的操作。假设用户发表朋友圈为 n 条朋友圈数据。

发布朋友圈的平均 TPS = 1.2 亿*n / 一天时间 = 1.2 亿 *n/ （24*60*60），约等= 1388*n （请求数/秒）n 大于等于 1

个人感觉用二八估算峰值好像也可以。

计算公式 ： TPS = 总请求数的 80% / (总时间 20%)

峰值 TPS = 5555*n（请求数/秒）n 大于等于 1

从 7.8 亿用户进入朋友圈：这里用户我觉得应该是用户数量。毕竟中国现在人口数量已经突破了 14 亿。其中 16-59 岁劳动年龄人口为 8.8 亿人。

那么 7.8 亿用户每天进入朋友圈的次数这里并没有给出。假设平均每人进入的次数是 n。

QPS 平均 = 7.8 亿*n/86400 = 9027*n

同样用二八估值来计算 QPS 峰值。

峰值 QPS = (7.8 亿*n*0.8) /(86400*0.2) = 36111*n

一开始对计算 TPS 我也有点模糊，为什么用 1.2 亿来计算，而不是 7.8 亿。

经过研究，TPS 表示的是业务，一般可以理解最后一步操作为写数据库。简单的理解就是 TPS 有涉及到写数据库的操作。而 QPS 没有。只有在特定的情况下，TPS 才会等于 QPS。

又了上面的分析，我们就可以结合起来分析高性能的复杂度。

单机负载数的分析

2016 年 Q2 微信用户大概是 8 亿，月活在 5.4 亿左右。

2022 年 微信用户没有算上海外用户，国内用户大概 12 亿。

从 2015 年的数据看，当时微信有 600 多台服务器服务 5 亿日活。那么当前 10 亿日活，假设服务器台数翻个倍。也就是 1200 多台服务器。

每台服务器支持的用户数：10.9 亿/ 1200 台=90 万。也就是平均单机支持 90 万用户。

由于今年几年服务器的发展。现代的服务器都可以支持百万用户级别。那么我们可以假设微信单机实现 100 万用户连接。

根据华仔老师《从 0 开始学架构》专栏：单服务器高性能的关键之一就是服务器采取的并发模型，并发模型有如下两个关键设计点：

• 服务器如何管理连接。

• 服务器如何处理请求。

那么并发的关键数据就是 TPS。前面分析出峰值的 TPS 为：5555*n。那么 epoll 是符合我们期望的。

单机

计算高性能

进程模型：直接沿用当前进程模型。

网络模型：根据上面分析，网络模型选用 epoll 模式。只是 epoll 是传统的网络模型。 reactor 将整个 epoll 架构进行抽象，将 read 和 write 接口化，epoll 整个机制封装在 reactor 中；所以我们网络模型选择 reactor 模型。

缓存模型：CDN 缓存。

为什么说缓存模型是 CDN 缓存呢。当我们朋友圈点击发送。总有种秒发出去的感觉。

那是因为，我们在发朋友圈时，是把你发布的图片传到就近的 CDN 节点，所以就特别快。存储高性能存储模型

朋友圈典型的 Feed 流，关系基本都是双向，有上限，排序按时间，能屏蔽能分组展示，妥妥的推流模式。那么必然要求读写操作都是高性能。redis 是个不错的选择。

集群

计算高性能

任务分配

1. 负载均衡即可

存储高性能

任务分解

1. 任务分类，读写分离。

2. 任务分断。数据库进行分表。

3. 
   

集群这块时间不太够了。时间都花在查漏补缺上了。没办法，暂时先放一放。

最后架构图：

还有一些细节自己还没搞清楚明白，不过时间真的不够。完成比完美更重要。先完成后，跟上进度，再慢慢查漏补缺吧。

参考附录

https://juejin.cn/post/6955479962530873381

2021微信公开课PRO精华总结！张小龙：不被看好的事情，就还有戏 | TOPYS创意内容平台http://www.jn001.com/paperappwb/content/content_631543.html

https://www.infoq.cn/article/weixin-bonus-loadhttps://36kr.com/p/1559853588466824