我叫姚晨，我來自于點融網(wǎng)莽使。我想作為非架構(gòu)師的我，在這里給大家分享一下在構(gòu)建點融支付系統(tǒng)的心路歷程笙僚，也算是在各位架構(gòu)師面前班門弄斧芳肌。

在點融，支付一開始是作為一個模塊存在于點融的大系統(tǒng)之中肋层，它缺乏統(tǒng)一實現(xiàn)亿笤、擴(kuò)展性較差，我們有大概栋猖，一開始大概有三到四個支付渠道净薛，每個支付渠道都有自己的端到端的實現(xiàn)。相同的加解密蒲拉、報文處理和機(jī)制有各自的實現(xiàn)肃拜。我們需要接入更多的渠道的時候痴腌，就在原有的支付模塊結(jié)構(gòu)中，只能通過重復(fù)代碼來實現(xiàn)燃领。這樣的話士聪，我們需要一個統(tǒng)一的支付網(wǎng)關(guān)一樣的存在，統(tǒng)一管理所有支付共通的業(yè)務(wù)邏輯猛蔽。

業(yè)務(wù)邏輯全靠代碼固化剥悟，這里說的是比如支付渠道的路由選擇，當(dāng)有支付渠道不可用的時候曼库，或者說出于費率考慮或者出于成功率考慮区岗，類似這樣的路由邏輯，其實我們都是通過代碼固化的毁枯。另外就是說慈缔，當(dāng)我們有新渠道或者新的支付方式、交互方式上線的時候后众，我們希望做一定的灰度開啟胀糜，這也是通過一定的代碼固化來實現(xiàn)的，也就是說蒂誉，當(dāng)我們有調(diào)整教藻，比如說我們希望把1%的用戶提高到10%甚至提高到50%甚至全部開放，這時候我們需要的是重新修改參數(shù)右锨，打包部署上線括堤。這對于一個互聯(lián)網(wǎng)公司來說，我覺得是無法接受的绍移。

另外悄窃，隨著點融業(yè)務(wù)的擴(kuò)展，我們將原有的點融大系統(tǒng)逐步拆分成多個業(yè)務(wù)子系統(tǒng)蹂窖。這時或多或少所有的業(yè)務(wù)子系統(tǒng)都需要一定的支付能力轧抗。這時候如果還是以支付模塊存在的話，那就意味著說瞬测，每一個子業(yè)務(wù)系統(tǒng)都需要copy這樣一個支付模塊横媚。所以我們覺得，那我們就把這個支付模塊給變成一個系統(tǒng)月趟。

那為什么支付需要服務(wù)化灯蝴，或者說為什么支付可以服務(wù)化？我覺得很簡單孝宗，其實它就是一個基礎(chǔ)服務(wù)穷躁，因為點融所有的業(yè)務(wù)系統(tǒng)都需要支付，所以這是一個足夠強(qiáng)大的理由說因妇，我們?nèi)グ堰@個東西做成一個單獨的服務(wù)问潭。另外猿诸，支付本身來說它具有清晰的上下文邊界，也就是說支付就是支付睦授，充值也好提現(xiàn)在也好代扣代付也好两芳，它跟業(yè)務(wù)緊密相關(guān)摔寨，但是它跟業(yè)務(wù)系統(tǒng)卻又是松耦合的去枷，是一個理想的服務(wù)化對象。另外我們需要提供一個演進(jìn)式的設(shè)計是复，以便適應(yīng)持續(xù)變化的業(yè)務(wù)需求删顶。這里說的是什么？一開始我們只有兩種支付渠道一種交互方式淑廊。隨著業(yè)務(wù)的演化逗余，隨著支付渠道通路的豐富，以及海外業(yè)務(wù)的拓展季惩，我們需要支持微信支付录粱，需要支持支付寶支付，甚至未來我們可能會支持區(qū)塊鏈支付画拾。類似這樣的話啥繁，我們希望能夠有一個良好的演進(jìn)式的設(shè)計，能夠很有彈性的支撐這樣的業(yè)務(wù)擴(kuò)展青抛，而不是說旗闽，當(dāng)我需要做一個區(qū)塊鏈服務(wù)的時候，我需要把整個系統(tǒng)推倒重來蜜另。

點融的支付服務(wù)到現(xiàn)在大概進(jìn)行了一年左右的時間适室，從一開始我們在設(shè)計這個系統(tǒng)的時候，其實我們就遵循了一定的原則举瑰。網(wǎng)上有個參考捣辆，12要素應(yīng)用。我覺得比較重要的幾點是這幾點此迅。首先我們的支付服務(wù)是一個無狀態(tài)的汽畴，無狀態(tài)的好處在于說，當(dāng)我們有用戶峰值或者有更高要求的訪問量或者使用量的時候邮屁，我們可以通過簡單的加機(jī)器來實現(xiàn)動態(tài)擴(kuò)容整袁。自包含是指我們摒棄了傳統(tǒng)的war包部署，也就是Tomcat容器部署佑吝，應(yīng)用本身就是一個jar包或者war包坐昙，然后通過腳本化的啟動，對外界就是一個黑盒子芋忿，你只關(guān)心的是數(shù)據(jù)交互炸客。這樣的好處是說疾棵，運(yùn)維不再關(guān)心說我需要Tomcat還是什么，我只需要說痹仙，我知道這個應(yīng)用自身啟動需要哪些東西即可是尔。

