请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 3
社交软件红包技术解密(二):解密微信摇一摇红包从0到1的技术演进

本文来自微信团队工程师张文瑞的技术分享,由“极客邦科技Geekbang”编辑发布,即时通讯网收录时有修订和改动。原文地址:mp.weixin.qq.com/s?__biz=MzAxNDU2MTU5MA==&mid=208037085&idx=1&sn=fb093eecec51c525f1cd3685645cef1a,感谢原作者的分享。


一、开场白


谢谢大家!我是来自腾讯WXG技术架构部的张文瑞,今天下午跟大家分享的主题是:微信团队是如何从0到1实现“有把握”的微信春晚摇一摇红包系统的

回忆一下春晚的活动,有什么样的活动形式呢?

1.jpg

当时我们是直接复用客户端摇一摇入口,专门给春晚摇一摇定制了一个页面,可以摇出“现金拜年”、“红包”。底下的红包肯定是大家比较感兴趣的,也是今天下午重点介绍的内容。

精彩的活动背后一定会有一个设计独到的系统,微信春晚摇一摇红包系统就是这样。

二、分享者


zhangwenrui.jpg

张文瑞:微信高级工程师,微信接入系统负责人。一直从事后台系统设计开发,早期涉足传统行业软件,后投身互联网。作为微信最早的后台开发之一,见证了微信从零开始到逐渐发展壮大的过程。

张文瑞还分享了微信其它方面的技术文章,您也可能感兴趣:

三、系列文章


❶ 系列文章目录:


❷ 其它相关文章:

四、从理论到实现:v0.1原型系统


4.1、概述


2.jpg

我们看一下这个系统,当时做了一个原型系统,比较简单,它已经实现了所有的功能。

如上图所示,摇那个手机的时候会通过客户端发出一个请求,接入服务器,然后摇一摇服务,进行等级判断,判断以后把结果给到后端,可能摇到拜年或红包,假设摇到红包,上面有LOGO和背景图,客户端把这个LOGO和背景图拉回去,用户及时拆开红包,拆的请求会来到红包系统,红包系统进行处理之后会到支付系统,到财富通的转帐系统,最终用户拿到红包。

拿到钱以后,只是其中一份,还有好几份是可以分享出去,我们称之为“分裂红包”,通过信息系统转发给好友或群里,好友跟群里的人可以再抢一轮。

整个过程归一下类,叫:资源流、信息流、业务流、资金流,今天讲的主要是资源流跟信息流。

原始系统看起来比较简单,是不是修改一下直接拿到春晚上用就可以了?肯定不行的。

到底它有什么样的问题呢,为什么我们不能用,在回答这个问题之前想请大家看一下我们面临的挑战。

4.2、我们面临怎样的挑战?


3.jpg

第一个挑战是比较容易想到的,用户请求量很大,当时预计7亿观众,微信用户也挺多的,当时预估一下当时峰值达到一千万每秒,通过图对比一下(见下图),左边是春运抢火车票,一秒钟请求的峰值是12万,第二个是微信系统,微信系统发消息有个小高峰,那时候峰值每秒钟是33万,比较高一点的是预估值一千万每秒,右边是春晚时达到的请求峰值是1400万每秒

aaa.jpg

这个活动跟春晚是紧密互动的,有很多不确定因素,体现在几个方面:

  • 1)在开发过程中,我们的活动怎么配合春晚,一直没有定下来,很可能持续到春晚开始前,显然我们的客户端跟我们的系统到那时候才发布出去,这时候我们的开发就会碰到比较多的问题了;
  • 2)在春晚过程中,因为春晚是直播型节目,节目有可能会变,时长会变,顺序会变,活动过程跟春晚节目紧密衔接在一起,自己也是会有挑战的,这也是不确定的因素;
  • 3)再就是我们系统是定制的,专门为春晚定制,只能运行这么一次,这是挺大的挑战,运行一次的系统不能通过很长的时间,检查它其中有什么问题很难,发出去了以后那一次要么就成功了,要么就失败了;
  • 4)因为春晚观众很多,全国人民都在看,高度关注,我们必须保证成功,万一搞砸了就搞砸在全国人民面前了。这么大型的活动在业界少见,缺少经验,没有参考的东西。还有就是我们需要做怎样的准备才能保证万无一失或者万有一失,保证绝大部分用的体验是OK的,有很多问题需要我们不断地摸索思考。原型系统不能再用的,再用可能就挂了。

