Flask框架开发实录

1.业务背景介绍

之前在做某量化投资交易平台, 主要业务就分为回测与模拟交易.
使用对象是基金公司或私募公募的基金经理.
具体产品的使用方式, 就是使用任意年份的交易数据, 尝试跑一些交易策略的回测, 觉得收益合适之后, 再放到模拟交易中进行模拟, 如果收益依旧不错的话, 可能会被基金经理采纳进真实投资组合中.
当然以上是本人对产品的使用的概述, 实际中基金经理可能有更多贴近实践的方式的.

2.技术栈介绍

项目是前后端分离的, 前端由前端团队开发, 采用React, 后端由我们来开发, 后端采用Flask, 并且只做业务逻辑和提供API接口, 对于权限和鉴权的功能, 有中台的云平台去做, 不需要后端做这部分内容.

另外,因为交易记录的存储, 很可能会在一个list中存多个dict这样的方式存储信息, 如果用传统的关系型数据, 后续还可能有数据结构的调整, 会很不方便操作, 所以采用了schemaless的MongoDB来存储所有系统中信息, 并做持久化. 对盘中常会更改的如持仓信息, 会在Redis中存储, 并定时向MongoDB进行同步. Redis只开启RDB持久化. 使用pymongo创建连接池, 封装API, 进行MongoDB的一些操作.

所以其实对于MVC的Web框架, 在这个项目中算是拆开了使用的, 这里更多包含MVC中C的部分, M的部分不像关系型数据那么强的schema关联了.

对于部署, 采用k8s中pods形式部署, Rancher做一些可视化管理.

对于人员, 后端3个开发, 2个人分工各条线的开发, 另一个是项目初期的开发者, 对整个系统的所有业务线有全面的理解, 前2个人的code review都需要通过第3人的认可, 才可以合并入分支.

测试1-2人, 因为会有不同线的功能并行进行测试, 所以可能同时对接多个测试人员.

产品经理1-2人, 同测试一致, 可能同时对接多个需求, 而需求来自多个产品经理.

前端1-2人, 一般来说, 此系统的开发不需要对接前端, 因为基本是在原有接口上新增功能, 只有输出依据, 之前的来即可, 除非有新需求需要开新接口时, 会有一些前后端对接的工作.

3.开发中做的好的与不好的

整个项目中的代码结构个人感觉不太好, 不过算是历史遗留问题比较严重, 测试用例陈旧, 导致很难改动之前代码的结构, 而不导致功能的改变.
多个交易品种之间耦合会很严重, 经常性出现, 修改一个品种的问题, 导致另一个品种出现问题, 也让排查错误变得非常耗时间, 可能很多时候, 会花上1个星期的时间只进行Bug的修复.

可以改进的地方: 当时这一套代码中, 会面对很多个性化或者定制化的项目的需求, 就是一个接口面对不同项目的调用, 返回的行为不太一致的. 所以, 导致每个接口中的业务十分错综复杂.

个人觉得, 如果可以拆出一个中间层.专门区分不同项目或产品的调用, 构建各自不同的返回信息, 而在当前项目中, 只返回所有可用信息的话, 可能可以更便捷的开发. 因为把系统中的数据处理, 和真正业务展示的信息给拆分开了. 所以其实还是MVC的设计模式没有贯彻好.