对于开发恒生交易API的Python封装有啥建议？

Posted 2023-02-21

因为一些不可抗力的原因，前一段时间开发的LTS API的Python封装暂时用不上，目前证券API这边剩下相对靠谱的选择只剩恒生了，同样是准备基于C++版本的API开发Python封装。现在的一个问题是，恒生的API风格上和国内大多数其他API非常不同，他的请求操作和数据推送需要用户自己发送和接收数据包并进行解析（类CTP的API会直接帮你处理好，用户只需传入结构体指针）。题主面临两个选择：直接对恒生API进行封装，提供数据包操作的Python接口。对恒生API进行类CTP封装后，再封装为Python接口，好处是可以和之前类CTP的API通用，缺点可能会损失部分恒生API独有的功能。这个API最后同样会整合到题主的vn.py框架中，这样对于很多大型券商（中信、海通、招商等等），用户也会多一个可以用Python进行量化开发的选择。恒生的接口应用应该是最普遍的，但是用恒生接口一般都需要券商给认证文件才能使用，大多数人应该都参与不了这个项目。可以参考quantbox和wind，先在框架上统一。最好先把ctp期货和证券做出来，毕竟兴业也在用，lts也是类ctp的。恒生的接口应用应该是最普遍的，但是用恒生接口一般都需要券商给认证文件才能使用，大多数人应该都参与不了这个项目。能做到封装后python API和现有vn.py已存在的lts和ctp的接口兼容，那就极好

参考技术A

底层接口：负责对接行情和交易API，将数据推送到系统核心中，以及发送指令（下单、数据请求等）中层引擎：用于整合程序中的各个组件（包括底层接口、数据库接口等等）到一个对象中，便于顶层UI调用顶层GUI：用于显示数据和调用中层引擎暴露的主动函数，实现各项具体功能。vn.py优势：语言易用：Java语言比Python啰嗦，架构简洁：Java的编程理念（纯面向对象，大量使用框架等）更是比Python的编程理念繁琐，事件驱动引擎：AlgoTrader使用的Esper引擎尽管功能强大，使用起来也过于复杂，对于国内绝大部分的量化业务而言完全用不着，本地化：vn.py完全为中国市场设计，在功能设计上更符合国人的使用习惯，而AlgoTrader则是针对欧美市场设计。

参考技术B

直接原因就是C++的API没法直接在Python里用，不过这个回答有点太简单，这里我们稍微做一些拓展解释：C++ API中很多函数的调用参数是ApiStruct.h（参见上一篇）中定义的结构体，而在Python中我们既无法直接创建这些结构体（主动函数），也无法提取结构体中包含的数据（回调函数）。Python虚拟机是基于C语言实现的，所有的Python对象，哪怕只是一个整数或者字符串，在C的环境中都是一个PyObject对象（好吧，我知道C里没有对象，只有结构体，但估计90%的读者都不在乎这个区别）。用户如果在Python中直接传递一个参数到C++环境里，C++是无法识别的（Python：买入1手股指, C++：你要买入多少？）。Python只能加载封装为PyObject对象的模块，因此原生C++的API在Python中连加载都加载不了。原生的API中每个功能分为了两个类：分别是包含回调函数的Spi类和主动函数的Api类，这种设计能让用户更好的分清不同的功能。但是从面向对象的角度，把两个类封装到一起更为方便，实际使用中绝大部分C++的用户也会将接口整合到一个类里面（可以参见网上很多CTP开发的示例代码），因此Python的API中，我们也会将Spi和Api两个类的功能封装到一个类中。原生的API中回调函数被触发后必须快速返回，否则会导致其他数据的推送被阻塞，阻塞时间长了还有可能导致API发生崩溃，因此回调函数中不适合包含耗时较长的计算逻辑。例如某个TICK行情推送后，如果用户在回调函数中写了一些比较复杂的计算（循环计算等等），耗时超过3秒（这个数字只是笔者的一个经验），则在这个3秒中，其他的行情推送用户是收不到的（被阻塞了），且很可能3秒后会出现API崩溃（程序死掉）。这里的解决方案是使用生产者-消费者模型，在API中包含一个缓冲队列，当回调函数收到新的数据信息时只是简单存入缓冲队列中并立即返回，而数据信息的处理和向Python中的推送则由另一个工作线程来执行。API的函数中使用了大量的结构体用于数据传送，这在C++而言是非常自然的设计，但是对Python封装会造成不小的麻烦，所有的结构体都要封装成对应的Python类，工作量太大也非常容易出错。这点我们可以利用Python相对于C++更为高级的数据结构来解决，Python中的dict字典本质是一个哈希表，但是同一个字典内键和值的类型允许不同，这个特性使得字典可以非常方便的用来代替C++的结构体。