交易系统开发总结
最近工作二年主要是从事交易系统开, 最近抽了些时间把大致的系统开发总结下,权当回顾.
这段时间里一共经历了3个交易系统, 第一个是类似电商交易系统, 另外2个是最近比较火的Blockchain行业, X交易系统.
其中一个交易系统崛起的过程非常快, 主要归结于: 布局策略以及时机把握得很准, 运营的创新点子很多, 市场商务宣传的精准, 系统研发干劲充足, 有半年的时间几乎是6*14的工作状态, 平均一个月通宵就有2,3次, 拼凌晨1到2点也是常有的事, 第二天依然9点半到公司. 在这里全面接触并见证了Blockchain交易所从起步到腾飞的全过程.
因政策的原因, 具体的名称就不方便透露,都以交易系统进行统称. 2018年中因各方面原因, 稍有名气的交易系统都一一出海,往新加坡,香港,英属维尔京群岛等迁移, 同时也因寒冬的到来, 大家都需要保存资金实力等待下一次机会.
个人认为交易系统核心几个特征:
安全: 很重要,很重要, 不管是小交易所还是大交易所. 有可能就是一次损失,就回到解放前了.
稳定: 交易是7*24进行的, 系统计算,运行,升级部署都要稳定, 否则非常影响用户的体验, 用户流失也很快.
准确: 属于金融行业的系统, 用户的每一笔交易,资金流水,操作都要有记录,历史可查并核对. 用户量巨大的交易系统,其交易历史通常保留时间很短(因其数据量大, 对系统性能, 存储, 维护成本影响很大).
高效: 行情突发的时间段内,用户非常活跃. 如果系统的并发处理不高, 则无法承载大量用户的交易请求,系统可能处于半瘫痪状态.
之后的几篇文章都用来阐述交易系统的大致实现, 从系统,架构,设计等相关点进行记录:
交易系统的主要框架如下图所示:
整个交易系统是以spring-cloud的微服务系统框架进行搭建的,使用到的组件有:
Eureka: 用于注册服务发现.
Zuul: 路由网关.
Feign: 服务消费.
Ribbon:客服端负载均衡.
Hystrix: 断路器, 防止服务故障的“雪崩”效应.
Zipkin: 服务的调用监控.
Turbine, Dashboard:用于收集和统计监控服务节点的整体压力和健康情况等.
整个系统中还包含其它组件或系统还有:
mysql(Mariadb), mongodb, redis集群, acitvemq, memached.
交易系统的是前后端分离, 后端系统核心服务主要有:
用户服务, 资金服务, 订单交易服务, 撮合服务, 行情服务. 其它的还有通知服务,资讯服务,管理后台服务.
当然还有一个重要的wallet系统,其相对比较独立.
接下来的篇章用于记录这些核心服务系统是如何实现的(鉴于保密协议,有些只能大致公开描述):
交易系统用户服务子系统
订单交易处理系统