嘘~ 正在从服务器偷取页面 . . .

我用一个月时间实现了一个全国唯三的开源股票交易所?


前言:持续更新ing 本篇只作为项目介绍,架构设计,技术选型等。😜

一. 写在前面

国内目前我所见过开源的交易所没有几个,这里我说一下我找到的两个其中一个是: Crypto-Exchange 这个在 gitee 上可以搜到的(文末会给出地址),我的这套项目的撮合引擎设计也有参考这个,这套的文档非常清晰,功能也十分全面,而且通过架构和技术选型可以看出这套的代码质量非常高,作者应该也是个技术大牛,但是对于想尝试的新手(比如我)非常不友好,不过这套项目面向的对象也不是小白,而是对于企业想进行二次开发的最好选择。😊

还有一个是尚学堂的 基于SpringCloudAlibaba货币交易系通(Coin-Exchange)这个 b 站上是有教学视频的,但是有几个问题,这套的文档非常不规范,乱七八糟,数据还不全,我不知道是什么原因,可能是因为网上流传太多导致这个项目越来越模糊,但是如果你有底子的话有些地方也是能参考的。 😅

上面我说的这两套项目我都有部署测试过,第一个太专业了,而且很多功能需要你对技术栈的配置非常熟练,而且对于服务器的配置有一定的要求,(文档中有个服务器配置要求感兴趣的可以去看看)有一些核心功能开源中并没有给出来需要联系作者,所以我也是跑了一些基础的功能,第二个我就不说了,写的乱七八糟只有一些业务逻辑还能参考参考。而且这两个的有些核心东西都很像,我也不太清楚是谁抄谁的。

我在做这个项目之前搜遍了全网 随便一个交易所的代码,搞个第三方的平台都能卖几千块钱,如果对这个有兴趣的可以联系我,我给你网址 hhhhh,关于交易所的项目国内网上所拥有的资源可以说是屈指可数,我个人认为有几个原因,首先是中国人对钱太敏感了,涉及到资金流相关的项目都是很保密的,其次就是接触过证券行业的同学应该都知道,整个交易所系统(我这里就拿其中一个业务:柜台 来举个例子)现在的供应商的行业现状就是国外一些比较大的供应商都是自主研发。回到国内,无论大大小小券商都是进行采购(买买买)👍 ,拿来就用的类型,国内目前占据绝大市场份额的供应商比较出名的就是杭州的恒生电子,这家上市公司的大股东非常的有来头,就是非常出名的蚂蚁金服,除了这家以外,其他的都是一些中小型的供应商,比如金证…等等。很多供应商都说自己使用的是自研的,但是据我了解多多少少都是使用的恒生的进行二次开发,然后让恒生的工程师过来进行调试,因为恒生目前在国内属于绝对的龙头企业。这是大概目前国内的行业现状。☔

说说我为啥要做这个项目:

没有为啥,因为我想做。

免责声明:(这个我每篇都会写一遍)

按照中国国家相关法律政策规定,不得向中国大陆境内公民提供数字货币资产交易服务,不得提供人民币对数字货币的兑换以及支付服务,如不予配合履行以上职责,造成一切后果与本人无关。

技术参考说明:

本项目相关的业务逻辑只要有参考或者模仿第三方平台或有关开源仓库的都会在文末进行说明并贴出相关传送门。

二. 项目的整体结构

2.1 委托终端(柜台)🔨

根据国内监管会要求,客户无法直接连接交易所系统,中间必须经过证券公司的系统,即柜台系统。

交易柜台是连接交易所的下单系统,这里保存着用户所有的数据,通过经纪公司交易柜台再将交易所委托汇报和成交回报反馈给投资者(用户)券商根据这些数据和商业银行清算资金和登记结算公司清算股份,最后和所有的客户清算资金和股份,现实生活中的清算业务是一个非常复杂的业务流程,感兴趣的可以自己去研究一下。

柜台第二个核心功能就是路由,例如,我现在想要购买茅台的股票,柜台在收到客户从终端发过来的委托之后,柜台需要判断这支股票是在哪里上市的,是深交所上市的股票,还是上交所上市的股票,判断发现是上交所上市的股票之后,它就会通过和上交所的交易网关把这笔委托发送过去,这个选择路由发送过去的过程就叫做订单路由。💨

