(转)恒生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架构几大特性

●组件化

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

●松耦合

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

●可扩展性

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

●开放接口

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

●内存极速交易

数据走内存(很快哟),先报单,再落库。

展开阅读全文

Git 实用技巧

11-24
这几年越来越多的开发团队使用了Git,掌握Git的使用已经越来越重要,已经是一个开发者必备的一项技能;但很多人在刚开始学习Git的时候会遇到很多疑问,比如之前使用过SVN的开发者想不通Git提交代码为什么需要先commit然后再去push,而不是一条命令一次性搞定; 更多的开发者对Git已经入门,不过在遇到一些代码冲突、需要恢复Git代码时候就不知所措,这个时候哪些对 Git掌握得比较好的少数人,就像团队中的神一样,在队友遇到 Git 相关的问题的时候用各种流利的操作来帮助队友于水火。 我去年刚加入新团队,发现一些同事对Git的常规操作没太大问题,但对Git的理解还是比较生疏,比如说分支和分支之间的关联关系、合并代码时候的冲突解决、提交代码前未拉取新代码导致冲突问题的处理等,我在协助处理这些问题的时候也记录各种问题的解决办法,希望整理后通过教程帮助到更多对Git操作进阶的开发者。 本期教程学习方法分为“掌握基础——稳步进阶——熟悉协作”三个层次。从掌握基础的 Git的推送和拉取开始,以案例进行演示,分析每一个步骤的操作方式和原理,从理解Git 工具的操作到学会代码存储结构、演示不同场景下Git遇到问题的不同处理方案。循序渐进让同学们掌握Git工具在团队协作中的整体协作流程。 在教程中会通过大量案例进行分析,案例会模拟在工作中遇到的问题,从最基础的代码提交和拉取、代码冲突解决、代码仓库的数据维护、Git服务端搭建等。为了让同学们容易理解,对Git简单易懂,文章中详细记录了详细的操作步骤,提供大量演示截图和解析。在教程的最后部分,会从提升团队整体效率的角度对Git工具进行讲解,包括规范操作、Gitlab的搭建、钩子事件的应用等。 为了让同学们可以利用碎片化时间来灵活学习,在教程文章中大程度降低了上下文的依赖,让大家可以在工作之余进行学习与实战,并同时掌握里面涉及的Git不常见操作的相关知识,理解Git工具在工作遇到的问题解决思路和方法,相信一定会对大家的前端技能进阶大有帮助。
©️2020 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值