系列文章重点介绍了由一个人以最小的预算和最短的时间创建一个反应系统的尝试。
实验目的：
- 对主题领域有更深入的了解并提高了技术专长
- 识别在开发交易系统中使用功能语言和开源项目的优缺点
本文介绍了项目的动机部分和任务的分解。
我计划在2019年春季开始实验，但是情况改变了截止日期。 因此，对于正在等待有关此主题的文章的少数订阅者，我表示歉意。
我怎么过这样的生活？
当我意识到自己对工作项目的常规感到厌倦时，我想做一些不寻常的事情。 我考虑了各种主题和方向，其实施过程对我来说是一个挑战。 制定了该项目的主要要求：
- 我感兴趣的知识领域；
- 应用程序的分布式和高度可访问性；
- 数据密集型应用程序具有的高信息容量和大量存储数据；
- 充分利用开源项目。
由于已经有一些开发对象数据仓库的经验，因此提出了一个主题，即使用冗余编码和快速哈希函数编写与s3兼容的存储的新实现的想法。 但是我想要一些更有趣的东西。 从开发人员的角度来看，金融系统对它们在近实时模式下的工作，大量的更新和存储的数据量感到好奇。 因此，我决定实施该交换系统。
关于交流
从广义上讲，交易所（来自拉特布尔萨-钱包）是买卖双方进行交易的市场。 根据什么是交易资产（工具），确定交易所的详细信息：
从历史上看，交易所确实是买卖双方在约定的时间聚集的买卖双方的地方。
交换的主要功能包括：
- 交易所交易流程的组织：
- 根据适用法律定义贸易规则
- 设定产品标准
- 材料和人员配置
- 信息活动。 提供有关工具价格，市场和公司的信息；
- 制定示范合同；
- 争端的解决（仲裁）；
- 为执行交易提供一定的保证。
现代交易所组织有序的交易大厅，可以根据特定规则运作，并集中供需。 交易所的经济性也很明显，交易所上的交易越多，交易所对所提供服务的回报就越高。
因此，该解决方案的一般功能是可以理解的，现在有必要限制工作量，以便在合理的时间内满足该想法的实施要求。
最有价值球员
由于有限的资源，原型的功能有限。 但是重要的和根本的事情需要得到充分执行。
问题分解与架构选择
在技术方面，交换是一个排队系统，在该系统中，参与者生成呼叫流-订单，并且该系统根据先前已知的规则对其执行操作。
服务订单应在最短的时间内完成。 交换必须容错并且高度可访问。
我们将项目分为服务和公共部分。 服务部分将允许您管理平台的组件和交易所的交易过程。 公共部分包括客户交互接口：Web API，Trading API，通知子系统。 这两部分都将基于分布式应用程序平台，负责整个系统的可伸缩性和可靠性。
由于我们受到预算的限制，因此我们将仅使用经过验证的开源解决方案来组织数据存储。 对于较热的系统数据，适用于Tarantool；对于较冷的PostgreSQL，则适用。
我们将描述系统的计划组成（图片可点击）：
人们会感到架构和设计与常规系统没有什么不同。 挑战在哪里？ 要回答这个问题，请考虑为货币兑换创建订单和完成交易的过程。
订单创建
- 检查授权
- 确保用户当前有足够的资金来创建订单。
- 创建订单
- 通知用户成功创建或错误
成交交易
- 查找配对订单
- 检查各方资产负债表上的资金是否充足以完成交易
- 固定交易：账户之间转移+交易佣金到交易佣金账户的转移。
- 保存已执行订单的历史记录。
- 更新信息数据：原始交易数据和图表的汇总数据。
- 通知所有感兴趣的交易方。
当我们从运行在同一台机器上的整体式设备迁移到部署在集群上的分布式容错系统时，困难就开始了。 我将每个市场的最低系统性能定为每秒5-7k笔已完成交易。 这对体系结构和数据使用施加了其他限制。
遵循KISS原则，每个应用程序应仅执行处理在其中实现的实体所需的那些功能：市场，帐户，授权等。
VTrade建立在水平缩放的原则上。 每个应用程序可以复数形式运行。 这使您可以实现容错能力和所需的性能水平。
技术栈
为了不增加熵，我们限制使用的语言和技术。
对于服务器，此集合将包括：
- Erlang 我认为，这是构建基础架构事物的理想语言。
- 铁锈。 非常适合系统问题和优化问题。
- PostgreSQL的 作为长期数据存储的主要基础
- Tarantool。 作为热数据存储（仅适用于MVP的时间）
- Clickhouse。 用于分析日志和深度分析功能。
- 的Linux 该系统必须支持现代发行版。
客户端软件是通过使用Vuex的Vue框架实现的。
由于项目最初涉及大量组件，为确保最终解决方案的质量达到适当水平，我们将编写大量基于属性的测试和集成测试。
关于计划
我计划在不久的将来分析该理论的基础知识，并在以下领域进行实践研究：
- 认股权证。 类型，处理功能。 存储贸易信息的方面。
- 权证书。 视觉表示市场。
- 出价历史。 印刷品，图形，个人历史记录。
正如他们所说的...如果有兴趣，例如订阅）