珠海优点信息数字货币交易所开发方案

一、交易所系统平台组件：

1、交易撮合引擎

2、前端用户交互界面

3、区块链钱包应用

4、后端管理控制台

二、系统整体架构

图1

2.1、交易撮合引擎

交易引擎是交易所应用的核心，它对于交易执行、余额计算、订单记录访问和买/卖交易的匹配都至关重要。

开发数字货币交易所时，应当优先考虑交易撮合引擎的建设。如果没有性能强大的撮合引擎，无论是哪种类型的交易所也只能是一个没有任何价值的空壳。

2.2、前端用户交互界面

用户界面是交易所的脸面，在很大程度上也决定了用户的体验感。确保以简约的方式构建用户友好且直观的界面，以提供令人惊喜的交易体验，使用户更容易执行交易订单。

具有以下功能模块：

2.2.1：场外交易功能（OTC、C2C）商家对客户/币币交易功能（多币种，自选交易对）

2.2.2：注册/登录/找回密码/安全验证等功能/交易行/K线功能

2.2.3：我的资产（充币、提币、划转）/订单管理（场外、币币、杠杆、合约等）

2.2.4：个人资料修改/安全中心实名认证/提币地址管理

2.2.5：系统公告/涨跌幅排行榜

2.2.6：系统版本信息/帮助中心

2.3用户端主要功能模块：

2.3.1：用户管理模块：合作方维护自有用户群体-可独立存储-涵盖登录-注册-权限管理-实名认证系统-谷歌认证-短信验证-邮件验证。

2.3.2：钱包模块：钱包管理冷热分离-资产保存与资产流动分离管控-钱包服务与网络环境物理隔离-杜绝安全隐患。

2.3.3：财务模块：用户充值-提现-下单锁定-财务流通-结算。

1、用户注册和登录

2、资金充值/提现

3、订单、交易、余额的查询与统计

4、专业版交易买进/卖出

5、客户支持功能

三、区块链钱包

接入数字货币钱包的支持对于交易所平台是非常重要的。所有数字货币将存储在用户的钱包中。安全性更强的钱包解决方案，将有助于发展用户与数字货币交易所之间的信任。

交易所钱包分冷/热钱包两种：

冷钱包：冷即离线、断网，也就是说，私钥存储的位置不能被网络所访问。例如纸钱包、脑钱包、硬件钱包等等。

热钱包：热即联网，也就是私钥存储在能被网络访问的位置。例如存放在交易所上、在线钱包网站、手机App钱包都属于热钱包。

通常而言，冷钱包更加安全，热钱包使用更加方便，两者相互搭配。

四、后端管理控制台

管理控制台将帮助交易所运营方或持有者管理整个平台的运作。控制台的功能可以根据具体的业务需求进行定制，但一般来说，管理控制台必须包含以下功能：

1、用户管理中心

2、管理数字货币列表

3、交易管理及参数设置

4、数据查询与统计

5、平台的风控管理

五、撮合系统设计总体设计

5.1 层次设计

一般而言，数字货币交易所的交易撮合系统中包括以下几个核心模块:

■ 用户：用户委托报价与数量，生成订单发送至交易平台。

■ 网关：负责收集用户订单，并将其派发给撮合引擎。

■ 撮合引擎：交易系统中的核心部分,用于接收订单并根据业务逻辑实现订单，撮合同时生成交易记录，随后给予用户交易结果反馈。

■ 行情引擎：接收撮合交易引擎的处理结果，将撮合的交易数据持久化到数据库，同时定时生成多时间周期的K线数据（开盘价、收盘价、交易量、最高价、最低价）。

■ 数据库：用来存放交易过程中的订单和交易记录,实现数据持久化。

此外，不同类型的数字货币交易产品（现货、合约、期货、杠杆）将撮合模块划分为若干业务分区，每个分区独立进行撮合，彼此不受影响。

5.2 撮合交易算法

如图5.a所示，撮合引擎的核心业务模块就是撮合交易算法撮合交易算法的任务一方面是完成对客户所下订单进行公平合理的排列和撮合功能，也要保证撮合算法的公平性、高效性以及扩展性等。