2.2 网关🔨

负责收集用户订单,并将其派发给撮合引擎,柜台通过 TCP 协议向交易所网关传递数据,前置网关对于柜台的业务并不做出具体答复。柜台流向网关的数据流是单向的,目的是将委托送到撮合核心的数据的优先级达到最高,所有其他业务必须给其让路,将带宽发挥到极限。💨

2.3 排队机🔨

排队机所作的工作有两个:

第一个:按照固定的频率从各个委托网关收集订单,第二个:对于所有收集到的订单进行排序。💨

另外排队机中最为核心的概念就是定序:定序目前存在三个规则:1. 时间优先:按照下单时间的优先级进行排序。2. 价格优先:如果两笔申报的时间相同,那么价格之间存在优势的一方排在前面,意思就是出价高的一方的委托申报会排在价格低的一方之前。3. 量优先:如果上述说的两种优先级都存在相同的情况下,那么谁的委托量大,谁就排在前面。这三条概念设定的原则就是为了能让更多的交易撮合成交,使整个市场的成交量达到最大。💨

此处还涉及到两个微服务概念:1. 高可用:排队机的服务不能存在宕机的现象,不能因为其中一个排队机节点出现故障导致整个排队机失效。2. 一致性:所有的这些节点保存的数据必须是一摸一样,如果排队机之后的撮合引擎宕机,那么需要重新去排队机中拉取数据,但是从哪个节点拉取并不确定,所以必须要保证这些排队机中的数据存在高度的一致性。(这里面还涉及到一致性算法和共识算法的特性这里也不在赘述)💨

2.4 撮合引擎(核心)🔨

交易系统中最为核心的部分,用于接收订单并根据业务逻辑是实现订单,撮合同时生成交易记录,随后给予用户交易反馈结果。撮合引擎所需要具备的功能点:1. 接收委托广播并进行校验,如果在接收过程中数据存在丢失,那么需要向排队机要回该数据。2. 委托撮合 3. 对外发布委托 / 行情广播。💨

2.6 行情引擎🔨

⾏情引擎:接收撮合交易引擎的处理结果,将撮合的交易数据持久化到数据库,同时定时⽣成多时间周期的K线数据(开盘价、收盘价、交易量、最⾼价、最低价)。💨

三. 项目介绍以及技术选型

2.1 项目介绍📡

本项目的核心架构参考 coinExchange,和慕课网(Spring Cloud+Vertx+Disruptor 撮合交易系统实战)。💨

该项目核心功能说明:

· 登录 / 注册 / 权限验证
· 基础查询(用户的资金持仓查询)
· 股票的买入卖出
· 委托成交查询(当日委托,当日成交,历史委托,历史成交)
· 银行业务(银行转账,银行查询)
· K 线展示

整套流程可形成完整的闭环流程

2.2 各个微服务的技术选型📡

1.柜台📡

使用 Nacos 作为服务注册中心,Ribbon 作为负载均衡配置,sentinel 进行服务降级和限流。这些都是 cloud 下的核心组件,应该不用特别细说了,关于柜台的核心功能上述已经写的很多了。💨

3.排队机📡

使用 SOFAJRaft-RheaKV 进行实现, SOFAJRaft 是基于百度的 braft 移植而来,百度的是 C++ 的版本,而 SOFAJRaft 是基于 Raft 一致性算法的生产级高性能 Java 实现。排队机本身还存在存储功能并且不能宕机,所以还需要一个 Key-Value 存储的分布式数据库来保证这个功能,这里涉及到使用 KV-Stroe 的知识以及为什么是 KV-Store。💨

第二个是订单收集的功能,就是排队机从网关将订单收集过来,这里涉及到网关和柜台的交互,网关作为 RPC 服务的提供者,排队机作为 RPC 服务的消费者。💨

第三就是定序,排队机在收集到所有这些订单后进行排序,这个逻辑上述有提到。最后就是将排序后的订单数据流广播给撮合引擎进行撮合。💨