環(huán)境不感知，具體是指我們把所有環(huán)境相關(guān)的配置統(tǒng)統(tǒng)挪到了一個配置中心开仰，也就是說同一份代碼可以無縫跑在開發(fā)環(huán)境拟枚、測試環(huán)境、生產(chǎn)環(huán)境众弓。這樣做的好處是說恩溅，我們可以做到完備的CACD過程，也就是當(dāng)任何一步谓娃，比如開發(fā)完一個功能脚乡，我們打包測試，通過以后我們會自動promotion到demo環(huán)境滨达，交給QA測試奶稠。QA測試完了以后我們會Promotiong交給UAT測試。整個UAT完備以后捡遍，我們可以自動化部署到生產(chǎn)锌订。本身這個應(yīng)用是從一開始的環(huán)境打包出來的那個，我們可以通過一個UUID或者（HushQ）的方式來確保整個部署環(huán)節(jié)稽莉，鏡像沒有被破壞瀑志。

第二點就是說，我們在設(shè)計整個系統(tǒng)的時候污秆，我們想說我們基于DDD劈猪，也就是鄰域模型驅(qū)動來設(shè)計整個系統(tǒng)內(nèi)部模塊。支付服務(wù)作為一個領(lǐng)域來說良拼，存在于點融的大系統(tǒng)之中战得。其實支付里面又有內(nèi)生的子領(lǐng)域，包括訂單庸推，包括用戶常侦，包括支付渠道。那我們不希望用傳統(tǒng)的一層一層三級架構(gòu)傳遞下去贬媒，我們希望作為一個模塊聋亡，比如說訂單模塊，作為一個商戶模塊际乘，作為一個支付渠道模塊坡倔，存在于自身的子模塊。這樣做的好處是未來系統(tǒng)的擴(kuò)展。最后做這個系統(tǒng)的時候罪塔，我們用了一些投蝉，也不算新的東西，應(yīng)該是比較不常見的東西征堪，我們用了CQRS和Event Sourcing瘩缆，CQRS簡單來說就是讀選分離，這樣做的好處在于佃蚜，通常情況下你會發(fā)現(xiàn)你的數(shù)據(jù)大部分情況下會是寫一次讀多次庸娱，而且讀的多樣性會遠(yuǎn)遠(yuǎn)超過你的預(yù)期。那這樣爽锥，我們可以有針對性的針對寫端涌韩，做性能優(yōu)化畔柔。我們也可以針對性的對讀端做性能優(yōu)化氯夷。比如支付系統(tǒng)里面應(yīng)用的時候，因為整個系統(tǒng)是基于Event設(shè)計的靶擦，Event本身沒有那么明顯的數(shù)據(jù)格式腮考，也就是我們不需要用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫來保存Event事件。這里用了MongoDB存儲一個一個事件流玄捕。最終這些事件流會異步或者同步到一個讀DB踩蔚，也就是MySQL。這個時候我們會根據(jù)業(yè)務(wù)的需要枚粘，去做一定量的數(shù)據(jù)重組馅闽，以方便后續(xù)的數(shù)據(jù)展示。

甚至我們都可以不需要View的存在馍迄，因為本身數(shù)據(jù)從重組的過程中就可以通過數(shù)據(jù)冗余實現(xiàn)View的功能福也。之所以用Event Sourcing，是來自于CQRS的衍生化的好處攀圈。對于支付系統(tǒng)來說暴凑，任何涉及到的錢的東西我們都希望能夠很好的追蹤，可以被審計赘来。Event Sourcing的好處就是說现喳，任何一步訂單操作，比如從你下單到執(zhí)行犬辰，到結(jié)算到清分嗦篱，任何一步動作都會作為事件存儲。我們可以很清楚的知道幌缝，整個訂單在系統(tǒng)中是如何流轉(zhuǎn)的灸促，它發(fā)生了哪些變化產(chǎn)生了哪些效果。另外Event Sourcing帶來另外一個好處就是說，當(dāng)我們生產(chǎn)發(fā)生問題的時候腿宰，其實我們是可以把生產(chǎn)的事件拿到本地或者測試環(huán)境呕诉，直接就可以找到問題的癥結(jié)在何處。

在這個過程中我們有些經(jīng)驗教訓(xùn)吃度，第一點甩挫，微架構(gòu)真的很重要。大家都知道架構(gòu)師是一個很誘人的title椿每，但是你做應(yīng)用的時候伊者，其實你是這個應(yīng)用的架構(gòu)師，某一個很小的應(yīng)用你也需要一個很細(xì)微的調(diào)整间护，以便這個應(yīng)用能夠自適應(yīng)發(fā)展亦渗。

大家知道你公司的系統(tǒng)架構(gòu)，一定程度上決定了你的公司業(yè)務(wù)的發(fā)展汁尺。但是你的應(yīng)用的系統(tǒng)的微架構(gòu)法精，某種程度上決定了你系統(tǒng)的命運(yùn)。如果它不能適應(yīng)業(yè)務(wù)的需求痴突，很快就會被另外一個新的應(yīng)用給替代搂蜓。第二連續(xù)，系統(tǒng)基于事件驅(qū)動去開發(fā)辽装，盡可能異步化處理帮碰。