4.3、原型系统存在哪些问题?


原型系统有哪些问题呢?

  • 1)第一个问题:是在流量带宽上,大量的用户请求会产生大量的带宽,预估带宽峰值是3000pb每秒,假设我们资源是无限的能够满足带宽需求,也会碰到一个问题,用户摇到以后有一个等待下载的过程;
  • 2)第二个问题:在接入质量这一块,我们预估同时在线3.5亿左右,特别是在外网一旦产生波动的时候怎么保证用户体验不受损而系统正常运作;
  • 3)第三个问题:请求量很大,1000万每秒,如何转到摇一摇服务,摇一摇服务也面临一千万请求量,我们系统要同时面对两个一千万请求量,这不是靠机器的,大家都有分布式的经验,这么大请求量的时候任何一点波动都会带来问题,这是一个很大的挑战。

4.jpg

4.4、我们是如何解决这些问题的?


针对以上几点,我们详细看一下每一点我们是怎么做到的。

我们首先看一下信心指数,把这个系统拿到春晚去跑有多少信心,这里的指数是10,如果这个系统拿到春晚去用,而且还成功了,这个概率是10%。

当然我们的系统不能建立在运气的基础上,应该怎么做?

  • 1)带宽利用:在带宽这一块客户端可以摇到多种多样的结果,结果大部分都是静态资源,静态资源我们可以提前制作出来下发到客户端,在后台做了资源推送的服务,客户端拿到列表以后可以先行下载,客户端利用闲时把资源拉过去。碰到几个问题,资源交付情况的问题,需要增量的发下去;
  • 2)资源更新;
  • 3)下载失败:资源下载失败,失败的话怎么办呢;
  • 4)资源覆盖率:依靠这个系统下载资源的用户,比如覆盖率只有20%、30%,两个东西就没有意义了,覆盖率要达到90%左右;
  • 5)离线下载:离线资源下载,万一有些人把里面的东西修改了,可能会产生意想不到的结果,怎么保证离线资源的安全。

这里有个数据,2月9号到2月18号下发资源65个,累积流量3.7PB,峰值流量1Tb/s。通过这种方式解决了下载资源的问题。

5.jpg

再就是外网接入质量,在上海跟深圳两地建立了十八个接入集群,每个城市有三网的介入,总共部署了638台接入服务器,可以支持同时14.6亿的在线。

6.jpg

所有用户的请求都会进入到接入服务器,我们建立了18个接入集群,保证如果一个出现问题的时候用户可以通过其它的接入。

但是在我们内部怎么把请求转给摇一摇服务,摇一摇处理完还要转到后端,怎么解决呢?

解决这个问题代价非常大,需要很多资源,最终我们选择把摇一摇服务去掉,把一千万每秒的请求干掉了,把这个服务挪入到接入服务。除了处理摇一摇请求之外,所有微信收消息和发消息都需要中转,因为这个接入服务本身,摇一摇的逻辑,因为时间比较短,如果发消息也受影响就得不偿失了。

不过,这恰好有一个好处,我们的接入服务的架构是有利于我们解决这个问题的。

在这个接入节点里分为几个部分。一个是负责网络IO的,提供长链接,用户可以通过长链接发消息,回头可以把请求中转到另外一个模块,就是接入到逻辑模块,平时提供转发这样的功能,现在可以把接入逻辑插入。这样做还不够,比方说现在做一点修改,还需要上线更新,摇一摇的活动形式没有怎么确定下来,中间还需要修改,但是上线这个模块也不大对,我们就把接入的逻辑这一块再做一次拆分,把逻辑比较固定、比较轻量可以在本地完成的东西,不需要做网络交互的东西放到了接入服务里。

