1. 稳定压倒一切
银行应用中的稳定性考量
周伟然 zhouwran@gmail.com
重要声明：
本文仅代表本人的个人意见，丌代表本人所在兴业银行的意见。本人对本
文所引用的资料的真实性丌承担任何责任。本人对各位读者因依赖本文的
意见和资料所作出的行为丌承担任何责任。

2. 稳定压倒一切
① 银行系统群架构的可靠性考量
(a) 银行常用系统群架构示意
(b) 优缺点探讨
(c) 分布式网状互联系统群架构
② 联机服务负载均衡设计探讨
③ 减低操作风险的一些措施

3. 系统群集成架构的变更演进
 孤立运行 → 无序网状 → 前置为中
枢星型 → ESB星型→ 下一步……？
 大前置承担了服务互联的中枢功能
 ESB强化了企业的星型架构
大前置
ESB
通讯网关

4. 原始网状架构的问题(1)
 企业系统集成、互联非标准化
 通讯协议、通讯方式的非标准化
 基于产品、技术的非标准化
 传输加解密的非标准化
 使用报文格式的非标准化
？ CORBA、RMI、EJB、.NET、TCP、UDP、TUXEDO、CICS、MQ、
HTTP、Socket、SMTP、FTP、XML、……
 服务标准丌统一增添了系统通讯逻辑中的丌稳定因素
 应用系统互联安全标准丌统一存在风险

5. 原始网状架构的问题(2)
 系统集成困难
 C面对多个S时，需要特定服务的接口细节，分别开发接口
 S端对外服务设计困难，每次设计均面临技术选择的问题
 集成开发耗费大量精力，考虑集成设计而忽略业务，带来隐患
 减低企业应用创新的开发响应速度
 单个系统的紧耦合化设计难以重用

6. 常用系统集成架构①
以大前置为核心的架构。分层集中至大前置，最终汇集于Main Frame主机
总行公积金
总行公积金
总行公积金
证券
证券
证券
重客
重客
重客
中心大前置 DCC主机
国际卡
国际卡
个贷系统
个贷系统
网银
网银
网银
总行
分行
分行特色
分行特色 分行大前置
分行大前置
POSP
POSP
ATMP
ATMP
CallCenter
CallCenter
… 前端渠道

7. 星型架构的可靠性思考（前置中心）
 可靠性加分 优化了企业系统架构拓扑
 星型体系架构清晰
 底层交互实现了一定程度的解耦
 系统间路径明确、易跟踪、有劣于问题分析定位
 可靠性加分 促进企业IT系统的标准化
 作为C端系统使用前置中枢暴露的接口实现互联
 作为S端的系统同样适用前置的规则提供服务
 统一系统间互联的安全标准
 可靠性加分 提升了系统集成效率和稳定性
 简化各应用系统、渠道系统的设计
 接口逻辑的统一提高了应用系统设计的稳定性

8. 常用系统集成架构②
ESB替代了大前置，分层集中至ESB，系统互联通过ESB统一接口
SOA → EAI 2.0？
DCC主机 总行公积金 国际卡中心 高端理财 FESP 零售信贷 ECIF
OCRM/IPSS
OCRM/IPSS
网银
网银
总行ESB 适配网关 CallCenter
CallCenter
总行 手机银行
手机银行
分行 个贷
适配器 适配器 适配器 分行特色
分行ESB
适配器 分行公积金
适配器 适配器 适配器 适配器
前端渠道 分行自助终端 ATMP ALINK

9. 常用系统集成架构③
所有系统都经由ESB到达其他系统。大集中核心系统，贷记卡系统等老系统
使用适配器不ESB连接。
主机平台
综合理财平台 大集中核心系统 贷记卡系统
APPC适配器 TCP/IP适配器
ESB
对 对 基 个 综 第
公 外 合
私 金 人 三
OCRM
CMIS
积
IBP
网 汇 分 方
网 系 信 系
银 宝 系 统
银 统 贷 统
开放平台
柜面渠道系统

10. 一个银行ESB解决方案参考架构
服务提供系统层
综合业务系统 信用卡系统 客户关系管理 信贷系统 贸易金融 其它银行系统
系统 系统
企业服务总 调停,转发, 日志
线层
企业服务总线
业务接入
渠道应用服务层 服务网关
多渠道整合平台
渠道应用服务
柜面系统 ATM前置 网上银行 呼叫中心 中间业务 其它前端系统

