關於票據系統設計在之前的博客中也聊過，今天做一個補充 1、架構 票據系統主要就是和票交所進行交互，圍繞這一核心，我們把系統劃分為三大部分，分別是：票據網關服務、票據業務服務、票據庫存服務。 網關服務：對接票交所，負責和票交所的交互，主要是收發報文。 業務服務：負責票據業務的處理，比如出票、背書、貼現 ...
關於票據系統設計在之前的博客中也聊過，今天做一個補充
1、架構
票據系統主要就是和票交所進行交互，圍繞這一核心，我們把系統劃分為三大部分，分別是：票據網關服務、票據業務服務、票據庫存服務。
網關服務：對接票交所，負責和票交所的交互，主要是收發報文。
業務服務：負責票據業務的處理，比如出票、背書、貼現等等。
庫存服務：負責票據信息的存儲，比如票據的交易、正面、背面等。
我簡單畫了個草圖，大概就是如下圖這樣：
說明一下：圖中“指令服務”和“對接票交所”其實它倆可以看成是一個整體，都是為了對接票交所，我這裡就統稱網關服務了。指令服務其實是在票交所返回的報文基礎上做了封裝和其它的業務處理，比如申請的時候做一些校驗和參數組裝，應答的時候可以統一做待應答處理
1）用戶在瀏覽器上操作，請求發送到服務端，業務服務開始處理，包括各種校驗和業務數據存儲，以及審批
2）業務服務調用網關服務發送申請報文，併在收到確認報文後進行庫存等相關處理
3）業務服務和網關服務是互相調用的，是全雙工通信
2、庫存
庫存包含的表比較多，主要的有：主表、子表、應收/應付表、背面表、交易表、加鎖表、餘額表等
2.1、交易
所有的業務都需要票交所的中轉，因此每次跟票交所的交互就是一次交易。以貼現為例，如果是內部貼現就會有兩條交易記錄，一條出庫交易，一條入庫交易，如果是貼現給外部，則申請方只有一條出庫交易，應答方只有一條入庫交易。
2.2、狀態
票據的狀態比較多，而且變化也很複雜，目前是直接修改，這樣造成的問題就是排查問題的時候都不知道是在哪裡被修改的，後續考慮用狀態機管理，比如：COLA中提供了一個狀態機組件cola-component-statemachine
2.3、挑票
不同的創建可供挑選的票不一樣，這個需要配合票據狀態來實現。從自己的應收/應付表中選擇那些條件的票，這些條件包括但不限定於票據狀態、流通狀態、風險狀態、庫存狀態、交易類型、票據類型、餘額等等
2.4、拆票
發起業務申請，審批通過後，發送報文。這裡有兩個區間，一個是票據原本的區間，一個是發送的區間。收到票交所返回的確認報文後，進行拆票。實際上，是先預拆票，發給票交所，票交所返回成功後，再真正的進行本地拆票。每拆一次票就多出兩個子票，原票置為已拆票已出庫，新票為未拆票在庫。這樣做可以很好的保存拆票歷史，一目瞭然。最後，切記拆票這裡要加鎖，防止併發問題導致的子票區間錯誤。
有人問：直接拆，拆完再發票交所，行不行？答案是行，但是很麻煩，如果票交所返回失敗，還得把票再合回去。這就好比是一張鈔票你先撕成兩半，再想恢復如初，想想都覺得麻煩。
2.5、加鎖
最簡單的加鎖就是給某一條數據加一個標識位（或者鎖標識的欄位），通過修改欄位的值來達到加鎖與解鎖的目的。
在業務申請後需要人工審批，審批通過後才會發報文，對方需要應答，整個過程很長，為了防止在此期間該業務中使用的票被其它業務使用，需要對該業務中用到的票據進行加鎖，加鎖之後其它業務就不能用了。這裡有幾張方案：
方案一：直接在票據字表上加一個欄位，用來表示該票據是否被鎖定。這種方案是可行的，但是直接對整張票加鎖的話粒度有點大，這就意味著同一時間這張票只能用於一個業務，即使另一個業務中只是想用部分區間那也不行，因為整個區間都被鎖死了。
方案二：加一張表，加鎖就往表中插入一條數據，解鎖就邏輯刪除這條數據。這種方案也是可行的，這個時候就重點要考慮鎖粒度的問題，如果只鎖票號和區間的話就跟第一種方案沒區別。那能不能鎖預拆票的區間呢？好像也不太行，同樣是2塊錢的票，由於區間不同，所以它們是不同的兩張票，但是沒拆票之前區間都是一樣的，所以沒法證明你的2塊跟我的2塊是不一樣的，所以，由於票據區間不能重疊，且預拆票的存在，導致不能只鎖票號和區間。
方案三：在方案二的基礎上，我們鎖票號、區間、業務編號。這樣的話，這張票可以同時用在多個業務中，但是僅僅這樣還不夠，還需要扣減占用的金額，為了防止用超了。借鑒一下電商中對庫存分段加鎖的設計，本來10個庫存，可以分成5組，每組2個庫存，這樣併發能力一下子提示了5倍，各搶各的互不幹預。
應收表的票據還有一個餘額欄位，每次加鎖後，直接扣減餘額。這樣的話，加鎖表中的記錄就失去了鎖的意義，純粹變成了一個記錄而已，一旦業務失敗，可以把扣掉的金額再加回去。
從這個意義上講，有了餘額欄位，這就相當於沒加鎖，是的，此處的加鎖表是為了做一個記錄，誰對那張票加了鎖，以便解鎖的時候可以恢復餘額。
回到最初的出發點上，我們再來思考，其實沒有必要擔心同一張票同時被多個業務使用，因為一張100塊的票，雖然咱倆都用了10塊，但是由於票據是可以拆分的，所以你用的10塊，跟我用的這10塊，不是同一個10塊，只要別用超了就行，此時這張票的餘額還剩80塊。
綜上，加鎖就是往加鎖表中插入數據，同時扣減占用金額，更新餘額。解鎖就是刪除加鎖表中的數據，恢復餘額。
以上是申請類的業務加鎖，還有應答類的業務也需要加鎖，這個就不贅述了，直接在待應答表上加鎖即可
3、個性化需求
不同的客戶有不同的定製化需求，因此如何屏蔽差異，儘可能的復用現有的代碼，成為了一個急需解決的問題。
通過分析，這些定製化需求通常表現為在某一個業務之前加校驗，或者在業務結束的時候推送數據
思路一：
1）就像模板方法一樣，在核心的方法中預留一些方法，以便子類可以做自己的邏輯處理。或者，介面都給出預設實現，不同的項目可以自己實現，也可以用預設的實現。或者用SPI
2）將核心功能做成組件，每個項目自己引入組件，有需要的話可以對組件進行擴展，擴展的方式可以是AOP攔截，或者實現相應的介面
思路二：
引入Groovy，將差異化的代碼可以寫在配置文件或者資料庫中，執行的時候動態生成執行邏輯
