珠海珠海優點信息技術有限公司數字貨币交易所開發方案

一(yī)、交易所系統平台組件：

1、交易撮合引擎

2、前端用戶交互界面

3、區塊鍊錢包應用

4、後端管理(lǐ)控制台

二、系統整體架構

圖1

2.1、交易撮合引擎

交易引擎是交易所應用的(de)核心，它對于交易執行(xíng)、餘額計算、訂單記錄訪問和(hé)買/賣交易的(de)匹配都至關(guān)重要。

開發數字貨币交易所時，應當優先考慮交易撮合引擎的(de)建設。如(rú)果沒有(yǒu)性能強大的(de)撮合引擎，無論是哪種類型的(de)交易所也隻能是一(yī)個沒有(yǒu)任何價值的(de)空殼。

2.2、前端用戶交互界面

用戶界面是交易所的(de)臉面，在很大程度上也決定了用戶的(de)體驗感。确保以簡約的(de)方式構建用戶友好且直觀的(de)界面，以提供令人驚喜的(de)交易體驗，使用戶更容易執行(xíng)交易訂單。

具有(yǒu)以下功能模塊：

2.2.1：場外交易功能（OTC、C2C）商(shāng)家對客戶/币币交易功能（多币種，自(zì)選交易對）

2.2.2：注冊/登錄/找回密碼/安全驗證等功能/交易行(xíng)/K線功能

2.2.3：我(wǒ)的(de)資産（充币、提币、劃轉）/訂單管理(lǐ)（場外、币币、杠杆、合約等）

2.2.4：個人資料修改/安全中心實名認證/提币地(dì)址管理(lǐ)

2.2.5：系統公告/漲跌幅排行(xíng)榜

2.2.6：系統版本信息/幫助中心

2.3用戶端主要功能模塊：

2.3.1：用戶管理(lǐ)模塊：合作方維護自(zì)有(yǒu)用戶群體-可(kě)獨立存儲-涵蓋登錄-注冊-權限管理(lǐ)-實名認證系統-谷歌認證-短(duǎn)信驗證-郵件驗證。

2.3.2：錢包模塊：錢包管理(lǐ)冷熱分離(lí)-資産保存與資産流動分離(lí)管控-錢包服務與網絡環境物理(lǐ)隔離(lí)-杜絕安全隐患。

2.3.3：财務模塊：用戶充值-提現-下單鎖定-财務流通-結算。

1、用戶注冊和(hé)登錄

2、資金充值/提現

3、訂單、交易、餘額的(de)查詢與統計

4、專業版交易買進/賣出

5、客戶支持功能

三、區塊鍊錢包

接入數字貨币錢包的(de)支持對于交易所平台是非常重要的(de)。所有(yǒu)數字貨币将存儲在用戶的(de)錢包中。安全性更強的(de)錢包解決方案，将有(yǒu)助于發展用戶與數字貨币交易所之間的(de)信任。

交易所錢包分冷/熱錢包兩種：

冷錢包：冷即離(lí)線、斷網，也就是說，私鑰存儲的(de)位置不能被網絡所訪問。例如(rú)紙錢包、腦錢包、硬件錢包等等。

熱錢包：熱即聯網，也就是私鑰存儲在能被網絡訪問的(de)位置。例如(rú)存放在交易所上、在線錢包網站、手機(jī)App錢包都屬于熱錢包。

通常而言，冷錢包更加安全，熱錢包使用更加方便，兩者相互搭配。

四、後端管理(lǐ)控制台

管理(lǐ)控制台将幫助交易所運營方或持有(yǒu)者管理(lǐ)整個平台的(de)運作。控制台的(de)功能可(kě)以根據具體的(de)業務需求進行(xíng)定制，但一(yī)般來說，管理(lǐ)控制台必須包含以下功能：

1、用戶管理(lǐ)中心

2、管理(lǐ)數字貨币列表

