1、前言
微信朋友圈包括图片和视频两套业务架构组成，朋友圈图片的特点是请求量大、消耗计算资源较多，视频则主要消耗带宽。
朋友圈的数据是永远存储的，而且随着业务的快速发展，存储容量、带宽和设备的消耗大量增加，尤其重大节日带来的使用量增长，更加剧了消耗，也给运维人员的保障带来了巨大压力。
在重在节假日节点，技术保障主要由三方面组成：
1）软件保障指通过程序、业务逻辑层面的优化和评估，减轻负载；
2）硬件保障主要指带宽、机器负载的评估和扩容；
3）柔性措施指的是通过业务调整，降低一些不重要特性的资源，来保障重点特性的正常运行。
学习交流：
- 即时通讯开发交流3群：185926912[推荐]
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
（本文同步发布于：http://www.52im.net/thread-1569-1-1.html）
2、相关文章
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
3、软件架构方面的保障
朋友圈整体情况如下图所示：
朋友圈的架构主要分为OC和IDC两种：
IDC指的是数据中心，即数据最终落地存储的地方；
OC指的是带外网的独立机房，SOC指规模较大的OC。
每个IDC都有一整套接口机/逻辑设备/存储设备用以支撑用户的上传下载、及文件落地存储的需求。
OC点的主要作用是提供外网访问，承载用户的下载流量。每个OC内的设备，一起组成一个缓存池，用户下载时，本地OC中缓存不命中，才到IDC去回源拉取文件。每个OC的功能都是相同的，用户一般到就近的OC点下载，当单个OC点故障时，会通过重试或者切换让用户到其他OC点下载，确保下载成功。
4、容灾及重试机制
朋友圈的模块容灾主要是实现单机故障时的自动剔除，主要形式是通过master管理服务器的ip列表，通过心跳探测等方式找到异常设备，并屏蔽故障ip，不返回给前端使用。
以front层的单机剔除为例：
如果整个OC或IDC点碰到故障，由于变动较大，一般依赖运维人员手工切换来恢复，或者通过模块之间的重试机制来保障。
朋友圈下载的重试：
不管是用户到OC的下载过程，还是OC到IDC的回源过程，默认都会进行2次失败后的重试，并且重试一定会选择异地的接入点，避免继续重试到故障的节点。实现的原理是每一层master都会返回给前端至少两组ip列表，并保证两组ip列表为异地节点，前端失败时才可以实现异地重试。
但重试由于会造成请求的增加，所以是把双刃剑，节日高峰期间由于请求本身涨幅已经很高，重试更容易引发问题，需要进行调整：
1）通过master路由下发，关闭重试。在元旦/春节这种请求有数倍增长的节日实行；
2）值班人员严密监控，如果IDC失败率超过20%，则紧急手工关闭重试。这种在中秋/国庆这种增长并不高的节日实行。
Front模块的重试控制界面：
5、硬件方面的保障
5.1 容量评估和设备扩容
重要节日前运维人员会连同资源组，根据业务预算和业务增长的需求及实际负载，进行各个机房、模块的设备扩容。预算以外的请求上涨，则通过柔性或者过载的方式，进行降低或者拒绝。
评估方法：
1）机房容量主要根据交换机带宽的上限评估；
2）接入层设备容量主要根据CPU、内存的负载比例、网卡的流量/包量占比来评估；
3）存储层设备容量主要根据CPU、内存的负载比例、磁盘IO的读写次数来评估。
5.2 春节朋友圈上传负载
业务侧春节要求的增长比例，是上传支持9倍增长，下载支持1倍增长，超过这个比例的请求可以拒绝掉，但根据预算扩容后，达到上图的效果，还是有部分模块无法支持这个涨幅，尤其是压缩compress模块，该模块每支持一倍增长就需要大量虚拟机扩容，预算内无法支持，这样就需要使用柔性策略来解决。
6、柔性策略简介
朋友圈的柔性策略分为两层：
第一层是粗暴柔性：即按比例、接业务直接限制上传下载的请求，被限制的请求会返回给用户失败，与微信C2C相同，这种一般用于超过系统预估的负载能力，造成系统故障时用于快速恢复业务时使用；
第二层是按业务特性柔性：即从业务层面通过降低图片视频清晰度、延迟用户更新等方向降低系统的负载。下面主要详述业务柔性。
朋友圈业务的主要增长与瓶颈：从前文的设备负载评估图看，在预算范围内，接入层和逻辑层都只能支撑5倍增长，而压缩compress模块只能支撑1倍增长。
7、柔性实践之：压缩compress柔性
Compress模块的作用是将客户端上传来的原始图片按需求压缩成各种格式和尺寸，以支持特定的业务场景，并且节省存储空间和带宽。由于压缩技术的不断发展，使用更先进的压缩格式，同等清晰度的图片压缩比例越高，需要消耗的压缩计算资源就越多。
所以如果反向操作，将当前使用的hevc格式替换回jpeg格式存储的话，就可以节省压缩资源，实测compress的cpu负载可以降为20%，即支持5倍增长。但图片的平均大小也会上涨，造成下载流量上涨。
所以采用的折衷方法，是在上传图片换回jpeg格式的同时，将图片的清晰度从70降为50，这样可以减小文件平均大小，从而抵消换回jpeg格式带来的流量上涨效果。实际测试中，发现用户对降清晰度的感知并不明显，在节假日短暂开启不会影响用户体验。
8、柔性实践之：小视频码率柔性
小视频的带宽平时会超过1TB，节日效应增长明显。所采取的降流量方法与图片类似，即降低上传视频的码率，通过降低文件平均大小的方法来节省带宽。
柔性： 小视频码率1800 -> 1200 平均大小 2.1MB -> 1.3MB
经测试，降码率后基本不会影响用户体验，但由于是对新上传视频生效，要体现到下载带宽的下降中，就有相当程度的延迟，大约需要4小时完全生效。所以这一柔性措施在节日之前就需要开启，不能用于应付紧急情况。
降码率生效期间流量变化：
9、柔性实践之：上传TSSD缓冲池柔性
由于上传preupload接口机及后层的逻辑模块等，都无法支持10倍涨幅。所以在架构中另外搭建了两套TSSD缓冲池，缓冲池用于临时存储新上传的文件，可以支持读写。按上图所示，在zone模块处增加了缓冲池一，在上传preupload处，增加了缓冲池二。两个缓冲池的作用是有区别的：
zone模块如果过载，主动过载掉的上传请求，不会直接返回失败，而是将请求写入到缓冲池一中，缓冲池一中的文件并不能被下载到，但会按比较慢的速度将文件下发，写入到后端模块。所以缓冲池一的主要作用是减缓短时间内大量的上传请求，而不是完全抵消上传请求，并且缓冲池一中的文件是不能被下载到的。
在preupload模块处增加了缓冲池二，preupload模块中对存储TFS的写请求次数做了限制，如果上传请求数超过了存储TFS的能力，则preupload会将请求写入缓冲池二。用户下载时，会根据文件标识进行判断，如果发现文件存储在缓冲池二而不是TFS中，则会到缓冲池二中去获取文件。所以缓冲池二可以替代TFS的功能，起到保护底层模块的效果。等到缓冲池二下架时，需要将其中的文件人工写入到TFS中。
10、柔性实践之：朋友圈timeline按比例柔性
timeline指的是微信朋友圈更新的时间戳，这一柔性的原理是将通知用户好友朋友圈更新的时间戳先缓存起来，不下发给用户的微信终端，这样微信上就看不到朋友圈更新的内容了，也就不会产生下载图片/视频的请求，可以直接减少下载流量。
timeline柔性后这里不会更新了：
但也有几点注意事项：
1）容易引起用户投诉，用户一般会明显感知到朋友圈内容变少了；
2）如果缓存timeline的时间过久，将缓存下发的过程就必须很慢，否则会引起下载流量的进一步暴涨。
春节人工执行柔性的步骤：
（原文链接：https://cloud.tencent.com/developer/article/1006591）
附录1：有关IM架构设计的文章
《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
《WhatsApp技术实践分享：32人工程团队创造的技术神话》
>> 更多同类文章 ……
附录2：QQ、微信团队分享的文章汇总
[1] QQ、微信团队原创技术文章：
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》
《腾讯技术分享：Android版手机QQ的缓存监控与优化实践》
《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》
《微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》
《腾讯技术分享：Android手Q的线程死锁监控系统技术实践》
《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《腾讯团队分享 ：一次手Q聊天界面中图片显示bug的追踪过程分享》
《微信团队分享：微信Android版小视频编码填过的那些坑》
《微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉》
《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》
《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
《移动端IM实践：Android版微信如何大幅提升交互性能（二）》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑》
>> 更多同类文章 ……
[2] 有关QQ、微信的技术故事：
《技术往事：微信估值已超5千亿，雷军曾有机会收编张小龙及其Foxmail》
《2017微信数据报告：日活跃用户达9亿、日发消息380亿条》
《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》
《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》
《开发往事：深度讲述2010到2015，微信一路风雨的背后》
《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-1569-1-1.html）
网友评论