# 泛娛樂時代下的儲值系統架構演進 - 陳康賢

{%hackmd j86FNbMoRoeN4Xn0pg5ofw %}

> 請從這裡開始

充值是典型的大流量場景

儲值系統的架構
1. 交易系統
* 訂單生成
* 收發貨
* 下單
* 支付
* 履行
* 交易狀態推進
* 儲值
* 餘額

3. 網關

### 儲值系統的挑戰
* 不知道何時發生，無法預估流量
* 廠商可能無法承載壓力而當機，但不能影響其他業務儲值
* 壓力大時，廠商會失敗，概率很高
* 充值是現金與代幣的轉換，數據不一致就會資損

損失隨著時間演進會變得很大
資料一致性->關鍵

發起充值
-> 成功ok
-> 失敗 ok
-> 超時 ？

### 保障調度的可靠度

付款是異步的動作

接收到付款成收的訊息後會去充值，但消息可能會言時、當機、各種問題，就有其他的機制去保障系統在消息的依賴出了問題的時候保障系統能運轉，會有定時任務去輪尋，還有人工接口手段。

這邊有個商家隊列，為何有三個框？實際上每個商家一個隊列

### 應對突發流量

之前碰過因為一些原因而做這樣的變更。我們背後有幾百個商家，幾千個商家，可能有個商家就充值不了。如果所有商家都在同一個隊列，就會導致充值隊列都堆積在隊列里，其他商家就不能充值。所以我們對商家做了隔離，確保每個商家有當機狀況不會影響其他商家。

再來就是多線程調度來提升充值效率，典型的生產者、消費者模型

通過錢台規則配置去調度，如果一個商家出現充值服務不可用，就會把訂單分配給其他商家。

### 自適應訂單分配

如果檢測到服務有問題，充值緩慢，就會調整規則，把前端流量...每個渠道都有調度規則，我透過自適應的方式分配訂單給有能力的商家。

#### 解決一致性問題

兩種方式保障一致性：
1. 不斷重試，直到成功，重是可以消息重投，或是定時任務
2. 商家回調通知，告知是否充值成功
3. 唯一要求：充值要冪等

> 分佈式交易成本較高。

手機淘寶，智付寶、天貓，前端有不同的調度規則，通過自適應的感知調控規則，把這些訂單調配給其他有能力的商家。

一致性問題，在兩者溝通，成功 ok 失敗也是，擔心不確定的狀況。

我們跟三方廠商，都是透過 HTTP 去交握的，這種時間成本較高，需要分散式的去做 N 次的確認，才能做一個同步的動作。

我們怎麼去實現數據一致性，一方面是不斷的嘗試，直到成功為止，透過消息或是定時任務，還有一種方式就是，透過商家的回調 (callback)，告知我是成功的，這要重置，充值一百塊錢，是要一百還是五十塊錢呢，

同一筆操作，只能成功一次

### 泛娛樂時代的新挑戰
1. 品類空前繁榮
2. 相同週期內要求對接的品類更多，對接的速度一定程度影響到市場份額和利潤
3. 不同的品類，個性化差異較大

人們生活娛樂方式改變，如直播

對於我們的挑戰為何，充值的品類越來越的繁榮，需要在更短的時間內對接商家，不同的品類他們的差異還是滿大的，充值一個視頻會員跟其他，背後的交易流程也是不一樣的。

#### 如何降低成本？如何加快對接速度？

用到組建化的思想，交易面露有七八成是一樣的，支持

核心：
1. 頁面快速搭建能力
2. 流程快速訂製能力

### 組建化渲染 -- 背景

不同訊息交易方法、排列方式不一樣，怎麼去讓業務能夠快速搭建這些頁面呢？ 這三張圖都是在手機淘寶裡面，我們還有其他柒道比如說天貓，不同渠道的頁面長得不一樣，可是時間功能是一樣的，只是主題不一樣。如何快速生成頁面呢？

透過組件化的方式做這這一點，首先數據插件先去後面取各式各樣的數據模型，每個商品、什麼價格、什麼優惠，都是透過數據插件去後端取，取回來是一個數據模型，要把這個數據模型轉換成 view model，所謂視圖模型是什麼呢？比如這個頁面上有多少個 input、button，是怎麼樣展現？排佈？ 規則？ 都是透腳本來做的。

前端做什麼呢？前端的組件識別到吐出的 view model，接收到以後就會把頁面渲染出來，就是右邊的頁面，這就是組件畫的思想。

### 組建化渲染 -- 選品引擎

* 解決的問題：
1. 充值不透單個商品，相同屬性的商品成千上萬，需 要進行篩選
2. 不同渠道，可佩不同選品規則
* 優勢：
1. 擴展 node 非常方便
2. 圖形化配置，複雜規則可視化
3. 變更即時生效