图5.a

5.3 订单队列

撮合交易的重要组成部分就是买卖订单，通过对买卖订单进行撮合最后形成交易记录。所以对无法立刻完成撮合的订单，需要有买入队列和卖出队列保存订单。队列按照“价格优先、同价格下时间优先”的原则。买入队列按照委托价格从低到高的顺序，卖出队列则按照委托价格从低到高的顺序排列，如图5.b所示：

图5.b

5.4 撮合顺序

撮合引擎接收到新的买入订单，则会到卖出队列的头部查找是否存在符合价格规则的卖出订单，如果存在卖出价格小于或等于买入价格的订单，则从队列中取出此订单并撮合成一笔交易；如果卖出队列为空或队列头部不满足价格关系，则将买入订单插入买入队列中，由于买入队列是按照价格与时间先后进行排序，所以新插入的订单会经过一次排序插入到买入队列的相应位置。

相同的，当撮合引擎接收到新的卖出订单，则会到买入队列的头部査找是否存在符合价格规则的买入订单，如果存在买入价格大于或等于卖出价格的订单，则从订单队列中取出此订单并撮合成一笔交易；如果买入队列为空或队列头部不满足价格关系，则将卖出订单插入到卖出队列中，由于卖出队列也是按照价格与时间先后进行排序的，所以新插入的订单会经过一次排序插入到卖出队列的相应位置。

图5.c

结合买卖订单情况，撮合算法流程如图5.c所示。从图5.c所示的撮合顺序可知，买卖队列的有序性是保证撮合顺序的确定性的基础，并且撮合过程中每笔订单都可以撮合出当前最优交易。

5.5 内存撮合

当前的数据库撮合技术的性能低下的原因在于过多与数据库交互，使得I/O很多，系统整体处理速度同时受数据库事务逻辑约束。

内存撮合技术通过最大程度去除与数据库的交互过程，将整个错和逻辑放在内存中进行(如图5.d所示)。因此比数据库撮合技术少了许多I/O交S 间，在性能上可以大幅提升撮合速度；例是内存撮合的弊端就是由于内存的易失性，服务器出现故障停机时，所有的交易数据将会丢失，系统的可靠性以及一致性都相应大幅降低。因此本文在提高内存撮合技术可靠性的方面采用丫多机热备份及分布式一致性技术作为补充，从而获得内存撮合技术的高性能以及数据库撮合技术的数据持久性。

图5.d

通过釆用多机热备份技术，降低了单一内存撮合引擎故障时系统不可用的问题，但仍旧无法提供100%的可用性，因为当出现大规模服务器集群故障时，仍旧存在服务不可用的可能性，但在实际生产环境中，三台互为备份的服务器就可以提供较高的可以用于生产环境的可靠性。

5.6 内存状态机复制

由于多机热备份技术引入了多台互为热备份的撮合引擎，根据撮合系统设计以及撮合逻辑要求，需要保证服务器之间的数据一致，这就需要保证多服务器之间一致性。

内存状态机复制方案，即将撮合算法视作一个确定性状态机，将其复制多份并部署到撮合系统中的多台撮合引擎中。每个撮合引擎副本从相同的初始状态开始运行，当撮合系统收到网关发来的订单时，系统中的每个撮合引擎都会撮合这个订单，并依次产生交易记录，同时更新确定性撮合算法状态机的独立状态。通过这样的方式，当撮合系统正常运转时，每个撮合引擎副本都会具有相同的结果状态；当撮合系统出现故障或异常时，撮合引擎就会出现状态的不一致情况，换句话说一旦撮合系统的结果或状态出现了不一致的情况就可以断定系统出现了异常。

5.7 关键技术点

为了实现这样的内存状态机复制撮合系统,将撮合系统划分为以下组成关键技术点

■ 将确定性撮合算法状态机服务部署到多个独立撮合引擎

■ 接收网关订单,并作为确定性撮合算法状态机的输入

■ 根据撮合算法需求,选择一种订单排序方式

■ 每个撮合引擎对按照排序方式排序过的订单进行撮合

