IOE架构对于金融业来说,涉及信息安全和成本过高的问题之外,还有许多技术上的问题。IOE架构的本质是“集中式计算+闭源商用系统”,程序运行在少数主机服务器上,底层代码无从得知,这会导致信息安全风险、自主可控能力弱化、可扩展性低。
小插曲:针对美方批量、陆续将中国有关企业、机构、高校和个人列入“实体清单”,去IOE的必要性更足了。
可行的解决方案:就是采用分布式架构,可按需扩容,快速响应业务变化,大幅降低IT成本,可实现灰度发布,可支持大并发访问,达到7*24小时运行。
去IOE
1) 采用集群部署,支持横向扩展
2) 封装核心系统对外发布服务和数据接口,减少外围系统配套改造
3) 重新建模、重构组件或系统,消除知识产权争议点
4) 365*24不间断服务,实现灰度发布
5) 多时区处理
6) 对分布式一致性设计而言,重点考虑本地事务和跨库事务
7) 批处理设计,重点考虑断点续跑和同步机制
8) 多法人设计
9) 用开源数据库或自主知识产权的数据库替换DB2、ORACLE、TERADATA
GoldenDB数据库是中兴通讯的金融级的交易型分布式数据库,是中国国内唯一一个即将完成在大型银行核心业务商用的数据库产品。
10) 使用云存储或私有云,来满足可扩展、安全性高、提高资源利用率,达到成本下降
去IOE的新一代架构
1) 核心业务子系统
2) 综合查询子系统
3) 报表子系统:
4) 作业调度管理子系统
5) 其他子系统
。。。。。。
1) 分库方案:原则上按分行来,涉及大行需要再次拆分,这时候需要考虑并行查询的技术性能问题。
2) 分表方案:业内通常采用分库内按客户号分表
3) 数据迁移方案
4) 设计原则:保持分行数据内聚、水平切分数据
1) 消息中心采用kafka
2) 分布式缓存集群:采用Cassandra Nosql作为索引,采用Redis Nosql来存放各种系统参数
3) 应用路由:采用Ngnix +JAVA,实现请求报文及交易规则分发。
4) 配置中心:采用Zookeeper +java ,配置各服务部署信息,交易归属网关等规则。
5) 作业调度子系统:负责作业执行编排及运行监控。
(1)实施要点
(2)切换策略