(转)恒生O32系统的前世今生

恒生O32系统的前世今生
2020-06-29信息技术部

恒生O32系统的发展历程

OH~~O32啊~我们天天使用的O32系统怎么来的？经历了哪些发展历程勒？您了解吗？

O32系统即基金投资管理系统，其实从名字不难看出最开始是为基金公司开发的系统，到后来逐步涉及到券商、券商资管、保险、信托、期货，所以说O32系统的发展历程几乎伴随着整个基金行业的发展。

首先为什么叫O32呢？其实主要是以底层数据库使用什么作为命名依据的，在2003年之前，由于使用的是SqlServer数据库，当时还叫做S1.0、S2.0；2003年3月恒生推出O3系统，开始引入Oracle数据库（系统所有的数据都存在里面），在S2.0系统基础上升级，所以改叫O3（"O"取用"Oracle"首字母，3代表升级了，不再是之前的S2.0了）；2007年恒生将O3系统多个业务模块重新开发升级，推出O3升级版O32系统，意思是我比之前的O3要强很多了。

这十几年中，恒生从O32衍生出很多系统，下面这些系统就和O32有着千丝万缕的关系，足见O32系统的庞大、复杂。

顺应行业发展的O45系统

前几年大家使用O32系统体验还是不错滴，但是随着业务量的不断提升，大家明显感受到现在O32系统在交易速度方面存在很大的性能瓶颈，这主要原因还是十几年前的系统架构已经无法支撑现在的业务量了，所以2015年起恒生考虑通过内存化交易从而提高交易速度，向市场推出了O4系统(也叫UFT, Ultra Fast Trade，极速交易)。但O4系统(O32版本的极速交易，在O32系统基础上增加的子系统)的同业使用率并不高，我司也没有使用该子系统，一是因为O32涉及业务范围太广，极速交易子系统无法快速满足所有业务场景；二也是因为恒生后续主要想向市场直接推广O45系统。所以今天主要为大家介绍O45系统：

No.1

行业为什么需要O45

No.2

我司目前面临的问题

01

下单速度慢

比如在上午10点或下午银行间交易集中的时候基金经理在下达指令时会等待数秒才能下达成功，这是由于这个时段同时下单的基金经理或交易员很多，造成了相对较高的并发，且系统内需要计算的风控条例较多，十几年前的架构对于高并发、计算量大的场景只能表示无奈。

02

接口开放性不高

对于O32而言，外围与核心系统通过数据表进行交互，比如我们现在场外系统和O32的对接主要就是通过抽取后台数据表数据进行交互，导致的结果就是核心系统与外围功能深度耦合在一起。如果恒生O32的表结构变化了，场外系统也需要同步改造；O32系统处理了某笔业务，需要等到场外再次通过调度任务抽数回去，才能知道这笔业务已经处理了，实时性很低。

03

O32内部技术架构深度耦合

系统牵一发而动全身：我们经常向恒生提交需求，他们总说需要评估，这可是真评估，而且是需要时间的，越涉及基础底层的东西，越难评估，一个修改就要涉及多个业务功能，需要多个开发组进行评估，如果评估不到位，就会产生缺陷引发生产交易事故，这么一个庞大的系统对于任何一个改动都需要慎之又慎，所以无法快速响应需求；

04

投资品种不断增加

比如QD\QF等业务发展；

No.3

系统架构

以交易系统O45为核心的基金公司涉及主要系统总览：

O45是统一主系统 + 子系统模式，各个子系统单独部署、单独升级，松耦合，比如只是改造创业板，那么只需要升级权益子系统即可，进行ETF相关改造，也不会涉及到固收子系统什么事。总体来说，把系统分为多个子系统，改哪儿就升级哪套子系统，只针对该子系统进行测试验证，无需脚摔伤了，把整个身体都检查一遍。

O32与O45的巅峰对决

O32系统目前采用基于插件的CRES架构，CRES理解为：C++、Reused（可复用）、Easy (易用)、 Solution（一个解决方案），主要靠各类插件支撑系统。

其中间件是C++语言开发、后台主应用服务大部分是C语言、前台程序是比较老的Delphi6开发，只能编译出32位程序，这就是为什么有时候恒生O32系统会弹出来带有out of memory关键字的报错，因为32位程序运行在我们在64位操作系统，最大寻址空间是2G，其中操作系统占用0.5G，我们的O32系统就只剩下了1.5G左右，超过1.5G就会报错，这个时候需要关闭O32客户端重启即可，所以若非必须，不建议同时打开很多菜单，因为每个菜单都会占用一定内存。

O45系统所采用的JRES3.0技术平台基于原生SpringBoot开发，是一个符合互联网分布式系统开发的JAVA开发技术平台，具备可复用（Resume）、可扩展（Extend）、高安全（Security）的特性，降低业务开发人员技术要求，提升开发效率以及系统稳定性。

其中间件是Java语言开发、后台主应用服务是Java和C++语言、前台不再单纯是之前CS架构了(即通过客户端登录)，增加了BS架构(即通过web浏览器的形式直接登录)，既可以通过客户端形式登陆，也可以通过浏览器登陆了。数据库也抛去了Oracle，引入了Mysql，准确说不能叫O45了，但是O32已经深入人心了（前面讲到之前的"O"就是指"Oracle"），所以也就延用这个名字。

以上这些变化主要是由于系统整体架构变化导致的，这也是整个互联网金融发展的趋势带来的变化，通过这些后台的改造，带给我们前端用户最直观的感受就是交易速度变快了，系统更加灵活、扩展性更强。如果说之前的O32是一头庞大的大象，有力而笨重，那么O45可以说是一只勇猛的狮子，强壮而灵活。

JRES3.0架构几大特性

●组件化

采用微服务技术架构，基于服务和组件，按最小业务单元划分，可根据用户需求对组件进行组装。

●松耦合

业务层微服务架构松耦合。

●可扩展性

采用小核心、大外延的设计思想，降低模块间耦合，具有高度的可扩展性和灵活性，适应未来的业务发展变化。

●开放接口

通过接口交互，只要保证接口不变，核心系统再怎么修改和演进也不会对外围功能产生影响，实现投资系统与外围功能的松耦合。

●内存极速交易

数据走内存（很快哟），先报单，再落库。