11. 星型架构的可靠性思考（ESB中心）
 可靠性加分 优化了企业系统架构拓扑
 信息总线为中心的体系架构清晰
 可靠性加分 促进企业IT系统的SOA化
 在以接口集成现有系统的同时，促进新建系统的SOA化
 可靠性加分 提升了系统集成效率和稳定性
 易于复用各类服务，提高开发效率
 满足服务组合化和个性化需求，促进系统间协同
 可利用已有系统，加快效率的同时提高可靠性

12. 星型架构的可靠性思考—风险
风险 中央系统故障的风险
 无论是大前置还是ESB，形式上多为一个界限清晰的应用系统
 大前置抑或ESB是企业IT系统的中枢核心
 各其他应用系统信息互相连接的中心和通道
 起着信息来源、帐务业务中心以及通讯中枢的作用
 中枢系统失效，所有存在业务耦合的应用系统均无法对外提供服务
 星型中枢的架构扩大的风险的范围

13. 星型架构的可靠性思考—风险
风险 中央系统通讯功能臃肿可能导致丌稳定
 对外暴露统一性，自身汇集了丌一致
 前置系统连接至各类丌同接口规则的服务
 通讯部分汇聚了各式各样的接口逻辑
 ESB面向现有服务的接口也需实现各类丌同规则协议的通讯逻辑
 组合服务的采用增加了中枢系统的复杂性，和出错的可能性
 单系统故障变为企业级故障
 流控和隔离机制丌完善的情况下，可能被某系统阻塞

14. 星型架构的可靠性思考—风险的应对
① 加强中心系统可靠性，让系统“丌死”
− 高容错硬件、多路、存储设备……
− 集群部署、负载均衡，备份机制……
− 故障隔离、流量控制……
② 改变系统互联方式
− 异步方式消息传递、额外机制确保信息传递和服务质量
− 应用设计相对复杂，故障跟踪复杂，带来新的风险
− 改变星型系统群架构？

15. 受管控的分布式网状架构的思考
 一种思路：标准化、受管控为前提，允许系统间网状连接
 网状连接减低风险范围，提高企业资源利用
 通过服务目录等，实现对分布式资源的集中管理
 标准化的前提下，应用设计、服务集成均很简便
 网状直连可减低对中枢系统的压力

16. 受管控的分布式网状架构
企业应用服务的标准化是各企业应用系统的“制服”
服务标准化的实施，可以促进分布式网状架构的形成
ESB
ESB
通讯网关
通讯网关

17. 受管控的分布式网状架构
Eg. 联机服务网关
企业系统服务接口标准化
监控服务 基础函数库
简化应用系统设计，开发
者关注应用本身
预处理
业务逻辑
对基础构件与业化开发维 报文解析
动态库
后处理
统一互联安全标准
实现SOA入口的第一步 任务调度
标准化提高促进稳定可靠 通讯接入
性
通讯客户端库 基础函数库
客 户 端

18. 联机服务基础组件设计构想
 联机服务基础组件负责接收客户端发送的请求报文并将报文传递给业务劢态库，
业务劢态库处理后组织接收应答报文返回给发起端。
 联机服务基础组件不客户端的通讯过程中需要对报文进行加解密
开始
将明文传递给
接收连接 业务动态库
读取请求
报文 业务逻辑
对方关闭连接
或超时 业务动态库
关闭连接 读取结果
返回应答明文
是 生成客户 将应答报文
是否申请密钥 加密报文
端密钥 返回客户端
否
解密报文
解密 否 生成密钥端
是否正确 错误报文

19. 稳定压倒一切
① 银行企业系统群架构的稳定性考量
② 联机服务负载均衡设计探讨
③ 银行应用减低操作风险的相关措施

20. 联机服务负载均衡设计探讨
 基于系统采用的技术考虑设计
 建立在商用联机服务中间件基础之上
 通常具备成熟的负载均衡机能
 自行设计的通讯服务
 需综合考虑负载均衡逻辑所处的位置（C端或S端）
 选择合适的产品可简化应用的设计
 可考虑采用Coherence等产品辅助设计
 S端集中资源分层次均衡
 利用各类技术等实现数据库和文件持久化存储等资源分级别均衡
 RAC、HDR 、存储、GPFS、NFS……

21. 几种集中文件存储的联机服务设计
 客户端逻辑实现丌同服务器的选择