另外一个涉及到网络交互的,需要经常变更的,处理起来也比较复杂的,做了个Agent,通过这种方式基本上实现了让接入能够内置摇一摇的逻辑,而且接入服务本身的逻辑性不会受到太大的损伤。解决这个问题之后就解决了接入的稳定性问题,后面的问题是摇一摇怎么玩,摇一摇怎么玩是红包怎么玩,在红包过程中怎么保证红包是安全的呢,红包涉及到钱,钱是不能开玩笑的。

还有一个问题是怎样跟春晚保持互动,春晚现场直播,我们怎么跟现场直播挂钩衔接起来。

7.jpg

先看红包如何发放。

8.jpg

前面说到摇一摇请求,其实是在接入服务做的,红包也是在接入服务里发出去的。

为了在发红包过程中不依赖这个系统,我们把红包的种子文件在红包系统里生成出来,切分,分到每个接入服务器里,每个接入服务器里都部署了专门的红包文件。

一个红包不能发两次,红包的发放速率需要考虑,发放红包一定有用户拆,拆了还要再抢,我们需要精确控制,确保所有请求量都是在红包系统能够接受的范围内。

在这个过程中还会有另外一个风险,用户摇到红包之后还可以有一些分裂红包分出去,他也可以不分享,不分享的也不会浪费,可以回收过来,会通过本地拉回去。这部分因为是比较少量的,问题不大,因为所有红包已经发出去了,只是补充的。这里我们就搞定了红包发放。

再就是怎么样保证红包不被多领或恶意领取,每个客户领三个红包,这是要做限制的,但这是有代价的,就是存储的代价。

9.jpg

我们在我们的协议里后台服务接入的摇一摇文件里下发红包的时候写一个用户领取的情况,客户端发再次摇一摇请求的时候带上来,我们检查就行了,这是一个小技巧,这种方式解决用户最多只能领三个、企业只能领一个限制的问题。但这个只能解决正版客户端的问题,恶意用户可能不用正版,绕过你的限制,这是有可能的。

怎么办呢?一个办法是在Agent里面,通过检查本机的数据能够达到一个目的,摇一摇接入服务例有638台,如果迫到不同的机器,我们是长连,还可以短连,还可以连到另一台服务器,可以连到不同的地方去。

还有一个问题是人海战术,有些人拿着几万、几十万的号抢,抢到都是你的,那怎么办呢?这个没有太好的办法,用大数据分析看用户的行为,你平时养号的吗,正常养号的话,都会登记出来。

怎样跟春晚现场保持互动?需要解决的问题有两个:

  • 1)是要迅速,不能拖太长时间,比如现在是刘德华唱歌,如果给出的明星摇一摇还是上一个节目不太合适,要求我们配置变更需要迅速;
  • 2)是可靠。

我们怎么做的呢?

10.jpg

春晚现场我们是专门有同学过去的,在他们电脑装了系统,可以跟我们后台进行交互的,节目变了节切一下,变动的请求会发到后台。

我们部署两套,一套在深圳、一套在上海,在这个配置里还准备了三步服务,哪一步都可以,同时还可以同步这个数据,这个数据还可以下发到所有的接入机器,会把它同步过去,不是用一种方式,而是用三种方式。

通过这种方式可以迅速的在一千台服务器成功,是不是能够达到配置一定能够用?不一定,春晚现场是不可控的,万一指令没有发出怎么办?如果六个配置服务都挂了怎么办,从上一个节目切到下一个节目的时候发生这种问题不是太大,但是主持人在十点三十的时候如果摇红包一摇啥都没有,这就怒了,口播出不来也就挂了。

11.jpg

