恒生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 我司目前面临的问题
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架构几大特性
- 组件化
采用微服务技术架构，基于服务和组件，按最小业务单元划分，可根据用户需求对组件进行组装。 - 松耦合
业务层微服务架构松耦合。 - 可扩展性
采用小核心、大外延的设计思想，降低模块间耦合，具有高度的可扩展性和灵活性，适应未来的业务发展变化。 - 开放接口
通过接口交互，只要保证接口不变，核心系统再怎么修改和演进也不会对外围功能产生影响，实现投资系统与外围功能的松耦合。 - 内存极速交易
- 数据走内存（很快哟），先报单，再落库。