3、交易管理(lǐ)及參數設置

4、數據查詢與統計

5、平台的(de)風控管理(lǐ)

五、撮合系統設計總體設計

5.1 層次設計

一(yī)般而言，數字貨币交易所的(de)交易撮合系統中包括以下幾個核心模塊:

■ 用戶：用戶委托報價與數量，生成訂單發送至交易平台。

■ 網關(guān)：負責收集用戶訂單，并将其派發給撮合引擎。

■ 撮合引擎：交易系統中的(de)核心部分,用于接收訂單并根據業務邏輯實現訂單，撮合同時生成交易記錄，随後給予用戶交易結果反饋。

■ 行(xíng)情引擎：接收撮合交易引擎的(de)處理(lǐ)結果，将撮合的(de)交易數據持久化到數據庫，同時定時生成多時間周期的(de)K線數據（開盤價、收盤價、交易量、最高(gāo)價、最低(dī)價）。

■ 數據庫：用來存放交易過程中的(de)訂單和(hé)交易記錄,實現數據持久化。

此外，不同類型的(de)數字貨币交易産品（現貨、合約、期貨、杠杆）将撮合模塊劃分為(wèi)若幹業務分區，每個分區獨立進行(xíng)撮合，彼此不受影響。

5.2 撮合交易算法

如(rú)圖5.a所示，撮合引擎的(de)核心業務模塊就是撮合交易算法撮合交易算法的(de)任務一(yī)方面是完成對客戶所下訂單進行(xíng)公平合理(lǐ)的(de)排列和(hé)撮合功能，也要保證撮合算法的(de)公平性、高(gāo)效性以及擴展性等。

圖5.a

5.3 訂單隊列

撮合交易的(de)重要組成部分就是買賣訂單，通過對買賣訂單進行(xíng)撮合最後形成交易記錄。所以對無法立刻完成撮合的(de)訂單，需要有(yǒu)買入隊列和(hé)賣出隊列保存訂單。隊列按照“價格優先、同價格下時間優先”的(de)原則。買入隊列按照委托價格從低(dī)到高(gāo)的(de)順序，賣出隊列則按照委托價格從低(dī)到高(gāo)的(de)順序排列，如(rú)圖5.b所示：

圖5.b

5.4 撮合順序

撮合引擎接收到新的(de)買入訂單，則會到賣出隊列的(de)頭部查找是否存在符合價格規則的(de)賣出訂單，如(rú)果存在賣出價格小于或等于買入價格的(de)訂單，則從隊列中取出此訂單并撮合成一(yī)筆(bǐ)交易；如(rú)果賣出隊列為(wèi)空或隊列頭部不滿足價格關(guān)系，則将買入訂單插入買入隊列中，由于買入隊列是按照價格與時間先後進行(xíng)排序，所以新插入的(de)訂單會經過一(yī)次排序插入到買入隊列的(de)相應位置。

相同的(de)，當撮合引擎接收到新的(de)賣出訂單，則會到買入隊列的(de)頭部査找是否存在符合價格規則的(de)買入訂單，如(rú)果存在買入價格大于或等于賣出價格的(de)訂單，則從訂單隊列中取出此訂單并撮合成一(yī)筆(bǐ)交易；如(rú)果買入隊列為(wèi)空或隊列頭部不滿足價格關(guān)系，則将賣出訂單插入到賣出隊列中，由于賣出隊列也是按照價格與時間先後進行(xíng)排序的(de)，所以新插入的(de)訂單會經過一(yī)次排序插入到賣出隊列的(de)相應位置。

圖5.c

結合買賣訂單情況，撮合算法流程如(rú)圖5.c所示。從圖5.c所示的(de)撮合順序可(kě)知，買賣隊列的(de)有(yǒu)序性是保證撮合順序的(de)确定性的(de)基礎，并且撮合過程中每筆(bǐ)訂單都可(kě)以撮合出當前最優交易。

