【核心技术】功夫量化的过去，现在和未来

董可人/CEO

我们在 2017 年底发布了第一版功夫量化开源版，至今已经过去两年半，从最初的基于 Docker 技术打包的命令行版本 1.0 ，到最新的跨平台绿色安装的 2.2，我们在产品形态上取得了不错的变化和进展；在功能上，我们至今还没能支持回测、策略调试、算法等一些重量级的特性，这给接下来的发展留下了很多有挑战的任务和想象空间。曲至中篇，虽然前路道阻且长，也到了一个需要总结的阶段，就用这篇文章做个记录。
以开源项目为核心运作一个商业模式，是一个看上去很美，做起来很难的事情。在创立初期，我们的这个想法其实就被很多行业前辈、投资人所质疑。确实，要想打造一个有影响力的开源生态，门槛远远比一眼看上去的要高，不仅仅是产品本身必须具备较高的品质，还需要一系列推广宣传上的助力，才有可能被大众接受。很多时候，产品本身的技术含量也并不是成功的保障，有很多著名的开源项目其实从技术角度来说并不能算是同类中的最佳，但诸多因素综合下来，却能最终胜出。关于这个问题，我至今仍然觉得很难从语言上解释一个方案的合理性，无论怎样论证总有疑点可以挑战，最终只有事实证明法一条路可走。就功夫项目本身来说，我们在一开始就明确的事情有：
 
然而不论是当时还是事后来看，这些都并不能绝对保证项目的顺利推行。我们无法回答例如说其他竞争者以相似水平的开发团队，迅速复制我们有所谓技术优势的架构，是否就能在短时间内完成竞品，以及我们如何在此种情况下保持竞争力。实际上在第一年（2018）我们就走了很多弯路。得益于上述优势，我们在发布初期即获得一些付费客户，但随后我自己花了大量精力参与线下推广但收效甚微，其他团队成员则忙于应付付费客户，以至于有很长一段时间我们在开源项目上缺乏维护，甚至有人到我们的 QQ 群里说我们侮辱了“开源”两个字。如果说这是因为精力分散所导致，但实际上我们当时集中了内部研发力量的商业版本在产品层面也并未取得如意的进展。
事后回顾，我得到的经验是产品的优势必须在理念和实现细节两方面都得到体现。仅仅有一个明确的方向、优秀的架构和一批有实力的成员并不必然能保证项目达到理想中的程度。以功夫为例，基于共享内存 mmap 开发的时序内存数据库可说是当时市面上公开的产品中有绝对优势的架构设计，其难点在于特别针对金融交易这一专业场景量身定做，这个理念本身即具备极高的方向性价值，而像是“跨平台”、”绿色安装“等这些大路货的特色看起来就没那么有吸引力。然而在实际开发中，很大的障碍却是来自这些大路货的东西，并不是靠着会写代码 + 996 莽上去平 A 就能实现的。例如我们曾经遇到这样一些问题：
 
  • 跨平台过程里对于诸如文件I/O等操作的处理需要依赖诸如 Boost 等第三方库，极大的增加代码编译难度；底层代码抽象不足时，会导致有大量的路径宏，维护扩展性非常差；
  • 为支持 Python 需要用户机上具备特定 Python 运行环境，我们也曾经做过把 Python 安装包硬塞进自家安装程序这样的操作，导致安装部署流程十分难用；
  • 前后端交互采用 Web 架构，开发难度非常大不说，导致还得自带像是 docker 或是 nginx 这样的东西来支持前端服务
