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

起因

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

过程

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

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

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

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

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

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

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

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

开始改造

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

随后我开始改造服务器端代码，服务器端用的是NetCore写的，毕竟玩了那么多年，用起来也算得心应手吧，改造也很快完成，但碰到一个问题。

之前用的是Jwt验证接口，之前客户端请求都必须带一个登陆后的Token的，但我这次肯定不能登录啊，这怎么搞呢？

起初我还在想要不改下验证逻辑，遇到特殊Header的时候能够验证正常，但看了下代码，改造方式有点困难，除了验证token，他还会给一个Claim，这个又是之前代码里的关键，这可怎么搞呢？

随后萌发了一个邪恶的念头，当客户端与我服务器链接后，我先验证客户端，然后直接给他一个token，这样不就好了吗？

马不停蹄的尝试了下，可以，稍微改了下验证的流程，基本上就能实现了。

下面是效果：

后续问题

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

• 回测数据过多，需要排队机制，考虑用ConcurrentQueue
• 回测服务器的统一管理
• 回测服务器的自动更新