4.撮合引擎📡

这里我还在优化,现在使用的解决方案是用慕课网上的那个案例: Disruptor,但是我还在研究一种更好的方法这里先不说明。💨

Disruptor是英国外汇交易公司LMAX开发的一个高性能队列,研发的初衷是解决内存队列的延迟问题。与Kafka、RabbitMQ用于服务间的消息队列不同,disruptor一般用于线程间消息的传递。基于Disruptor开发的系统单线程能支撑每秒600万订单。💨

disruptor是用于一个JVM中多个线程之间的消息队列,作用与ArrayBlockingQueue有相似之处,但是disruptor从功能、性能都远好于ArrayBlockingQueue,当多个线程之间传递大量数据或对性能要求较高时,可以考虑使用disruptor作为ArrayBlockingQueue的替代者。💨
官方也对disruptor和ArrayBlockingQueue的性能在不同的应用场景下做了对比,目测性能只有有5~10倍左右的提升。

撮合核心和排队机之间的交互目前写了两套实现方案,这个要取决于数据吞吐量的大小,所以我也在考虑中因为如果要想体现出量化交易的效果,需要很高的数据量,而且对于数据库的一些操作要求很高,目前测试所用的数据是我从某证券公司爬取的,所以使用的是以 Kafka 作为撮合订单信息的传输,但这远远不够,如果真正想要进行使用我还有一个备选方案是通过 UDP 协议进行通信。💨

5. 行情引擎以及 K 线发布📡

整套项目的前端主要使用的还是 Vue,这里 K 线所使用的工具来源于第三方,本来有考虑过使用 TradingView 进行实现的,但是要收费而且网上对于这个的相关资料也是少的可怜,并且它传递数据的方式说实话看了三天没看太懂,具体还是通过前端进行传递的由于我本身是做后端的,对于前端一些传输数据的方法和封装看的很不习惯所以还是拿熟练的来写。💨

这里可以展示一下效果:

四. 写在最后🎃

这个项目应该是我目前能力的巅峰了,写这篇博客的时候脑子很乱,因为要复盘整个开发流程,后续可能会再进行更改,先凑合着看,里面涉及了目前微服务百分之 80 的主流中间件和框架,涉及的内容十分多,还需要对金融知识有一定了了解和储备,我在设计之初搜遍了内外网所有的资料,网上对有很多核心功能的解释和实现都是模棱两可,而且资料少的可怜,由于撮合系统是各大证券公司和交易所的核心业务,是不对外展示的,导致进度非常的缓慢。整个项目目前还是挺有含金量的,我会在完全体做完后开源发布并一直维护。感谢行内的朋友和开源社区给我提供帮助的大佬,由衷的希望国内的开发社区能够越来越好。最后的最后我要说一句,这个项目花了我很多时间和精力,很多功能和业务逻辑上和上面我提到的两个项目是没法比的,你要是觉得不行你可以去试试拿那两个练手,没有必要阴阳怪气的来嘲讽我,或者写一个比我还好的,代码胜于雄辩!

参考链接:🔍
Crypto-Exchange gitee 链接:https://toscode.gitee.com/angery/CoinExchange#https://gitee.com/cexchange/CoinExchange/attach_files

coinExchange(尚学堂)b 站链接:https://www.bilibili.com/video/BV1gZ4y1G7Kf/?spm_id_from=333.337.search-card.all.click&vd_source=63fa5182fb3fc864ef5946e373f34c7e

Spring Cloud+Vertx+Disruptor 撮合交易系统实战(慕课网):https://coding.imooc.com/class/437.html

文档猫数字货币交易所开发笔记:https://wendang.xuehi.cn/doc/08ac9611f211f18583d049649b6648d7c1c7086a.html

github 链接:
Crypto-Exchange github 链接:https://github.com/exchange-server/CoinExchange

coinExchange(尚学堂)github 链接:https://github.com/binbin0915/Java_CoinExchange(这个去搜一下到处都是,我这里是随便找的)


文章作者: 清风摇翠
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 清风摇翠 !
评论
  目录