怎么做的呢?主持人肯定有口播,口播的时间点我们大致知道,虽然不知道精确的时间点,比如彩排的时候告诉我们一个时间,后来变了,我们大致知道时间范围,可以做倒计时的配置,比如十点半不管你有没有口播我们都要发红包了。

如果节目延时太长了,你的红包十分钟发完了,之后摇不到,那也不行,这种情况下我们做了校正:在节目过程中我们不断校正倒计时的时间,设了一个策略,定了一个流程,半小时的时候要通知一下我这个时间,因为它是预估的,节目越到后面能定下来的时间范围越精确,提前告诉我们,我们就可以调整。

那时候现场是在春晚的小会议室,在小会议室看不到现场什么情况,也是通过电视看,结果电视没信号了,就蒙了,校准就不知道现在怎么回事,进行到哪一步了,当时很着急,还好后来没事,后续的几个节目还是校正回来了,最终我们是精确的在那个时间点出现了抢红包。

12.jpg

前面讲了怎么在系统解决流量的问题、请求量的问题,最重要的一点是我们预估是一千万每秒,但如果春晚现场出来的是两千万、三千万或四千万怎么办,是不是整个系统就挂掉了。

13.jpg

我们就是采用过载保护,过载保护中心点是两点,前端保护后端,后端拒绝前端:

  • 1)一个是在客户端埋入一个逻辑,每次摇变成一个请求,摇每十秒钟或五秒钟发送一个请求,这样可以大幅度降低服务器的压力,这只会发生到几个点;
  • 2)一个是服务访问不了、服务访问超时和服务限速。实时计算接入负载,看CPU的负载,在衔接点给这台服务器的用户返回一个东西,就是你要限速了,你使用哪一档的限速,通过这种方式,当时有四千万用户在摇我们也能扛得住。

五、进一步优化:v0.5测试版


这是我们的0.5测试版,对这个我们的信心指数是50,为什么只有50%的把握?

14.jpg

我们前面解决的问题都是解决用户能摇到红包,服务器还不会坏掉,但是对摇红包来说那是第一步。后面还有好几步,还要把红包拆出来,还要分享,分享完以后其它人可以抢,这个体验是要保证的。

简单分析一下可以发现前面是本人操作,后面是好友操作。

这里就存在一个契机,你可以做一些服务,一旦出现问题是可以利用的点,可以做延时。剩下的问题是保证本人操作比较好,后面出点问题可以延迟,有延迟表示有时间差处理那个东西。

1)核心体验是什么?

15.jpg

这里面我们需要确保成功,确保体验是完全OK的,确保成功的时候前面提到原型的系统里解决了摇到红包的问题,剩下的就是拆红包和分享红包。怎么样确保拆红包和分享红包的用户体验?

2)如何确保拆/分享红包的用户体验?

16.jpg

拆红包和分享红包可以做一下切割,可以切割成两个部分:

  • 1)一个是用户的操作,点了分享红包按纽;
  • 2)之后是转帐。

对我们来说确保前面一点就可以了,核心体验设计的东西再次缩小范围,确保用户操作这一步能够成功。

怎么确保呢?我们称之为“铁三角”的东西,拆/分享红包=用户操作+后台业务逻辑。这是我们能做到的最高程度了。

3)还能做得更极致吗?

17.jpg

但我们还可以做的更好一点,前面这个用户看起来还是成功的,只是入帐入的稍微迟一点点,用户感觉不到。如果我们异步队列这里挂了,或者网络不可用了,概率比较低,我们有三个数据中心,挂掉一个问题不大。万一真的不能用呢?

我们又做了一次异步,分两部分:

  • 1)一个是业务逻辑,校验这个红包是不是这个用户的;
  • 2)还有一个透传队列,把这个数据再丢到后边,其实可以相信本机的处理一般是可以成功的,只要做好性能测试基本上是靠谱的。

在后面出现问题的时候我们用户的体验基本不受损,保证绝大多数用户的体验是OK的。

六、继续打磨:v0.8预览版


