我叫姚晨，我來自于點融網。我想作為非架構師的我，在這里給大家分享一下在構建點融支付系統的心路歷程，也算是在各位架構師面前班門弄斧。
在點融，支付一開始是作為一個模塊存在于點融的大系統之中，它缺乏統一實現、擴展性較差，我們有大概，一開始大概有三到四個支付渠道，每個支付渠道都有自己的端到端的實現。相同的加解密、報文處理和機制有各自的實現。我們需要接入更多的渠道的時候，就在原有的支付模塊結構中，只能通過重復代碼來實現。這樣的話，我們需要一個統一的支付網關一樣的存在，統一管理所有支付共通的業務邏輯。
業務邏輯全靠代碼固化，這里說的是比如支付渠道的路由選擇，當有支付渠道不可用的時候，或者說出于費率考慮或者出于成功率考慮，類似這樣的路由邏輯，其實我們都是通過代碼固化的。另外就是說，當我們有新渠道或者新的支付方式、交互方式上線的時候，我們希望做一定的灰度開啟，這也是通過一定的代碼固化來實現的，也就是說，當我們有調整，比如說我們希望把1%的用戶提高到10%甚至提高到50%甚至全部開放，這時候我們需要的是重新修改參數，打包部署上線。這對于一個互聯網公司來說，我覺得是無法接受的。
另外，隨著點融業務的擴展，我們將原有的點融大系統逐步拆分成多個業務子系統。這時或多或少所有的業務子系統都需要一定的支付能力。這時候如果還是以支付模塊存在的話，那就意味著說，每一個子業務系統都需要copy這樣一個支付模塊。所以我們覺得，那我們就把這個支付模塊給變成一個系統。
那為什么支付需要服務化，或者說為什么支付可以服務化？我覺得很簡單，其實它就是一個基礎服務，因為點融所有的業務系統都需要支付，所以這是一個足夠強大的理由說，我們去把這個東西做成一個單獨的服務。另外，支付本身來說它具有清晰的上下文邊界，也就是說支付就是支付，充值也好提現在也好代扣代付也好，它跟業務緊密相關，但是它跟業務系統卻又是松耦合的，是一個理想的服務化對象。另外我們需要提供一個演進式的設計，以便適應持續變化的業務需求。這里說的是什么？一開始我們只有兩種支付渠道一種交互方式。隨著業務的演化，隨著支付渠道通路的豐富，以及海外業務的拓展，我們需要支持微信支付，需要支持支付寶支付，甚至未來我們可能會支持區塊鏈支付。類似這樣的話，我們希望能夠有一個良好的演進式的設計，能夠很有彈性的支撐這樣的業務擴展，而不是說，當我需要做一個區塊鏈服務的時候，我需要把整個系統推倒重來。
點融的支付服務到現在大概進行了一年左右的時間，從一開始我們在設計這個系統的時候，其實我們就遵循了一定的原則。網上有個參考，12要素應用。我覺得比較重要的幾點是這幾點。首先我們的支付服務是一個無狀態的，無狀態的好處在于說，當我們有用戶峰值或者有更高要求的訪問量或者使用量的時候，我們可以通過簡單的加機器來實現動態擴容。自包含是指我們摒棄了傳統的war包部署，也就是Tomcat容器部署，應用本身就是一個jar包或者war包，然后通過腳本化的啟動，對外界就是一個黑盒子，你只關心的是數據交互。這樣的好處是說，運維不再關心說我需要Tomcat還是什么，我只需要說，我知道這個應用自身啟動需要哪些東西即可。
環境不感知，具體是指我們把所有環境相關的配置統統挪到了一個配置中心，也就是說同一份代碼可以無縫跑在開發環境、測試環境、生產環境。這樣做的好處是說，我們可以做到完備的CACD過程，也就是當任何一步，比如開發完一個功能，我們打包測試，通過以后我們會自動promotion到demo環境，交給QA測試。QA測試完了以后我們會Promotiong交給UAT測試。整個UAT完備以后，我們可以自動化部署到生產。本身這個應用是從一開始的環境打包出來的那個，我們可以通過一個UUID或者（HushQ）的方式來確保整個部署環節，鏡像沒有被破壞。
第二點就是說，我們在設計整個系統的時候，我們想說我們基于DDD，也就是鄰域模型驅動來設計整個系統內部模塊。支付服務作為一個領域來說，存在于點融的大系統之中。其實支付里面又有內生的子領域，包括訂單，包括用戶，包括支付渠道。那我們不希望用傳統的一層一層三級架構傳遞下去，我們希望作為一個模塊，比如說訂單模塊，作為一個商戶模塊，作為一個支付渠道模塊，存在于自身的子模塊。這樣做的好處是未來系統的擴展。最后做這個系統的時候，我們用了一些，也不算新的東西，應該是比較不常見的東西，我們用了CQRS和Event Sourcing，CQRS簡單來說就是讀選分離，這樣做的好處在于，通常情況下你會發現你的數據大部分情況下會是寫一次讀多次，而且讀的多樣性會遠遠超過你的預期。那這樣，我們可以有針對性的針對寫端，做性能優化。我們也可以針對性的對讀端做性能優化。比如支付系統里面應用的時候，因為整個系統是基于Event設計的，Event本身沒有那么明顯的數據格式，也就是我們不需要用傳統的關系型數據庫來保存Event事件。這里用了MongoDB存儲一個一個事件流。最終這些事件流會異步或者同步到一個讀DB，也就是MySQL。這個時候我們會根據業務的需要，去做一定量的數據重組，以方便后續的數據展示。
甚至我們都可以不需要View的存在，因為本身數據從重組的過程中就可以通過數據冗余實現View的功能。之所以用Event Sourcing，是來自于CQRS的衍生化的好處。對于支付系統來說，任何涉及到的錢的東西我們都希望能夠很好的追蹤，可以被審計。Event Sourcing的好處就是說，任何一步訂單操作，比如從你下單到執行，到結算到清分，任何一步動作都會作為事件存儲。我們可以很清楚的知道，整個訂單在系統中是如何流轉的，它發生了哪些變化產生了哪些效果。另外Event Sourcing帶來另外一個好處就是說，當我們生產發生問題的時候，其實我們是可以把生產的事件拿到本地或者測試環境，直接就可以找到問題的癥結在何處。
在這個過程中我們有些經驗教訓，第一點，微架構真的很重要。大家都知道架構師是一個很誘人的title，但是你做應用的時候，其實你是這個應用的架構師，某一個很小的應用你也需要一個很細微的調整，以便這個應用能夠自適應發展。
大家知道你公司的系統架構，一定程度上決定了你的公司業務的發展。但是你的應用的系統的微架構，某種程度上決定了你系統的命運。如果它不能適應業務的需求，很快就會被另外一個新的應用給替代。第二連續，系統基于事件驅動去開發，盡可能異步化處理。
基于事件驅動的開發的好處在哪？大家用過MQ的人都知道，異步化處理，對于系統的橫向擴展是有相當大的好處的。我們在這里實際上做了一個相當于系統內嵌的消息處理機制，也就是說訂單事件觸發時，會仍到一個消息中心，而這個消息會被多個感興趣的監聽者所監聽。一開始我們可能只有支付，我們希望用戶能夠充值或者提現。后續我們希望監測一些用戶的異常行為，比如說異常提現或者充值異常。這時候我們不需要在原有的支付邏輯上加代碼，我們只要監聽這個支付事件即可。同樣我們也需要在支付成功或者支付失敗的時候，希望能夠第一時間通知到用戶。傳統的做法，比如在Updata，拿到最新狀態的時候插入另外一行邏輯處理代碼。而基于事件的好處就是說，我們可以類似插件式的處理，比如把插件中心這個東西直接嵌入進來，它只需要監聽它干興趣的事件，做對應的處理即可。后續我們可能會有更多的組件模塊，同樣這些所有的處理都可以并行處理，而不需要傳統的，一步一步傳統的處理模式。
什么情況下我們會用到同步操作，什么情況下我們會用到異步操作？拿點融的支付業務場景來做簡單的舉例即可明白，充值跟投資，我們不希望用戶被中斷，所以我們需要把用戶停留在操作界面上。所以整個用戶參與度高的情況下，我們會希望說，所有的請求盡量同步化處理，以便用戶得到及時反饋。反之亦然，在提現這個場景下，由于支付渠道和銀行的限制，其實到賬時間往往會超過一小時，甚至一天。這種情況下是一個理想的可以用于異步操作的場景，事實上也是如此。對于點融支付來說，出去充值這一環節，其他的所有事件我們都是盡量異步化處理。
然后我要說一下，其實很多人在一開始寫代碼的時候會想說，這個類似過度優化或者什么。我們一開始想說要盡可能的把代碼寫得足夠靈活，以便適應系統的需要或者業務的需要。但是實際上，其實就好像跳舞，如果你沒有一定的節奏，或者沒有一定的節拍，其實你反而在尬舞，如果你良好的節拍和良好的動作，你可以創造出更優美的舞姿。
同樣，我們一開始做支付策略的時候陷入了一個誤區，我們會覺得支付策略這些東西是不是可以由產品經理或者風控部門自己定義自己設計規則？于是我們弄了一個相當于腳本引擎的東西，也就是說我們把一些重工作統統交給了業務人員，這樣的后面其實，我們一開始想象的是說，我們希望減緩開發人員的工作，因為我只要執行你的腳本即可，而且業務人員也可以運行腳本，去驗證你想要的結果。這時候發現一個問題，其實在整個的過程中，整個支付策略的設計過程中，還有實現過程中，我們會發現大部分時間還是開發人員在參與。業務人員不懂腳本怎么寫，我們也無法在短時間內提供完備的DSL，以便業務人員輕松書寫業務規則。于是我們推倒重來，這樣我們就給你一定的節拍和一定的舞步，于是我們設計了新的支付策略，也就是我們給了你一個條條框框，我們希望這個條條框框里，你可以自定義你想要的功能。
這一點挺好玩的，就像剛剛說的支付策略，我們其實是在自己造輪子，而且說起來不好意思，我們應該造了兩次。第一次不是太成功，第二次正在驗證。但是我覺得，很重要的一點是說，我們不需要反復的自己去造輪子或者任何功能我們都自己去造輪子。正如這個圖上畫的一樣，我覺得可能我們一開始造的那個支付策略的輪子，要么是個三角形要么是個方形。實際上大家都知道，要跑起來的輪子一定得是圓形。所以在現在這種開放社區或者大廠商，各種開源框架比較完善的情況下，我覺得其實開源是一個更好的選擇，或者你有現有框架，往往對你來說是更方便更快捷的事情。
可視化數據，監控所有能監控的數據。這一點非常重要，對于你的業務改變，還有對于你的系統的監測，以及系統后續的演化，是非常重要非常關鍵的。
比如說，我們這里是點融支付業務的核心數據的實時監控，這里我們用到了很多開源框架。從CQRS和Event Sourcing，我們用到了（Acson）框架，用了CQRS和Event
Sourcing之后，我們不需要業務數據埋點，我們不需要重新梳理我們的關鍵路徑，因為每一個事件都是關鍵路徑。我們需要做的只是集中一個點收集這些事件，我們只需要短短幾行代碼去監聽這個消息，然后通過卡夫卡傳遞給（Logstash），簡單處理后交給（Elasticsearch），最終用（Kibana）做一個非常漂亮的圖形化展示。所有這些工作大概只需要花費一到兩周的時間，這也是為什么我會覺得說，我們不需要重復造輪子，我們要花更多的心思在微架構上調整。
當然，業務數據很重要，性能數據也同樣重要。對我們來說，支付很大程度上是跟銀行和支付渠道打交道。我們需要監控說，API的調用次數，API的耗時長度。我們也需要說，究竟是我們的問題還是三方支付公司的問題。大家可以看到，圖看起來蠻相似的，最上面的是我們服務器的響應的時長，最下面是三方支付公司，我們在請求發往三方支付公司所耗的時長。大家可以發現，我們大部分時間都耗在了三方支付公司，要么是網絡要么是支付公司的處理能力。
這樣，我們一開始所有的請求處理其實都是同步的，這個時候我們會發現問題，比如說代扣、提現、代付，不需要用戶參與的情況下，我們會發現我們的處理能力會急劇的下降，當達到某一個用戶的峰值的時候，我們會發現大量的排隊大量的超時。這時候我們需要做一個內部的排隊處理，我們通過上述的數據分析可以清楚的得到說，原來是三方支付公司或者是網絡問題，導致了我們系統性能的下降。
這里我們用到的開源框架，（job viser）會收集所有的系統，最終展示的效果同樣也是一個開源框架，我們用了（Grafita）做一個數據展示。
說完了系統，本身Java程序少不了的必須要監控，JVM，大家可以看到曲線還是比較夸張的，因為我們的用戶方式或者說我們的支付方式會比較有規律，所以我們會發現有一個很有規律的變化。上面是JVM的使用情況，下面有GC，還有（sred）。很多開源框架有一個問題，就是說它在用（Sred），比較揮霍無度，我們通過這個來觀察是不是有異常。這個也是通過（Job viser）能夠簡單實現的。
自動化一切可以自動化的。這里有一些風險，一會兒會提到。簡單來說，你需要自動化部署，自動化部署的前提是你需要自動化測試。自動化測試的前提是什么？你需要有一個穩定的測試環境。但是三方支付公司的測試環境通常有各種各樣的問題，甚至有些三方支付公司根本不提供測試環境。這時候怎么辦？我們自己寫。我們在跟三方支付公司測試鏈條完畢以后，系統上線以后，我們會寫對應的（moc），也就是我們把所有三方支付公司的請求處理都（moc）一遍。不過現階段可能比較簡陋，因為我們更多的是迫于業務的要求，我們更多是正向的考核，沒有負向或者沒有（Educase），這樣難免會有些問題。另外（Moc）會導致說，你不確定三方API是否有變更，這會帶來一定的風險。我們更多依賴于支付公司不會輕易發生這樣的變化。
未來我們要怎么做？我們用了一些開源框架，對于我們后續的變化會有極大的好處，比如說實時數據分析。當我們可以便捷的進行數據分析，這時候我們可以做適當的智能路由。比如說常見的場景是某一個銀行把支付通路給關了，但是它并沒有提前告知到支付渠道，支付渠道也不可能提前告知到我們。這個時候，我們傳統來說會采用輪巡的方式，比如每五分鐘或者每一分鐘監測一下，這個時間段這個支付渠道大概有多少筆失敗的訂單、失敗的原因是什么。這時候會有一個問題是說，你一定會有一個時間段的誤差，也就是它未必是真實的表象。這時候如果我們有實時數據，如果我們能夠做實時分析，那這個會形成一個良好的生態鏈路，也就是說當一個渠道真正有問題的時候，我們可以拿到第一手資料，進行第一手分析，然后做一個動態的智能切換。
之前也說了，我們設計整個支付服務的時候就考慮到，支付里面每一個子領域都是可以獨立拆分的。那就意味著說，未來可能支付服務本身就會變成另外一個微服務化的系統。這樣的話，我們會想說，我們到底要固守Java世界還是要采取語言不可知論？最近突然比較火熱的（Kotlin）。拿支付策略來舉例，我們現在還是用Java實現，但是或多或少都有些別扭，因為Java本身并不是一個function program language。它本身也不支持太友善的DSL。反過來我們可能會有Ruby在DSL獨樹一幟，有（Go）更適合在ATI網關這種應用場景下發揮它的作用，為什么要固守Java世界？對我們來說我們會嘗試更多的不同的語言，就好像我們現在的支付管理后臺，我們并不是用傳統的JSP來做的，我們是用Ruby來寫的。未來我們要做的API網關可能會采取（Go）。上面說的實時數據分析，Java也不擅長這個東西，我們可能會用（Scala），可能用Ruby甚至可能用更新的（Kotlin）。因為這些靜態化的腳本語言，它的應用場景更適合。
另外是說，最近比較火熱的Serverless和Lambda架構，它的好處在哪？其實我們不需要一個stand by的server，比如說我們在考慮計費，我們在做策略試算的時候，其實我們不需要一個24小時stand by的server在那里等著某一個時間段突然爆發的請求，我們只需要說，在需要處理的時候快速的去響應快速的去處理。像Amazon提供的Lambda架構是一個理想的狀態，就像剛剛說的計費，計費不需要那么實時，我甚至可以跑批處理。
如果獨立開一個計費模塊的話，你會發現你要一個7×24小時stand by的東西，但是它偶爾要處理一些東西。其實我只需要在處理的時候去獲取我需要的計算機資源即可。點融的支付服務運行到現在，我們在考慮做一些技術輸出的方向，也就是說我們會跟銀行合作，會跟其他公司合作，想要推我們的支付服務。這另外會面臨一個比較大的問題，就是如何信任。如果解決不了這個問題，我們面臨的問題是我們變成了一個傳統的軟件開發公司，我們技術外包，把系統開發好，部署交給銀行或者交給其他公司去使用。這個想來跟大家知道的現有的科技趨勢是背道而馳的。我們會想說有沒有更好的辦法去解決？我們其實更重要的是說，我們需要保證的，最核心的一點是說，我們希望保證交易的雙方是可信的，交易雙方的數據是不被篡改的。這個時候我們也會有區塊鏈，相信大家知道，應該是一個理想的選擇。但是區塊鏈有一個問題是，交易雙方的數據會被整個鏈路所有人共享。也就是說我跟么個特定銀行的交易會被整個鏈路其他銀行或者其他公司共享。雖然數據加密可以解決這個問題，但是我本身就不希望數據流向其他鏈路。
最近出來的Corda，提供的是分布式總帳的方案。它和區塊鏈的區別在哪？交易數據僅存在于交易雙方。當然這個還是比較新的，因為它本身的語言事件也是用（Kotlin），還是比較巧的，有待考證。但是本身來，對于支付服務的演化，未來很重要的一點應該是區塊鏈，我們希望服務可以被大家使用，我們也希望我們的服務是可信的，而且數據不被篡改。通過技術，我們應該是可以實現這樣的目標。
下面是一些參考資料，第一個是12要素app，告訴你怎樣做好12要素的應用，以便適應未來的需要。第二個是MartinFowler的，第三個也是Martin馬大神的。
今天就介紹到這里，謝謝。
提問：我本身也是做支付，我想問一下，你們微化之后，很多服務，相互的調用是怎么樣的？管理怎么處理的？還有異步性，很核心的訂單如果異步了，可能是為了提高性能，但是加入我們出現了宕機，這樣的一些容災措施應該是如何處理？
姚晨：首先第一個問題，當你微服務化的時候，最重要的是注冊中心，還有一個API網關的概念。也就是說，你希望對外提供的是一個服務，但是內部可能是不同的，RPC也好，用哪個實現，這個更多取決于公司內部，用什么不太重要。但是一旦有了很好的配置中心和服務，相當大的程度上能夠解決第一個問題。第二個問題是消息發生了遺失怎么辦，CQRS的好處是遺失了你可以重復播放，異步不是所有的東西都異步，只是用戶發起了之后你可以異步執行。具體訂單的狀態的流轉，其實你可以做同步化，但是每一步同步化，產生的事件沒有被及時處理，可以再發送。好處在這里。本身來說，CQRS有一定的學習成本，所以不見得所有的系統都可以跑，尤其是已有系統，改造起來會比較麻煩。
提問：我看到你有引用馬大神一些東西，關于這個有兩個問題，我看到你們已經應用了他的一些理論，那第一個是說，比如你用到的Event Sourcing，在發生一些變化的時候是變成一個一個Event，這樣可以在一個完全開始的狀態去把一件事情重復出來。我看到一個引發的問題是說，怎么樣結構化的存儲這些Event，就是這件事情變化的時候，你是用Event存儲起來的，怎么樣結構化的存儲到一些結構化數據庫里面，以你怎么樣，比如說怎么樣去查詢，拿到像結構化數據庫里面很容易拿到的一些結果？第二個有用到Serverless和Lambda的架構，需要的時候可以申請一些資源做一些事情，那怎么保證速度和響應時間？
姚晨：先說第二個問題，其實還沒有開始用，只是預計未來想要這樣發展。但是如果考慮到時間來說，其實你起一個Lambda的function program的話要快得多，你可以保證它在毫秒級。運行過Java層知道，那是秒級才會起的。這個還需要后續的驗證。當然我覺得這是一個未來的方向。
關于第一點，我們用到了CQRS不單單是Event Sourcing，因為CQRS的好處是你可以很方便的去用Event Sourcing。如果是純粹的Event Sourcing，不知道怎么去處理非結構化數據，讓它結構化。CQRS的好處是說，你可以把非結構化的數據在讀端結構化，也就是說我們會有兩個DB，對于點融支付有兩塊DB，一個是MongoDB存非結構化數據，然后有一個MYSQLDB，用來存最終狀態的存放，這時候可以實現結構化處理。
其實任何，當然這里有一點很重要是說，任何事件的觸發一定是基于Event產生的那個最終的內存狀態。也就是說，其實你存儲到非結構化數據里面，實際上是一個一個事件，當這個事件不再被使用的時候，本身這個訂單已經被丟失了。當你下一次來操作來查詢，查詢并不會這樣，操作的時候，后臺的框架是把所有的Event拿出來，逐個播放，最終可以得到一個真正有效的狀態。所以其實，老實講還是得益于框架的使用，所以我們可以很好的做一個讀跟寫的數據的分離。
提問：所以你們的Mongo，處理寫，MySQL在讀，所以這兩個中間有一個轉化？
姚晨：對，這個轉化也得益于，我們只要去監聽對Event的狀態。
提問：我有兩個小問題，我本身是做風控的，想問一下關于風控的問題。第一個問題是說，你們的風控是，比如說像策略平臺，是自己實現的還是說引入了外部的技術和系統開發的？第二個問題是說，你們目前風控的攔截，大概有多少？有沒有出現因為風控的原因導致的資損這種問題？
姚晨：其實我覺得我們說的風控不是同一個維度的風控，我說的更多是支付本身業務的風控，而不是更外層那種。
提問：就是進入支付之后的風控？
姚晨：對，本身支付業務的風控我們是自己開發的，因為風控老實來講，還是比較專有的領域。你還是需要自定義的DSL，要么是別人幫你實現的DSL，要么是你自己實現的DSL，這樣你的業務人員才能去改那樣的規則書寫那樣的規則，否則我們一開始選擇的純腳本化，真的不是很好的選擇。可能回答不了您的問題。
提問：我有兩個小問題，一個是在支付服務里面有沒有遇到什么分布式伺服的問題？如果有是怎么解決？還有一個是我看到你這邊圖表，包括業務數據和性能數據，我理解是這兩個權限管理都很弱的，你們在權限管理方面是怎么做的？
姚晨：第一個問題，我個人是強烈反對分布式伺服，所以在我們系統里面是沒有分布式伺服存在。我的理解，理論上是可以，但是本身這個框架也支持一個（Saga），一個大的伺服，但是并不像伺服那么明顯。之所以用分布式的初衷一定是想要rollback，出現問題的時候。其實如果有良好的補償機制，是可以做到程序化的回滾。
提問：就是所有的服務都是帶有補償機制？
姚晨：對。第二個問題是，實際上沒錯，這兩個權限都弱爆了。在（Kibana）那一塊我們用到了開源的一個框架，做了一些基本的權限控制。理論上來說還是可以滿足一定的要求。另外我們也咨詢過開發公司，他們提供的解決方案會相對來說成本比較高，所以我們會用（Serchga）我建議你可以嘗試一下。
提問：我在你們講座的過程中，聽說點融網作為第三方的支付公司，接的渠道有第三方公司，第三方公司在后面也是接銀行、銀聯、銀企，你們為什么不直接接銀行？你們接入第三方支付公司，耗時會有提升，提供支付服務，為什么別人找你們做第三方支付，你們又接第三方支付公司？這樣別人就可以直接找別人，為什么要找你們？你們作為第三方支付公司，接第三方支付公司，成本也會大很多。
姚晨：其實這個有各種方面的原因，因為其實不是我們不想跟銀行玩，是銀行不想跟我們玩。因為金融行業實際上是有監管，有準入門檻。我們沒有牌照或者我們現在互金行業在重新監管。實際上合規還在進行中，其實會有各種各樣的資質約束。所以我們只能去跟支付公司打交道。但是本身來說，我覺得支付公司也好，銀行也好，其實對于支付系統來說都是一個通道，也就是說我們提供給支付公司或者其他公司來用，我并不是把我的支付能力給到你，因為我沒有支付牌照，我不能幫你做二清。那意味著說，我其實是我是幫你提供技術解決方案。支付或多或少都會面臨同樣的問題，你要做渠道選擇，你要做路由策略，你要做監控，你要做審，你要做風控。這些東西都是公有的業務，我們提供的還是一個綜合的解決方案，而不是告訴你說我有這個支付通路，你來用我的支付通路。因為這個理論上來說是不合規。
提問：我有兩個問題，一個是關于CQRS，你們寫入是用MongoDB，后面的消息隊列機制，你們有用到什么框架？還有一個是關于區塊鏈的，能不能先回答我第一個問題？這兩個問題不太一樣。
姚晨：其實是一個內嵌的，我們通過框架內嵌了一個消息隊列，當然它支持分布式的消息隊列處理。
提問：事件監聽有用到嗎？
姚晨：事件框架本身就是靠框架支撐的。
提問：會為每一個頁面用一種方式去做嗎？
姚晨：這不會，但是我們會根據業務需求做一定的優化。其實你的訂單，比如說某一個支付訂單，其實你可能會需要很多數據，我們傳統做法是會有一個view的存在，把數據整合起來。對于我們來說，不需要View的存在，甚至ReportDB也不需要，我們可以通過Event的方式做到很多以前需要其他東西輔助才能完成的東西。
提問：主要是用在MySQL？
姚晨：對。
提問：還有一個問題是關于區塊鏈，你們三月份初你們老大在美國發布了跟富士康的那個，區塊鏈框架你們本身是用的Corda？
姚晨：據我所知應該是，但是實際上應該是這樣，區塊鏈老實來講更多是底層服務，支付是基礎服務，是構建于底層服務之上的，我們有專門的組負責整個區塊鏈的開發和應用。對于我來說，我的訴求很簡單，就需要一個分布式的帳簿就好了。
提問：Corda剛出來，你們團隊用了18個月開發。
姚晨：應該還沒有開始，就像我說的，我們要微服務化，要解決的最核心的就是交易雙方的信任問題。區塊鏈和Corda應該是可以解決類似的問題。目前還在調研階段。
提問：不是有產品已經上線了？
姚晨：那個更多是信息，那是供應鏈金融，其實我們想知道的是說，下游的廠商的資質，更多是信息的區塊鏈的保障。我們這邊未來要做的更多是支付。
提問：但是那套系統不是也有用到區塊鏈嗎？
姚晨：對，那個項目并不是我參與的，所以可能沒法很好的回答你。我只能說，我們需要類似的東西去解決這些問題。
提問：我想問一下，因為您這次分享的主題提到了DDD這一塊，以前在其他的會上我見到這個很少，這次非常感謝。有一個問題，你提到（EDA）架構和Event Sourcing，我覺得還是比較困難的，它會導致我們整個開發思維發生變化，由原來的連續的邏輯思維方式變成一個離散的方式。我不知道像你們這種，在你們公司應用下來，有沒有受到阻力？比如人員的要求提高什么的。
姚晨：我覺得還是蠻挑戰的，就我自身來說，在整個應用過程中都發現，邏輯思維會有一個很大的轉變。當然，我覺得當你接受或者說感受到它的好處的時候，其實也未嘗不可。因為你想，其實都是慣性思維。這對于開發人員，會要求更高。因為幾乎是完全摒棄了傳統的做法。
提問：沒錯，這有一定的阻力。我們在公司里面想一個人推動這個是非常困難的。以什么方式可以推動這個事情？
姚晨：我可能比較幸運我在做這個的時候只有我一個人，所以我只要負責把它大致的框架弄好就好了。這個老實講來真的蠻有難度的，整個思維方式有蠻大的變化。
本文作者：姚晨（點融黑幫），混跡于 IT 行業多年的碼農，熱愛編程，從流水線上的作業系統到衍生品市場的風控系統再到大宗商品市場的交易系統皆有所貢獻；善專研喜折騰，典型的不折騰會死星人。設計和構建點融支付系統，致力于推進最佳實踐在點融系統中的應用。