5.5 內(nèi)存撮合

當前的(de)數據庫撮合技術的(de)性能低(dī)下的(de)原因在于過多與數據庫交互，使得I/O很多，系統整體處理(lǐ)速度同時受數據庫事務邏輯約束。

內(nèi)存撮合技術通過最大程度去(qù)除與數據庫的(de)交互過程，将整個錯和(hé)邏輯放在內(nèi)存中進行(xíng)(如(rú)圖5.d所示)。因此比數據庫撮合技術少了許多I/O交S 間，在性能上可(kě)以大幅提升撮合速度；例是內(nèi)存撮合的(de)弊端就是由于內(nèi)存的(de)易失性，服務器出現故障停機(jī)時，所有(yǒu)的(de)交易數據将會丢失，系統的(de)可(kě)靠性以及一(yī)緻性都相應大幅降低(dī)。因此本文在提高(gāo)內(nèi)存撮合技術可(kě)靠性的(de)方面采用丫多機(jī)熱備份及分布式一(yī)緻性技術作為(wèi)補充，從而獲得內(nèi)存撮合技術的(de)高(gāo)性能以及數據庫撮合技術的(de)數據持久性。

圖5.d

通過釆用多機(jī)熱備份技術，降低(dī)了單一(yī)內(nèi)存撮合引擎故障時系統不可(kě)用的(de)問題，但仍舊(jiù)無法提供100%的(de)可(kě)用性，因為(wèi)當出現大規模服務器集群故障時，仍舊(jiù)存在服務不可(kě)用的(de)可(kě)能性，但在實際生産環境中，三台互為(wèi)備份的(de)服務器就可(kě)以提供較高(gāo)的(de)可(kě)以用于生産環境的(de)可(kě)靠性。

5.6 內(nèi)存狀态機(jī)複制

由于多機(jī)熱備份技術引入了多台互為(wèi)熱備份的(de)撮合引擎，根據撮合系統設計以及撮合邏輯要求，需要保證服務器之間的(de)數據一(yī)緻，這就需要保證多服務器之間一(yī)緻性。

內(nèi)存狀态機(jī)複制方案，即将撮合算法視(shì)作一(yī)個确定性狀态機(jī)，将其複制多份并部署到撮合系統中的(de)多台撮合引擎中。每個撮合引擎副本從相同的(de)初始狀态開始運行(xíng)，當撮合系統收到網關(guān)發來的(de)訂單時，系統中的(de)每個撮合引擎都會撮合這個訂單，并依次産生交易記錄，同時更新确定性撮合算法狀态機(jī)的(de)獨立狀态。通過這樣的(de)方式，當撮合系統正常運轉時，每個撮合引擎副本都會具有(yǒu)相同的(de)結果狀态；當撮合系統出現故障或異常時，撮合引擎就會出現狀态的(de)不一(yī)緻情況，換句話說一(yī)旦撮合系統的(de)結果或狀态出現了不一(yī)緻的(de)情況就可(kě)以斷定系統出現了異常。

5.7 關(guān)鍵技術點

為(wèi)了實現這樣的(de)內(nèi)存狀态機(jī)複制撮合系統,将撮合系統劃分為(wèi)以下組成關(guān)鍵技術點

■ 将确定性撮合算法狀态機(jī)服務部署到多個獨立撮合引擎

■ 接收網關(guān)訂單,并作為(wèi)确定性撮合算法狀态機(jī)的(de)輸入

■ 根據撮合算法需求,選擇一(yī)種訂單排序方式

■ 每個撮合引擎對按照排序方式排序過的(de)訂單進行(xíng)撮合

■ 将确定性撮合算法狀态機(jī)輸出的(de)交易記錄作為(wèi)給用戶或數據庫的(de)響應

■ 監控撮合引擎副本的(de)狀态或輸出的(de)差别

5.8 實現方案