我们又做了0.8的版本,预览版,信心指数70,我们认为这个东西有七成把握是可以成功的。

18.jpg

大家知道设计并不等于实现,设计的再好实践有问题也很崩溃。

正式发布前我们必须要保证:

  • 1)是全程压测;
  • 2)是专题CODE REVIEW;
  • 3)是内部演练;
  • 4)是线上预热;
  • 5)是复盘与调整。

19.jpg

技术复盘包括两部分:

  • 1)有问题的时候可以把异常问题看出来;
  • 2)二是很正常,跑的时候是不是跟想象的一样,需要对正常情况下的数据做预估的重新评估,看看是不是符合预期。

我们进行了两次预热:

  • 1)一次是摇了3.1亿次,峰值5000万一分钟,100万每秒,跟我们估算的一千万每秒差很远,当时只是针对iPhone用户,放开一个小红点,你看到的时候可以抢,发放红包5万每秒,春晚当晚也是五万每秒;
  • 2)后面又发了一次,针对前面几个问题再做一次。

20.jpg

七、正式交付:v1.0正式版


做完这两次连接后面就迎接2月18号春晚的真正考验。这是1.0正式版,信心指数达到80,我们认为80%是可以搞定的。

21.jpg

剩下20%在哪里?有10%是在现场,现场不可能一帆风顺,有可能现场摇的很High,但后面到处灭火,10%是在现场处置的时候有比较好的预案和方案能够解决,另外10%是人算不如天算,一个很小的点出现问题导致被放大所有用户受影响也是有可能的,我们很难控制了。要做出完美无缺的基本不太可能,剩下10%就是留运气。

当年2月18号跑出来的结果是这样的,当时摇了110亿次,峰值是8.1亿每分钟,1400万每秒。

22.jpg

我今天跟大家的分享到这里。谢谢大家。