基于事件驅(qū)動的開發(fā)的好處在哪？大家用過MQ的人都知道拾积，異步化處理殉挽，對于系統(tǒng)的橫向擴(kuò)展是有相當(dāng)大的好處的。我們在這里實際上做了一個相當(dāng)于系統(tǒng)內(nèi)嵌的消息處理機(jī)制拓巧，也就是說訂單事件觸發(fā)時斯碌，會仍到一個消息中心，而這個消息會被多個感興趣的監(jiān)聽者所監(jiān)聽玲销。一開始我們可能只有支付输拇，我們希望用戶能夠充值或者提現(xiàn)。后續(xù)我們希望監(jiān)測一些用戶的異常行為贤斜，比如說異常提現(xiàn)或者充值異常策吠。這時候我們不需要在原有的支付邏輯上加代碼，我們只要監(jiān)聽這個支付事件即可瘩绒。同樣我們也需要在支付成功或者支付失敗的時候猴抹，希望能夠第一時間通知到用戶。傳統(tǒng)的做法锁荔，比如在Updata蟀给，拿到最新狀態(tài)的時候插入另外一行邏輯處理代碼。而基于事件的好處就是說，我們可以類似插件式的處理跋理，比如把插件中心這個東西直接嵌入進(jìn)來择克，它只需要監(jiān)聽它干興趣的事件，做對應(yīng)的處理即可前普。后續(xù)我們可能會有更多的組件模塊肚邢，同樣這些所有的處理都可以并行處理，而不需要傳統(tǒng)的拭卿，一步一步傳統(tǒng)的處理模式骡湖。

什么情況下我們會用到同步操作，什么情況下我們會用到異步操作峻厚？拿點融的支付業(yè)務(wù)場景來做簡單的舉例即可明白响蕴，充值跟投資，我們不希望用戶被中斷惠桃，所以我們需要把用戶停留在操作界面上浦夷。所以整個用戶參與度高的情況下，我們會希望說刽射，所有的請求盡量同步化處理军拟，以便用戶得到及時反饋。反之亦然誓禁，在提現(xiàn)這個場景下，由于支付渠道和銀行的限制肾档，其實到賬時間往往會超過一小時摹恰，甚至一天。這種情況下是一個理想的可以用于異步操作的場景怒见，事實上也是如此俗慈。對于點融支付來說，出去充值這一環(huán)節(jié)遣耍，其他的所有事件我們都是盡量異步化處理闺阱。

然后我要說一下，其實很多人在一開始寫代碼的時候會想說舵变，這個類似過度優(yōu)化或者什么酣溃。我們一開始想說要盡可能的把代碼寫得足夠靈活，以便適應(yīng)系統(tǒng)的需要或者業(yè)務(wù)的需要纪隙。但是實際上赊豌，其實就好像跳舞，如果你沒有一定的節(jié)奏绵咱，或者沒有一定的節(jié)拍碘饼，其實你反而在尬舞，如果你良好的節(jié)拍和良好的動作，你可以創(chuàng)造出更優(yōu)美的舞姿艾恼。

同樣住涉，我們一開始做支付策略的時候陷入了一個誤區(qū)，我們會覺得支付策略這些東西是不是可以由產(chǎn)品經(jīng)理或者風(fēng)控部門自己定義自己設(shè)計規(guī)則钠绍？于是我們弄了一個相當(dāng)于腳本引擎的東西秆吵，也就是說我們把一些重工作統(tǒng)統(tǒng)交給了業(yè)務(wù)人員，這樣的后面其實五慈，我們一開始想象的是說纳寂，我們希望減緩開發(fā)人員的工作，因為我只要執(zhí)行你的腳本即可泻拦，而且業(yè)務(wù)人員也可以運(yùn)行腳本毙芜，去驗證你想要的結(jié)果。這時候發(fā)現(xiàn)一個問題争拐，其實在整個的過程中腋粥，整個支付策略的設(shè)計過程中，還有實現(xiàn)過程中架曹，我們會發(fā)現(xiàn)大部分時間還是開發(fā)人員在參與隘冲。業(yè)務(wù)人員不懂腳本怎么寫，我們也無法在短時間內(nèi)提供完備的DSL绑雄，以便業(yè)務(wù)人員輕松書寫業(yè)務(wù)規(guī)則展辞。于是我們推倒重來，這樣我們就給你一定的節(jié)拍和一定的舞步万牺，于是我們設(shè)計了新的支付策略罗珍，也就是我們給了你一個條條框框，我們希望這個條條框框里脚粟，你可以自定義你想要的功能覆旱。

這一點挺好玩的，就像剛剛說的支付策略核无，我們其實是在自己造輪子扣唱，而且說起來不好意思，我們應(yīng)該造了兩次团南。第一次不是太成功噪沙，第二次正在驗證。但是我覺得已慢，很重要的一點是說曲聂，我們不需要反復(fù)的自己去造輪子或者任何功能我們都自己去造輪子。正如這個圖上畫的一樣佑惠，我覺得可能我們一開始造的那個支付策略的輪子朋腋，要么是個三角形要么是個方形齐疙。實際上大家都知道，要跑起來的輪子一定得是圓形旭咽。所以在現(xiàn)在這種開放社區(qū)或者大廠商贞奋，各種開源框架比較完善的情況下，我覺得其實開源是一個更好的選擇穷绵，或者你有現(xiàn)有框架轿塔，往往對你來說是更方便更快捷的事情。