為(wèi)實現基于內(nèi)存狀态機(jī)複制的(de)撮合系統,本文主要通過以下方案實現狀态機(jī)複制的(de)關(guān)鍵技術點:

■ 采用原子(zǐ)多播解決撮合引擎訂單的(de)可(kě)靠多播與全局有(yǒu)序性

■ 采用基于無鎖訂單隊列的(de)流水線撮合技術提供快速的(de)訂單撮合

■ 采用異步一(yī)緻性持久化技術實現與數據庫的(de)交互

■ 采用失效備援技術對撮合引擎集群進行(xíng)狀态監控并保證系統的(de)容錯能采用進度追趕技術解決将故障撮合引擎的(de)恢複或新撮合引擎的(de)加入

5.9 系統架構

5.9.1 系統硬件體系架構

典型的(de)高(gāo)可(kě)靠高(gāo)性能撮合模型硬件架構如(rú)圖5.e所示，系統由n台客戶端、N台網關(guān)、X個産品集群(每個集群由2至3台撮合引擎組成，負責響應産品訂單的(de)處理(lǐ))、一(yī)個交易記錄數據庫和(hé)可(kě)選的(de)監視(shì)系統組成。其中客戶端連接到相應網關(guān)，網關(guān)負責接收客戶端提交的(de)訂單，并根據訂單相關(guān)的(de)金融産品類别，轉發到相對應的(de)産品集群。産品集群中所有(yǒu)撮合引擎均接收網關(guān)發送的(de)訂單，根據撮合業務規則，将其撮合并回饋消息給網關(guān)和(hé)客戶端，同時将撮合生成的(de)交易記錄持久化到交易記錄數據庫中。

圖 5.e

5.9.2 系統軟件體系架構

圖5.f

如(rú)圖5.f所示，高(gāo)可(kě)靠高(gāo)性能撮合模型主要由表示層、轉發層、業務層和(hé)數據層組成。其核心部分業務層主要由撮合引擎集群組成，每個撮合引擎采用原子(zǐ)多播将訂單定序後進行(xíng)撮合處理(lǐ)，并結合無鎖訂單隊列實現高(gāo)效流水線撮合，最後結果寫入本地(dì)日志。整個業務流程由消息傳遞總線将消息反饋給轉發層。轉發層則根據産品轉發規則将訂單轉發給相應撮合引擎集群；而撮合引擎将本地(dì)日志中的(de)交易記錄讀取到異步持久化代理(lǐ)進程中，并進而與數據層的(de)異步持久化寫入進程通信，并最終持久化到數據庫中。本地(dì)日志增強了撮合系統數據的(de)可(kě)靠性，在出現故障後，數據仍就可(kě)以從本地(dì)日志中恢複；而界步的(de)持久化機(jī)制則提高(gāo)了數據的(de)持久化吞吐率。

5.9.3 撮合引擎架構

圖5.g

為(wèi)了使系統可(kě)擴展易維護，撮合引擎由原子(zǐ)多播訂單定序模塊、撮合處理(lǐ)器模塊、交易記錄日志模塊和(hé)內(nèi)存數據組成，每個模塊根據功能業務劃分。其中各部分主要有(yǒu)以下功能：

■ 交易訂單接收線程：負責從網關(guān)接收訂單，并完成原子(zǐ)多播定序流程。

■ 交易訂單發送線程：将定序完成的(de)訂單發送給相關(guān)撮合業務線程。

■ 交易信息發送線程：将訂單交易狀态反饋給網關(guān)。

■ 外圍業務邏輯線程：進行(xíng)撮合數據的(de)準備處理(lǐ),更新內(nèi)存訂單數據。

■ 撮合業務邏輯線程：根據确定性撮合算法撮合接收的(de)訂單。

■ 交易行(xíng)情發布線程：處理(lǐ)內(nèi)存行(xíng)情信息并發布給網關(guān)。