(原文链接:点此进入

八、后续:文章中的热门题解答


提问 1:第一个是有一个压测,压测是怎么做的?怎么做到模拟这么大的量?还有两个不太明白的地方,防用户重复刷红包的地方会拉用户已经发的红包的历史记录,这个地方每次都会请求的话是不是每次单点?

张文瑞:先回答你压测的问题,压测分几个阶段,有一个压测工具,压测工具符合请求量的去压它,有了这个东西之后后面有全流程的压测,从所有东西的起点开始,把整个流程能够串起来,压测工具压的时候肯定要压线网系统,我们留了测试集群,放的是同样的机器去压,能够产生的结果跟我们是不是对得上。另外我们的接入,如果没有真正验证过一千万每秒的话单机测好像可以,但是比较危险。我们在客户端里做了一个触发。

提问 2:实际上还是发了一千万的请求?

张文瑞:不一定是一千万每秒。我们部署的几个集群,每个集群里几组机器,保证那部分OK就可以了。

对于第二个恶意领取的问题,其实不会有那个请求,第一个是通过Cookie,另外一部分是通过本机的Agent,通过本地计算是通过本地,是本地访问,是功能内存,不需要跑到后面访问,客户请求需要跑到后端访问。

提问 3:汇总的数据量不是很大吗?

张文瑞:有的用户可能摇到好几个。汇总这里整个挂掉是没有问题的,也不是完全没影响,对破解协议之类的,跟用户对抗的时候会受损,这部分数据就没有同步了,假设这个服务挂了或同步的网络出问题了,一般是不会出问题的,你不能让用户摇到十个红包,不能让大部分用户摇到十个红包然后其它用户没有。其它的层层递进,先做单机的,又做跨机的,前一层并不依赖后一层,你挂掉对我们来说也是可以接受的。

提问 4:最终发放的时候是靠红包系统,红包系统每秒处理多少个?

张文瑞:红包发放是在接入那里发出去的,红包不参与发放。用户拆红包的动作是要进入红包系统的,我们这里放过去的量在每秒钟五万,就是放出去,让用户摇到红包五万,红包系统本身他们预设处理十秒以上。

提问 5:还有一个问题是跟产品相关的,你用了Cookie和单机的校验,但可靠性不高,这样的情况下怎么做承诺你的设计能够承担,你怎么做产品方面分析的承诺呢?一个用户只能收到三个红包,假设这个时候有六个呢?

张文瑞:用户能摇到的红包是三个,但是他还可以抢。

提问 6:他拿到的三个红包是在接入那一块你给他算或了?是这样吗?

张文瑞:对。

提问 7:六百个服务器并发接入,如果很短的时间去接入的话呢。

张文瑞:用正版的客户端做不到这一点,他一定是拿了自己写的自动机或模拟机并发模拟。所以我们对产品的承诺正常用户是保证领三个红包,每个企业最多领到一个,但是有恶意用户,我们会一直提高对抗的水平,但是道高一尺魔高一丈,他永远想办法搞定你,我们靠后面的机制,就是多机共享数据来搞定。99.999%的情况下它可能是OK的,但是存在那么一点可能挂掉,如果挂掉我们就牺牲出那一部分,那没办法了。因为资源不是无限制的,有限资源你能做到最好的东西。

提问 8:我刚才听到在微信朋友圈那边到会有四个IDC,我连接哪个IDC写入数据的时候就写那个,再同步到其它的IDC上,怎么保证发红包的时候有那么大的量。

张文瑞:我们不用同步。用户只连到其中一个IDC,对用户进行切分,那个用户可能是属于上海的或加拿大的,你是上海的就只能连接上海的。数据本身也不需要同步的。我们的做法是这样的,我们计算出来每秒发放五万个,算好每个机发放多少,那台机按照那个量发就可以了。在红包这一块不用同步,后面的数据就靠用户点、拆。

附录1:有关微信、QQ的文章汇总


[1] QQ、微信团队原创技术文章:
微信朋友圈千亿访问量背后的技术挑战和实践总结
腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)
腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)
微信团队分享:微信移动端的全文检索多音字问题解决方案
腾讯技术分享:Android版手机QQ的缓存监控与优化实践
微信团队分享:iOS版微信的高性能通用key-value组件技术实践
微信团队分享:iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的?
腾讯技术分享:Android手Q的线程死锁监控系统技术实践
微信团队原创分享:iOS版微信的内存监控系统技术实践
让互联网更快:新一代QUIC协议在腾讯的技术实践分享
iOS后台唤醒实战:微信收款到账语音提醒技术总结
腾讯技术分享:社交网络图片的带宽压缩技术演进之路
微信团队分享:视频图像的超分辨率技术原理和应用场景
微信团队分享:微信每日亿次实时音视频聊天背后的技术解密
QQ音乐团队分享:Android中的图片压缩技术详解(上篇)
QQ音乐团队分享:Android中的图片压缩技术详解(下篇)
腾讯团队分享:手机QQ中的人脸识别酷炫动画效果实现详解
腾讯团队分享 :一次手Q聊天界面中图片显示bug的追踪过程分享
微信团队分享:微信Android版小视频编码填过的那些坑
微信手机端的本地数据全文检索优化之路
企业微信客户端中组织架构数据的同步更新方案优化实战
微信团队披露:微信界面卡死超级bug“15。。。。”的来龙去脉
QQ 18年:解密8亿月活的QQ后台服务接口隔离技术
月活8.89亿的超级IM微信是如何进行Android端兼容测试的
以手机QQ为例探讨移动端IM中的“轻应用”
一篇文章get微信开源移动端数据库组件WCDB的一切!
微信客户端团队负责人技术访谈:如何着手客户端性能监控和优化
微信后台基于时间序的海量数据冷热分级架构设计实践
微信团队原创分享:Android版微信的臃肿之困与模块化实践之路
微信后台团队:微信后台异步消息队列的优化升级实践分享
微信团队原创分享:微信客户端SQLite数据库损坏修复实践
腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率
腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(下篇)
腾讯原创分享(三):如何大幅压缩移动网络下APP的流量消耗(上篇)
微信Mars:微信内部正在使用的网络层封装库,即将开源
如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源
开源libco库:单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]
微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]
微信团队原创分享:Android版微信从300KB到30MB的技术演进
微信技术总监谈架构:微信之道——大道至简(演讲全文)
微信技术总监谈架构:微信之道——大道至简(PPT讲稿) [附件下载]
如何解读《微信技术总监谈架构:微信之道——大道至简》
微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]
微信异步化改造实践:8亿月活、单机千万连接背后的后台解决方案
微信朋友圈海量技术之道PPT [附件下载]
微信对网络影响的技术试验及分析(论文全文)
一份微信后台技术架构的总结性笔记
架构之道:3个程序员成就微信朋友圈日均10亿发布量[有视频]
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
快速裂变:见证微信强大后台架构从0到1的演进历程(二)
微信团队原创分享:Android内存泄漏监控和优化技巧总结
全面总结iOS版微信升级iOS9遇到的各种“坑”
微信团队原创资源混淆工具:让你的APK立减1M
微信团队原创Android资源混淆工具:AndResGuard [有源码]
Android版微信安装包“减肥”实战记录
iOS版微信安装包“减肥”实战记录
移动端IM实践:iOS版微信界面卡顿监测方案
微信“红包照片”背后的技术难题
移动端IM实践:iOS版微信小视频功能技术方案实录
移动端IM实践:Android版微信如何大幅提升交互性能(一)
移动端IM实践:Android版微信如何大幅提升交互性能(二)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)
移动端IM实践:iOS版微信的多设备字体适配方案探讨
信鸽团队原创:一起走过 iOS10 上消息推送(APNS)的坑
腾讯信鸽技术分享:百亿级实时消息推送的实战经验
IPv6技术详解:基本概念、应用现状、技术实践(上篇)
IPv6技术详解:基本概念、应用现状、技术实践(下篇)
腾讯TEG团队原创:基于MySQL的分布式数据库TDSQL十年锻造经验分享
微信多媒体团队访谈:音视频开发的学习、微信的音视频技术和挑战等
了解iOS消息推送一文就够:史上最全iOS Push技术详解
腾讯技术分享:微信小程序音视频技术背后的故事
腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面
微信多媒体团队梁俊斌访谈:聊一聊我所了解的音视频技术
腾讯音视频实验室:使用AI黑科技实现超低码率的高清实时视频聊天
腾讯技术分享:微信小程序音视频与WebRTC互通的技术思路和实践
手把手教你读取Android版微信和手Q的聊天记录(仅作技术研究学习)
微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)
微信技术分享:微信的海量IM聊天消息序列号生成实践(容灾方案篇)
腾讯技术分享:GIF动图技术详解及手机QQ动态表情压缩技术实践
微信团队分享:Kotlin渐被认可,Android版微信的技术尝鲜之旅
社交软件红包技术解密(一):全面解密QQ红包技术方案——架构、技术实现等
社交软件红包技术解密(二):解密微信摇一摇红包从0到1的技术演进
>> 更多同类文章 ……