■ 将确定性撮合算法状态机输出的交易记录作为给用户或数据库的响应

■ 监控撮合引擎副本的状态或输出的差别

5.8 实现方案

为实现基于内存状态机复制的撮合系统,本文主要通过以下方案实现状态机复制的关键技术点:

■ 采用原子多播解决撮合引擎订单的可靠多播与全局有序性

■ 采用基于无锁订单队列的流水线撮合技术提供快速的订单撮合

■ 采用异步一致性持久化技术实现与数据库的交互

■ 采用失效备援技术对撮合引擎集群进行状态监控并保证系统的容错能采用进度追赶技术解决将故障撮合引擎的恢复或新撮合引擎的加入

5.9 系统架构

5.9.1 系统硬件体系架构

典型的高可靠高性能撮合模型硬件架构如图5.e所示，系统由n台客户端、N台网关、X个产品集群(每个集群由2至3台撮合引擎组成，负责响应产品订单的处理)、一个交易记录数据库和可选的监视系统组成。其中客户端连接到相应网关，网关负责接收客户端提交的订单，并根据订单相关的金融产品类别，转发到相对应的产品集群。产品集群中所有撮合引擎均接收网关发送的订单，根据撮合业务规则，将其撮合并回馈消息给网关和客户端，同时将撮合生成的交易记录持久化到交易记录数据库中。

图 5.e

5.9.2 系统软件体系架构

图5.f

如图5.f所示，高可靠高性能撮合模型主要由表示层、转发层、业务层和数据层组成。其核心部分业务层主要由撮合引擎集群组成，每个撮合引擎采用原子多播将订单定序后进行撮合处理，并结合无锁订单队列实现高效流水线撮合，最后结果写入本地日志。整个业务流程由消息传递总线将消息反馈给转发层。转发层则根据产品转发规则将订单转发给相应撮合引擎集群；而撮合引擎将本地日志中的交易记录读取到异步持久化代理进程中，并进而与数据层的异步持久化写入进程通信，并最终持久化到数据库中。本地日志增强了撮合系统数据的可靠性，在出现故障后，数据仍就可以从本地日志中恢复；而界步的持久化机制则提高了数据的持久化吞吐率。

5.9.3 撮合引擎架构

图5.g

为了使系统可扩展易维护，撮合引擎由原子多播订单定序模块、撮合处理器模块、交易记录日志模块和内存数据组成，每个模块根据功能业务划分。其中各部分主要有以下功能：

■ 交易订单接收线程：负责从网关接收订单，并完成原子多播定序流程。

■ 交易订单发送线程：将定序完成的订单发送给相关撮合业务线程。

■ 交易信息发送线程：将订单交易状态反馈给网关。

■ 外围业务逻辑线程：进行撮合数据的准备处理,更新内存订单数据。

■ 撮合业务逻辑线程：根据确定性撮合算法撮合接收的订单。

■ 交易行情发布线程：处理内存行情信息并发布给网关。

■ 同步日志写线程：将订单撮合产生的交易记录同步持久化到本地日志文件。

■ 异步持久化代理进程：异步将日志文件中的数据读取并持久化到数据库。

■ 订单信息：存储订单的相关价格、数量、用户、限制、类型和状态等信息。

■ 交易行情信息：撮合交易过程中的交易行情信息。

5.9.4 系统接口

撮合系统主要为使用者提供订单的下单和查询服务、交易行情的实时反馈功能以及系统状态的监控查看服务。因此系统需要实现预留的接口主要包括：

■ 下单接口

■ 订单查询接口

■ 行情查询接口

■ 系统控制接口和运行状态查询接口等

从总体设计入手,将撮合业务处理从数据库迁移至内存中,同时釆用多机热备份技术解决内存撮合技术的易失性问题,最终提出内存状态机复制方案作为高可靠髙性能撮合系统的实现路线。

六、前后端分离

整套系统的前端与后端完全分离开，这是比较主流的开发方式，可以让后端开发人员与前端开发人员各自专注于自己的业务实现。目前可以看到前端主要有四个：用户PC端、用户Android端、用户IOS端、管理员PC端。它们都是通过Api与服务对接，传输数据是通过Json。