■ 同步日志寫線程：将訂單撮合産生的(de)交易記錄同步持久化到本地(dì)日志文件。

■ 異步持久化代理(lǐ)進程：異步将日志文件中的(de)數據讀取并持久化到數據庫。

■ 訂單信息：存儲訂單的(de)相關(guān)價格、數量、用戶、限制、類型和(hé)狀态等信息。

■ 交易行(xíng)情信息：撮合交易過程中的(de)交易行(xíng)情信息。

5.9.4 系統接口

撮合系統主要為(wèi)使用者提供訂單的(de)下單和(hé)查詢服務、交易行(xíng)情的(de)實時反饋功能以及系統狀态的(de)監控查看服務。因此系統需要實現預留的(de)接口主要包括：

■ 下單接口

■ 訂單查詢接口

■ 行(xíng)情查詢接口

■ 系統控制接口和(hé)運行(xíng)狀态查詢接口等

從總體設計入手,将撮合業務處理(lǐ)從數據庫遷移至內(nèi)存中,同時釆用多機(jī)熱備份技術解決內(nèi)存撮合技術的(de)易失性問題,最終提出內(nèi)存狀态機(jī)複制方案作為(wèi)高(gāo)可(kě)靠髙性能撮合系統的(de)實現路線。

六、前後端分離(lí)

整套系統的(de)前端與後端完全分離(lí)開，這是比較主流的(de)開發方式，可(kě)以讓後端開發人員與前端開發人員各自(zì)專注于自(zì)己的(de)業務實現。目前可(kě)以看到前端主要有(yǒu)四個：用戶PC端、用戶Android端、用戶IOS端、管理(lǐ)員PC端。它們(men)都是通過Api與服務對接，傳輸數據是通過Json。

6.1區塊鍊錢包接口

項目中對每個币種的(de)RPC接口做(zuò)了一(yī)層抽象，作為(wèi)抽象層的(de)wallet項目，屏蔽了不同币種的(de)對接問題，區塊鍊錢包節點的(de)RPC調用方式千奇百怪，項目中通過wallet把生成地(dì)址、掃塊、充值監控、餘額歸集等操作抽象出來，當我(wǒ)們(men)想接入新的(de)币種的(de)時候，隻需要對Wallet-RPC-XXX項目進行(xíng)複制粘貼就可(kě)以了。

6.2交易機(jī)器人

交易機(jī)器人通過同步獲取到了各大交易所的(de)交易數據，進而在自(zì)身交易所種繪制相應的(de)K線，機(jī)器人的(de)設計原理(lǐ)，尤其是其中有(yǒu)很多參數的(de)設計，非常關(guān)鍵，可(kě)以讓盤面表現出跟大型交易所一(yī)樣的(de)行(xíng)情展示效果。

安全性對于數字貨币來說至關(guān)重要，如(rú)何從技術方面保障安全的(de)？

安全對于交易所來說是非常重要的(de)一(yī)面,我(wǒ)們(men)由經驗豐富的(de)安全專家帶隊參與到了開發和(hé)運營的(de)方方面面，從代碼安全到系統監控甚至社交攻擊防護。 在快速發展的(de)過程中，可(kě)能面臨了大規模的(de)DDOS攻擊，我(wǒ)們(men)在改進自(zì)身系統和(hé)的(de)同時，可(kě)引入烏雲、安全寶、加速樂(yuè)等安全領域的(de)公司的(de)專業服務， 在解決自(zì)身安全問題的(de)同時，我(wǒ)們(men)也在風控系統中增加了對用戶的(de)安全監控，比如(rú)有(yǒu)用戶帳号被盜以後如(rú)果存在異常的(de)登陸提現等行(xíng)為(wèi)，我(wǒ)們(men)客服系統上會有(yǒu)相應的(de)報警，客服人員會在第一(yī)時間和(hé)用戶進行(xíng)電話核實。

在架構和(hé)運維方面是如(rú)何做(zuò)？

