作者 | 馬超 編輯 | 夕顏
來源|CSDN（ID:CSDNnews）
日前，武漢合眾易寶科技有限公司（簡稱“合眾支付”）股權變更引起廣泛關注。因為穿透下來，接盤方背後站着的實際控制人是字節跳動創始人張一鳴。
儘管張一鳴掌控的其他公司斬獲支付牌照並不意味着字節跳動直接掌控支付牌照，但字節跳動對此的回應透露出了默認的味道。9月3日，字節跳動方面向多家媒體確認獲取合眾支付牌照的信息，並表示此舉將有利於提升用户體驗，與其他支付方式一起更好地服務字節跳動旗下產品的用户。此次，字節跳動已獲三張金融牌照，分別涉及保險經紀、互聯網小貸、第三方支付。
沒有支付牌照的互聯網公司，算不上是一家行業巨頭，阿里、騰訊、京東、美團、百度等都手握這一重要底牌。不僅如此，微眾、百信等互聯網銀行其背後也都有BAT的身影。
第三方支付牌照是字節跳動借抖音進軍電商交易的閉環，另外一方面對於字節跳動完成今年的業績也是大有好處。前幾年，字節跳動的營收上漲很快，從2016年的60億元竄升到2019年的1400億元，據稱今年字節的營收目標要突破2000億，而無論是年初的新冠黑天鵝，還是近日TikTok的強賣事件，對於字節跳動的高速增長而言都蒙上了一層陰影。在這樣的背景下，字節渴望通過支付牌照建立自己的金融帝國，一掃之前陰霾的用意也就非常明顯了。
不過就公開資料來看，字節跳動之前的技術棧還是聚焦在AI算法推薦與視頻技術等領域，沒有過支付系統的相關經驗，類似於Oceanbase、TiDB這類金融級數據庫的研發經驗似乎更是缺失，然而金融級數據庫是恰恰是支撐支付系統的重中之重。下面，筆者就帶大家一起來走近三方支付背後的金融帝國。
支付體系也險些被卡脖子，我國支付體系建立的前世今生
其實在美國對我們各種斷供的時候，筆者作為一名長年在金融行業工作的程序員，十分慶幸在支付系統方面我國現在走在了世界的前列，不管是二代大小額支付系統CNAPS，還是跨境人民幣支付系統CIPS，我國在支付系統的建設上已經形成了完整的體系，否則美國真要把我們從SWIFT體系中踢出去，那真的可能是我們不能承受之重了。
年輕的讀者可能不會了解，其實我們在2000年上線的一代支付系統還是世界銀行援建的項目，從設計到實現全部依靠國外的技術，因為當時我國的程序員是不懂金融的，而金融業也不懂IT，在2000年之前我國金融行業的IT部門，基本都是由會計部門下屬的，在那之前我們幾乎沒有一個現代化的電子支付平台。
在上世紀90年代初期，銀行的IT系統有個專有的術語叫“會計電算化”，從這個名字也能看出來，這是將會計使用的賬本由人工記賬變成電子記賬，這種系統的設計不太會考慮什麼互通互聯的場景，當時各大銀行基本都在體系內部開展卡系統的研發，也就是將銀行的會計操作打造以各自零售客户資源為依託銀行卡網絡，形成了互相獨立的發展模式。這種分佈式0.1版本架構的好處就是銀行無法推託責任，必須對用户的投訴問題負全責，不過其缺點也十分明顯，那就是各行的銀行片標準不統一，遇到有刷卡需求的客户，商家要先找到那家銀行的POS機開機簽到後才能完成收款，整個交易流程比較繁鎖。
後來為了提高銀行卡使用的便利性，國家啓動了“金卡工程”，中國銀聯在也在各地卡中心的基礎上建立起來。在成立之初，銀聯發佈了《銀行卡聯網聯合技術規範》，通過統一標準全面整合了ATM和POS等自助終端，建立起了現在互聯互通的支付清算體系。
但是隨着交易鏈條的不斷增長，系統也不斷的趨向複雜，目前最簡要的支付業務流程都要用聯機交易、風險控制、日終處理等三大模塊共同參與完成，而每個模塊分出來還有很多內容，下面這麼複雜的圖其實也只能説個大概，而當銀行卡使用到一定階段以後已經略顯僵化，靈活方便、用户體驗更好的三方支付產品也是在這個背景下出現的。
風控與便利的對決，銀行支付VS三方支付
可能很多讀者都有這樣的一個問題，為什麼銀行不做三方支付功能，如此之大的蛋糕為什麼要拱手讓人呢？客觀地講，這不能單純歸罪於銀行不思進取，其背後深層次原因還是在於我國銀行本質上還是有政府信用背書的，風險控制才是銀行的首要任務，在這樣的語境下求穩是銀行安身立命之本。
下面舉個例子説明，相信各位讀者在生活中進行水、電費繳納或者信用卡還款的時候往往都會看到這個界面：
凡是這種帶有“銀行處理中”字眼的交易其實都是非實時性的交易。支付系統鏈條中各方本質上互不信任的，所以對於這種實時性要求不高的業務以一般以銀行的處理回執作為支付憑證，用作仲裁的依據。所以這個回執的發送都是極度審慎的，具體表現就是一遇風吹草動處理時間就會變長。可能大家都有親身經歷，雖然絕大部分時間在網上繳納電費響應都很快，不過真到了年底出賬那幾天可能是半天等不到個結果，本質上都是由於審慎的風控思維。
第二個比較典型的例子，就是大額轉賬了，大家日常在網銀轉賬時選擇通道時經常會看到以下畫面，其中的大額通道其實就是指通過大額支付系統轉賬了。大額的特點是實時到帳，但是細心的讀者也會發現，這個大額轉賬的通道，不是7*24小時全天開啓的，是有營業時間的，這本質上也是因為銀行支付系統需要一定的對帳時間，來確保自身的賬務沒有問題。
而第三方支付的出現恰好彌補了便利支付產品方面的空缺，這種支付模式是由支付寶首創的，買方選購商品後，使用第三方平台提供的賬户進行貨款支付（支付給第三方），並由第三方通知賣家貨款到賬、要求發貨；買方收到貨物，檢驗貨物，並且進行確認後，再通知第三方付款；第三方再將款項轉至賣家賬户。銀行基於自身風險考慮是不會對於自己不熟悉的商户或者買家提供信用擔保的，這是一個銀行不會進入的領域，因此在三方支付牌照剛剛興起時，引得無數機構競相爭奪。
不過2017年初，中國人民銀行發佈了支付新規明確了第三方支付機構在交易過程中，產生的客户備付金（即從買家付款到賣家收款之間產生的資金池），今後將統一交存至指定賬户，由央行監管，支付機構不得挪用、佔用客户備付金。而隨着這項規定的出台，這也從某種程度上度絕了三方支付公司挪用備付金進行投資的渠道，風光一時的三方支付自此降温，成為了金融巨頭才會考慮的細分市場。
Sql or NoSql？這是個問題
在解讀了支付系統自身的邏輯及發展歷史之後我們再聊聊其背後的核心技術。考慮到抖音直播帶貨這麼大的交易量還需要支持秒殺場景的話，必須有一個強力的數據庫做核心。
目前數據庫基本分為兩種類型，一種是非關係型(NoSQL)數據庫，這是一種類似於Hadoop式的Key-Value型數據庫，這種數據庫專門為海量數據服務，不過要求數據之間的關聯計算不能太多，像字節視頻社交的相關業務用户每條動態之間幾乎不會進行關聯計算的，因此相信之前字節對於NoSql數據庫應該是比較熟悉的；另外一個是在關係型（Sql）數據庫，比如電商場景下客户的一筆交易既要動商家的庫存又要動買家的帳户餘額，這種場景下一般關聯計算還是要用關係型數據庫的。而像“雙十一”這樣的秒殺場景，對於數據庫來講，既提供海量數據服務又提供高性能關聯計算服務，這種明顯是需要技術積累的，而打通NoSql與Sql任督二脈的國內大廠除了阿里之外，好像只有2015年紅包大戰前的騰訊做到了。
在筆者所在的銀行業，一般將涉及客户帳餘額變化的交易稱為動帳類交易或金融類交易，微信紅包的金額可能不大，但其實用户每搶一次紅包都涉及一筆金融交易，而如此大併發的金融類交易，在之前業界根本聞所未聞，在紅包的背後關鍵要靠 數據庫的支持。在微信支付之前，騰訊與字節一樣也基本沒有過金融的業務場景，而相比之前的社交場景，金融交易對於數據庫的在性能、災難備份等等方面的要求要高得多，想支撐微信紅包首先要解決數據庫的問題。
當時的騰訊在數據庫方面已經有了不少的積累，擁有了兩個自研的數據庫，一個是NoSql的CKV也就是TBASE的前身，還有一個是Sql型的CDB也就是TDSql的前身，不過當時兩個數據庫團隊一起評估了一下微信紅包的流量，這是一個天量加關聯計算性能全都有要求的場景，所以當時的結論是CKV和CDB，恐怕都無法支撐起微信紅包的一片天地。
據稱當時騰訊團隊甚至想到是否要採用類似於網遊的分區策略，也就是讓用户在自己的服務區內部搶紅包，想跨區還得重新註冊ID。不過這個問題在春節前兩個月時解決了，騰訊的數據庫技術團隊把CKV和CDB合體了，他們CKV 中插入了CDB的“樹結構”，這樣在搶紅包的時候，系統就不用告訴數據庫每個數字的變化，而是數據庫根據已有的關鍵數據，自己補全剩餘的數據。CKV與CDB的聯合大大提升數據庫的效率，也成了至今還被我國數據庫界同仁所津津樂道的一段美談。
爆發式增長的靠的是一招鮮吃遍天，而對於擁有遠大志向的公司來講，沒有深厚的內功根本無法開宗立派。不過在基礎內功領域內的競爭，並不像流量之戰一樣吸引眼球。正如淘金時代的最大受益者不是金礦主，而是那些賣鏟子的人，所以我們看到科技巨頭在基礎技術儲備方面都有非常驚人的儲備，而如果字節跳動拿到支付牌照，也同時吹響他們要向基礎技術進行探索與轉型的號角，那麼字節跳動的未來可期。