選品引擎用在同一個品類下選出要充值的商品。不同的渠道可以配置不同的規則，是通過積木塊的方式去拖拉方式把規則生成。

### 微服務編排引擎

哪個插件先執行、後執行？ 透過我們的微服務編排引擎做編排。不同於工作流程情工作特性：

* 核心特色：
1. 支持上下文參數管理，可以配製上下文可見參數
2. 執持並行，該特性對於提升插件執行效率非常重要，而現有工具，儒內部的 tbbpm、smartengine，外部的 activiti 都只支持串行。
3. 內存執行

不同節點之間做參數傳遞，哪些節點可以訪問到哪些參數，工作引擎不管，但視微服務引擎...這是因為在一系列服務中發生問題，導致要這樣配置。這些服務用不同人開發，他不知道哪些參數能訪，哪些不能，可能會污染參數。

### 組建化渲染 -- 系統架構

因為我們要支援錢前台的渲染，效率就很重要，我們支持並行執行

我們搭建一整套體系來支撐組件化，四大核心，一塊是組件化協議，前端跟後端之間靠協議溝通，前端只要去關注頁面上需要有展現多少 input 多少圖片，組織形式是什麼，後端我就生成這些 view model 吐出給前端。

前端的 SDK 就是去解析view model，後端有渲染引擎，把數據轉換成 view model。要讓一整套系統思想可以再生產環境 run 起來，他需要不斷修改bug，增加新功能、業務，去做跌代，需要一整套組件、模版，變更管理工具來做這件事。

* 四大核心
1. 組建化協議
2. 前端 SDK
3. 渲染引擎
4. 組建、模板管理 & 變化

* 幾個特色
1. 高性能
2. 變更即時生效
3. 輕量級易於擴展

### 組建化渲染 -- 持續集成

最核心的演進：引入變更

我們研發環境內，分成三套，`日常環境`、`預發環境`、`線上環境`，底層 DB 是同一套的，預發跟日常環境是隔離的，建好模板之後，我在預發環境再去編輯，編輯好之後透過預發環境之後，推動到線上環境。有很多問題，其中一個問題不同環境在看發中可能改到相同模板，發生衝突的話，會倒致問題。或是在發布裡面呢，可能不知道改了多少組件，會在預發環境修改了，提交到線上環境，也是個問題。

我們做了最重要的改變就是引入變更，透過變更把變更同步到線上，避免很多問題

### 儲值鎑路個性化 -- 背景

關鍵詞：個性化、效率、可維護性

* 不同的商家合品類、幾要鍊路上的流程節點不盡相同，比如充值信息的收集，分帳、優惠、售後，電單超時，跟廣傷互惠

因為開發模式不同，生產效率大大不同。
可維護性我講個case，之前也是各自搭建，後來我們想要發行優惠券，在所有充值管道都能用，但沒有辦法支援。這種開發模式導致整個生產效率大大降低，研發成本會提高很多。

### 充值鏈路個性化 -- 核心價值

* 擷面化：通過流程節點的訂製，以及流程的組裝，更塊擴展出一個全節錄功能，縮短開發週期。
* 接口泛話調用：網關通過 groovy 適配第三方接口，接口語意更清晰，降低開發成本，縮短開發週期。

實際上分為兩個點，一個是截面化，一個是接口泛用化調用

對於相同流程節點來說，新開發練路只要適用之前的流程節點就好，我開發自己的個性化節點，串起來就ok了。

### 充值鍊路個性化 --- 流程抽象
交易創建、交易履行。

交易矮行主要做的事情就是充值，當用戶付款之後，交易就開始履行調用第三方進行充值動作。兩個流程是透過工作流引擎結果起來。

這裡面最關鍵的一點是什麼？有一張圖高速公路，不同的是走在不同道上，就是擔心發生交通事故。對於值儲鍊路也是一樣，每個流程有一個明確的身份標示，如果我改了我的流程只會引響到我的交易鍊路，最多只會影響到我自己，不會影響到其他的商家。通過業務身皆分能做到商家之類的隔離。

給他們身分驗證，能讓他們行駛在自己的車道上面，除了這兩個核心流程之外，我們還有其他配置工作能保障生產環境穩定的運行，不同的業務能透過不同的流程，透過 api 來組織，結點可以複用也可以

控制台他負責業務員數據配置，接口元數據配置，第三方交互用的證書、簽名方式、密鑰也好，都透過控制台的方式管理。

請幫忙分配圖片，感恩！


> 用技術的方式，提高效率，降低成本。

講師聯繫方式
wechat longlong_AT_taobao.com

## Q&A
* 當系統進行改動時，是否有商家不願意進行配合改動的？

用泛化接口去適應商家的設定

* 現行架構若導致無法儲值，有沒有方法應對？
有方法解決：只有一家當機，其他不會被影響

###### tags: `MW18`