微博付费打赏架构:一个社交场景下准金融项目开发和实践

whocases 8年前
   <p>导读:内容变现平台是当今互联网的一个风口,其背后都需要互联网金融的支持, 上个月微博商业产品部联合小米支付、天弘基金等金融技术团队策划了首届互联网金融系统沙龙,围绕在互联网金融过程中碰到技术架构问题与业界展开分享及交流。本文是刘其秀在沙龙上的演讲,授权高可用架构发表。</p>    <p>刘其秀,新浪微博技术 leader,曾在金融界、赶集等公司担任架构设计和技术管理工作,专注于高可用、高并发、可伸缩系统架构研究,对 IM、防爬虫、搜索、股票相关技术领域均有涉猎。目前在微博商业产品部担任资深研发工程师,致力于后端分布式、金融交易领域相关技术的研究和探索。</p>    <h2>互联网风口的环境</h2>    <h3>与背后的金融技术</h3>    <p>6 月 16 日微博超级网红节在上海举办,有 2 亿人在网上看直播,超过 8 亿次点赞,可见网红真的很红。由于网红经济的兴起,虎牙、斗鱼和熊猫 TV 等直播平台也站在了今年的风口上。</p>    <p><img src="https://simg.open-open.com/show/5163a9f0932593bfd4e876f7f6dff2e3.jpg"></p>    <p>今年另外一个风口行业就是内容变现平台 ,这样的产品有分答和值乎、新浪微博的产品付费阅读和打赏等。今天给大家介绍一下付费阅读和打赏的技术实现。</p>    <h3>付费打赏业务情况</h3>    <p>付费打赏项目 2014 年上半年就已经上线,上线后为很多自媒体作者带来不菲的收入。因此吸引了不少的自媒体用户入驻微博,同时受到明星企业微信和支付宝的跟进。付费阅读是前向付费的产品,先付费再阅读。打赏是后向付费,看视频或者文章觉得好就可以打赏一点。所以付费和打赏产品其实是需要基于内容的。</p>    <p>上线以来,付费阅读接入了多个业务方,文章、视频、直播、股票直播室等,经常上微博的同学应该能注意到。所以我们的流量也非常大,达到十亿的数量级。由于大家对内容版权越来越重视以及网红经济的兴起,整个 2015 年付费打赏业务量增长了数十倍。</p>    <h2>微博付费打赏架构</h2>    <h3>架构之分层结构</h3>    <p>下面我们整个付费打赏的架构,它是分层架构,分为接入层、服务层、交易系统、数据层和业务层。</p>    <p><img src="https://simg.open-open.com/show/ea3ac92144a4aac661d5321ac52a5831.jpg"></p>    <h3>分层的目的是什么?</h3>    <ul>     <li> <p>首先,可以方便的把系统拆分成交易金融、服务、应用开发这三种不同性质的系统,交易金融重视质量、一致性,服务重视性能、可用性,应用开发注重迭代速度。</p> </li>     <li> <p>其次,很容易做垂直拆分,当业务增长到一定级别的时候,我们就可以很方便对这个系统进行水平、垂直拆分。例如,将交易系统在系统和数据库中单独剥离出去。</p> </li>    </ul>    <h3>架构之数据库</h3>    <p>数据方面,我们还是采用传统的分库分表,硬盘我们使用的是 SSD 硬盘,这给我们带来了巨大性能的提升,去年我们系统出现一个 BUG,导致所有请求全部打到主库上去了,每秒大概将近 2 万次的请求,依然抗住了。</p>    <h3>架构之异步化设计</h3>    <p>在系统中,我们采用了大量的异步化来提升系统的性能,举个例子,在交易系统中,用户支付、退款之后,采用异步的方式通知到付费阅读和打赏,他们各自处理自己的业务数据,交易系统只处理订单相关数据,这样就能很大程度上提高订单的并发量。使用异步化,对于金融系统来说必须要有可靠消息系统,像 MetaQ、notify 等。</p>    <h3>监控系统</h3>    <p>对于付费打赏这个业务来说,最重要的就是监控系统,因为我们有很多业务方的接入,所以业务的增长很不可控。所以我们开发或者合作开发了很多监控系统,像容量监控系统,监控各个资源使用情况,包括 MySQL、mc、redis 等;错误监控系统,用来查看系统中隐藏的测试不容易浮现的 bug 等。</p>    <h3>小额免密产品</h3>    <p>今年三月份的时候微博打赏上线一个小额免密功能,小额免密就是在用户授权的情况下,不需要用户再输入支付密码直接扣钱,很大程度上提高了用户的使用体验。</p>    <p><img src="https://simg.open-open.com/show/72ccf8d890cdc65df33e75b4330aad4a.jpg"></p>    <p>对我们技术挑战主要体现在像一致性、数据安全等问题上。</p>    <h3>架构之幂等与超时设计</h3>    <p>首先要考虑的问题就是幂等。幂等对于金融系统非常重要,当我们调用一个接口的时候,会出现三种状态:成功、失败、不确定。不确定往往是由于 TIMEOUT 超时引起的。在出现超时的时候,我们往往会重新请求一次接口,所以这个时候就要保证多次请求只会处理一次,这就是幂等。</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/af6da81c4264b51241518aca5b4df5ab.jpg"></p>    <p>幂等的实现包含两点:请求要包含唯一 id,像我们在支付的时候都会创建一个订单 id;对这个 id 我们在数据库中要保存状态。在我们的系统中,用户如果在打赏的时候超时,再点一次两次,我们只会扣用户一次钱。</p>    <h3>架构之分布式事务处理</h3>    <p>在小额免密产品中,我们要保证用户、打赏、微博支付三者的最终一致性,所以我们开发定期校对系统,定期检查,保证微博支付和打赏这边的数据一致性,分为两种情况:</p>    <p>1、  支付成功,打赏不成功。这种情况只需要调用打赏业务处理接口就可以了</p>    <p>2、  打赏成功,支付不成功。那这就需要打赏这边的接口支持事务补偿机制,也就是把之前提交的事务回滚回来。</p>    <p>对于这些接口都要求支持幂等。</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/b190ae1b92e81564a2d6fb44604aaaba.jpg"></p>    <p>关于更多的关于分布式事务相关可以参考支付宝程立老师的《大规模 SOA 系统中的分布事务处理》,也可参考文末分布式事务相关阅读文章。</p>    <h3>架构之系统安全</h3>    <p>最后讲一下在小额免密产品中我们采用的安全策略。</p>    <ul>     <li> <p>产品角度。技术的人往往会有一个误区,想用技术解决所有问题,但是有些情况下使用产品方式解决问题可能更简单。 在小额免密的产品中,我们采用 T + 3 的方式进行资金监管,每天免密金额受到限制,再加上完备的投诉机制,即使账户被盗了,资金丢失的成本也会很高。所以上线了这么久,我们还没处理过一起这样的投诉。</p> </li>     <li> <p>技术角度。 在技术上面做了很多安全方面的考虑,请求采用 https 加密防止被监听,每个请求都是唯一性,保证它不可能被重放。</p> </li>     <li> <p>监控侧 ,我们做了诸如异常交易报警,用户资产报警之类。</p> </li>    </ul>    <p>由于演讲时间的原因,今天主要跟大家做上述一个简单介绍,感兴趣的朋友欢迎在文章留言进一步交流。</p>    <p><a href="http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=2653547549&idx=1&sn=20af803e5b822ed0376e033ed1c5f1b8&scene=0">阅读原文</a></p>    <p> </p>