集中支付系统设计.pptVIP

业务关键控制点 控制点 正向业务控制： 出纳业务申请控制点 财务审核控制点 总经理审批控制点 直接审批 预约审批 越级审批 支付中心操作员控制点 支付中心复核员控制点 日终上下对账控制 资金调度控制 备用金业务控制 业务关键控制点 控制点 正向业务控制： 出纳业务申请控制点 账户不同控制点实时可用余额 差错申请控制 收入输入控制 用款单编号控制 操作员多重身份控制 企业账户与支付中心对口控制 非网银支付出账确认控制 账务正向平衡控制 初始移植账户余额控制 业务关键控制点 逆向业务控制 初始账户已支付未达账调整（移植类） 收入发生额差错处理 支付发生额差错处理 备用金支付差错处理 支付令作废冲正处理 调度资金差错处理 其他异常差错平账调账处理 账户取消平账清账处理 支付中心网银支付差错处理 差错业务全程追踪再现 业务关键控制点 技术控制 登录身份安全控制 数据分割控制 操作权限控制 数据权限控制 远程数据安全控制 网络安全控制 主账数据库及服务器安全 支付中心数据安全控制 业务细节问题 初次建设，先易后难 同一账户，多备用金处理（内部虚账户的处理） 同一分公司，多备用金处理 分公司与子分司 支付细化 用款单与会计账之间的纠结（不同会计用途的资金，请分别填写不同的用款单，用款单简易化原则） 1个公司可能有多个出纳 财务经理同时兼任多个公司，多种角色 分公司上收子公司账户？ 多个银行账户与会计账之间的关系？需不需要用款单配合？ 。。。。 软件技术架构 主要功能模块设计 技术需求特点 业务请求容错率较低 页面请求处理一般只能极少量容忍技术出错 高峰或紧急类请求可能会经常出现 信息立即送达和处理 所有请求，必须是立即送到至下一控制点。 查询时间要求较高 业务实时查询，要求数据精确 不能容忍关键数据点出现差错或不及时数据 账务主机高可靠 账务主机运行环境或数据故障执行零容忍标准 远程应用（B/S应用才可能解决) 绝大业务应用建立在远程通讯网络，网络速度很不稳定 B/S架构的不足与业务技术需求冲突难以简单调和 B/S不是可靠服务设计 非实时性处理技术设计 不支持多种事务同步处理 关键技术应用 网页接入 Redis高速一级缓存，应对高速浪涌请求 Mysql支持和快速留存页面数据请求 C_Pcom安全交易请求，安全隔离主数据库 中间件 内部专属消息安全、快速信息交换(MQ) 集群服务基础，预留负载均衡体系(MQ) 主数据服务 C_ORA_SERVER安全接入，强调TPS性能 信息认证，交易可信 灌溉前置MySQL数据 重点技术攻关 三级远程通讯机制 Web请求嵌入数据包远程安全通讯机制的实现(PHP与C,JAVA 与C,APACHE与C,CPCOM与CSERVER),小型专用通信平台，全自主研发。 解决数据实时与安全，统一入口处理 三级消息同步 消息中间件与通讯机制的实时可信同步融合 解决三级数据同步与事务平衡 二级高速缓存机制 远程访问请求一级高速缓存及峰浪平滑 二级同步平滑及容错 业务数据攻关 复杂业务流的账务准确入账 统一接口下的各种特殊业务 逆向业务的冲正平算 账务准确性实时粗粒度检查 多控制点实时可用参考余额一致 网点签退，账务快速异常检查回应 主账中心日终细粒度检查深度与时间优化 主账中心异常数据处理池管理 时间资源计划 整体时间规划 12月 保障初期上线 在使用中逐步走向完善 业务细节调整优化 常规报表、统计分析改进或新增 主体集中研发时间 4个月 初期上线计划 10月8日 支付中心管理人员测试基础业务 9月下旬 业务组密集配合（中财公司业务人员） 4个月（深入讨论、确定业务细节） 研发成本预算 技术集中开发期 2.5个月*12万元/月 1.5个月*9万元/月 技术运行支撑期 8个月*2万元/月 吃、住、交通、资料等费用 6万元 共计65.5万元 集中支付系统概要设计方案 集中支付 硬件需求设计及建议 业务框架设计 软件技术架构 时间资源规划 研发成本预算 硬件需求设计及建议 机房条件需求 设备安全 独立空间，专人管理 环境 温度（空调）、湿度、高度、静电 供电 电源保障（UPS）、接地、防雷 机柜 机架式机柜 外部进线 互联网接入光纤线 机房建设比较 公司机房 优点 环境、机柜 强电、互联网接入 专人管理 独立空间 不足 UPS不能保障，建设UPS需要保障全机房，超出本系统的硬件UPS预算 独立空间过小，服务器过多，一旦空调停转，升温迅速。（据硬件相关人员介绍，已发生过服务器因温度过高直接停机事件） 在服务器上直接处理的事项，比如升级，监控和优化性能等操作，需要公司硬件相关人员配合，在业务系统未