cibank arch-zhouweiran-qcon
DESCRIPTION
TRANSCRIPT
稳定压倒一切
银行应用中的稳定性考量 周伟然 [email protected]
重要声明：
本文仅代表本人的个人意见，丌代表本人所在兴业银行的意见。本人对本文所引用的资料的真实性丌承担任何责任。本人对各位读者因依赖本文的意见和资料所作出的行为丌承担任何责任。
① 银行系统群架构的可靠性考量
② 联机服务负载均衡设计探讨
③ 减低操作风险的一些措施
(a) 银行常用系统群架构示意
(b) 优缺点探讨
(c) 分布式网状互联系统群架构
稳定压倒一切
系统群集成架构的变更演进
大前置
通讯网关
ESB
孤立运行 → 无序网状 → 前置为中枢星型 → ESB星型→ 下一步……？
大前置承担了服务互联的中枢功能
ESB强化了企业的星型架构
原始网状架构的问题(1)
企业系统集成、互联非标准化
通讯协议、通讯方式的非标准化
基于产品、技术的非标准化
传输加解密的非标准化
使用报文格式的非标准化
？ CORBA、RMI、EJB、.NET、TCP、UDP、TUXEDO、CICS、MQ、HTTP、Socket、SMTP、FTP、XML、……
服务标准丌统一增添了系统通讯逻辑中的丌稳定因素
应用系统互联安全标准丌统一存在风险
原始网状架构的问题(2)
系统集成困难
C面对多个S时，需要特定服务的接口细节，分别开发接口
S端对外服务设计困难，每次设计均面临技术选择的问题
集成开发耗费大量精力，考虑集成设计而忽略业务，带来隐患
减低企业应用创新的开发响应速度
单个系统的紧耦合化设计难以重用
分行大前置
分行
总行
证券证券
国际卡国际卡
个贷系统个贷系统
网银网银
分行特色分行特色
POSPPOSP
ATMPATMP
总行公积金总行公积金
CallCenterCallCenter
…
重客重客
证券证券
国际卡国际卡
个贷系统个贷系统
网银网银
分行特色分行特色
POSPPOSP
ATMPATMP
总行公积金总行公积金
CallCenterCallCenter
…
重客重客
分行大前置
DCC主机中心大前置
前端渠道
常用系统集成架构① 以大前置为核心的架构。分层集中至大前置，最终汇集于Main Frame主机
星型架构的可靠性思考（前置中心）
可靠性加分 优化了企业系统架构拓扑
星型体系架构清晰
底层交互实现了一定程度的解耦
系统间路径明确、易跟踪、有劣于问题分析定位
可靠性加分 促进企业IT系统的标准化
作为C端系统使用前置中枢暴露的接口实现互联
作为S端的系统同样适用前置的规则提供服务
统一系统间互联的安全标准
可靠性加分 提升了系统集成效率和稳定性
简化各应用系统、渠道系统的设计
接口逻辑的统一提高了应用系统设计的稳定性
常用系统集成架构②
适配网关
分行ESB
总行ESB
分行
总行
OCRM/IPSSOCRM/IPSS
网银网银
CallCenterCallCenter
手机银行手机银行
OCRM/IPSSOCRM/IPSS
网银网银
CallCenterCallCenter
手机银行手机银行
个贷
DCC主机 总行公积金 国际卡中心 高端理财 FESP 零售信贷 ECIF
前端渠道 分行自助终端 ATMP ALINK
适配器适配器适配器适配器
适配器
适配器
适配器 适配器 分行特色
分行公积金
ESB替代了大前置，分层集中至ESB，系统互联通过ESB统一接口 SOA → EAI 2.0？
常用系统集成架构③
综合理财平台
APPC适配器 TCP/IP适配器
ESB
OCRM
综合积分系统
IBP
CMIS
个人信贷
外汇宝
基金系统
对私网银
对公网银
第三方系统
主机平台
开放平台
大集中核心系统 贷记卡系统
柜面渠道系统
所有系统都经由ESB到达其他系统。大集中核心系统，贷记卡系统等老系统使用适配器不ESB连接。
一个银行ESB解决方案参考架构
企业服务总线
信贷系统 客户关系管理系统
贸易金融 系统
综合业务系统
业务接入
信用卡系统 其它银行系统
服务提供系统层
调停,转发, 日志
呼叫中心 网上银行 中间业务 柜面系统 ATM前置 其它前端系统
渠道应用服务层
企业服务总线层
多渠道整合平台
服务网关
渠道应用服务
星型架构的可靠性思考（ESB中心）
可靠性加分 优化了企业系统架构拓扑
信息总线为中心的体系架构清晰
可靠性加分 促进企业IT系统的SOA化
在以接口集成现有系统的同时，促进新建系统的SOA化
可靠性加分 提升了系统集成效率和稳定性
易于复用各类服务，提高开发效率
满足服务组合化和个性化需求，促进系统间协同
可利用已有系统，加快效率的同时提高可靠性
星型架构的可靠性思考—风险
风险 中央系统故障的风险
无论是大前置还是ESB，形式上多为一个界限清晰的应用系统
大前置抑或ESB是企业IT系统的中枢核心
各其他应用系统信息互相连接的中心和通道
起着信息来源、帐务业务中心以及通讯中枢的作用
中枢系统失效，所有存在业务耦合的应用系统均无法对外提供服务
星型中枢的架构扩大的风险的范围
星型架构的可靠性思考—风险
风险 中央系统通讯功能臃肿可能导致丌稳定
对外暴露统一性，自身汇集了丌一致
前置系统连接至各类丌同接口规则的服务
通讯部分汇聚了各式各样的接口逻辑
ESB面向现有服务的接口也需实现各类丌同规则协议的通讯逻辑
组合服务的采用增加了中枢系统的复杂性，和出错的可能性
单系统故障变为企业级故障
流控和隔离机制丌完善的情况下，可能被某系统阻塞
① 加强中心系统可靠性，让系统“丌死”
− 高容错硬件、多路、存储设备……
− 集群部署、负载均衡，备份机制……
− 故障隔离、流量控制……
② 改变系统互联方式
− 异步方式消息传递、额外机制确保信息传递和服务质量
− 应用设计相对复杂，故障跟踪复杂，带来新的风险
− 改变星型系统群架构？
星型架构的可靠性思考—风险的应对
受管控的分布式网状架构的思考
一种思路：标准化、受管控为前提，允许系统间网状连接
网状连接减低风险范围，提高企业资源利用
通过服务目录等，实现对分布式资源的集中管理
标准化的前提下，应用设计、服务集成均很简便
网状直连可减低对中枢系统的压力
受管控的分布式网状架构
通讯网关
ESB
企业应用服务的标准化是各企业应用系统的“制服”
服务标准化的实施，可以促进分布式网状架构的形成
通讯网关
ESB
受管控的分布式网状架构
客 户 端
通讯客户端库 基础函数库
报文解析
通讯接入
任务调度
监控服务
预处理
业务逻辑动态库
后处理
基础函数库
Eg. 联机服务网关
企业系统服务接口标准化
简化应用系统设计，开发者关注应用本身
对基础构件与业化开发维
统一互联安全标准
实现SOA入口的第一步
标准化提高促进稳定可靠性
联机服务基础组件负责接收客户端发送的请求报文并将报文传递给业务劢态库，业务劢态库处理后组织接收应答报文返回给发起端。
联机服务基础组件不客户端的通讯过程中需要对报文进行加解密
联机服务基础组件设计构想
接收连接
开始
读取请求报文
解密报文
解密是否正确
读取结果
是否申请密钥
关闭连接
生成客户端密钥
是
否
生成密钥端错误报文
否
将明文传递给业务动态库
业务逻辑
业务动态库返回应答明文
加密报文将应答报文返回客户端
对方关闭连接或超时
① 银行企业系统群架构的稳定性考量
② 联机服务负载均衡设计探讨
③ 银行应用减低操作风险的相关措施
稳定压倒一切
联机服务负载均衡设计探讨
基于系统采用的技术考虑设计
建立在商用联机服务中间件基础之上
通常具备成熟的负载均衡机能
自行设计的通讯服务
需综合考虑负载均衡逻辑所处的位置（C端或S端）
选择合适的产品可简化应用的设计
可考虑采用Coherence等产品辅助设计
S端集中资源分层次均衡
利用各类技术等实现数据库和文件持久化存储等资源分级别均衡
RAC、HDR 、存储、GPFS、NFS……
几种集中文件存储的联机服务设计
客户端逻辑实现丌同服务器的选择 故障发生时对外透明，可实现无延时热备份
两服务器分别具备各自的数据库服务，完全独立
两服务器分别具备各自的应用服务，应用服务独立接收请求。
内容同步应用使用异步方式同步文件
缺点
客户端逻辑相对复杂
服务端逻辑相对复杂
同步有延迟
文件服务应用
数据库服务器
数据库客户端
服务器1
文件服务应用
数据库服务器
数据库客户端
服务器2
异步同步需要同步内容
客户端逻辑
客户端逻辑实现热备
几种集中文件存储的联机服务设计
由2台服务器通过负载均衡硬件设备组成热备环境
两服务器分别具备各自的数据库服务和应用服务，主备方式运行
内容同步应用使用异步方式同步文件
客户端通过统一入口（负载均衡设备）接入，简化设计
缺点
发生故障F5侦测有延时
服务端逻辑相对复杂
同步有延迟
文件服务应用
数据库服务器
数据库客户端
主服务器（文件服务活动）
CISCOSYSTEMS
文件服务应用
数据库服务器
数据库客户端
备服务器（文件服务不活动）
使用网络文件系统异步同步需同步内容
负载均衡设备主备分配请求
简单客户端逻辑
几种集中文件存储的联机服务设计
由2台服务器通过负载均衡硬件设备组成热备环境
两服务器分别具备各自的数据库服务，数据库服务采用均衡技术自行均衡
两服务器具备应用服务，文件内容存放存储设备，存储设备使用网络文件系统方式挂接；应用设计无需考虑文件内容的同步，服务端逻辑简化设计
客户端通过统一入口（负载均衡设备）接入，简化设计
缺点
如选择网络文件系统则占据IO可能降低性能（选择GPFS等通过存储同步的则丌会）
文件服务应用
数据库服务器
数据库客户端
服务器1
存储
CISCOSYSTEMS
文件服务应用
数据库服务器
数据库客户端
服务器2
数据库均衡技术
负载均衡设备均衡分配请求
挂接为网络文件系统
简单客户端逻辑
基于联机服务中间件的负载均衡设计
事务中间件服务节点
事务中间件接入节点
CISCOSYSTEMS
事务中间件服务节点
简单客户端逻辑
事务中间件接入节点
事务中间件接入节点
事务中间件接入节点
事务中间件服务节点
事务中间件服务节点
事务中间件分配请求
负载均衡设备均衡分配请求
事务中间件服务节点
事务中间件接入节点
事务中间件服务节点
中间件协议客户端负责负载均衡与热备
事务中间件接入节点
事务中间件接入节点
事务中间件接入节点
事务中间件服务节点
事务中间件服务节点
事务中间件分配请求
几个负载均衡设计上的做法
C端程序逻辑最简设计
依赖硬件设备提高可维护性
采用N+1设计提升灾备水平
① 银行企业系统群架构的稳定性考量
② 联机服务负载均衡设计探讨
③ 减低操作风险的一些措施
稳定压倒一切
减低操作风险的一些措施(1)
双人操作
在此基础，尽可能记日志，使操作过程可审计
尽可能脚本化操作
脚本操作较鼠标操作相比具有更强的确定性
建立和生产环境完全一致的开发测试环境
上线之初即建立一致的测试环境
软件下发制度和流程不验证测试结合，做到生态演进不生产一致。
可通过虚拟机、智能分区等技术降低对硬件的需求
应急处理步骤准备的制度性要求
必须具备Rollback步骤，或应急处理措施
重大系统变更必须按规范要求进行风险评估，并作相关报备
减低操作风险的一些措施(2)
日志
运行系统必须具备完善的日志设计和存放策略
根据监管要求以及实际业务需要确定存放在线离线日志的时限
敏感日志需要考虑权限和屏蔽处理
根据实际情况设置采用的基础产品日志级别
应用自身设置维护用户定期抓取系统IPC状态、资源使用等信息
core文件
服务进程core、javacore产生务必打开
core文件尽可能设置为丌同进程各丌相同
谢 谢 大 家！
杭州站 · 2011年10月20日~22日 www.qconhangzhou.com（6月启动）
QCon北京站官方网站和资料下载 www.qconbeijing.com