这样一大套问题下来，一个看起来很不错的研发团队实际上很容易就会陷入各种技术陷阱中无法自拔。因为这些问题本身都相当有迷惑性，例如说仔细设置 docker/nginx 本身也是非常有技术含量的任务，我们无法评价擅长此类技术和用其他方式解决问题的人在技术水平上到底孰优孰劣（甚至很可能前者会看上去会具备更强的技术能力和更多的开发经验），只能说，有一些无法用语言评说的直觉上的东西，似乎并不是那么容易传递。《人月神话》的魔咒似乎永远在飘荡，最终只能采取把最精锐的力量投入到这些细节的考量和实现，用时间的代价来换取质量的保证。从结果看，虽然代价高昂，但的确有效：时至今日，我认为功夫真正的优势正是积累了大量诸如此类的细节处理，使得我们有足够的信心即便在开源模式下，技术壁垒也能够长期保持；但这又终归只是一个主观判断，很难以一个简单的描述论证其必然性。
除却这些大路货功能的技术挑战，像是“基于共享内存 mmap 的时序数据库”这样的设计理念，实际上也并没有看上去那样容易理解。从初版发布以来，我在包括我们自己团队成员以及开源用户的反馈上来看，大多数人并不能完全理解此方案的真正价值，通常情况下人们会认为这仅仅是为了实现超低延迟而做的设计，而这恰恰是买椟还珠式的理解。如果仅仅是为了低延迟，一开始就并没有必要一定使用 mmap ，简单的 ring buffer 实际上就完全可以胜任速度方面的要求；而如果着眼点仅仅在于低延迟，就更无法论证一套软件系统和例如像是 FPGA 化的硬件系统相比的价值所在。实际上，像是 mmap 这样一种支持 zero copy 持久化的方案，在交易场景下更大的意义在于可以极大的简化开发难度，像是交易系统这样内部状态机极其复杂又对鲁棒性要求极高的应用，如果系统仅仅能在运行时调试，开发和运维难度都是难以想象的。如果实时交易时发生故障，缺乏复现和诊断手段，付出的代价是难以估计的（要知道为了性能考虑，实时系统几乎一定会缺少细节日志）。基于 mmap 的架构，根本上解决的是这样一个问题：以对性能影响最小的代价，保存尽可能多的运行时状态，这里真正的魔术并不在于低延迟，而是那个 zero copy 的时空转换。
过去两年，经常会有朋友对于我们还在坚持做这样一款产品表示惊奇或是质疑，其中也不乏业内专业的同行们。常见的问题有：
 
  • 头部私募机构有自研的 IT 系统，不会采购第三方产品
  • FPGA 大法好，软件没前途
  • 用户数量不够多，无法贴近真实用户需求
然而基于上述经验，我认为这些问题并不是我们真正的挑战。正是因为这个产品它真正的价值并不在于某一两个单一的技术点（例如低延迟）或是特色功能（例如多账户多策略），也并不是一个像哥德巴赫猜想那样的超级技术难题（对科技类创业项目，风投机构最喜欢这样的故事：几个技术宅在自家车库里鼓捣出来一个划时代的技术产品，但功夫并不是这种类型），它的生命力实际上是隐藏在重重迷雾之下的。到今天为止，我们不是那种需要对自己的技术细节严格保密的研发型团队，也并不是那种需要花大量时间和客户一起讨论需求的承包式团队，是因为这个产品它的内核是关于那些我们早已清楚存在的、但从未被人真正关注和解决的问题。这些问题的难点也不在那种破解谜题式的技术细节或是对用户的细心访谈，而是在概念理解上，一旦理解有偏差，不论投入多少研发资源，都一定会跑偏，不可能做出类似的产品。
目前为止，功夫在用户数量的绝对值上还算不上取得什么成绩，看起来它仍然是一个相当小众的冷门项目；我认为这主要是由于我们一直在花费大量的精力来构建可靠的底层基础，从功能完成度来说，像是回测、算法等功能的欠缺，都会非常阻碍普通用户上手使用。然而这确实是一个必经阶段，如果基本的问题不能在现在妥善解决，所有上层的功能最终都是空中楼阁。我们接下来的开发节奏仍然不会太快，预计在今年内能够完成的功能如下：
 
  • 完整的数据管理：对于实时交易数据和回测用数据都在前端上提供直观的查看管理功能
  • 基于历史数据的回测：在数据管理的基础上，提供一键运行策略回测的功能，在无需修改代码的基础上支持回测实盘策略
  • 基本的风控模块：支持诸如挂撤单比、下单流控等常规风控指标
一个产品要最终赢得用户的认可，必须足够“好用”。那些例如说“专业机构不会使用第三方产品“的疑问，恰恰是因为市面上没有”好用“的第三方产品。功夫仍在破局的路上，行至中途，产品尚未进化成完全体，就绝不能说此路不通。因此，尽管有些慢，但前进不会停止，感谢大家支持。