導讀
近來經歷了一件事，就是小碼農所在的公司由于被某大廠競購以后要進行融合了，其他方面的融合就沒必要說了，明天俺們只是聊一下支付系統融合的事情。首先從好多互聯網公司的發展經驗來看，隨著多條業務線的發展，最終都是會催生出建設統一支付系統的強烈需求。
這是為何呢？由于支付系統太重要了，它擁有公司所有的現金流水，是進行業務清算、財務核算、上市審計以及后續各種財務信息管理的關鍵系統之一。一家公司被競購后新老總們最關心的事也莫過分財務數據的確切性了，之前小碼農從事支付系統的研制工作加入的都是早已比較成熟的團隊，去建設的支付系統也都是為了幫助所在公司來實現上述的目標和戰略，而所采用的策略也都是在強悍的下層的支持下進行業務線統一支付入口的歸集。
只不過這一次作者所加入的是一家互聯網創業公司，而在支付系統的建設上，也屬于比較混亂和中級的階段，因而在被競購后屬于是在另外一個強悍下層的支持下而被統一的一方而已。其實從客觀的角度看，這也是一件十分合理的事情，由于一個大的集團公司無論是從成本還是統一管理的角度看都是沒有必要重復建設多套支付系統的，而對一家被競購的公司而言，其支付系統肯定也是首先須要被融合的關鍵系統之一。
作者對此持開放和豁達的心態，雖然這個過程對個人會有一些影響。只是由于在此之前經歷了好多的艱辛，認為有好多事情還是值得總結一下，因而才想著寫一篇文章來追憶下這個過程。而總結的目的，也只是希望還能對未來會經歷這樣一個過程的公司，有一點參考價值，由于雖然是被融合，假如做的比較好的話也會讓融合的過程會愈加容易一些，起碼能夠得到一些口碑，否則就很容易遭人罵了，而從技術本身看也會是一種失敗。
被忽略的團隊
關于支付團隊是否是被忽略的團隊的問題，可能因公司而異（或則其實因不同公司處于關鍵崗位的技術是否具備這樣的經驗和遠見而異），可能有一些互聯網創業公司在發展早期并不是很Care這件事微信訂貨系統，由于初期的業務也確實沒有這么復雜，在業務代碼中接個微信、支付寶能有多難，兩三個人都嫌多還想造成哪些樣的注重？
的確，作者最開始加入這家互聯網創業公司時，真的就只是在業務代碼中對接了一個支付寶、微信，看上去似乎真的是沒有這么復雜，在人員方面也就是兩個沒有太多支付經驗的研制而已，連即將的支付訂單流電表都沒有，還基本上是與業務訂單耦合在一起的那個。
但是，其實這一切似乎也并沒有影響公司業務的蓬勃發展，在線收款業務量也是下降迅速，每晚好幾個億的進帳。只是這個時侯，會時常出現好多掉單而已，總之用戶投訴了，寫條SQL改下訂單狀態，要么退貨，要么用SQL進行下業務處理。
其實，看上去一切并沒有這么復雜，只是前面又降低了幾個新的支付渠道，而支付寶、微信這些由于開了新的入口（如和微信小程序合作，支付寶第三方合作之類）又申請了下新的微信、支付寶商戶號。
從截至到以上階段的場景上剖析，到目前為止都只是在雙向的進行收款操作。而此后的事情可能就有點戲曲性了，由于忽然某三天，發生了擠兌的事，系統的退貨懇求迅速降低，其實，此時大部份的退貨懇求還都只是走原路進行全額退票的操作，還沒有部份退貨等一些復雜的業務退貨情況，而此時的退貨掉單則有點扯了，由于這造成了大量用戶早已退貨，而業務系統邏輯并沒有更新狀態的情況，此時此刻也就為后續財務數據的混亂埋下了相應地伏筆（之前的支付掉單處理得不及時，也是在埋伏筆）。
雖然更為糟糕的是，由于有些用戶太過分忠誠，支付的訂單時間過長，早已超出了第三方渠道容許進行原路退貨返回的年限，而此時由于未能通過系統手動進行原路退票，最終沒有辦法客服小妹妹只能人工搜集顧客上報的資料（如支付寶帳號），之后通過Excel由哪兩位悲催的開發去通過手工的形式整理后通過單獨申請的支付寶代付帳號進行轉帳退貨操作，雖然這些方法也沒有哪些太大問題，只是比較原始而已。的確是這樣，但是不幸的是，只是這些人工操作時常都會失敗，須要重新發起和進行系統訂單狀態的更新（假如真的把錢給他人轉成功了，得用SQL把狀態給改了啊），而這個過程由于人工誘因，致使了一些狀態未更新的情況，以及匯款重復的小失誤，而這也為后續財務數據的混亂埋下了另外一筆伏筆。
見到這兒，其實不少朋友就會驚訝，這臥槽為何不設計相應的機制來解決呢？所以，這個時侯開始有人談起了支付系統構建的問題。而此時作者剛好加入這家公司，所以心想也算一個機會，于是也提出的自己的構建方案。細節不提了，只說一個基本的支付系統應當是哪些樣，如右圖所示：
于是作者激情滿滿的找到了領導，提出了自己的看法。但是，令人沒想到的是，還有個項目由于也涉及到一些支付功能的構建，所以須要找人相關人員溝通下，好吧，此時才曉得原先支付系統早已在秘密地被重塑了，只是正常開發和維護支付系統的人竟然不曉得這件事。也罷，而讓人更意想不到的事，這是竟然還不算完，由于還有另外一個團隊，屬于另外一個VP領導下的團隊也在進行支付系統的構建，只是正常的支付團隊以及秘密構建的項目都還彼此不曉得而已。
說到這兒，仔細想想，作者也是很驚訝，不過好歹由于作者提出的這個看法并鼓起勇氣和大鱷溝通，終于讓你們彼此曉得了這件事，也算是一個良好的進步和開端。而與此同時，還有另外一個團隊在開發所謂的財務系統（實際上就是作者圖中所規劃的帳目系統，其實前者由于種種胡扯的因素，在做了兩月以后做黃了，以至于到目前為止依然缺位這一塊，而競購方希望融合方法則正是所有的業務線接入她們統一收銀臺的同時，還須要接入其帳目系統，這樣資金流、業務流就完成單向閉環了，這樣業財核實、收入估算就可以通過集團統一而完備的系統進行集中處理了）。
于是乎，似乎此時此刻，這件事應當是奔向好的方向發展了，支付系統應當是在比較充足的資源配置的情況下，而且經過合理的設計后開始有計劃有步驟地構建了。但是，不幸的事，此時此刻又出現了新的攪局者，新來了一位貌似很有經驗的產品總監，提出要建設一套很牛逼的統一交易系統，而支付系統其實只是其中底層的一個小部份而已。
這么如此，最終經過N輪的推諉、溝通以及團隊利益的苦惱廝殺，最后就由某甲團隊開始進行支付系統的構建了，與此同時作者呢由于剛來，所以就做起了你們都認為很不起眼的對帳工作了。但是，后續支付系統的構建，并沒有完成徹底的重新打造，整個系統的訂單模型并沒有進行脫胎換骨的整修和升級，對于歷史數據的處理，也是避重就輕，只是簡單的在新的支付系統的代碼層面進行了適配，并采用了無敵的詞尾策略，這么至今還是詞尾（客觀地究其緣由，由于那種團隊實際參與構建的也只有2～3人，在經驗和資源缺少的情況下，也很難將這件事做的相對全面而完整）。
以上種種也就為支付系統的先天殘缺，資金數據的混亂以及后續為了適配各類新業務而疲于奔命，因而造成更多的不確定埋下了深深的伏筆。而這其中，又經歷了不同主管的更換，但其實沒有一個是專業的，于是締造了現現在的種種頑疾。
通過上述的曲折歷程的回顧，這可能并不像是一個技術問題，而更多的像是由于創業公司的技術管理混亂而造成一種扭曲的現象。其實換一個CTO就不一定會是這些狀態，所以這些情況是否屬于共性問題，也就須要你們自己按照自身公司的實際情況進行判別了。只是在這兒作者將其扼要的怪罪為對支付團隊統一建設的一種忽略吧。
有問題的組織
關于這個問題，不同的公司的情況可能是不一樣的，正如前面所說，初期在業務代碼中對接個支付寶、微信的插口其實并不是太復雜的事，而且須要說明的是假如考慮到未來業務的擴充所造成的復雜性，而且在早已開始構建支付系統的情況下，則是一定要做到“麻雀雖小，臟腑俱全”，之所以如此說，緣由在于支付系統是一種對數據一致性要求十分高，而且又很難單純的從某一個小的方面保證數據一致性的系統，它須要一個完整的體系來保證。
而前面提及的復雜性，就有好多種情況了，比如假如涉及系統退貨，退票本身都會存在眾多的復雜性，如全額原路退貨、部分原路退貨、在線匯款退貨、線下匯款退貨等，但是不同的支付渠道所能支持的程度還有差別。
另外，假如涉及多渠道、同一渠道不同的商戶主體，以及工行卡支付／非交行卡支付，海外支付多發的等情況，則帶來的復雜性也會相應地降低。由于此時支付系統除了須要滿足參數配置化、渠道路由化等要求，支付方法、交易方法所形成的數據訂單也須要具備完整的儲存邏輯。
其實，上述邏輯復雜度的降低也不是一開始就是這樣的，而是隨著業務發展逐漸遞增的。所以對于支付團隊的配置，也沒有必要一開始就配置一個大的團隊，并且作為團隊的技術，一定要清楚在哪些階段須要哪些樣的人員配備，但是明晰的指定一名具有一定專業度的支付團隊技術來帶頭進行有組織、有計劃地構建工作，而不是在這個問題上含混不清，由于根據個人的經驗，在這個事情上的瞎競爭似乎是沒有哪些用處的，最終可能會帶來混亂。
支付訂單模型
在具體討論怎樣對支付訂單模型進行設計討論之前，和你們一起回顧了一些團隊發展和建設的問題，由于起碼在作者目前看來，最本質的問題并不是出在技術本身上，而是由于團隊技術管理混亂，帶來了一系列的弊端。
但好多時侯，其實以上種種并不是我們作為普通技術人員本身就能干預得了的，由于這常常牽涉好多技術以外的誘因。這么假如假定你承當了這一角色，或則作為一名具體的工程師，在你具體構建或設計支付系統時，怎樣盡可能地想得長遠一些呢？這兒有作者依據自身經驗設計的一套邏輯模型，供你參考。
上圖是一張精簡的關于支付系統訂單模型設計的圖，在模型中我們將訂單分為交易&支付兩個層面，之所以要如此界定，是在于我們進行支付系統開發時好多時侯是須要滿足一部份業務邏輯的，而設置交易訂單的目的則是為了屏蔽這些業務不確定性而帶給支付訂單本身的復雜性。
在這個模型中，交易訂單作為與業務交易映射的一張記錄表，比如業務A通過支付系統發起了一筆沖值交易（如10塊錢），這么都會在交易訂單中插入一條10塊錢的沖值交易流水，而這筆沖值流水正常情況下可以通過相應地支付渠道進行支付，可以一次性支付10塊錢（插入一條對應的支付訂單流水），也可以支付兩次5塊錢，但是還可以分別使用不同的支付渠道（分別插入兩筆對應的5塊錢的支付訂單流水），所以交易訂單與支付訂單的關系為1:N。
之所以容許這樣的情況發生，是由于在實踐中，由于渠道限額，業務容許重復發起支付等誘因，所以必須容許進行拆單支付的情況發生。而倘若在這些情況下又須要容許交易進行退票的話，為了精簡數據儲存，對于交易訂單可以通過狀態機進行處理（如設置交易退貨狀態），而對于支付來說，退票本身也是支付流水，所以不應當直接在支付訂單流水上進行狀態修改，而是應當單獨設計獨立的退貨流電表，只是須要在退票流電表中設置原始支付的訂單信息，以及退貨的具體形式即可。
而支付退貨本身又可以分為原路退貨/非原路退貨，而這兩種退貨形式又分別可以分為全額退票和部份退貨兩種情況，所以支付流水與退票流水之間又存在1:N的關系。還是舉里面那種事例，假如用戶沖值交易所支付的10塊錢，是一次性通過微信支付的，這么退票時假如時全額原路退票，則只須要插入一條與支付流水對應的10塊錢的退貨流水，并更新交易訂單狀態為“已退貨”即可。
假如是由于該用戶的沖值部份，使用了5塊，剩下的5塊錢可以退貨，這么此時發起的就是原路部份退貨，在退貨流電表中插入一條與支付流水相關的5塊錢的退貨流水即可，而且此時須要將對應的交易訂單狀態更新為”部分退貨“的狀態。
據悉，以上情況倘若因為支付訂單時間太久，原支付渠道已難以再進行原路退貨，此時只能通過線上或線下匯款形式／代付形式進行退票的話，則為了建立模型，我們也須要在退票流電表中記錄一條與原支付訂單關聯的退貨流水，只是退票形式須要記錄非原路退貨的情況，但是在發起匯款或代付退貨后，須要在退貨流水中關聯對應的匯款或代付流水號微信訂貨系統，然后按照實際退貨的情況更新對應的交易訂單狀態為“已退貨/部份退貨”。
而匯款或代付本身由于又是一種單獨的支付形式，所以此時我們須要在支付流電表中單獨記錄匯款訂單或代付訂單，但由于此時與交易訂單本身無直接關聯，所以不須要形成新的交易流水。
對于海外支付渠道由于形成了的情況，我們須要將其視為與匯款類似的非原路退貨方法，因而進行退票流水的記錄，以及訂單本身的記錄，這一點對于海外支付渠道的支付邏輯建立以及本身的溯源會比較重要。
根據這些模型進行支付訂單結構的設計，并在一開始就擼清楚這種支付場景的對應的數據儲存邏輯，會對未來系統的分拆擴充大有益處，由于起碼數據邏輯是十分清晰的了。只是為了確保這套數據邏輯的一致性，我們還須要強化對帳系統關于內部訂單對帳的邏輯，確保不出現異常和不一致的數據問題。
以上就是本次作者關于支付部份想寫的全部內容了，希望還能對一些正在經歷支付系統建立的同學們無論優劣有一點參考借鑒的意義。
談一下家國情結
在這兒里面干貨部份的內容就說完了，接出來的內容純屬抒發下心情，希望指正！近來由于華為風波，作者也看了好多報導和相關的剖析文章，總結一點就是華為的5G太強悍，打動了以英國為主導的西方利益，由于一旦5G網路建設的主導權被中國公司把握，這么未來世界的網路格局就要發生翻天覆地的變化了，所以日本開始搞一些下三濫的綁票手段了。
在這兒作者作為一名中國人，對此表示強烈的悲痛，同時也認識到這個世界還是一個弱肉強食的世界，之前好多人都說日本這兒好，那里好的，其實我也承認日本的確在好多方面還領先中國，并且正所謂“金窩銀窩不如自己的狗窩”，還是希望你們多多愛自己的祖國，不要經常的隨波逐流噴我們國家這不好，那不好的了。做好自己的本質工作，不求為國做多大貢獻，只求不給國家唱反調就行！
最后，以本文的封面抒發下對華為這家偉大企業的支持！感謝你們！
—————END—————
免責聲明：部分文章信息來源于網絡以及網友投稿，本站只負責對文章進行整理、排版、編輯，出于傳遞更多信息之目的，并不意味著贊同其觀點或證實其內容的真實性，如本站文章和轉稿涉及版權等問題，請作者在及時聯系本站，我們會盡快為您處理。