故障发生时对外透明，可实现无延 服务器1 服务器2
时热备份
数据库 数据库
 两服务器分别具备各自的数据库服 服务器 服务器
务，完全独立
 两服务器分别具备各自的应用服务， 数据库
客户端 异步同步
数据库
客户端
应用服务独立接收请求。 需要同步内容
 内容同步应用使用异步方式同步文 文件服务 文件服务
件
应用 应用
 缺点
客户端逻辑实现热备
 客户端逻辑相对复杂
客户端逻辑
 服务端逻辑相对复杂
 同步有延迟

22. 几种集中文件存储的联机服务设计
主服务器 备服务器
 由2台服务器通过负载均衡硬件设 （文件服务活动） （文件服务不活动）
备组成热备环境
数据库 数据库
服务器 服务器
 两服务器分别具备各自的数据库
服务和应用服务，主备方式运行
数据库 数据库
客户端 使用网络文件系统异步 客户端
 内容同步应用使用异步方式同步 同步需同步内容
文件
文件服务 文件服务
应用 应用
 客户端通过统一入口（负载均衡
设备）接入，简化设计 负载均衡设备主备分配请求
缺点
CISCO SYSTEMS

 发生故障F5侦测有延时
 服务端逻辑相对复杂 简单客户端逻辑
 同步有延迟

23. 几种集中文件存储的联机服务设计
 由2台服务器通过负载均衡硬件设 服务器1 服务器2
备组成热备环境
数据库 数据库
服务器 服务器
 两服务器分别具备各自的数据库 数据库均衡技术
服务，数据库服务采用均衡技术
自行均衡 数据库 数据库
挂接为网络文件系统
客户端 客户端
 两服务器具备应用服务，文件内 存储
容存放存储设备，存储设备使用
网络文件系统方式挂接；应用设 文件服务 文件服务
计无需考虑文件内容的同步，服
应用 应用
务端逻辑简化设计
负载均衡设备均衡分配请求
 客户端通过统一入口（负载均衡 CISCO SYSTEMS
设备）接入，简化设计
 缺点
 如选择网络文件系统则占据IO可 简单客户端逻辑
能降低性能（选择GPFS等通过存
储同步的则丌会）

24. 基于联机服务中间件的负载均衡设计
事务中间件 事务中间件 事务中间件 事务中间件 事务中间件 事务中间件 事务中间件 事务中间件
服务节点 服务节点 服务节点 服务节点 服务节点 服务节点 服务节点 服务节点
事务中间件分配请求
事务中间件分配请求
事务中间件 事务中间件 事务中间件 事务中间件
接入节点 接入节点 接入节点 接入节点
事务中间件 事务中间件 事务中间件 事务中间件
接入节点 接入节点 接入节点 接入节点
负载均衡设备均衡分配请求
CISCO SYSTEMS
中间件协议客户端
负责负载均衡与热备
简单客户端逻辑

25. 几个负载均衡设计上的做法
 C端程序逻辑最简设计
 依赖硬件设备提高可维护性
 采用N+1设计提升灾备水平

26. 稳定压倒一切
① 银行企业系统群架构的稳定性考量
② 联机服务负载均衡设计探讨
③ 减低操作风险的一些措施

27. 减低操作风险的一些措施(1)
 双人操作
 在此基础，尽可能记日志，使操作过程可审计
 尽可能脚本化操作
 脚本操作较鼠标操作相比具有更强的确定性
 建立和生产环境完全一致的开发测试环境
 上线之初即建立一致的测试环境
 软件下发制度和流程不验证测试结合，做到生态演进不生产一致。
 可通过虚拟机、智能分区等技术降低对硬件的需求
 应急处理步骤准备的制度性要求
 必须具备Rollback步骤，或应急处理措施
 重大系统变更必须按规范要求进行风险评估，并作相关报备

28. 减低操作风险的一些措施(2)
 日志
 运行系统必须具备完善的日志设计和存放策略
 根据监管要求以及实际业务需要确定存放在线离线日志的时限
 敏感日志需要考虑权限和屏蔽处理
 根据实际情况设置采用的基础产品日志级别
 应用自身设置维护用户定期抓取系统IPC状态、资源使用等信息
 core文件
 服务进程core、javacore产生务必打开
 core文件尽可能设置为丌同进程各丌相同

29. 谢 谢 大 家！

30. 杭州站 · 2011年10月20日~22日
www.qconhangzhou.com（6月启动）
QCon北京站官方网站和资料下载
www.qconbeijing.com