恒生 O32 到 O45：一次金融架构革命#
从 Oracle + Tuxedo + 三层架构，到服务化、分布式、云原生金融平台。
O32 到 O45，不只是一次产品升级，而是中国资管 IT 架构的一次代际跃迁。
一、O32 的时代：IOE 架构黄金时期#
1.1 2000 年代金融 IT 背景#
2000 年以后，中国基金、券商资管行业进入高速发展阶段。
行业核心需求：
- 基金交易
- 投资管理
- 清算核算
- 风险控制
- 组合管理
当时全球金融 IT 主流：
IBM Server
*
Oracle Database
*
BEA Tuxedo Middleware
*
EMC Storage也就是后来被称为：
IOE 架构时代
1.2 O32 的诞生背景#
恒生资管系统经历：
S1.0
↓
S2.0
↓
O3
↓
O32其中：
- S1/S2 使用 SQL Server
- O3 开始采用 Oracle
- O32 在 O3 基础上进行了全面升级
“O” 的含义：
Oracle 技术体系
二、O32 经典架构模型#
O32 典型架构：
用户终端
|
Client Application
|
Tuxedo Application Server
|
Business Module
|
Oracle DB
|
Storage System
这是典型金融三层架构：
表现层
↓
业务逻辑层
↓
数据访问层三、O32 架构优势#
3.1 稳定可靠#
O32 继承了传统金融架构特点：
- 强事务
- 强一致性
- 数据集中管理
Oracle 提供：
- ACID事务
- 数据锁
- 存储过程
- 高可靠数据库
3.2 中间件负责事务#
Tuxedo 在 O32 中承担：
- 请求管理
- 事务协调
- 服务调用
典型模式：
Client
|
Tuxedo
|
Service
|
Database这也是 BEA Tuxedo 长期成为金融核心系统标准的原因。
3.3 业务模型完整#
O32 覆盖：
- 投资交易
- 指令管理
- 组合管理
- 清算
- TA处理
- 风控
在 2007-2015 年：
O32 成为中国基金、券商资管领域事实标准。
四、O32 的架构瓶颈#
随着资管规模增长：
传统架构开始暴露问题。
4.1 数据库压力越来越大#
早期：
业务逻辑
↓
Oracle大量计算进入数据库。
例如：
- 组合计算
- 风控计算
- 清算处理
结果：
数据库成为瓶颈。
4.2 系统耦合严重#
O32 时代：
业务模块
*
数据库表
*
存储过程大量业务逻辑绑定数据库。
问题：
修改一个业务：
可能影响：
- 表结构
- 存储过程
- 清算逻辑
- 周边接口
4.3 外部系统集成困难#
早期接口：
系统A
↓
数据库表
↓
系统B典型：
- 通过中间表交换数据
- 批处理同步
无法满足：
- 实时风控
- 高频交易
- 多市场接入
五、CRES：O32 向现代架构过渡#
恒生开始升级底层中间件。
推出：
CRES#
(C++ Reused Extend Simple)
定位：
高性能通信与交易处理中间件。
架构变化：
O32：
Client
↓
Tuxedo
↓
Database升级：
Client
↓
CRES
↓
Business Service
↓
DatabaseCRES 负责：
- 通信
- 路由
- 服务管理
- 交易处理
- 数据访问
核心思想：
把更多业务能力从数据库迁移到中间件。
六、从 CRES 到 JRES：服务化时代开始#
随着互联网金融发展：
金融系统开始需要：
- API
- 服务化
- 微服务
- 云部署
恒生进一步演进：
CRES
↓
JRES
↓
Light-JRES技术方向：
从：
集中式交易系统走向：
分布式服务平台七、O45 的架构革命#
O45 最大变化：
不是功能增加。
而是：
架构思想完全变化。
7.1 从三层架构到服务化架构#
O32：
客户端
|
应用服务器
|
Oracle数据库O45：
Front End
|
API Gateway
|
Service Layer
|
---
Investment Service
Trading Service
Risk Service
Clearing Service
Data Service
--- |
Database
|
Distributed Storage
7.2 业务能力服务化#
O32：
一个大型应用：
O32
|
+---交易
|
+---清算
|
+---风控
|
+---组合O45：
拆分：
Trading Service
Risk Service
Portfolio Service
Settlement Service
Query Service优势：
- 独立扩展
- 独立升级
- 灵活部署
7.3 从数据库中心到服务中心#
O32：
Database
↑
Business LogicO45：
Business Service↓
Database核心变化：
业务逻辑从数据库释放。
八、性能架构变化#
O32#
典型：
交易请求
↓
应用服务器
↓
Oracle事务性能受：
- 数据库
- 锁
- 存储
限制。
O45#
采用：
- 内存计算
- 服务缓存
- 分布式处理
架构：
Request
↓
Service Cluster
↓
Memory Layer
↓
Database提升：
- 并发能力
- 扩展能力
- 实时能力
九、O32 与 O45 对比#
| 维度 | O32 | O45 |
|---|---|---|
| 时代 | IOE时代 | 云原生时代 |
| 架构 | 三层架构 | 服务化架构 |
| 中间件 | Tuxedo/CRES | JRES |
| 业务模型 | 大模块 | 微服务 |
| 数据库 | 中心数据库 | 数据服务化 |
| 部署 | 集中式 | 分布式 |
| 扩展 | 纵向扩展 | 横向扩展 |
| 接口 | 数据库接口 | API服务 |
| 核心理念 | 稳定 | 敏捷+弹性 |
十、为什么 O32 必然走向 O45？#
不是 O32 不优秀。
相反：
O32 是那个时代最优秀的金融架构。
但是时代变了。
2005 年：#
关注：
- 稳定
- 一致性
- 集中管理
2020 年：#
关注：
- 实时
- 开放
- 多资产
- 云化
- 服务化
架构必须变化。
十一、恒生架构演进路线#
完整路线：
证券综合业务平台|
AR/AS|
CRES|
JRES|
Light-JRES|
O45 / UF3.0 / 新一代金融平台十二、O32 到 O45 的历史意义#
O32 代表：
中国资管 IT 从手工作业走向集中化、规范化。
O45 代表：
中国资管 IT 从集中式系统走向现代金融云平台。
二者不是替代关系：
而是：
金融行业
第一代数字化↓
集中交易时代↓
服务化时代↓
云原生时代十三、结语#
恒生 O32 到 O45 的演进，本质是一场金融软件架构革命。
O32 解决：
如何让金融业务稳定运行。
O45 解决：
如何让金融业务持续演进。
从：
Oracle + Tuxedo + IBM到：
Service + API + Cloud Native二十年的架构变化，见证了中国金融 IT 从：
IOE 集中式时代
走向：
自主分布式金融平台时代。
O32 是中国资管 IT 的工业化时代代表。
O45 是中国资管 IT 服务化时代的开端。
两者共同构成了恒生电子金融技术演进最重要的一条主线。