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

Posted 2020-12-21

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

导读：内容变现平台是当今互联网的一个风口，其背后都需要互联网金融的支持，上个月微博商业产品部联合小米支付、天弘基金等金融技术团队策划了首届互联网金融系统沙龙，围绕在互联网金融过程中碰到技术架构问题与业界展开分享及交流。本文是刘其秀在沙龙上的演讲，授权高可用架构发表。

刘其秀，新浪微博技术 leader，曾在金融界、赶集等公司担任架构设计和技术管理工作，专注于高可用、高并发、可伸缩系统架构研究，对 IM、防爬虫、搜索、股票相关技术领域均有涉猎。目前在微博商业产品部担任资深研发工程师，致力于后端分布式、金融交易领域相关技术的研究和探索。

互联网风口的环境

与背后的金融技术

6 月 16 日微博超级网红节在上海举办，有 2 亿人在网上看直播，超过 8 亿次点赞，可见网红真的很红。由于网红经济的兴起，虎牙、斗鱼和熊猫 TV 等直播平台也站在了今年的风口上。

今年另外一个风口行业就是内容变现平台，这样的产品有分答和值乎、新浪微博的产品付费阅读和打赏等。今天给大家介绍一下付费阅读和打赏的技术实现。

付费打赏业务情况

付费打赏项目 2014 年上半年就已经上线，上线后为很多自媒体作者带来不菲的收入。因此吸引了不少的自媒体用户入驻微博，同时受到明星企业微信和支付宝的跟进。付费阅读是前向付费的产品，先付费再阅读。打赏是后向付费，看视频或者文章觉得好就可以打赏一点。所以付费和打赏产品其实是需要基于内容的。

上线以来，付费阅读接入了多个业务方，文章、视频、直播、股票直播室等，经常上微博的同学应该能注意到。所以我们的流量也非常大，达到十亿的数量级。由于大家对内容版权越来越重视以及网红经济的兴起，整个 2015 年付费打赏业务量增长了数十倍。

微博付费打赏架构

架构之分层结构

下面我们整个付费打赏的架构，它是分层架构，分为接入层、服务层、交易系统、数据层和业务层。

分层的目的是什么？

• 首先，可以方便的把系统拆分成交易金融、服务、应用开发这三种不同性质的系统，交易金融重视质量、一致性，服务重视性能、可用性，应用开发注重迭代速度。
• 其次，很容易做垂直拆分，当业务增长到一定级别的时候，我们就可以很方便对这个系统进行水平、垂直拆分。例如，将交易系统在系统和数据库中单独剥离出去。

架构之数据库

数据方面，我们还是采用传统的分库分表，硬盘我们使用的是 SSD 硬盘，这给我们带来了巨大性能的提升，去年我们系统出现一个 BUG，导致所有请求全部打到主库上去了，每秒大概将近 2 万次的请求，依然抗住了。

架构之异步化设计

在系统中，我们采用了大量的异步化来提升系统的性能，举个例子，在交易系统中，用户支付、退款之后，采用异步的方式通知到付费阅读和打赏，他们各自处理自己的业务数据，交易系统只处理订单相关数据，这样就能很大程度上提高订单的并发量。使用异步化，对于金融系统来说必须要有可靠消息系统，像 MetaQ、notify 等。

监控系统

对于付费打赏这个业务来说，最重要的就是监控系统，因为我们有很多业务方的接入，所以业务的增长很不可控。所以我们开发或者合作开发了很多监控系统，像容量监控系统，监控各个资源使用情况，包括 mysql、mc、redis 等；错误监控系统，用来查看系统中隐藏的测试不容易浮现的 bug 等。

小额免密产品

今年三月份的时候微博打赏上线一个小额免密功能，小额免密就是在用户授权的情况下，不需要用户再输入支付密码直接扣钱，很大程度上提高了用户的使用体验。

对我们技术挑战主要体现在像一致性、数据安全等问题上。

架构之幂等与超时设计

首先要考虑的问题就是幂等。幂等对于金融系统非常重要，当我们调用一个接口的时候，会出现三种状态：成功、失败、不确定。不确定往往是由于 TIMEOUT 超时引起的。在出现超时的时候，我们往往会重新请求一次接口，所以这个时候就要保证多次请求只会处理一次，这就是幂等。

幂等的实现包含两点：请求要包含唯一 id，像我们在支付的时候都会创建一个订单 id；对这个 id 我们在数据库中要保存状态。在我们的系统中，用户如果在打赏的时候超时，再点一次两次，我们只会扣用户一次钱。

架构之分布式事务处理

在小额免密产品中，我们要保证用户、打赏、微博支付三者的最终一致性，所以我们开发定期校对系统，定期检查，保证微博支付和打赏这边的数据一致性，分为两种情况：

1、 支付成功，打赏不成功。这种情况只需要调用打赏业务处理接口就可以了

2、 打赏成功，支付不成功。那这就需要打赏这边的接口支持事务补偿机制，也就是把之前提交的事务回滚回来。

对于这些接口都要求支持幂等。

关于更多的关于分布式事务相关可以参考支付宝程立老师的《大规模 SOA 系统中的分布事务处理》，也可参考文末分布式事务相关阅读文章。

架构之系统安全

最后讲一下在小额免密产品中我们采用的安全策略。

• 产品角度。技术的人往往会有一个误区，想用技术解决所有问题，但是有些情况下使用产品方式解决问题可能更简单。在小额免密的产品中，我们采用 T + 3 的方式进行资金监管，每天免密金额受到限制，再加上完备的投诉机制，即使账户被盗了，资金丢失的成本也会很高。所以上线了这么久，我们还没处理过一起这样的投诉。
• 技术角度。在技术上面做了很多安全方面的考虑，请求采用 https 加密防止被监听，每个请求都是唯一性，保证它不可能被重放。
• 监控侧，我们做了诸如异常交易报警，用户资产报警之类。

由于演讲时间的原因，今天主要跟大家做上述一个简单介绍，感兴趣的朋友欢迎在文章留言进一步交流。

相关阅读

点击链接阅读相关文章

• 互联网金融系统技术沙龙：余额宝技术架构及演进
• 互联网金融系统技术沙龙:微博众筹架构设计
• 互联网金融系统技术沙龙:小米风控实践
• 分布式事务必读：保证分布式系统数据一致性的6种方案

想更多了解本期互联网金融系统沙龙内容，请关注「ArchNotes」微信公众号以阅读后续文章。转载请注明来自高可用架构及包含以下二维码。

高可用架构

改变互联网的构建方式

长按二维码 关注「高可用架构」公众号

专注互联网领域求职的拉勾将度过第三个生日，在这个特别的时间点上，拉勾想用36个问题，邀请所有坚持不平凡的职场人一起回答，请点击阅读原文。