可視化數(shù)據(jù)仲墨，監(jiān)控所有能監(jiān)控的數(shù)據(jù)勾缭。這一點非常重要，對于你的業(yè)務(wù)改變目养，還有對于你的系統(tǒng)的監(jiān)測俩由，以及系統(tǒng)后續(xù)的演化，是非常重要非常關(guān)鍵的癌蚁。

比如說幻梯，我們這里是點融支付業(yè)務(wù)的核心數(shù)據(jù)的實時監(jiān)控，這里我們用到了很多開源框架努释。從CQRS和Event Sourcing碘梢，我們用到了（Acson）框架，用了CQRS和Event

Sourcing之后伐蒂，我們不需要業(yè)務(wù)數(shù)據(jù)埋點瓦堵，我們不需要重新梳理我們的關(guān)鍵路徑存和，因為每一個事件都是關(guān)鍵路徑倘要。我們需要做的只是集中一個點收集這些事件锈拨，我們只需要短短幾行代碼去監(jiān)聽這個消息，然后通過卡夫卡傳遞給（Logstash）昭雌，簡單處理后交給（Elasticsearch），最終用（Kibana）做一個非常漂亮的圖形化展示健田。所有這些工作大概只需要花費一到兩周的時間烛卧，這也是為什么我會覺得說，我們不需要重復(fù)造輪子妓局，我們要花更多的心思在微架構(gòu)上調(diào)整总放。

當(dāng)然，業(yè)務(wù)數(shù)據(jù)很重要好爬，性能數(shù)據(jù)也同樣重要局雄。對我們來說，支付很大程度上是跟銀行和支付渠道打交道存炮。我們需要監(jiān)控說炬搭，API的調(diào)用次數(shù)蜈漓，API的耗時長度。我們也需要說宫盔，究竟是我們的問題還是三方支付公司的問題融虽。大家可以看到，圖看起來蠻相似的灼芭，最上面的是我們服務(wù)器的響應(yīng)的時長有额，最下面是三方支付公司，我們在請求發(fā)往三方支付公司所耗的時長彼绷。大家可以發(fā)現(xiàn)巍佑，我們大部分時間都耗在了三方支付公司，要么是網(wǎng)絡(luò)要么是支付公司的處理能力寄悯。

這樣萤衰，我們一開始所有的請求處理其實都是同步的，這個時候我們會發(fā)現(xiàn)問題热某，比如說代扣腻菇、提現(xiàn)、代付昔馋，不需要用戶參與的情況下筹吐，我們會發(fā)現(xiàn)我們的處理能力會急劇的下降，當(dāng)達(dá)到某一個用戶的峰值的時候秘遏，我們會發(fā)現(xiàn)大量的排隊大量的超時丘薛。這時候我們需要做一個內(nèi)部的排隊處理，我們通過上述的數(shù)據(jù)分析可以清楚的得到說邦危，原來是三方支付公司或者是網(wǎng)絡(luò)問題洋侨，導(dǎo)致了我們系統(tǒng)性能的下降。

這里我們用到的開源框架倦蚪，（job viser）會收集所有的系統(tǒng)希坚，最終展示的效果同樣也是一個開源框架，我們用了（Grafita）做一個數(shù)據(jù)展示陵且。

說完了系統(tǒng)裁僧，本身Java程序少不了的必須要監(jiān)控，JVM慕购，大家可以看到曲線還是比較夸張的聊疲，因為我們的用戶方式或者說我們的支付方式會比較有規(guī)律，所以我們會發(fā)現(xiàn)有一個很有規(guī)律的變化沪悲。上面是JVM的使用情況获洲，下面有GC，還有（sred）殿如。很多開源框架有一個問題贡珊，就是說它在用（Sred）最爬，比較揮霍無度，我們通過這個來觀察是不是有異常飞崖。這個也是通過（Job viser）能夠簡單實現(xiàn)的烂叔。

自動化一切可以自動化的。這里有一些風(fēng)險固歪，一會兒會提到蒜鸡。簡單來說，你需要自動化部署牢裳，自動化部署的前提是你需要自動化測試逢防。自動化測試的前提是什么？你需要有一個穩(wěn)定的測試環(huán)境蒲讯。但是三方支付公司的測試環(huán)境通常有各種各樣的問題忘朝，甚至有些三方支付公司根本不提供測試環(huán)境。這時候怎么辦判帮？我們自己寫局嘁。我們在跟三方支付公司測試鏈條完畢以后，系統(tǒng)上線以后晦墙，我們會寫對應(yīng)的（moc）悦昵，也就是我們把所有三方支付公司的請求處理都（moc）一遍。不過現(xiàn)階段可能比較簡陋晌畅，因為我們更多的是迫于業(yè)務(wù)的要求但指，我們更多是正向的考核，沒有負(fù)向或者沒有（Educase）抗楔，這樣難免會有些問題棋凳。另外（Moc）會導(dǎo)致說，你不確定三方API是否有變更连躏，這會帶來一定的風(fēng)險剩岳。我們更多依賴于支付公司不會輕易發(fā)生這樣的變化。

