微博付費打賞架構：一個社交場景下準金融項目開發和實踐
導讀：內容變現平臺是當今互聯網的一個風口，其背后都需要互聯網金融的支持， 上個月微博商業產品部聯合小米支付、天弘基金等金融技術團隊策劃了首屆互聯網金融系統沙龍，圍繞在互聯網金融過程中碰到技術架構問題與業界展開分享及交流。本文是劉其秀在沙龍上的演講，授權高可用架構發表。
劉其秀，新浪微博技術 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 加密防止被監聽，每個請求都是唯一性，保證它不可能被重放。
-
監控側 ，我們做了諸如異常交易報警，用戶資產報警之類。
由于演講時間的原因，今天主要跟大家做上述一個簡單介紹，感興趣的朋友歡迎在文章留言進一步交流。