我(wǒ)們(men)在所有(yǒu)的(de)系統架構都為(wèi)高(gāo)可(kě)用做(zuò)了大量的(de)設計，在前端Web層面和(hé)後台數據緩存和(hé)業務服務層均允許做(zuò)任意的(de)節點失效。在數據庫層面我(wǒ)們(men)通過複制和(hé)數據分區的(de)方式實現了主備層面的(de)高(gāo)可(kě)用，在出現故障後通過相應的(de)業務日志檢查即可(kě)迅速通過ip漂移實現數據庫的(de)故障恢複。

運維方面，從硬件層面的(de)IDC機(jī)房線路到防火牆等網絡設我(wǒ)們(men)都實現了自(zì)動化的(de)主備切換的(de)能力，除了對所有(yǒu)服務器和(hé)網絡設備的(de)監控外，還根據業務場景提供了數百個監控點，使我(wǒ)們(men)可(kě)以在第一(yī)時間獲得系統的(de)運行(xíng)狀況和(hé)問題報告。并為(wèi)用戶提供了随時可(kě)以聯系報故障的(de)渠道(dào)，使我(wǒ)們(men)能快速響應用戶的(de)問題。

技術棧是怎樣的(de)？

基于LNMP搭建的(de)交易平台，在關(guān)鍵的(de)錢包和(hé)撮合引擎方面使用C++實現，随着業務的(de)發展和(hé)業務增長(cháng)帶來的(de)營運壓力提升，可(kě)逐漸根據業務的(de)特點進行(xíng)了相應的(de)技術升級。

PHP作為(wèi)Web層實現與用戶的(de)交付，使用Redis做(zuò)持久化的(de)存儲和(hé)數據緩存。

通過Node.js和(hé)QuickFix這兩個開源項目我(wǒ)們(men)實現了實時的(de)行(xíng)情推送，并為(wèi)用戶提供了可(kě)靠的(de)交易API服務。

數據庫層面我(wǒ)們(men)使用MySQL、InnoDB實現了業務數據的(de)存儲。交易終端覆蓋Windows/Mac OS X/Android/iOS，在桌面和(hé)移動端為(wèi)用戶提供了更好的(de)交易體驗。

維護響應體系

    根據日常維護內(nèi)容的(de)緊急程度，将事件劃分為(wèi)四個級别：

Ø  一(yī)級維護：在網站上發放緊急通告：

Ø  二級維護：新內(nèi)容補充需求或內(nèi)容修改；

Ø  三級維護：技術更新；

針對不同的(de)維護級别，限定對維護的(de)反應時間及解決限期，對于涉及到公司的(de)維護任務，處理(lǐ)如(rú)下：

²  一(yī)級維護：30分鐘響應，1小時內(nèi)解決；

²  二級維護：在資料收集完畢及确認後，1個工作日內(nèi)完成：

²  三級維護：根據需求時間而定

故障響應體系

n  故障級别劃分

    根據突發故障對系統及網站的(de)影響程度将事件劃分為(wèi)三個級别；

Ø  一(yī)級故障：浏覽者(操作員)無法打開界面、系統癱瘓、所有(yǒu)功能完全不能正常使用、APP無法打開，嚴重影響工作的(de)錯誤；

Ø  二級故障：系統性能下降較為(wèi)嚴重，部分主要功能不能使用；

Ø  三級故障：少量次要功能不能正常使用，性能下降導緻工作效率略微降低(dī)，頁面上的(de)錯誤不影響網頁的(de)浏覽。

n  故障響應

    針對不同的(de)故障級别，處理(lǐ)如(rú)下：

Ø  一(yī)級故障：l小時響應，24小時內(nèi)解決：

Ø  二級故障：l小時響應，72小時內(nèi)解決；

Ø  三級故障：1小時響應，一(yī)周內(nèi)解決；

報價部分：

DEMO