未來我們要怎么做入热？我們用了一些開源框架卢肃，對于我們后續(xù)的變化會有極大的好處，比如說實時數(shù)據(jù)分析才顿。當(dāng)我們可以便捷的進(jìn)行數(shù)據(jù)分析，這時候我們可以做適當(dāng)?shù)闹悄苈酚捎容铩１热缯f常見的場景是某一個銀行把支付通路給關(guān)了郑气，但是它并沒有提前告知到支付渠道，支付渠道也不可能提前告知到我們腰池。這個時候尾组，我們傳統(tǒng)來說會采用輪巡的方式忙芒，比如每五分鐘或者每一分鐘監(jiān)測一下，這個時間段這個支付渠道大概有多少筆失敗的訂單讳侨、失敗的原因是什么呵萨。這時候會有一個問題是說，你一定會有一個時間段的誤差跨跨，也就是它未必是真實的表象潮峦。這時候如果我們有實時數(shù)據(jù)，如果我們能夠做實時分析勇婴，那這個會形成一個良好的生態(tài)鏈路忱嘹，也就是說當(dāng)一個渠道真正有問題的時候，我們可以拿到第一手資料耕渴，進(jìn)行第一手分析拘悦，然后做一個動態(tài)的智能切換。

之前也說了橱脸，我們設(shè)計整個支付服務(wù)的時候就考慮到础米，支付里面每一個子領(lǐng)域都是可以獨立拆分的。那就意味著說添诉，未來可能支付服務(wù)本身就會變成另外一個微服務(wù)化的系統(tǒng)屁桑。這樣的話，我們會想說吻商，我們到底要固守Java世界還是要采取語言不可知論掏颊？最近突然比較火熱的（Kotlin）。拿支付策略來舉例艾帐，我們現(xiàn)在還是用Java實現(xiàn)乌叶，但是或多或少都有些別扭，因為Java本身并不是一個function program language柒爸。它本身也不支持太友善的DSL准浴。反過來我們可能會有Ruby在DSL獨樹一幟，有（Go）更適合在ATI網(wǎng)關(guān)這種應(yīng)用場景下發(fā)揮它的作用捎稚，為什么要固守Java世界乐横？對我們來說我們會嘗試更多的不同的語言，就好像我們現(xiàn)在的支付管理后臺今野，我們并不是用傳統(tǒng)的JSP來做的葡公，我們是用Ruby來寫的。未來我們要做的API網(wǎng)關(guān)可能會采忍跛（Go）催什。上面說的實時數(shù)據(jù)分析，Java也不擅長這個東西宰睡，我們可能會用（Scala）蒲凶，可能用Ruby甚至可能用更新的（Kotlin）气筋。因為這些靜態(tài)化的腳本語言，它的應(yīng)用場景更適合旋圆。

另外是說宠默，最近比較火熱的Serverless和Lambda架構(gòu)，它的好處在哪灵巧？其實我們不需要一個stand by的server搀矫，比如說我們在考慮計費，我們在做策略試算的時候孩等，其實我們不需要一個24小時stand by的server在那里等著某一個時間段突然爆發(fā)的請求艾君，我們只需要說，在需要處理的時候快速的去響應(yīng)快速的去處理肄方。像Amazon提供的Lambda架構(gòu)是一個理想的狀態(tài)冰垄，就像剛剛說的計費，計費不需要那么實時权她，我甚至可以跑批處理虹茶。

如果獨立開一個計費模塊的話，你會發(fā)現(xiàn)你要一個7×24小時stand by的東西隅要，但是它偶爾要處理一些東西蝴罪。其實我只需要在處理的時候去獲取我需要的計算機(jī)資源即可。點融的支付服務(wù)運(yùn)行到現(xiàn)在步清，我們在考慮做一些技術(shù)輸出的方向要门，也就是說我們會跟銀行合作，會跟其他公司合作廓啊，想要推我們的支付服務(wù)欢搜。這另外會面臨一個比較大的問題，就是如何信任谴轮。如果解決不了這個問題炒瘟，我們面臨的問題是我們變成了一個傳統(tǒng)的軟件開發(fā)公司，我們技術(shù)外包第步，把系統(tǒng)開發(fā)好疮装，部署交給銀行或者交給其他公司去使用。這個想來跟大家知道的現(xiàn)有的科技趨勢是背道而馳的粘都。我們會想說有沒有更好的辦法去解決廓推？我們其實更重要的是說，我們需要保證的翩隧，最核心的一點是說受啥，我們希望保證交易的雙方是可信的，交易雙方的數(shù)據(jù)是不被篡改的。這個時候我們也會有區(qū)塊鏈滚局，相信大家知道，應(yīng)該是一個理想的選擇顽频。但是區(qū)塊鏈有一個問題是藤肢，交易雙方的數(shù)據(jù)會被整個鏈路所有人共享。也就是說我跟么個特定銀行的交易會被整個鏈路其他銀行或者其他公司共享糯景。雖然數(shù)據(jù)加密可以解決這個問題嘁圈，但是我本身就不希望數(shù)據(jù)流向其他鏈路。