6.1区块链钱包接口

项目中对每个币种的RPC接口做了一层抽象，作为抽象层的wallet项目，屏蔽了不同币种的对接问题，区块链钱包节点的RPC调用方式千奇百怪，项目中通过wallet把生成地址、扫块、充值监控、余额归集等操作抽象出来，当我们想接入新的币种的时候，只需要对Wallet-RPC-XXX项目进行复制粘贴就可以了。

6.2交易机器人

交易机器人通过同步获取到了各大交易所的交易数据，进而在自身交易所种绘制相应的K线，机器人的设计原理，尤其是其中有很多参数的设计，非常关键，可以让盘面表现出跟大型交易所一样的行情展示效果。

安全性对于数字货币来说至关重要，如何从技术方面保障安全的？

安全对于交易所来说是非常重要的一面,我们由经验丰富的安全专家带队参与到了开发和运营的方方面面，从代码安全到系统监控甚至社交攻击防护。 在快速发展的过程中，可能面临了大规模的DDOS攻击，我们在改进自身系统和的同时，可引入乌云、安全宝、加速乐等安全领域的公司的专业服务， 在解决自身安全问题的同时，我们也在风控系统中增加了对用户的安全监控，比如有用户帐号被盗以后如果存在异常的登陆提现等行为，我们客服系统上会有相应的报警，客服人员会在第一时间和用户进行电话核实。

在架构和运维方面是如何做？

我们在所有的系统架构都为高可用做了大量的设计，在前端Web层面和后台数据缓存和业务服务层均允许做任意的节点失效。在数据库层面我们通过复制和数据分区的方式实现了主备层面的高可用，在出现故障后通过相应的业务日志检查即可迅速通过ip漂移实现数据库的故障恢复。

运维方面，从硬件层面的IDC机房线路到防火墙等网络设我们都实现了自动化的主备切换的能力，除了对所有服务器和网络设备的监控外，还根据业务场景提供了数百个监控点，使我们可以在第一时间获得系统的运行状况和问题报告。并为用户提供了随时可以联系报故障的渠道，使我们能快速响应用户的问题。

技术栈是怎样的？

基于LNMP搭建的交易平台，在关键的钱包和撮合引擎方面使用C++实现，随着业务的发展和业务增长带来的营运压力提升，可逐渐根据业务的特点进行了相应的技术升级。

PHP作为Web层实现与用户的交付，使用Redis做持久化的存储和数据缓存。

通过Node.js和QuickFix这两个开源项目我们实现了实时的行情推送，并为用户提供了可靠的交易API服务。

数据库层面我们使用MySQL、InnoDB实现了业务数据的存储。交易终端覆盖Windows/Mac OS X/Android/iOS，在桌面和移动端为用户提供了更好的交易体验。

维护响应体系

    根据日常维护内容的紧急程度，将事件划分为四个级别：

Ø  一级维护：在网站上发放紧急通告：

Ø  二级维护：新内容补充需求或内容修改；

Ø  三级维护：技术更新；

针对不同的维护级别，限定对维护的反应时间及解决限期，对于涉及到公司的维护任务，处理如下：

²  一级维护：30分钟响应，1小时内解决；

²  二级维护：在资料收集完毕及确认后，1个工作日内完成：

²  三级维护：根据需求时间而定

故障响应体系

n  故障级别划分

    根据突发故障对系统及网站的影响程度将事件划分为三个级别；

Ø  一级故障：浏览者(操作员)无法打开界面、系统瘫痪、所有功能完全不能正常使用、APP无法打开，严重影响工作的错误；

Ø  二级故障：系统性能下降较为严重，部分主要功能不能使用；

Ø  三级故障：少量次要功能不能正常使用，性能下降导致工作效率略微降低，页面上的错误不影响网页的浏览。

n  故障响应

    针对不同的故障级别，处理如下：

Ø  一级故障：l小时响应，24小时内解决：

Ø  二级故障：l小时响应，72小时内解决；

Ø  三级故障：1小时响应，一周内解决；

报价部分：

DEMO