花了2天时间,把量化平台的回测从本地放到了在线

起因

去年不是撸了个量化平台嘛,自己用起来蛮舒服的,但很多用户反应,家里没有电脑,无法做到回测,起初呢也不在意,最近正好有时间,花了2天时间,让它支持了在线回测。

过程

其实之前就有想法了,本来想重新用python撸一个的,但改造到一半,突然想到了资源问题,因为服务器价格昂贵,如果放到云端,我这个免费平台怎么可能受得了呢?突然有个想法,为什么不利用废弃电脑呢?毕竟回测客户端需要的性能并非很高,哪怕我自己多新建几个虚拟机也可,想到这里我就策划起来。

这是当前的回测流程模型:

这是最初想做的在线回测模型:

这种模型需要花费大量的精力处理并发,排队,最主要还是金钱

最后我决定使用下面的模型:

使用上面的好处有哪些呢?

  1. 我可以根据需求增加或者减少回测客户端
  2. 成本低廉,完全可以使用自己家里的废弃电脑,或者市面上的挂机宝等等
  3. 改造难度小,我不需要重新撸代码了

基于上面的考虑,我开始倒腾了起来。

开始改造

首先我需要改造Python端,因为Python也属于面向对象的语言,所以改造起来还算方便,我继承了原有的Runner后,重写了2个方法,一个是绑定,一个是回测,其他的都不需要调整。

随后我开始改造服务器端代码,服务器端用的是NetCore写的,毕竟玩了那么多年,用起来也算得心应手吧,改造也很快完成,但碰到一个问题。
之前用的是Jwt验证接口,之前客户端请求都必须带一个登陆后的Token的,但我这次肯定不能登录啊,这怎么搞呢?
起初我还在想要不改下验证逻辑,遇到特殊Header的时候能够验证正常,但看了下代码,改造方式有点困难,除了验证token,他还会给一个Claim,这个又是之前代码里的关键,这可怎么搞呢?

随后萌发了一个邪恶的念头,当客户端与我服务器链接后,我先验证客户端,然后直接给他一个token,这样不就好了吗?
马不停蹄的尝试了下,可以,稍微改了下验证的流程,基本上就能实现了。
下面是效果:

后续问题

基本上目前解决了大部分问题,接下来还需要解决一些细节:

  • 回测数据过多,需要排队机制,考虑用ConcurrentQueue
  • 回测服务器的统一管理
  • 回测服务器的自动更新
posted @ 2022-07-28 11:28  James.Ying  阅读(271)  评论(0编辑  收藏  举报