[2] 有关QQ、微信的技术故事:
技术往事:微信估值已超5千亿,雷军曾有机会收编张小龙及其Foxmail
QQ和微信凶猛成长的背后:腾讯网络基础架构的这些年
闲话即时通讯:腾讯的成长史本质就是一部QQ成长史
2017微信数据报告:日活跃用户达9亿、日发消息380亿条
腾讯开发微信花了多少钱?技术难度真这么大?难在哪?
技术往事:创业初期的腾讯——16年前的冬天,谁动了马化腾的代码
技术往事:史上最全QQ图标变迁过程,追寻IM巨人的演进历史
技术往事:“QQ群”和“微信红包”是怎么来的?
开发往事:深度讲述2010到2015,微信一路风雨的背后
开发往事:微信千年不变的那张闪屏图片的由来
开发往事:记录微信3.0版背后的故事(距微信1.0发布9个月时)
一个微信实习生自述:我眼中的微信开发团队
首次揭秘:QQ实时视频聊天背后的神秘组织
为什么说即时通讯社交APP创业就是一个坑?
微信七年回顾:历经多少质疑和差评,才配拥有今天的强大
前创始团队成员分享:盘点微信的前世今生——微信成功的必然和偶然
即时通讯创业必读:解密微信的产品定位、创新思维、设计法则等
QQ的成功,远没有你想象的那么顺利和轻松
QQ现状深度剖析:你还认为QQ已经被微信打败了吗?
[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗?
QQ和微信止步不前,意味着即时通讯社交应用创业的第2春已来?
那些年微信开发过的鸡肋功能,及其带给我们的思考
读懂微信:从1.0到7.0版本,一个主流IM社交工具的进化史
同为IM社交产品中的王者,QQ与微信到底有什么区别
还原真实的腾讯:从最不被看好,到即时通讯巨头的草根创业史
>> 更多同类文章 ……

附录2:更多架构方面的文章汇总


[2] 有关IM架构设计的文章:
浅谈IM系统的架构设计
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)
一套原创分布式即时通讯(IM)系统理论架构方案
从零到卓越:京东客服即时通讯系统的技术架构演进历程
蘑菇街即时通讯/IM服务器开发之架构选择
腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT
微信后台基于时间序的海量数据冷热分级架构设计实践
微信技术总监谈架构:微信之道——大道至简(演讲全文)
如何解读《微信技术总监谈架构:微信之道——大道至简》
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
17年的实践:腾讯海量产品的技术方法论
移动端IM中大规模群消息的推送如何保证效率、实时性?
现代IM系统中聊天消息的同步和存储方案探讨
IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?
IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议
IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token
WhatsApp技术实践分享:32人工程团队创造的技术神话
微信朋友圈千亿访问量背后的技术挑战和实践总结
王者荣耀2亿用户量的背后:产品定位、技术架构、网络方案等
IM系统的MQ消息中间件选型:Kafka还是RabbitMQ?
腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面
以微博类应用场景为例,总结海量社交系统的架构设计步骤
快速理解高性能HTTP服务端的负载均衡技术原理
子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践
知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路
IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列
微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)
微信技术分享:微信的海量IM聊天消息序列号生成实践(容灾方案篇)
新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践
一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践
阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史
阿里技术分享:阿里自研金融级数据库OceanBase的艰辛成长之路
>> 更多同类文章 ……