最近出來的Corda蟀淮，提供的是分布式總帳的方案最住。它和區(qū)塊鏈的區(qū)別在哪？交易數(shù)據(jù)僅存在于交易雙方怠惶。當(dāng)然這個還是比較新的涨缚，因為它本身的語言事件也是用（Kotlin），還是比較巧的策治，有待考證脓魏。但是本身來，對于支付服務(wù)的演化通惫，未來很重要的一點應(yīng)該是區(qū)塊鏈茂翔，我們希望服務(wù)可以被大家使用，我們也希望我們的服務(wù)是可信的履腋，而且數(shù)據(jù)不被篡改珊燎。通過技術(shù)，我們應(yīng)該是可以實現(xiàn)這樣的目標(biāo)遵湖。

下面是一些參考資料悔政，第一個是12要素app，告訴你怎樣做好12要素的應(yīng)用奄侠，以便適應(yīng)未來的需要卓箫。第二個是MartinFowler的，第三個也是Martin馬大神的垄潮。

今天就介紹到這里烹卒，謝謝。

提問：我本身也是做支付弯洗，我想問一下旅急，你們微化之后，很多服務(wù)牡整，相互的調(diào)用是怎么樣的藐吮？管理怎么處理的？還有異步性，很核心的訂單如果異步了谣辞，可能是為了提高性能迫摔，但是加入我們出現(xiàn)了宕機(jī)，這樣的一些容災(zāi)措施應(yīng)該是如何處理泥从？

姚晨：首先第一個問題句占，當(dāng)你微服務(wù)化的時候，最重要的是注冊中心躯嫉，還有一個API網(wǎng)關(guān)的概念纱烘。也就是說，你希望對外提供的是一個服務(wù)祈餐，但是內(nèi)部可能是不同的擂啥，RPC也好，用哪個實現(xiàn)帆阳，這個更多取決于公司內(nèi)部哺壶，用什么不太重要。但是一旦有了很好的配置中心和服務(wù)舱痘，相當(dāng)大的程度上能夠解決第一個問題变骡。第二個問題是消息發(fā)生了遺失怎么辦，CQRS的好處是遺失了你可以重復(fù)播放芭逝，異步不是所有的東西都異步塌碌，只是用戶發(fā)起了之后你可以異步執(zhí)行。具體訂單的狀態(tài)的流轉(zhuǎn)旬盯，其實你可以做同步化台妆，但是每一步同步化，產(chǎn)生的事件沒有被及時處理胖翰，可以再發(fā)送接剩。好處在這里。本身來說萨咳，CQRS有一定的學(xué)習(xí)成本懊缺，所以不見得所有的系統(tǒng)都可以跑，尤其是已有系統(tǒng)培他，改造起來會比較麻煩鹃两。

提問：我看到你有引用馬大神一些東西，關(guān)于這個有兩個問題舀凛，我看到你們已經(jīng)應(yīng)用了他的一些理論俊扳，那第一個是說，比如你用到的Event Sourcing猛遍，在發(fā)生一些變化的時候是變成一個一個Event馋记，這樣可以在一個完全開始的狀態(tài)去把一件事情重復(fù)出來号坡。我看到一個引發(fā)的問題是說，怎么樣結(jié)構(gòu)化的存儲這些Event梯醒，就是這件事情變化的時候宽堆，你是用Event存儲起來的，怎么樣結(jié)構(gòu)化的存儲到一些結(jié)構(gòu)化數(shù)據(jù)庫里面冤馏，以你怎么樣日麸，比如說怎么樣去查詢，拿到像結(jié)構(gòu)化數(shù)據(jù)庫里面很容易拿到的一些結(jié)果逮光？第二個有用到Serverless和Lambda的架構(gòu)，需要的時候可以申請一些資源做一些事情墩划，那怎么保證速度和響應(yīng)時間涕刚？

姚晨：先說第二個問題，其實還沒有開始用乙帮，只是預(yù)計未來想要這樣發(fā)展杜漠。但是如果考慮到時間來說，其實你起一個Lambda的function program的話要快得多察净，你可以保證它在毫秒級驾茴。運(yùn)行過Java層知道，那是秒級才會起的氢卡。這個還需要后續(xù)的驗證锈至。當(dāng)然我覺得這是一個未來的方向。

關(guān)于第一點译秦，我們用到了CQRS不單單是Event Sourcing峡捡，因為CQRS的好處是你可以很方便的去用Event Sourcing。如果是純粹的Event Sourcing筑悴，不知道怎么去處理非結(jié)構(gòu)化數(shù)據(jù)们拙，讓它結(jié)構(gòu)化。CQRS的好處是說阁吝，你可以把非結(jié)構(gòu)化的數(shù)據(jù)在讀端結(jié)構(gòu)化砚婆，也就是說我們會有兩個DB，對于點融支付有兩塊DB突勇，一個是MongoDB存非結(jié)構(gòu)化數(shù)據(jù)装盯，然后有一個MYSQLDB，用來存最終狀態(tài)的存放与境，這時候可以實現(xiàn)結(jié)構(gòu)化處理验夯。

其實任何，當(dāng)然這里有一點很重要是說摔刁，任何事件的觸發(fā)一定是基于Event產(chǎn)生的那個最終的內(nèi)存狀態(tài)挥转。也就是說，其實你存儲到非結(jié)構(gòu)化數(shù)據(jù)里面，實際上是一個一個事件绑谣，當(dāng)這個事件不再被使用的時候党窜，本身這個訂單已經(jīng)被丟失了。當(dāng)你下一次來操作來查詢借宵，查詢并不會這樣幌衣，操作的時候，后臺的框架是把所有的Event拿出來壤玫，逐個播放豁护，最終可以得到一個真正有效的狀態(tài)。所以其實欲间，老實講還是得益于框架的使用楚里，所以我們可以很好的做一個讀跟寫的數(shù)據(jù)的分離。

提問：所以你們的Mongo猎贴，處理寫班缎，MySQL在讀，所以這兩個中間有一個轉(zhuǎn)化她渴？

姚晨：對达址，這個轉(zhuǎn)化也得益于，我們只要去監(jiān)聽對Event的狀態(tài)趁耗。

提問：我有兩個小問題沉唠，我本身是做風(fēng)控的，想問一下關(guān)于風(fēng)控的問題对粪。第一個問題是說右冻，你們的風(fēng)控是，比如說像策略平臺著拭，是自己實現(xiàn)的還是說引入了外部的技術(shù)和系統(tǒng)開發(fā)的纱扭？第二個問題是說，你們目前風(fēng)控的攔截儡遮，大概有多少乳蛾？有沒有出現(xiàn)因為風(fēng)控的原因?qū)е碌馁Y損這種問題？

姚晨：其實我覺得我們說的風(fēng)控不是同一個維度的風(fēng)控鄙币，我說的更多是支付本身業(yè)務(wù)的風(fēng)控肃叶，而不是更外層那種。

提問：就是進(jìn)入支付之后的風(fēng)控十嘿？

姚晨：對因惭，本身支付業(yè)務(wù)的風(fēng)控我們是自己開發(fā)的，因為風(fēng)控老實來講绩衷，還是比較專有的領(lǐng)域蹦魔。你還是需要自定義的DSL激率，要么是別人幫你實現(xiàn)的DSL，要么是你自己實現(xiàn)的DSL勿决，這樣你的業(yè)務(wù)人員才能去改那樣的規(guī)則書寫那樣的規(guī)則乒躺，否則我們一開始選擇的純腳本化，真的不是很好的選擇低缩〖蚊埃可能回答不了您的問題。

提問：我有兩個小問題咆繁，一個是在支付服務(wù)里面有沒有遇到什么分布式伺服的問題讳推？如果有是怎么解決？還有一個是我看到你這邊圖表玩般，包括業(yè)務(wù)數(shù)據(jù)和性能數(shù)據(jù)娜遵，我理解是這兩個權(quán)限管理都很弱的，你們在權(quán)限管理方面是怎么做的壤短？

姚晨：第一個問題，我個人是強(qiáng)烈反對分布式伺服慨仿，所以在我們系統(tǒng)里面是沒有分布式伺服存在久脯。我的理解，理論上是可以镰吆，但是本身這個框架也支持一個（Saga）帘撰，一個大的伺服，但是并不像伺服那么明顯万皿。之所以用分布式的初衷一定是想要rollback摧找，出現(xiàn)問題的時候。其實如果有良好的補(bǔ)償機(jī)制牢硅，是可以做到程序化的回滾蹬耘。

提問：就是所有的服務(wù)都是帶有補(bǔ)償機(jī)制？

姚晨：對减余。第二個問題是综苔，實際上沒錯，這兩個權(quán)限都弱爆了位岔。在（Kibana）那一塊我們用到了開源的一個框架如筛，做了一些基本的權(quán)限控制。理論上來說還是可以滿足一定的要求抒抬。另外我們也咨詢過開發(fā)公司杨刨，他們提供的解決方案會相對來說成本比較高，所以我們會用（Serchga）我建議你可以嘗試一下擦剑。

提問：我在你們講座的過程中妖胀，聽說點融網(wǎng)作為第三方的支付公司芥颈，接的渠道有第三方公司，第三方公司在后面也是接銀行做粤、銀聯(lián)浇借、銀企，你們?yōu)槭裁床恢苯咏鱼y行怕品？你們接入第三方支付公司妇垢，耗時會有提升，提供支付服務(wù)肉康，為什么別人找你們做第三方支付闯估，你們又接第三方支付公司？這樣別人就可以直接找別人吼和，為什么要找你們涨薪？你們作為第三方支付公司，接第三方支付公司炫乓，成本也會大很多刚夺。

姚晨：其實這個有各種方面的原因，因為其實不是我們不想跟銀行玩末捣，是銀行不想跟我們玩侠姑。因為金融行業(yè)實際上是有監(jiān)管，有準(zhǔn)入門檻箩做。我們沒有牌照或者我們現(xiàn)在互金行業(yè)在重新監(jiān)管莽红。實際上合規(guī)還在進(jìn)行中，其實會有各種各樣的資質(zhì)約束邦邦。所以我們只能去跟支付公司打交道安吁。但是本身來說，我覺得支付公司也好燃辖，銀行也好鬼店，其實對于支付系統(tǒng)來說都是一個通道，也就是說我們提供給支付公司或者其他公司來用郭赐，我并不是把我的支付能力給到你薪韩，因為我沒有支付牌照，我不能幫你做二清捌锭。那意味著說俘陷，我其實是我是幫你提供技術(shù)解決方案。支付或多或少都會面臨同樣的問題观谦，你要做渠道選擇拉盾，你要做路由策略，你要做監(jiān)控豁状，你要做審捉偏，你要做風(fēng)控倒得。這些東西都是公有的業(yè)務(wù)，我們提供的還是一個綜合的解決方案夭禽，而不是告訴你說我有這個支付通路霞掺，你來用我的支付通路。因為這個理論上來說是不合規(guī)讹躯。