[2] 更多其它架构设计相关文章:
腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面
快速理解高性能HTTP服务端的负载均衡技术原理
子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践
知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路
新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践
阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史
阿里技术分享:阿里自研金融级数据库OceanBase的艰辛成长之路
达达O2O后台架构演进实践:从0到4000高并发请求背后的努力
优秀后端架构师必会知识:史上最全MySQL大表优化方案总结
小米技术分享:解密小米抢购系统千万高并发架构的演进和实践
一篇读懂分布式架构下的负载均衡技术:分类、原理、算法、常见方案等
通俗易懂:如何设计能支撑百万并发的数据库架构?
>> 更多同类文章 ……

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:求教IM中单聊的数据库设计是怎么样的设计思想下一篇:社交软件红包技术解密(三):微信摇一摇红包雨背后的技术细节

本帖已收录至以下技术专辑

推荐方案
评论 3
热乎乎的。。。
引用:踏雪寻梅 发表于 2019-05-10 11:23
热乎乎的。。。

能把这样的文章吃下去,下份工作工资一定翻倍。。
签名: 《红包技术解密(五):微信红包系统是如何实现高可用性的》http://www.52im.net/thread-2564-1-1.html
引用:JackJiang 发表于 2019-05-10 11:29
能把这样的文章吃下去,下份工作工资一定翻倍。。

打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部