提問：我有兩個問題菩彬，一個是關(guān)于CQRS，你們寫入是用MongoDB潮梯，后面的消息隊列機(jī)制骗灶，你們有用到什么框架？還有一個是關(guān)于區(qū)塊鏈的秉馏，能不能先回答我第一個問題耙旦？這兩個問題不太一樣。

姚晨：其實是一個內(nèi)嵌的萝究，我們通過框架內(nèi)嵌了一個消息隊列免都，當(dāng)然它支持分布式的消息隊列處理。

提問：事件監(jiān)聽有用到嗎帆竹？

姚晨：事件框架本身就是靠框架支撐的琴昆。

提問：會為每一個頁面用一種方式去做嗎？

姚晨：這不會馆揉，但是我們會根據(jù)業(yè)務(wù)需求做一定的優(yōu)化。其實你的訂單抖拦，比如說某一個支付訂單升酣，其實你可能會需要很多數(shù)據(jù)，我們傳統(tǒng)做法是會有一個view的存在态罪，把數(shù)據(jù)整合起來噩茄。對于我們來說，不需要View的存在复颈，甚至ReportDB也不需要绩聘，我們可以通過Event的方式做到很多以前需要其他東西輔助才能完成的東西。

提問：主要是用在MySQL耗啦？

姚晨：對凿菩。

提問：還有一個問題是關(guān)于區(qū)塊鏈，你們?nèi)路莩跄銈兝洗笤诿绹l(fā)布了跟富士康的那個帜讲，區(qū)塊鏈框架你們本身是用的Corda衅谷？

姚晨：據(jù)我所知應(yīng)該是，但是實際上應(yīng)該是這樣似将，區(qū)塊鏈老實來講更多是底層服務(wù)获黔，支付是基礎(chǔ)服務(wù)蚀苛，是構(gòu)建于底層服務(wù)之上的，我們有專門的組負(fù)責(zé)整個區(qū)塊鏈的開發(fā)和應(yīng)用玷氏。對于我來說堵未，我的訴求很簡單，就需要一個分布式的帳簿就好了盏触。

提問：Corda剛出來渗蟹，你們團(tuán)隊用了18個月開發(fā)。

姚晨：應(yīng)該還沒有開始耻陕，就像我說的拙徽，我們要微服務(wù)化，要解決的最核心的就是交易雙方的信任問題诗宣。區(qū)塊鏈和Corda應(yīng)該是可以解決類似的問題膘怕。目前還在調(diào)研階段。

提問：不是有產(chǎn)品已經(jīng)上線了召庞？

姚晨：那個更多是信息岛心，那是供應(yīng)鏈金融，其實我們想知道的是說篮灼，下游的廠商的資質(zhì)忘古，更多是信息的區(qū)塊鏈的保障。我們這邊未來要做的更多是支付诅诱。

提問：但是那套系統(tǒng)不是也有用到區(qū)塊鏈嗎髓堪？

姚晨：對，那個項目并不是我參與的娘荡，所以可能沒法很好的回答你干旁。我只能說，我們需要類似的東西去解決這些問題炮沐。

提問：我想問一下争群，因為您這次分享的主題提到了DDD這一塊，以前在其他的會上我見到這個很少大年，這次非常感謝换薄。有一個問題，你提到（EDA）架構(gòu)和Event Sourcing翔试，我覺得還是比較困難的轻要，它會導(dǎo)致我們整個開發(fā)思維發(fā)生變化，由原來的連續(xù)的邏輯思維方式變成一個離散的方式垦缅。我不知道像你們這種伦腐，在你們公司應(yīng)用下來，有沒有受到阻力失都？比如人員的要求提高什么的柏蘑。

姚晨：我覺得還是蠻挑戰(zhàn)的幸冻，就我自身來說，在整個應(yīng)用過程中都發(fā)現(xiàn)咳焚，邏輯思維會有一個很大的轉(zhuǎn)變洽损。當(dāng)然，我覺得當(dāng)你接受或者說感受到它的好處的時候革半，其實也未嘗不可碑定。因為你想，其實都是慣性思維又官。這對于開發(fā)人員延刘，會要求更高。因為幾乎是完全摒棄了傳統(tǒng)的做法六敬。

提問：沒錯碘赖，這有一定的阻力。我們在公司里面想一個人推動這個是非常困難的外构。以什么方式可以推動這個事情普泡？

姚晨：我可能比較幸運(yùn)我在做這個的時候只有我一個人，所以我只要負(fù)責(zé)把它大致的框架弄好就好了审编。這個老實講來真的蠻有難度的撼班，整個思維方式有蠻大的變化。

本文作者：姚晨（點融黑幫）垒酬，混跡于 IT 行業(yè)多年的碼農(nóng)砰嘁，熱愛編程，從流水線上的作業(yè)系統(tǒng)到衍生品市場的風(fēng)控系統(tǒng)再到大宗商品市場的交易系統(tǒng)皆有所貢獻(xiàn)勘究；善專研喜折騰般码，典型的不折騰會死星人。設(shè)計和構(gòu)建點融支付系統(tǒng)乱顾，致力于推進(jìn)最佳實踐在點融系統(tǒng)中的應(yīng)用。