新一代智能柜台
整体解决方案

文档历史记录

文档约定

本文档中使用以下约定，以区分于文档中的其它部分。

目录

文档历史记录
文档约定
目录
1. 项目背景
2. 建设目标
3. 平台简介
3.1. 平台简介
3.2. 平台优势
3.2.1. 网点全渠道跨平台软件平台
3.2.2. 创新的软件版本管理方式
3.2.3. 整合生物识别技术及新型人机交互
3.2.4. 敏捷开发及平台扩展能力
3.3. 平台国产化适配表
4. 总体设计
4.1. 设计原则
4.2. 系统组成
4.3. 系统体系结构
4.3.1. iBank4前端业务系统体系结构设计
4.3.2. iBank4后台整体体系结构设计
4.4. 硬件资源
4.4.1. 生产主机房硬件资源
4.4.2. 同城双活机房硬件资源
4.5. 关键技术
4.5.1. 微服务技术
4.5.2. 数据库技术
4.5.3. Web应用技术
4.5.4. 持续集成技术
4.5.5. 服务监控技术
4.5.6. 接口通讯技术
4.5.7. 日志实现技术
4.5.8. 应用部署技术
4.5.9. 链路跟踪技术
4.5.10. 缓存技术
4.5.11. 开源技术栈
4.6. 应用服务简介
4.6.1. 终端接入模块
4.6.2. 联机交易模块
4.6.3. 监控模块
4.6.4. 运营管理模块
4.6.5. 大堂Pad模块
4.6.6. 任务中心模块
4.6.7. 移动运维模块
4.7. 服务划分
5. 架构设计
5.1. 应用架构
5.2. 技术架构
5.2.1. 系统架构图
5.2.2. 网络部署图
5.2.3. 同城双活部署结构图
6. 平台设计
6.1. 基础平台设计
6.1.1. 网关系统
6.1.2. 序列号模块
6.1.3. 注册配置中心
6.1.4. 文件管理服务
6.1.5. 日志服务
6.1.6. 监控系统
6.2. 数据库设计
6.2.1. 数据库表设计原则
6.2.2. 命名规范
6.2.3. 数据库开发
6.3. 接口设计
6.3.1. 后管接口设计
6.3.2. Restful接口说明
6.3.3. ISO8583接口规范
6.4. 缓存设计
6.4.1. 缓存原则
6.4.2. 全局缓存方案
6.4.3. 会话缓存方案
6.5. 权限设计
6.5.1. 系统权限设计原则
6.5.2. 对接统一用户平台
6.5.3. 登录授权
6.5.4. 服务鉴权
6.5.5. 权限管理
6.5.6. 权限配置
6.5.7. 权限分配
6.5.8. 访问审计
6.6. 访问控制
6.6.1. 访问控制模型三要素
6.6.2. 基于角色的访问控制（RBAC）
6.6.3. 权限控制的具体方法
6.6.4. 二次认证支持
6.6.5. 敏感标记支持
6.6.6. 异常会话控制管理
6.6.7. 黑名单支持
6.6.8. 技术用户与业务用户分离机制
6.7. 日志设计
6.7.1. 实现方案
6.7.2. 日志规范
6.7.3. 日志归档
6.8. 安全设计
6.8.1. 通讯及访问安全
6.8.2. 文件上传安全
6.8.3. 日志安全
6.8.4. 数据安全
6.8.5. 敏感信息管控
6.8.6. SQL注入防范
6.8.7. 跨站点脚本攻击防范
6.8.8. 外部脚本执行漏洞
6.8.9. 代码安全设计
7. 应用服务功能
7.1. 用户管理服务
7.1.1. 机构管理
7.1.2. 用户管理
7.1.3. 权限管理
7.1.4. 菜单管理
7.1.5. 数据字典
7.1.6. 国际化
7.1.7. 定时任务
7.2. 运营管理服务
7.2.1. 终端管理
7.2.2. 版本升级
7.2.3. 电子流水
7.2.4. 状态监控
7.2.5. 运维设置
7.2.6. 报表统计
7.2.7. 参数管理
7.2.8. 生命周期管理
7.3. 联机交易服务
7.3.1. 平台功能
7.3.2. 业务功能
7.4. 移动运维服务
7.5. Pad授权服务
8. 终端运维
8.1. 例行停机方案
8.2. 终端升级
8.2.1. 模块化升级方案
8.2.2. 自动化部署升级方案
8.2.3. 升级过程
8.2.4. 升级回滚机制
8.2.5. 升级过程中对外提供服务情况
9. 系统运维方案
9.1. 服务管理
9.2. 服务部署
9.3. 版本管理
9.4. 持续集成
9.5. 高可用方案
9.5.1. 高可用原则
9.5.2. 服务高可用
9.5.3. 数据库高可用
9.5.4. Elasticsearch高可用
9.5.5. Redis高可用
9.5.6. 7*24小时方案
9.5.7. 灰度发布方案
9.6. 负载均衡方案
9.6.1. 网关负载均衡
9.6.2. 应用负载均衡
9.6.3. 数据库负载均衡
9.7. 备份方案
9.7.1. 备份策略
9.7.2. 数据库备份
9.7.3. 文件备份
9.7.4. 日志备份
9.8. 容灾方案
9.8.1. 服务器容灾方案
9.8.2. 应用容灾方案
9.8.3. 数据库容灾方案
9.8.4. 同城双活及服务
10. 数据库备份方案
10.1. 备份类型
10.2. 备份操作
10.3. 备份方案
10.4. 备份数据管理与清理
10.4.1. 数据库级别备份清理
10.4.2. 业务逻辑备份管理与清理
11. 双活方案
11.1. 异地主备双活设计
11.1.1. 整体设计
11.1.2. 文件同步
11.1.3. 数据缓存同步
11.1.4. 服务同步
11.2. 异地主备双活部署
11.2.1. 部署要求
11.2.2. 主中心
11.2.3. 灾备中心
12. 终端测试
12.1. TakeCard话框
12.2. InsertCard对话框
12.3. ErrorSimulating对话框
12.4. Status对话框
12.5. CardInfo对话框
13. 性能测试内容
13.1. 测试环境
13.2. 测试策略
13.2.1. 基准/混合场景测试
13.2.2. 稳定性测试
13.2.3. 异常测试
13.3. 测试结果
13.3.1. 基准场景结果
13.3.2. 混合场景测试结果
13.3.3. 稳定性测试结果
13.3.4. 异常测试结果
14. 知识转移策略
14.1. 技术转移安排
14.2. 产品转移
14.3. 技能转移

1. 项目背景

新一代智能柜台项目拟对智能柜台前、后台进行全面重构，实现对设备、用户、业务的全生命周期管理及参数化管理，有效提升系统风险管控能力及应对业务变化的敏捷调整能力；建立组建化业务模式，对交易中高频出现的共用部分，进行抽象分解，拆分成多种类型组件，并建立完善的组件库。在此基础上，对柜面业务进行梳理整合，迁移至智能柜台并实现业务场景化、流程标准化，大幅提升客户体验。
随着银行为进一步提升客户体验，拟对新一代智能柜台，围绕相关系统的业务场景，业务功能更加多样化，需要核心系统支持更加灵活的业务支撑能力，支持新业务，新模式的快速二次开发和上线能力。
整体系统建设达成以下目标：
l 对智能柜台后台管理端进行重构，实现对设备、用户、业务的全生命周期管理及参数化管理，有效提升系统风险管控能力及应对业务变化的敏捷调整能力；
l 对智能柜台前端业务流程进行重构，建立组建化业务模式，对交易中高频出现的共用部分，进行抽象分解，拆分成多种类型组件，并建立完善的组件库。
l 对柜面个人业务进行梳理整合，迁移至智能柜台并实现业务场景化、流程标准化。

2. 建设目标

新一代智能柜台项目拟对智能柜台前、后台进行全面重构，实现对设备、用户、业务的全生命周期管理及参数化管理，有效提升系统风险管控能力及应对业务变化的敏捷调整能力；建立组建化业务模式，对交易中高频出现的共用部分，进行抽象分解，拆分成多种类型组件，并建立完善的组件库。在此基础上，对柜面业务进行梳理整合，迁移至智能柜台并实现业务场景化、流程标准化，大幅提升客户体验。
本项目所需应用软件能够兼容我行所有品牌及型号的硬件设备，支持WINDOWS、LINUX、安卓等多操作系统，并免费对硬件设备进行升级测试。项目主要内容如下：
1．在设备前端开发部分管理功能，实现对重空领用、上缴、清机、查询、重空短缺预警的管理；设备状态查询、设备自检、电子日志查询的管理等。
2．实现对设备、用户、业务的全生命周期管理，包括设备的新建、变更、删除、状态监控等；系统管理员、操作员等用户的新建、变更、删除、业务权限分级管理等；业务流水查询、电子凭证生成、电子档案保存等；建立业务及管理功能等的参数化体系等。
3．实现流水无纸化、凭证无纸化，支持PDF生成；屏幕输入法，支持拼音联想、手写等主流输入；远程密钥管理，支持国际/国密等密码算法；完善版本管理，支持灰度发布，支持分机构、分厂商、分部件、分组发布，支持版本包分布下载。
4．借记卡及账户管理相关功能：个人账户开立、激活、密码管理、挂失、解挂、补换卡或存单/折、销户；客户信息更新功能；转账汇款、账单打印；综合签约/解约等。
5．信用卡相关功能：包括信用卡申请、密码重置、自动还款签约/解约、信用卡还款、卡激活、账单查询、积分查询兑换等。
6．财富管理相关功能：包括理财、基金、保险等。
7．电子银行相关功能：短信通知、个人网银、手机银行、直销银行等。
8．根据监管要求等对系统进行优化；配合核心及其他系统的改造。
智慧银行运营管理系统项目建设目标需达成如下：
1) 先进性 系统采用符合信息技术发展趋势的先进技术，硬件系统应选择先进、成熟、稳定、性价比高的设备；软件系统的选择与开发应在满足业务需求的基础上，具有易改造、易升级、易操作、易维护等特点。
2) 前瞻性 高起点规划，高标准建设，高水平管理。充分把握银行业前端渠道拓展的发展趋势，满足系统上线后 5-10 年的业务发展。
3) 稳定性
系统应具有较高的可靠性和持续使用能力，保证全年 7×24 小时稳定运行， 具有强大的并发响应能力及足够的扩充能力。
4) 安全性 系统必须具有严谨周密的安全体系结构，必须能够提供有效、全方位、多层次的安全机制，抵御可能产生的恶意攻击和病毒侵蚀，并且在运行安全、网络安
全和应用系统安全等方面有合理可靠的策略。
5) 可扩展性
系统设计遵循模块化、组件化、参数化设计原则，方便灵活，易于改造和扩 展；并能通过系统预留的升级接口独立地、平滑地进行升级，功能扩展不会明显 影响系统效率。全面兼容现有银行前端系统，支持现有系统的业务扩展；能够整 合新兴渠道和相关系统应用。
6) 标准化和开放性 系统应具有开放的、标准的接口，能够实现与行内各系统及行业应用第三方系统的联接。系统必须提供标准接口，满足多样现金设备的统一接入。
7) 易用性 系统应具有友好的用户监控、管理维护界面，操作简洁、高效。结构清晰，模块化、参数化程度高，可灵活设置，方便维护和管理。
8) 故障恢复 必须具有相应的故障检测和恢复机制，最大限度的减少故障带来的损失和危害。
9) 高效实用性 系统结构合理、效率高、资源占用率低，避免过多的数据冗余；适用的硬件系统应具有先进性、成熟性、稳定性，性价比较高；适用的软件系统应具有易改造、易升级、易操作、易维护等特性。
10) 可管理性 能够对主机、网络、数据库、应用等资源进行监控、管理和调度，并根据需要进行调整。

3. 平台简介

3.1. 平台简介

iBank4运营管理平台是广电运通公司结合多年网点跨平台软件生产部署经验，采用业内最新的软件工程理念和技术，设计开发的一整套适合网点设备运营使用的跨平台全渠道软件系统。
银行网点自助设备系统在多年应用中，逐渐浮现出一些痛点：
l 客户办理业务过程中出现白屏，无法自行回复。
l 客户办理业务过程中操作页面偶发出现空白闪烁，影响客户操作体验。
l 客户办理业务过程中端机操作响应速度不稳定，时快时慢，影响客户操作体验。
l 系统运行期间出现弹框崩溃， 稳定性差。
l 新业务开发测试部署困难。
l 不同类型设备需要不同种类的软件，不同设备上的相似业务需要在不同种类软件中重复开发测试，增加了银行科技管理网点软件系统的难度和工作量，延长了新业务上线的时间。
l 设备部署系统版本管理困难，难以强制设备采用的软件版本。
l 系统采用的开发技术老旧过时或者过于小众化，导致难以找到合适的开发人员维护，且学习成本较高。
l 系统业务架构耦合性高，难以快速更新扩容，从而适应业务人员提出的各种新型业务场景。
l 跨操作系统能力差，不同的操作系统需要不同的业务处理代码，增加了开发测试的工作量，延长了新业务上线的时间。
l 新业务开发过程中，页面设计开发和业务逻辑开发不能很好的分离，彼此纠缠在一起，从而导致开发人员需要同时完成页面设计开发和业务逻辑编写，提高了对开发人员的技能要求，加重了开发人员的工作压力，延长了新业务上线的时间。
l 系统显示页面演示效果一般，难以展示令人惊艳的效果，带给客户自然生动的交互体验。
l 针对以上一系列的痛点iBank4终端业务系统做了有针对性的设计，力求从系统本质框架上解决这些痛点。
iBank4终端业务系统拥有了以下的特点：
l 是网点全渠道跨操作系统跨平台系统软件，实现了一套软件适配网点所有类型自助设备业务。
l 架构上结合C/S和B/S两种架构的优点，摒弃其缺点。
l 采用微服务架构搭建后台联机交易服务系统，业务架构耦合性低，系统动态扩容能力强，能够很容易适应各种新型业务场景。
l 采用业内最通用流行的技术，不采用小众或者独门技术体系，最大限度减少学习使用的成本。
iBank4服务端拥有了以下的特点：
l 架构上结合了C/S 和B/S 两种模式的优点，摒弃了单一C/S模式的缺点。从而提高了设备系统升级及回滚的成功率。
l 网点全自助设备跨平台终端业务系统软件，实现一套系统能适配网点所有类型的设备。创新的设备版本管理方式，可以根据需要强制设备软件保持到预定版本，避免生产中出现的版本不一致的情况。
l 网点全自助设备跨平台软件开发遵循MVVM模式，实现了页面设计与业务逻辑开发的有效分离，让页面设计人员和业务逻辑开发人员能够并行开发，加快新业务开发测试的速度，缩短上线的时间。
l 网点全自助设备跨平台软件是终端设备使用的系统，采用html5+CSS3技术，基于VUE框架的单页面渲染系统。从技术上，避免了页面切换时出现的白屏，闪烁和响应速度慢的问题，同时拥有了展示令人惊艳效果的能力。
l 网点全自助设备跨平台软件采用基于JavaScript语言的功能接口访问硬件外设，记录日志或存取数据池变量，实现了操作系统对业务系统功能透明化，业务系统代码可以在不同操作系统之间无缝迁移。
l iBank4后台采用当前流行的微服务系统架构设计，整体系统设计高可用服务采用同城双活，服务集群化结构部署，所有节点、存储和网络设备均以高可用结构部署，提供负载的同时，提高应用服务的可用性，所有的应用服务器均采用容器化技术，支持服务自动编排、动态伸缩等特性。
l iBank4后端采用微服务架构搭建联机交易服务系统，结合银行现阶段业务状况及前瞻性的业务需求，以先进的业务模型和应用技术架构为基础，构建具备技术先进性、前瞻性的网点统一渠道服务平台，实现对网点自助设备、移动柜面和网点柜面服务渠道的服务功能支撑和统一管理，实现线上服务、线下服务各渠道间的互联互通、数据共享、服务联动和统一管理能力。
l iBank4前后端采用业内最通用流行的技术，不采用小众或者独门技术体系，最大限度减少学习使用的成本。对人员的技能水平要求不高。

3.2. 平台优势

3.2.1. 网点全渠道跨平台软件平台

iBank4智慧银行运营平台为业务子系统提供了基于JavaScript语言的硬件外设访问接口层，为业务逻辑代码提供了一致的硬件外设访问方式。iBank4智慧银行运营平台的Native平台通过驱动代理系统，抽象硬件外设厂商的WOSA驱动或非WOSA驱动，为JavaScript的硬件外设访问接口提供支撑。
在硬件外设驱动方面，iBank4智慧银行运营平台支持WOSA/XFS协议。WOSA/XFS标准在硬件操作层面提供了跨厂商设备应用能力，WOSA为客户应用实现了一个标准API，并为金融设备应用实现了一个服务提供商接口（SPI），目前XFS标准已为更多的业界厂商所接受，不只是ATM生产商，其他的金融终端也按照这个规范运行。
在前端页面展示方面，iBank4智慧银行运营平台提供了html5 + CSS3技术，基于VUE框架的创建单页面应用渲染框架，在客户操作体验上实现了多种金融设备业务统一开发部署，为客户提供一致的操作体验。平台软件不仅能应用于智能柜台，还可以在现金设备以及其他设备上进行应用。达到不同设备使用同一套平台软件，就可满足银行各设备业务应用的需要。同时，在现有工行案例应用中，取代了NCR公司的NDC协议标准。达到了终端设备全国产化及自主可控的目的。
通过采用微服务技术框架，iBank4智慧银行运营平台的联机交易服务集群整合了银行后台原来各个渠道，如电子银行，卡系统，基金理财等，经过梳理，拆分和整合处理，为端机提供了统一一致的访问接口。梳理，拆分和整合原各渠道服务系统中公有的业务服务成公共微服务镜像，减少各渠道的重复建设，打通各渠道的数据流转，为实现线上线下联动业务场景提供了支持。联机交易服务集群的微服务采用Docker容器化技术和Kubernates 自动化编排系统部署镜像，实现了服务动态扩容，高并发，高可用的技术特点。
通过上述统一的外设驱动访问接口，统一了前端展示框架，统一了联机交易服务集群，统一了网点内全渠道各种自助设备的软件系统，避免了相似业务在不同设备软件系统上的重复开发，减少了业务开发工作量，减轻了银行科技部管理软件系统的压力，加速了新业务上线部署速度，降低了运营成本，提高了客户满意度。
2）国产化适配支持
iBank4智慧银行运营平台的业务子系统提供了基于JavaScript语言的业务开发接口，完全摒弃了传统的系统强相关的业务开发方式（如采用OCX控件访问外设），结合页面采用的html5 + CSS3的渲染展现方式，共同实现了对操作系统透明无感的业务开发运行的环境。简言之，基于iBank4开发的业务代码，可以在Window, Linux和Android系统之间无缝迁移，不需要做任何修改。（当然，不同设备页面的分辨率和纵横比相差较大到，需要对CSS做必要的调整）
借助iBank4提供的平滑跨操作系统能力，银行可以节省开发成本，避免重复开发工作，减轻科技部门管理软件系统的工作压力，有利于新业务场景的不同操作系统之间的快速上线落地。
3）支持C/S和B/S的混合架构
iBank4智慧银行运营平台软件架构结合了C/S架构运行效果高，客户操作体验好，网络依赖低和B/S架构业务开发部署容易，数据易于集中的优点。简言之，iBank4智慧银行运营平台是以C/S架构方式运行，以B/S架构方式部署系统。这种新颖的混合架构方式，
iBank4智慧银行运营平台的混合架构从技术上提供了客户近乎无感的操作延迟，提升了客户的操作体验，支持业务版本的灰度发布和业务版本的快速升级部署，加快业务人员设想的新型业务场景落地，提高银行的竞争力。

3.2.2. 创新的软件版本管理方式

网点自助设备实际运营过程中，设备软件版本管理是一个重要的工作。由于设备软件版本发布升级过程中，受各种因素影响，如网络速度慢或者中断等，容易出现版本更新失败的情况，升级失败的设备继续维持运行旧软件版本，未能如生产预期提供给客户使用。如何管理设备软件版本，强制设备软件运行在生产预期的版本，是网点运管人员急需要有的功能。
iBank4通过版本重定向机制和启动时版本检查更新机制，实现了以设备号，厂商，网点，设备类型多个维度的软件版本统一管理。网点运管人员可以通过iBank4的版本服务器，发布设备的软件版本。iBank4启动时动态查询版本服务器，获取并重定向到设备指定的版本地址，实现强制指定版本的功能。

3.2.3. 整合生物识别技术及新型人机交互

随着人脸识别，指纹识别，指静脉识别，声纹识别技术逐步成熟， 刷脸支付，验密，授权，VIP客户识别等银行新业务应用场景也从实验阶段逐渐走向了现实生活中，成为网点终端设备一项新颖功能，为客户提供了便捷的业务办理体验。终端设备开发平台能否迅速方便的引入并整合生物识别技术在业务流程中，势必成为新一代开发平台所必须具备的能力。
iBank4软件系统已经引入并整合了业内最领先生物识别云平台技术，能够很方便的满足新型业务场景在生物识别技术方面的需要。
人与机器之间如何进行交互，从早期的打孔纸写指令，机器以闪烁信号灯回应，到通过屏幕，键盘和鼠标等外设，再到通过手势，触摸等肢体语言进行人机交互，这些类型的人机交互尽管逐渐变得更加容易方便，但是始终是一种“哑语”式的交互方式，这类交互方式放大增强了终端设备冷冰冰的金属感，缺少了人与人交互的自然温馨感觉，降低了客户的体验。受益于现代语音识别技术的进步，全程语音交互方式也被逐渐引入终端设备上，结合手势，触摸的交互方式，实现了一种更自然更易于接受的人机交互方式，成为了终端设备人机交互方式的未来发展趋势。
iBank4软件系统整合了业内流行的语音识别技术，能够很方便的满足新型业务场景在新型人机交互方式上的需要。

3.2.4. 敏捷开发及平台扩展能力

iBank4软件采用了业内标准主流的技术和框架设计开发的，并不使用任何小众化或者独门特殊技术，降低了使用iBank4的开发人员学习难度，也方便找到开发维护工程师开发维护系统，从另一方面降低了使用维护设备软件的成本。
iBank4采用以下的技术和框架：
l Html5 + CSS3 + JavaScript ES6 + VUE框架构建了端机前端页面系统
l Java + spring boot 构建了Native平台和服务器系统
l C++ + Protocol Buffer 构建了驱动代理平台
l Docker + Kubernates + Tomcat 构建了联机交易服务容器云
上述技术和框架都是业内主流的技术和框架，容易学习和维护。
iBank4的页面采用Html5 + CSS3技术构建，让专业的页面设计开发人员创建出令人惊艳的效果，给客户带来良好的体验。后台采用微服务架构可实现后台服务功能的无线扩充。

3.3. 平台国产化适配表

表：终端信创适配清单

表：后台信创服务适配清单

4. 总体设计

4.1. 设计原则

iBank4系统主要设计原则如下：
（1） 高可用原则
整体系统设计高可用服务采用同城双活，服务集群化结构部署，所有的服务节点、存储和网络设备均以高可用结构部署。同城双机房通过网络设备实现跨机房的双活结构。
所有应用服务均采用集群化部署，提供负载的同时，提升应用服务的可用性。每一个应用服务子系统均至少部署2个以上服务节点。所有的应用服务器均采用虚拟化技术，因此，相同子系统服务须确保部署在不同的物理服务器上。
机房网络线路、跨机房光纤网络，均采用不同运营商双线部署，网络设备采用主备结构，确保服务的故障的快速切换。
数据库按DDD设计思想，根据领域建模进行按库切分，不同服务采用不同库连接。在数据存储方面，对大表采用分表分库进行拆分存储，采用MySQL官方提供的MGR高可用方案，实现数据库方面的高可用。
（2） 高性能原则
整体系统采用高并发，低延时的网络通讯技术，在网关层采用新型的支持NIO以及HTTP长连接的服务器，支持高并发下的HTTP数据传输和通讯，实现网络链路复用，提高数据吞吐能力。
应用服务采用微服务架构，微服务内部采用稳定高效的Undertow服务框架，具有优秀的并发性能和稳定性。在TCP方面采用Netty高性能服务器提供服务。
数据库连接采用HikariCP数据库连接池，具有高效的数据库连接和通讯性能，也是微服务框架主流的数据库连接池技术。数据库采用MySQL，按领域模型进行库切分，大表支持分表分库存储，同时实现读写分离，从而提高数据库的IO性能。
针对读写频繁的操作上，在确保数据一致的前提下，使用Redis分布式缓存技术，减少对数据库的访问以及数据的频繁重复计算，提高系统IO性能，降低对数据库的访问压力。
（3） 安全性原则
系统的安全包括系统安全，服务安全，密码安全，接口安全，数据安全，web安全，敏感信息加密等方面。
操作系统部署用户权限采用最小应用权限原则，应用服务对操作系统操作权限最小化，系统不用root权限部署应用，系统对外端口由部署应用决定，针对服务间通讯开通特定通讯端口。
应用服务采用Docker部署，用Kubernetes实现自动编排部署，应用部署采用单独容器独立部署。内部服务仅通过接口网关对外提供访问能力。
系统中所有涉及用户密码，配置文件密码，数据库密码全部采用加密存储，确保密码安全。
服务接口，数据接口通讯，涉及权限访问接口，均通过授权方式获取访问能力。服务间接口通讯，通过对IP地址、端口号的限制进行权限管控。
数据方面借住成熟的数据库安全管控功能和文件存储的安全管控功能对数据进行安全管理，有效控制数据的访问、备份及恢复。
管理端web访问通过特定堡垒机和固定内网终端访问，不可通过互联网访问。web页面全部安全可靠的技术框架，可防范XSS、SQL注入等恶性攻击。web端服务接口全部使用统一鉴权防访问，确保接口访问权限安全。
对外暴露的用户敏感信息，对操作管理维护人员的操作数据库数据时，敏感用户信息全部采用加密显示，屏蔽用户敏感信息，确保用户信息的查看安全性。
（4） 可扩展性原则
系统设计采用服务化解耦，遵循高内聚，低耦合模式，接口服务均为无状态服务设计，系统服务不存在关键节点依赖。各系统模块均可通过服务集群方式进行处理能力扩展。
在数据库服务器和应用服务器，同时可以通过对服务器资源进行垂直扩展，对硬件的计算能力，存储能力，网络带宽进行扩展升级。可基于业务量规模的扩展，选择性的对整体系统进行水平或垂手的扩展。
（5） 可维护性原则
整体平台各个子系统和功能模块都提供独立的web管理界面，对相关服务进行可视化操作管理。对日志系统、监控系统都提供可视化管理页面，方面运维人员对服务的管理和监控。
（6） 标准化原则
系统开发遵循银行金融行业标准、国家标准以及国际标准。对相关监管报送、上送数据按相关规范要求定义并提供。
对外系统相关对接均遵循相关接口定义规范，服务接口定义标准规范，数据报文结构标准规范，参数标准规范，数据字典规范以及操作流程规范。
系统内部接口遵循安全系统通讯标准，主要通过标准的HTTP协议与TCP固定格式数据进行交互通讯。
（7） 幂等性原则
在系统业务逻辑层面均通过系统设计保证相关接口和数据处理的幂等性。在对异常重试，数据重跑，请求重发等处理上，均保证数据结果的一致性。
（8） 可监控原则
所有发布服务，应用进程均进行监控。所有服务日志通过日志收集工具统一采集，监控系统日志异常。针对服务器资源，服务健康度，服务流量，调用超时，异常日志均通过监控服务进行监控管理。
（9） 持续集成原则
系统服务部署均采用Jenkins+Git+Docker持续集成及自动化发布部署，改变运维人传统的服务部署模式。通过自动化部署脚本和操作，一键完成系统版本的切换及集群服务部署。

4.2. 系统组成

iBank4平台由前端业务系统和运营后台系统组成。前端业务系统主要用于设备端的使用，主要包含自助设备上各业务的办理。运营后台系统主要是用于后台的管理端，主要包含对设备的管理、监控等。

4.3. 系统体系结构

4.3.1. iBank4前端业务系统体系结构设计

前端业务系统实现了相应端机设备的业务场景，提供操作页面给客户办理业务，包括但不限于以下业务场景：
Ø ATM业务
Ø 智能柜台业务
Ø 发卡机业务
Ø 远程视频柜员机业务
Ø 信息发布系统业务
Ø 填单机业务
Ø 排队叫号机业务
Ø 查询机业务
Ø 存折补登机业务
Ø 电子回单打印业务
业务系统使用Html5页面展示操作页面，使用JavaScript编写业务逻辑。
业务系统包含3部分组件，分别是：
1. 浏览器
浏览器被用做页面呈现和JS脚本容器，使用VUE框架和Html5+CSS3展示页面的单页面应用。
浏览器要求支持html5，iBank4前端默认采用Chrome.
2. 标准JavaScript库（SJSL）
SJSL实现了与Native平台之间的通信连接，报文发送接收处理，提供设备外设访问，日志记录和数据存取的JS接口。
3. 标准JavaScript业务组件库(SJSBL)
SJSBL架构在SJSL之上的业务组件库，实现了常用的业务功能组件，如交换密钥，读卡，点钞，存钞等，方便了后续组织创建业务序列
(1)Native平台
Native平台为业务系统的SJSL提供了外设接口，日志记录接口和数据存取接口，同时实现了基于规则引擎的业务安全检查机制，确保账务不出现致命问题。
Native平台由以下几个组件组成：
l JS访问组件
JS访问组件实现了管理业务系统的SJSL连接，接收并处理请求的功能。
l 设备管理组件
设备管理组件实现了扫描，加载，管理各种外设设备服务的功能。
l 监控管理组件
监控管理组件实现了查询，获取设备外设状态信息并上送到监控管理服务器的功能。
l 日志管理组件
日志管理组件实现了记录并管理日志文件的功能。日志管理组件基于logback库实现
l 驱动代理组件
驱动代理组件实现了Java端远程访问驱动代理平台，获取设备外设访问接口的 功能。
l 驱动代理平台
驱动代理平台实现了中间件的独立加载管理的功能，Native平台的Java端通过驱动代理组件连接驱动代理平台，根据需要创建驱动代理应用，获取相应的硬件外设访问接口操作硬件外设。
驱动代理平台分别以下几个组件：
n 代理孵化器
代理孵化器负责根据指令孵化并管理驱动代理应用。当驱动代理应用出现问题时，立刻重启恢复。
n 驱动代理应用
驱动代理应用是采用C++开发的应用，实现了以下功能：
Ø 通过加载外设的WOSA中间件以访问WOSA驱动来访问硬件外设
Ø 通过加载厂商驱动来访问硬件外设
Ø 启动时连接native平台，建立指令和事件通道
Ø 接受并处理来自于native平台JAVA端发送的指令，返回处理结果
Ø 接收硬件外设事件，并将事件封装后通过事件通道发送给native平
n 厂商驱动/WOSA驱动
中间件提供了外设SP的功能，厂商驱动提供了外设特定厂商驱动外设的。
n 厂商介质驱动
厂商硬件介质是固化在设备外设固件中的驱动程序，由厂商提供。
(2)Keeper
Keeper守护监管系统是Native平台和业务系统的创建者和运行状态监控者，它实现了以下功能：
1) 运行环境检查
运行环境检查功能实现了设备控制系统在运行前操作系统内各种要素的检查，如操作系统空闲内存，CPU占用率，依赖的第3方系统已经正常运行等，以确保设备控制系统能够正常启动运行，避免遭受恶意应用干扰。
2) 运行环境监测
运行环境监测功能实现了对运行设备控制系统的操作系统各项要素数值的监控，如空闲内存数，CPU占用率等，当要素数值达到或者超过设定的阙值，执行指定的操作，并发送警报通知到监控管理服务器。
3) 控制软件状态监测
控制软件状态监测实现了对设备控制系统的运行状态监测，通过监控操作系统进程列表和相互之间心跳包处理，及时发现设备控制系统的异常状态，并根据情况，执行必要的操作。
4) 版本管理
版本管理功能实现了设备控制系统和自身的版本升级操作。
5) 业务数据文件管理
业务数据文件管理功能实现了对采集到的业务数据文件上传服务器，管理业务数据文件存放空间的功能。
6) 主机指令处理
主机指令处理实现了对管理服务器下发的主机指令进行处理的功能，如开机，关机，版本更新等。
7) 升级回滚处理
升级回滚处理功能实现了版本升级过程中出现异常后进行回滚处理的功能，它也实现了管理服务器下发的版本回滚指令，将其回滚到指定版本的功能。
(3)中间件
1) 支持CEN/XFS协议标准（Windows平台）、GRGSISE标准协议和LFS标准协议（Linux平台）；
2) 支持跨厂商、设备型号运行。
3) 支持跨操作系统运行，支持Windows系列及微软公司后续发布的Windows系列操作系统（Windows7、10、10X）；支持Linux系列操作系统（如UOS，麒麟）
4) 提供基于多进程化设备驱动代理框架的外设访问平台，提供高稳定行，高性能，可恢复性的驱动外设管理机制。
5) 支持硬件厂商的SP驱动和非SP驱动统一访问机制。
iBank4支持ATM/CRS、STM、VTM、移动背夹等设备。iBank4的业务子系统提供了基于JavaScript语言的业务开发接口，完全摒弃了传统的系统强相关的业务开发方式（如采用OCX控件访问外设），结合页面采用的html5 + CSS3的渲染展现方式，共同实现了对操作系统透明无感的业务开发运行的环境。简言之，基于iBank4开发的业务代码，可以在Window, Linux和Android系统之间无缝迁移，不需要做修改（当然，不同设备页面的分辨率和纵横比相差较大到不能借助html5的自适应适配的时候，需要对CSS做必要的调整）。
iBank4软件架构结合了C/S架构运行效果高，客户操作体验好，网络依赖低和B/S架构业务开发部署容易，数据易于集中的优点。简言之，iBank4是以C/S架构方式运行，以B/S架构方式部署系统。这种新颖的混合架构方式。
iBank4的混合架构从技术上提供了客户近乎无感的操作延迟，提升了客户的操作体验，支持业务版本的灰度发布和业务版本的快速升级部署，加快业务人员设想的新型业务场景落地，提高银行的竞争力。

4.3.2. iBank4后台整体体系结构设计

图：系统整体体系结构设计
l 负载层：外部接口通过负载均衡层暴露的端口和IP实现对内部系统的访问。本系统负载均衡结构包含2层结构，一层为DNS路由负载，通过公网的DNS实现对不同机房的IP地址的路由。第二层为F5硬件负载，针对网关服务实现同机房内部，以及跨机房的服务负载路由。
l 服务网关层：系统服务网关连接内部服务，负责实现对内部服务请求的分发路由，负责流量管控和内部服务的负载分发。应用服务网关为业务服务的负载路由网关，负责对内部服务的负载、服务接口路由、报文解析、服务熔断和流量管控功能。
l 应用服务层：系统核心应用服务，所有业务应用服务，按服务方式划分为：终端接入、联机交易、设备监控、大堂Pad、运营管理、任务中心等。
l 支撑管控层：系统相关的支撑服务，支撑应用服务，网关服务的运行，业务日志采集，服务监控，业务管理平台，运维管理平台，服务链路跟踪等服务。
l 数据资源层：主要包括关系型数据库、内存数据库、消息队列、文件存储等资源存储介质，这一层主要为应用层和服务层提供数据支持。

4.4. 硬件资源

4.4.1. 生产主机房硬件资源

如下配置信息为生产环境主机房服务器信息。

表：生产主机房硬件资源表
以上应用服务可以按照行里的实际情况，进行灵活的整合部署。具体部署与行方进行沟通确认，可以适当将多个服务部署在同一台服务器上。

4.4.2. 同城双活机房硬件资源

参考生产主机房硬件资源

4.5. 关键技术

4.5.1. 微服务技术

iBank4系统服务采用SpringCloud 微服务技术框架。所有服务均以SpringBoot独立服务方式部署的无状态服务。服务通过微服务框架中的网关组件，注册中心组件，配置服务组件，监控组件，负载均衡组件，断路器组件实现系统服务集群的搭建。
iBank4系统采用Nacos组件作为服务治理与配置中心，网关服务采用Spring Cloud Gateway组件实现，网关服务主要承担接口路由，内部服务负载均衡功能。在网关服务和应用服务之间，采用Ribbon和Feign组件实现网关和服务间的负载均衡，在限流降级以及熔断方面采用阿里巴巴的Sentinel组件实现。
系统所有管理、监控服务均采用可视化管理平台页面配置管理，管理服务集群。

4.5.2. 数据库技术

本系统采用MySQL-5.7作为数据库使用。采用MySQL官方提供的MGR高可用方案搭建数据库环境。
业务应用均采用数据库连接池技术保持和维护数据库的连接，基于不同的服务设置数据库连接池的大小和连接时间，本系统使用HikariCP作为数据库连接池使用，HikariCP与其他连接池相比具有有吞吐量大，并发能力强，功能稳定等特点。
系统ORM开发框架采用Mybatis数据库开发框架。Mybatis轻巧灵活，非常方便进行开发。

4.5.3. Web应用技术

管理平台Web端采用VUE框架技术，前端工程独立构建，工程框架使用webpack搭建，独立编译，打包。前端开发技术体系成熟，安全性高，便于开发进行定制化开发。
页面开发采用响应式布局，遵循标准的HTML5的页面规范，页面展示兼容chrome，IE8以上版本浏览器。前端交互全部采用富客户端交互技术，具有优秀的用户交互体验。前端的样式文件和发布的javascript均使用了压缩技术，提高页面加载和响应速度。
管理服务端接口采用Spring MVC框架向页面端发布数据交互接口，数据接口全部采用标准HTTP+JSON的接口形式提供。页面端接口采用Restful方式进行定义，通过不同的HTTP方法定义对应的CRUD操作功能。

4.5.4. 持续集成技术

系统采用无状态服务部署结构，使用Jenkins+GIT+Maven+Sonar持续集成，自动化测试。持续部署工具。基于DevOps原则，对服务进行快速发布部署。Jenkins的pipeline对执行流程进行定制，GIT管理代码版本和分支，工程使用Maven编译、打包，使用Sonar对代码质量进行管理和漏洞扫描。

4.5.5. 服务监控技术

系统核心指标、服务运行状态通过Spring Boot Admin完成系统的性能监控和服务监控。Spring Boot Admin Client通过HTTP协议周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口就可以接入监控。通过Spring Actuator暴露的监控服务接口可监控发布服务的所有指标。

4.5.6. 接口通讯技术

系统通讯服务接口采用TCP和HTTP协议，其中，TCP+自定义报文采用Netty网络通讯框架，实现自定义接口，8583报文接口的数据通讯，使用NIO技术。服务间通讯接口采用标准HTTP+JSON接口进行通讯。系统接口格式定义统一化，接口定义标准参考Restful风格定义。

4.5.7. 日志实现技术

iBank4微服务系统日志解决方案采用ELK组合，通过ELK把各个节点服务的日志收集汇总，根据规则对日志数据进行过滤清洗后存储到ElasticSearch，供Kibana进行可视化呈现。

4.5.8. 应用部署技术

iBank4系统支持多种打包发布部署方式，支持原始脚本部署，支持Docker单独部署，同时也支持Kubernetes实现自动编排部署等方案，满足多种环境的部署要求。

4.5.9. 链路跟踪技术

iBank4系统采用基于java探针方式无侵入的SkyWalking技术框架实现服务调用链路的跟踪。监控服务之间的相互调用情况，检测调用过程是否存在问题，本系统使用SkyWalking无侵入方式实现服务链路的跟踪，实时监控系统请求的整体情况。

4.5.10. 缓存技术

iBank4系统采用分布式缓存Redis实现，为系统提供全局缓存能力，Redis具备高性能高吞吐量，并且具有非常丰富的数据类型，满足绝大部分业务场景的需求，是当前分布式缓存解决方案的主流选择。

4.5.11. 开源技术栈

系统开发技术全部采用主流开源技术框架，这些技术已经被广泛应用于各种软件系统中，有着成熟度高、开发快，使用灵活、安全且易于扩展，并且自主可控等诸多优秀特性。

表：开源技术栈表

4.6. 应用服务简介

4.6.1. 终端接入模块

终端接入服务（iL-service）是基于JAVA语言开发，实现一套高性能、高可靠、易拓展、易维护、易二次开发的平台。支持多通讯协议转换，支持多报文转换，支持流程配置，支持REDIS内存数据库、支持日交易量1000万笔以上，支持线性横向扩展。主要将终端业务系统的数据转换到银行其他系统。

4.6.2. 联机交易模块

联机交易服务（iXT-service）是通过国内先进银行最佳实践，结合银行现阶段业务状况及前瞻性的业务需求，以先进的业务模型和应用技术架构为基础,构建具备技术先进性、前瞻性的网点统一渠道服务平台，实现对网点自助设备、移动柜面和网点柜面服务渠道的服务功能支撑和统一管理，实现线上服务、线下服务各渠道间的互联互通、数据共享、服务联动和统一管理能力。
联机交易服务是基于JAVA语言开发，采用分布式系统架构，实现一套高性能、高可靠、易拓展、易维护、易二次开发的平台。支持多通讯协议，支持多报文，支持流程配置，支持REDIS内存数据库、支持日交易量1000万笔以上，支持线性横向扩展；系统性能并发处理能力高于800TPS。
联机交易服务支持银行管理交易、金融类交易、非金融类交易、支持国密、支持银联模型等。

4.6.3. 监控模块

现代技术加速银行业务模式与服务方式的转型升级，但在智能化转型的过程中，银行设备运维难的问题日益凸显。
银行原有设备故障信息反馈速度慢，故障维护时效长。一方面需要支行现场确认设备状态并逐级反馈上级管理部门。另一方面，原有针对自助设备的监控系统，不能覆盖无标准通信接口的设备，且接口属于总行管控也无法提供给第三方，分行也没有修改或开发新功能的变更权限，管理维护十分不便。
银行希望将各网点可接入网络的实装设备运行开机情况信息收集，提升设备维护效率。希望通过一套软件系统，管理部门可实时查看所有网点设备运行及交易流量。

4.6.4. 运营管理模块

运营管理模块，是采用微服务架构，围绕对设备的智能化运营与管理的新平台，采用契合当下流行的技术线路，维护成本低，开发效率高，致力于降低对设备管理、运营及维护的成本，提高管理，运营及维护的效率。
其核心功能集成有：远程控制，远程批量对设备升级，智能化报表分析，终端交易的高准确性与实时性监控，终端设备各模块状态的高准确性与实时性的监控，设备整个生命周期的完善管理等功能，其辅助功能集成有：国际化，定时任务调度等。

4.6.5. 大堂Pad模块

为使大堂经理真正走出营业室，发挥大堂经理的厅堂营销作用，科技部在省联社帮助下，顺利上线厅堂管理系统，为每位大堂经理配备了厅堂PAD,进行柜外业务授权。
柜员直接在终端上选择柜外授权，大堂经理就会在厅堂PAD上收到要授权的信息。大堂经理在PAD上对授权内容进行查看，核对。大堂经理在柜台外面就可以进行授权，方便快捷。能让大堂经理充分履行职责，在营业厅开展授权，与客户面对面交流，沟通，营销我行业务。
后续随着智慧柜员机、智能排队机等设备上线，将真正发挥智慧厅堂的作用，以服务和营销为导向，提供网点运营的集中监控、客户线上预约和业务营销的有效支持，提升效率，改善客户体验，提高服务水平，为网点转型和营销转型打下良好的基础，逐步建立开放融合的智慧型服务网点。

4.6.6. 任务中心模块

任务中心使用调度程序的系统时钟来确定何时启动任务。要从任务中心中选择调度程序系统，在调度程序系统字段中选择一个系统。当您登录至任务中心时，就会登录至选择的调度程序。每次启动任务中心时都必须登录。要授予或撤销对一个任务的特权，您必须是该任务的创建者。要创建、改变或删除任务，必须对该任务有写权限。要运行任务，必须对该任务有运行权限。
从任务中心中主要完成的功能有：任务策略配置、任务执行、数据迁移、数据备份、数据统计、命令下发等。

4.6.7. 移动运维模块

随着移动网络和应用终端的发展，针对网络及业务的维护工作，结合电子运维系统的功能应用，逐步提供相应的功能模块操作，实现移动端与PC端业务流的交互，使得运维工作人员能对现场维护工作进行实时反馈处理，提高工作效率。

4.7. 服务划分

表：服务划分表

5. 架构设计

5.1. 应用架构

交易接口标准必须按照不同业务接口的报文标准制定，采用TCP和HTTP通信协议。应用架构遵循高内聚，低耦合的设计原则，借鉴使用微服务设计12要素，整体结构清晰，架构先进。服务间通过标准接口调用，服务中使用集群化服务，对外提供高可用、可扩展的服务支撑，每个应用服务均使用集群或主备结构，彻底避免服务单点问题。

图：系统应用架构图
系统整体的应用架构主要包括：
l 服务接口：系统对外提供服务以及调用外部服务统一管理，提供HTTP、TCP通讯协议，对报文进行解析。
l 注册/配置中心：为服务提供不同环境的配置管理和服务注册发现服务。
l 管理平台：web用户操作界面，包括参数、组织架构操作管理功能。
l 系统监控：系统性能状态指标监控，服务性能指标监控。
l 日志监控：服务日志采集监控，日志查看。
l 权限管理：机构、岗位、角色、用户多级管理，灵活配置。

5.2. 技术架构

5.2.1. 系统架构图

图：系统架构图
1. F5负载：对业务请求接口请求提供服务负载功能。
2. 网关集群：对核心系统应用服务，管理访问web服务，提供接口路由，限流和应用服务负载等能力。服务网关为独立的api server服务，由注册中心统一注册管理服务有效性以及发现内网服务。
3. 业务服务集群：业务核心应用服务，按业务操作场景划分多个服务，业务服务均通过无状态的 API Server提供接口服务能力，通过多应用服务实现对单一类型服务的负载均衡和高可用能力。通过web管理平台提供业务管理操作能力。
4. 监控服务：采用Prometheus Grafana和springboot-admin的监控服务方案，对服务器系统指标和应用服务指标进行监控和告警。使用ELK对日志进行采集，ELK通过采集系统日志实时监控系统日志信息。
5. 注册中心：采用Nacos作为应用服务的配置中心和注册中心，管理系统中的所有配置信息和服务注册与服务发现，采用无中心化的服务集群模式部署模式。
6. 数据存储：包括核心业务数据库，采用MySQL高可用结构存储。ElasticSearch存储业务系统日志数据。为Kibana的数据分析提供基础日志数据。NAS为文件共享存储，与外部系统提供文件共享存储和文件交换功能。

5.2.2. 网络部署图

图：网络部署图
上图为系统服务网络部署结构图。服务节点数量为示例的服务器部署数量，可按实际情况增减。其中：
1. 服务网关F5：为内部网关负载，主备结构；
2. 网关服务集群：3台，独立应用服务部署，高可用负载结构；
3. 业务服务：9台，独立应用部署，高可用负载结构；
4. 注册中心集群：3台，环形集群部署，高可用主备结构，可保证1台可用则整体集群可用；
5. 日志服务：3台，包含es3个节点，Logstash服务3个，kibana管理服务2个，1份数据备份，2个节点可用，则整体集群可用；
6. 服务监控：2台，主备结构，部署Prometheus 监控和存储，以及Grafana的管理监控管理；
7. 后管服务：2台，web管理，主备结构；
8. 文件管理服务：2台，主备结构；
9. MySQL数据库：3台，数据库高可用结构；

5.2.3. 同城双活部署结构图

图：同城双活部署结构图
1. 同城双活：通过F5对同城双机房网关实现跨机房负载双活，其中机房A为主机房承担90%以上的请求流量；
2. 跨机房数据交互：B机房的服务通过光纤向A机房实现数据库交互，B机房服务只连A机房数据库；
3. 应用服务：B机房应用服务全部连主机房A的数据库，实现数据交互；
4. 注册中心：双机房有独立的注册中心，相互之间不干扰，独立为单独各种机房提供服务使用；
5. 数据库主备：B机房数据库作为从库同步备份A机房数据库数据，B机房不做业务库访问；
6. 双机房服务监控：监控管控通过F5提供跨机房的高可用web访问，通过光纤网络实现2个机房的整体服务监控集群部署；
7. 日志服务采集：管理端通过F5提供web高可用访问，通过光纤网络，实现双机房日志的双份采集，双份存储监控；
8. 后管服务高可用：通过F5实现跨机房的高可用web服务；系统架构图

6. 平台设计

6.1. 基础平台设计

6.1.1. 网关系统

(一) 功能目标
iBank4系统的网关子系统主要是作为系统对外和对内的连接工作。对外通过负载均衡设备对接外部服务、设备等，负载多个系统的业务请求对接。对内负责将请求发送到系统的各个业务子系统。
(二) 实现技术
l iBank4系统的网关子系统基于Spring开源的Spring cloud gateway实现。
l 服务限流通过集成阿里的开源Sentinel组件。
(三) 服务功能
1) 路由
路由是网关系统最基本最重要的功能。负责将请求根据路径规则路由到各业务子系统处理业务。
2) 负载均衡
iBank4系统的各业务服务部署多个实例，统一注册到Nacos注册中心，网关服务也注册到nacos中，通过通过Spring Cloud微服务组件Ribbon和RestTemplate实现多服务实例间的负载均衡调用。
3) 限流
限流是网关系统的一个重要功能，当外部请求速度大于内部服务处理的速度时，网关系统应该触发限流限制，防止内部业务服务被压垮。网关系统实现限流是通过阿里巴巴开源的sentinel组件实现，可以通过QPS流量作为限流标准。

6.1.2. 序列号模块

(一) 功能目标
iBank4系统中包含多种序号的使用，本模块主要是说明系统中各种需要的生成和使用说明。比如系统主键，数据库表自增ID，用户号等。
(二) 序列号设计
iBank4系统中数据库自增ID以及各种流水号需要保证全局唯一性，故其生成方式采用分布式ID生成策略的雪花算法生成18-20位长度的数字字符串。

6.1.3. 注册配置中心

(一) 功能目标
iBank4系统采用Spring Cloud分布式服务框架中，注册中心与配置中心使用阿里开源的Nacos系统。Nacos系统是配置中心和注册中心一体化，通过控制台针对注册中心服务管理和配置中心管理进行可视化操作。使用Nacos既易运维，又可以得到更强大的功能。
(二) 服务结构
1) 系统架构

l 多个Nacos节点组成集群，通过一致性协议来实现高可用。
l 通过Nacos Console可视化管理配置信息，包括查看历史版本信息。
2) 逻辑架构

(三) 高可用设计
Nacos高可用是三个服务相互注册和同步实现，其中一个服务不可用后，另外两个服务也同步备份了失效服务的数据，保证服务的可用性和数据一直性。

6.1.4. 文件管理服务

(一) 功能目标
系统运行过程中，需要使用到很多文件进行业务的流转，同时系统本身也会生成相应的业务文件，且项目模块众多，所以会涉及到很多文件的存放问题，为了使各类文件有序存放，规范化管理，抽取文件存储成单独一个文件服务，为业务系统提供文件存取功能。
(二) 技术实现
iBank4系统文件服务的实现是基于支持S3存储协议的Minio对象存储的云原生应用服务，非常适合存储大容量非结构化的数据，例如图片、视频、日志文件、备份数据和容器/虚拟机镜像等，Minio可以通过简单的复制即可实现水平扩展。
(三) 备份机制
过控制部署多节点Minio应用程序，让Minio使用分布式的纠删码功能，可以在集群中的某结点或某些结点出现故障后，剩下的集群还能保持完整的数据不间断对外服务。

6.1.5. 日志服务

(一) 功能目标
iBank4系统中日志服务系统主要是收集和处理业务系统产生的日志，技术上采用主流的ELKF组合，即Elasticsearch、Logstash、Kibana、FileBeat，ELKF为当前主流的分布式日志服务典型的解决方案，将处理过的日志存储到Elasticsearch数据库，并通过kibana进行可视化日志展示。
(一) 服务结构

iBank4系统的各个业务子系统服务通过logback日志组件写日志信息到日志文件中，通过日志收集组件filebeat读取logback日志文件数据同步到日志处理组件logstash，日志处理组件接收到通过的日志内容后按配置的日志处理规则进行日志内容格式化处理，并将处理后的日志内容保存到Elasticsearch数据库中。用户可以通过日志展示组件kibana可视化查看或是通过Elasticsearch数据库提供的API查询。
(二) 数据存储
日志服务的数据存储采用开源分布式存储搜索引擎数据库Elasticsearch，将收集处理后的日志索引并存储起来，方便业务方检索查询。同时可以通过Kibana对日志数据设置失效时间，以减少数据堆积占满磁盘空间。

6.1.6. 监控系统

(一) 功能目标
通过整体监控来预防并快速定位问题从而解决问题，把监控体系穿插在开发、测试、灰度、生产等各个环节，并能保持配置简单，可定制化高，组件间耦合度低，展示化程度高，通知信息完善，易扩展、快速部署，数据多维度等等优势的情况下，完成基础设施的监控，关键业务流程的数据监控（在业务层做埋点），系统应用的的关键数据监控。
(二) 技术方案
采用Spring Boot- Admin成熟的监控方案。通过集成监控客户端Spring Boot Actuator，通过http协议上送监控数据，信息包含：应用状态、内存、线程、堆栈等，比较全面的监控了Spring Boot应用的整个生命周期。
(三) 监控告警
Spring Boot Admin监控服务的告警功能可以对接邮件、短信等告警渠道，在监控到服务上下线、内存使用情况等等方面可以根据要求设置告警情况，实时监控服务的健康状态。
(四) 监控指标

6.2. 数据库设计

6.2.1. 数据库表设计原则

(一) 索引原则
l 唯一索引：除了主表自然自增主键之外，每个表的唯一业务主键字段建立唯一索引，例如账户表中的账户号，客户表中的客户号。
l 非唯一索引：在业务流水表，账户交易表中，除了交易流水号为唯一索引外，还需根据业务查询要求，添加业务非唯一索引，例如账户号。
l 分区索引：当数据表存储超过2G的存储量时，建立分区索引，在本系统中，主要对交易账户表做分区，按时间做分区。
l 组合索引：基于各业务实际情况创建字段组合索引，组合字段数不要超过3个字段。
l 外键索引：本系统不做外键关联，无外键索引。
(二) 主键原则
l 所有表都必须包含主键。
l 自增主键：每个表都包含一列自增主键，无业务含义，自增主键在数据库中以序列来实现。
l 业务主键：每一个业务表必须包含唯一的业务主键，业务主键有系统发号器生成，保证唯一，且对交易或事件类型表的主键由按时间递增关系。
(三) 数据类型原则
l 固定长度字符：明确固定长度字符字段使用CHAR类型
l 金额：使用DECIMAL带小数位类型
l 业务字段中禁止使用CLOB，BLOB类型
l 字符串类型使用VARCHAR，每个字符使用两个字节存储（字符集），VARCHAR只对汉字和全角等字符占两字节，数字，英文字符等都是一个字节
常用数据类型：

表：常用数据类型表
(四) 分区原则
l 数据库单表数据量超过1000万时，需要对表进行分区
l 单表数量存储大于2G事，需要对表进行分区
(五) 数据字段原则
创建数据表的字段应该遵循如下原则：
l 表字段设计不严格遵循范式原则，在保证数据一致的情况下，允许不同表的字段冗余，减少关联表查询，提高处理速度
l 避免业务大宽表，除非特殊业务表
l 表的每个字段都要有注释，说明其含义
l 参数表应该包含如下字段
n 所有参数表主键均为系统产生的ID，类型为bigint型
n 所有参数表均包含状态字段，定义在create_time之前，定义为（_status,char(1),0=失效，1=有效）
n 所有参数表均包含描述字段，定义为（description,varchar(60)
l 所有表中均应包含以下4个字段

表：共用字段表
l 常用字段：

6.2.2. 命名规范

(一) 命名约定
l 本约定是指对数据库、数据库对象如表、字段、索引、序列、存储过程等的命名约定；
l 命名使用富有意义的英文词汇，尽量避免使用缩写，禁止使用汉语拼音。多个单词组成，中间以下划线分割，所有字符大写；
l 避免使用MySql的保留字；
l 数据库名称建议长度为5-10个字符，数据库表名称和字段名称最大长度为30字符，数据表名称建议25个字符以内(为表的备份，索引等预留5个字符)；
l 命名只能使用英文字母，数字和下划线，以字母开始，两个下划线中间不能是纯数字;
l 各表内相同字段名称保持一致，单词缩写保持一致，子系统和模块缩写保持一致；
l 子系统和模块缩写使用2-4个字符；
(二) 表命名规则
表命名规则为XX_YY_TABLENAME。XX表示子系统名称，YY为子模块名称（可以没有），TABLENAME为表含义。
TABLENAME规则如下：
l 使用英文单词或词组作为表名，不能使用汉语拼音
l 使用名词和名词短语作为表名。
l 不能使用复数
相同表内容，按渠道拆分的，渠道放在后面，如果是遇到统一的后缀_LOG或是_HISTORY,需要放到统一后缀的前面
(三) 字段命名规则
l 字段命名规则为英文字母，数字和下划线组成，单词之间使用下划线分割
l 首字母必须是英文字母
(四) 索引命名规则
索引命名规则为表名称+字段名称+后缀” _IDX”,多单词组成的column name，取前几个单词首字母，加末单词组成column_name。每表必须包含一个唯一索引，同时每索引列中字段长度总和不得超过1000。
示例如下：
TST_SAMPLE表MEMBER_ID上的索引: TST_SAMPLE_MID_IDX
TST_SAMPLE表TITILE上的索引: TST_SAMPLE_TITILE_IDX；
(五) 主键命名规则
l 主键命名规则为表名称加后缀_PK；
l 示例如：TST_SAMPLE表的主键: TST_SAMPLE_PK

6.2.3. 数据库开发

(一) 数据库划分
系统使用MySQL数据库，按业务来划分数据库分为：业务数据库，服务和配置数据库。
按数据库实例划分：业务数据库单独一个数据库实例，其他数据库公共一个数据库实例。
(二) 持久层框架
系统业务中与数据交互的持久框架使用Mybatis，Mybatis具有开发效率高，执行速度快，便于开发二次扩展的特点，可通过手动编写sql语句，可以完成业务逻辑复杂处理和按需获取数据表字段提高查询效率。
(三) 开发标准
l 通过表结构生成model和Mapper代码。代码生成使用maven插件org.mybatis.generator 来自动生成自动生成。
l 使用Mybatis的注解方式提供Mapper的操作映射，禁止生成mybatis的xml配置映射文件。
l 禁止开发在自动生成的代码上做修改和增加新的逻辑代码。
l 为了和自动生成的代码分离，我们手动编写的sql语句全部放在一个自定义的Mapper类中，防止数据库表结构发生变化后重新生成代码会删除我们自己手动编写的sql语句。
l 新增数据时create_time,update_time必须赋值当前时间，修改时只更新update_time。创建表时必须设置create_time和update_time的默认值为数据库的系统时间:now()
l update_by为创建人，后管服务发起的请求记录柜当前操作员编号。

6.3. 接口设计

6.3.1. 后管接口设计

业务后台管理子系统采用前后端分离架构，前端页面调用后台提供的基于REST设计风格和JSON格式定义的http协议接口。REST是一种软件架构风格、设计风格，提供了一组设计原则和约束条件。基于这个风格设计的接口可以更简洁，更有层次，更易于实现缓存等机制，可参考Restful接口基本规范。
后台管理子系统接口采用统一的json结构，包含返回码，返回码描述信息，返回数据信息三个一级节点信息。返回数据信息主要包含以下几种类型信息：数据对象信息、数据对象列表信息、固定的分页结构对象信息，分页结构对象主要包含当前页数，每页记录条数，总记录条数，总页数和当前页数据对象列表。

6.3.2. Restful接口说明

Restful是基于HTTP协议+JSON报文结构的API接口设计方法。通常用于服务间相互调用通讯。使用HTTP协议不同的METHOD方法实现对数据的增删改查操作。采用RESTFul架构风格的API接口可以为开发者带来简单性，可伸缩性和松耦合三方面的优点。
REST主要有五个操作动作，每个操作动作针对系统中不懂的操作实现，具体如下：
l GET ：从服务器检索特定资源，或资源列表。主要是针对系统的查询操作。
l POST ：在服务器上创建一个新的资源。主要是针对系统中重新新对象和数据操作。
l PUT ：更新服务器上的资源，提供整个资源。主要是针对系统中修改操作。
l DELETE ：从服务器删除资源。主要是针对系统中删除操作。
在Restful架构中，每个URL代表一种资源（resource），路径名称以名词命名，名词往往与数据库的表格名对应。
路径中url以 /v2/api开头，第三段以业务聚合根命名如/platform、/admin等，必须符合restful风格。
路径中包含参数的规则为只能是ID值，分页参数等字幕数字类的内容，最多不要超过三个参数，多余的参数放到request中。

6.3.3. ISO8583接口规范

8583协议是基于ISO8583报文国际标准的包格式的通讯协议，8583包最多由128个字段域组成，每个域都有统一的规定，并有定长与变长之分。8583包前面一段为位图，它是打包解包确定字段域的关键代替。信用卡发卡系统主要使用自定义8583协议接口，银联85883协议接口和VISA8583协议接口。
自定义8583协议报文参照中国银联《银联卡联网联合技术规范》制定本接口规范联机交易通信方式和信息安全处理参见《第1部分 交易处理说明》。

6.4. 缓存设计

6.4.1. 缓存原则

l 由于iBank4系统为分布式架构，缓存服务需提供分布式缓存能力。
l 数据缓存划分为2类：第一类为全局缓存，当前系统中缓存的数据，为当前系统中的所有处理线程提供共享缓存数据，例如认证授权数据、权限数据等；第二类为会话缓存数据，为当前业务请求，当前线程中存放的缓存数据。

6.4.2. 全局缓存方案

l 缓存实现：本系统全局缓存技术实现使用Redis官方Cluster部署方案作为缓存实现。缓存采用独立与应用的缓存服务器部署，不依赖业务服务。
l 缓存生命周期：全局缓存为全部服务提供服务，缓存数据按业务模块设置对应的过期时间，防止缓存数据无限增长。
l 缓存更新：当业务服务更新相应的数据后，需同步删除缓存数据，保持数据一致性。在保持数据一致性时，需使用技术手段保证消息队列或者事务表确保操作的一致性。
l 缓存时效：缓存数据过期时间的设置需根据具体业务进行设置，缓存的时效与业务的生命周期应当一致。

6.4.3. 会话缓存方案

会话缓存用于当前请求，一个线程处理内部的临时缓存。当前线程的缓存数据，供当前线程上下文使用的缓存数据。
l 缓存实现：会话缓存直接使用Java集合类缓存数据，对在相同同一线程内的临时缓存数据，跨方法调用则将缓存存放在ThreadLocal中作为相同线程不同方法上下文的时候使用。
l 缓存的生命周期：会话缓存数据仅保存在当前线程中，处理完成后，随即释放清除，生命周期短，不跨线程使用。
l 缓存的更新：会话缓存不会再对缓存数据进行更新。
l 缓存时效：跟随当前请求周期，请求结束则缓存清除。

6.5. 权限设计

6.5.1. 系统权限设计原则

系统权限设计以最小授权为原则，从两方面说明：一是权限分配遵守最小授权原则，二是系统业务权限按最小粒度设置划分管理。
权限分配就是按角色和岗位实际需要的权限划分，不同角色和岗位都可以根据具体需求分配不同的权限。
l 系统权限按角色职责划分权限，权限划分遵循岗位制衡原则。
l 不同角色分配权限可以根据具体的使用情况划分，而不是相同角色下的用户权限相同。比如: 不同部门管理员应该有当前部门使用的权限，不使用的权限不分配。
l 不同用户可以具体使用情况单独赋予特殊的权限
系统业务权限按最小粒度设置划分管理是系统业务权限按菜单访问权限，页面访问权限，页面功能权限三方面进行划分管理。给用户分配权限也是按最小粒度分配，比如一个操作画面有查询和操作权限，如果某个岗位只有查询权限，那这个岗位下的用户将无法使用操作权限。

6.5.2. 对接统一用户平台

若行里有统一用户平台，iBank4系统的使用用户不在独立创建，使用银行内部统一用户平台的用户。权限管理按银行提供的接口对接内部系统统一用户平台。

6.5.3. 登录授权

iBank4系统用户使用行内统一用户平台用户，用户登录时账号密码检查通过行内系统调用统一用户平台接口验证。统一用户平台返回正常结果后，应用权限管理系统再根据当前用户信息判断用户拥有的权限，根据权限进入相应系统。
1) 用户访问权限管理系统进入登录页面
2) 用户输入账号密码，提交登录
3) 权限管理系统后台接收到用户账号和加密的密码后，通过行内ESB系统访问统一用户平台做登录鉴权
4) 鉴权通过获取token，调用验证token接口
5) Token验证通过，调用获取用户信息接口
6) 通过获取的统一用户平台用户信息，应用权限管理系统验证用户信息是否存在，权限检查，判断用户角色
7) 根据用户角色跳转到相应系统。

6.5.4. 服务鉴权

iBank4系统后台管理平台采用前后端分离架构，前端页面和业务实现分系统部署。后管平台的服务操作全部发送到前端系统，由前端系统统一做拦截和服务鉴权，调用权限管理系统进行服务鉴权，通过以后在调用业务系统做业务处理，业务处理结果返回给前端页面展示。
针对需要权限才能访问的接口，在通过身份验证后，还需校验用户是否具有该接口的访问权限，在后台管理系统分配好权限后，把权限数据放到redis缓存，后续的权限校验会从redis查询对应的权限进行验证

6.5.5. 权限管理

iBank4系统的权限管理子系统中有权限设置和权限分配两部分。其中超级管理员负责权限设置和给部门管理员分配权限和部门管理员负责给用户分配权限。

6.5.6. 权限配置

权限管理系统的权限配置包含三部分内容，分别是业务权限菜单，页面接口权限和系统业务参数。其中业务权限菜单和页面接口权限配置可以通过导入配置文件和系统页面两种方式配置，系统业务参数根据业务系统需求单独在系统配置。
权限管理系统的通过系统页面配置业务系统菜单和页面接口权限，业务系统菜单以树形结构展示，可以配置多个层级的系统菜单。每个系统菜单的叶子节点对应业务系统一个功能画面。每个叶子节点可以设置菜单项配置比如菜单名称，访问地址等。 还要配置菜单对应的功能画面的接口信息，比如查询，修改，保存等接口信息。
权限管理系统配置业务系统参数通过系统页面配置实现。系统超级管理员有业务系统参数定义权限，主要定义业务系统参数名称，类型，默认值等信息。部门管理员根据岗位和岗位用户配置具体的业务系统参数值。

6.5.7. 权限分配

权限管理系统针对业务系统权限和业务系统参数分配分为两个阶段实现。第一个阶段为系统超级管理员给部门管理员分配业务系统权限和系统系统参数，系统超级管理员在创建完部门，分配好部门管理员后，应该给部门初始化业务系统权限和业务系统参数，把业务系统配置的系统菜单和页面接口权限按部门的实际使用情况分配给部门。第二个阶段为部门管理员在创建岗位时给岗位分配部门拥有的系统权限和业务系统参数。部门管理员还可以单独给岗位下的具体某个成员添加特殊权限项和调整业务系统参数。

6.5.8. 访问审计

权限管理系统记录两类日志提供查询，第一种日志为用户登录日志，来查看那个用户在什么时间，登录那个系统，日志还包含：用户登录系统的IP地址，登录结果等信息。第二种日志为用户访问系统业务功能的服务鉴权日志，记录服务鉴权结果和服务鉴权数据。

6.6. 访问控制

6.6.1. 访问控制模型三要素

l 主体（Subject) 指主动对其它实体施加动作的实体
l 客体 (Object) 是被动接受其他实体访问的实体
l 控制策略 (Policy) 为主体对客体的操作行为和约束条件

6.6.2. 基于角色的访问控制（RBAC）

管理员定义一系列角色（roles）并把它们赋予主体。系统进程和普通用户可能有不同的角色。设置对象为某个类型，主体具有相应的角色就可以访问它。这样把管理员从定义每个用户的许可权限的繁冗工作中解放出来。
基于角色的访问控制 (RBAC, Role Based Access Control) 在用户和权限之间引入了 “角色（Role）” 的概念，角色解耦了用户和权限之间的关系。
角色和组的主要区别：
组是用户的集合
角色是权限的集合
角色 / 权限之间的变化比组 / 用户关系之间的变化相对要慢得多，减小了授权管理的复杂性
基于角色的访问控制模型 RBAC，有时成为基于规则的基于角色的访问控制（Rule-Based Role-Based Access Control，RB-RBAC）。它包含了根据主体的属性和策略定义的规则动态地赋予主体角色的机制。例如，你是一个网络中的主体，你想访问另一个网络中的对象。这个网络在定义好了访问列表的路由器的另一端。路由器根据你的网络地址或协议，赋予你某个角色，这决定了你是否被授权访问。

6.6.3. 权限控制的具体方法

n 服务调用鉴权
所有服务调用都需经过后端前置服务的鉴权操作。
n 操作权限管理支持的颗粒度
l 接口或菜单访问权限控制
l 工作操作权限控制：如查询、修改、删除等
l 数据控制权限。可以从法人不同、机构、用户角色、用户等级不同的维度控制数据的类型、数据的要素等访问
n 角色分配的控制
支持不同角色的互斥关系。存在互斥关系的不同角色不允许添加给同一用户组
n 角色启用的控制
用户管理员创建不同的用户组、分配角色后，需要经过审核后才能正式启用

6.6.4. 二次认证支持

可以基于用户属性、用户访问时间、操作类型等判定用户目标操作或调用请求触发进行二次认证。只有通过二次认证后才进行后续处理。
二次认证的方式可支持：用户+口令、手机验证码、动态令牌、人脸识别。
二次认证时的方式必须与初次认证的方式不同。

6.6.5. 敏感标记支持

敏感标记主要分为两类：
l 敏感操作行为
l 敏感数据
n 敏感操作的控制
支持定义某些操作或接口调用为敏感操作。可以维护具体的操作等需要哪种角色或岗位类型以后的才允许直接操作，部分允许操作的用户角色触发这类敏感操作时，自动触发授权申请，在授权审核后在特定时间范围内才放行操作请求。
n 敏感数据的控制
支持对敏感数据表、敏感数据要素定义为敏感数据。涉及到敏感数据的定义默认放行的用户角色、用户等级。定义需授权后操作的用户角色等。

6.6.6. 异常会话控制管理

l 用户身份验证异常控制
支持配置用户身份验证最多连续尝试的次数。在超过配置的次数后，此用户自动冻结指定的时长。
在自动解冻后常规登录验证通过后，支持配置二次认证。
l 异常次数进行用户身份验证的控制
在规定时长内，发起超过指定次数的用户将被系统硬冻结。此类用户解冻需要走申请流程有用户管理员进行解冻
l 用户会话的控制
在用户连续无访问、操作的超过指定的时间长，系统自动清理用户已验证通过等会话信息。用户重新操作需要先进行验证操作。

6.6.7. 黑名单支持

系统可以支持配置黑名单现在用户等访问或操作请求。黑名单可以支持用户标识、访问渠道、访问地址等维护限制可访问性。

6.6.8. 技术用户与业务用户分离机制

n 初始化的系统管理员的控制
系统支持的用户主要分为两类：技术用户、业务用户。其中技术用户分为两种：（1）系统初始化的系统管理员；（2）系统交接后客户系统管理员。
系统初始化管理员（1）只在系统初始上线使用。主要是用来初始化必须的系统基础数据。在启用了客户实际的系统管理员（2）后，就被永久禁用。后续所有的技术类维护只能由客户的系统管理员完成。
n 技术用户与业务用户的控制分离
技术用户主要为不同等级的系统管理员。此类管理员只有针对系统管理类的相关功能、操作等方面进行权限配置。自动无法对业务功能、业务操作、业务数据进行权限配置。
业务相关的权限分配只能由不同级别的业务管理员进行操作。

6.7. 日志设计

6.7.1. 实现方案

iBank4系统各个子系统统一使用slf4j+Logback框架记录日志。在logback的配置文件中配置日志输出到控制台和文件，输出方式为异步输出，提高系统性能，避免日志输出影响系统吞吐能力。在日志汇总管理方面，采用ELK组合实现所有微服务日志的汇总管理，方便后续运维。

6.7.2. 日志规范

系统输出的日志按使用类别可以分为两大类，一类是系统日志主要是为了记录系统的操作行为和异常信息，另外一类是数据日志主要是记录系统的业务数据信息。不同的日志类型记录的日志内容和日志格式，日志级别也有所不同。主要日志规范如下：
1. 系统日志包含如下内容：时间，日志级别，线程，类路径，方法名称，行号，内容
2. 数据日志应该包含如下内容：时间，日志内容
3. 数据日志按数据类型单独记录到独立的文件中
4. 所有日志文件至少保存 15 天，因为有些异常具备以“周”为频次发生的特点。网络运行状态、安全相关信息、系统监测、管理后台操作、用户敏感操作需要留存相关的网络日志不少于 6 个月。

6.7.3. 日志归档

iBank4系统为了方便查看日志我们对日志文件做如下归档要求：
1. 在生产环境中业务日志和错误日志不向控制台输出，控制台日志只输出服务启动和停止日志。控制台日志跟随服务上线发布代码备份策略来归档保存控制台日志。
2. 业务日志和数据日志文件按时间和大小归档，按天归档日志文件，每个日志文件最大不能超过300M。
3. 归档日志的目录在日志根目录的backup目录下，并且进行gzip压缩归档
4. 归档日志的保留时间为6个月

6.8. 安全设计

6.8.1. 通讯及访问安全

iBank4系统服务内所有的对外接口访问全部通过服务网关。各个子系统的IP和端口号在网络防火墙端预先设置通讯白名单，非预先设定应用的服务端口和IP均不可访问和开通。
只有应用服务和运维终端具备访问数据库的权限和能力，其他业务终端和非业务服务均禁止直接访问业务数据库。
所有的运维管理系统需要通过专属的跳板机登录访问。业务管理终端仅可内网业务管理操作人员访问。
iBank4平台采用正则表达式的方式统一封装了密码校验规则，密码需具有大小写字母、数字、特殊字符，长度达到8位及以上的要求。

6.8.2. 文件上传安全

iBank4管理平台端上传文件遵循文件类型最小原则：
l 上传文件限定上传文件类型
l 限定文件大小，不超过设定文件容量
l 文件路径预先设置，统一将上传文件保存设定目录下
l 过滤文件名称中敏感字符和非法字符，将上传文件带有时间戳存放
l 上次文件目录只有读写权限，禁止有执行权限。

6.8.3. 日志安全

应用系统日志存在在指定的目录下，按运维规范归档存储，业务应用日志保存不少于180天，通常保存6个月内业务日志。
所有日志信息中不会出现用户敏感信息，如身份证号，密码，卡信息，身份信息，以及完整的交易信息，所有的敏感信息需脱敏处理。

6.8.4. 数据安全

系统的数据安全划分为3部分，第一部分为配置数据安全，第二部分为文件数据安全，第三部分是数据库安全。
系统配置数据通过Nacos配置中心统一提供，配置数据禁止手工在系统应用中修改，统一在注册配置中心维护。
文件数据全部统一放在文件服务器上，只用应用服务器设定客户权限方可访问。业务系统只能通过文件管理服务对文件进行访问。
数据库数据通过MySQL应用服务器将数据库数据独立存储，通过数据库跨机房的备份保证数据的分布式安全。
在数据库存储上，将业务数据库和配置数据库采用不同的数据库应用实例独立提供服务。对访问权限独立分配用户管控。

6.8.5. 敏感信息管控

l 配置文件信息不明文保存用户名和用户密码，全部加密存储；
l 数据库中的用户敏感信息全部加密保存，密码信息采用不可逆加密；
l 密码禁止使用简单可撞库的作为系统密码和应用访问密码，必须包含大小写字母和数字，密码长度不小于8位；
l 应用系统禁止通过HTTP请求和页面端可下载应用系统的配置文件和系统文件；

6.8.6. SQL注入防范

l 在HttpServletRequest中使用修饰者模式封装对Request的参数值进行过滤，过滤敏感的SQL保留关键字；
l 在使用自定义的Mybatis参数匹配时，采用类似PreparedStatement参数的形式阻止SQL注入。

6.8.7. 跨站点脚本攻击防范

l 在HttpServletRequest中使用修饰者模式封装对Request的参数值进行过滤，过滤单引号，双引号，<，>，script，&等关键字，做转义处理阻止跨站点脚本注入；

6.8.8. 外部脚本执行漏洞

l 在程序中调用RunTime.exec()执行脚本时，执行的脚本只能在规定的配置路径下，不可以是任意的绝对路径脚本；

6.8.9. 代码安全设计

l 系统代码全部经alibaba编码规范插件扫描，解决Blocker和Critical级别代码问题；
l 系统代码经Sonar插件扫描，解决Sonar插件的Blocker和Critical级别的代码问题。

7. 应用服务功能

7.1. 用户管理服务

统一用户管理平台是按全网统一规划用户信息管理规则，建立统一用户信息管理机制，将分散在各业务系统用户信息进行紧密的整合，建立全网唯一的可信用户信息权威源，并为各业务系统提供支持与服务，从而形成一套高效、可扩展、适应性强的人员信息使用与管理平台，以满足银行用户集中管理、分布式使用的需求。

7.1.1. 机构管理

系统支持以行别为基础的机构管理体系，不同行别间的机构管理模式相对独立，同一行别内的机构可灵活设置管理级别和业务权限。机构管理功能与系统内机构柜员管理系统实现无缝对接，由机构柜员管理系统提供机构数据同步功能。系统管理员可通过该页面对组织机构进行管理。对于银行机构，总行下有多个分行，分行下有多个支行或网点。

7.1.2. 用户管理

系统支持按照行别独立实现用户角色管理、状态管理、权限管理等功能。用户管理功能与系统内机构柜员管理系统实现无缝对接，由机构柜员管理系统提供用户数据同步功能。系统管理。

7.1.3. 权限管理

由用户管理和角色管理组成。每个用户可分属一个或多个角色，每个角色级别和数据权限不同，可访问的系统数据模块不同。当用户登录系统时，系统可根据用户的角色权限提供其可访问的数据，权限外的数据将不可访问。

7.1.4. 菜单管理

菜单管理主要对web应用服务的菜单进行配置管理。主要信息有菜单名称*、菜单URL、上级菜单、排列序号、图标。

7.1.5. 数据字典

数据字典管理主要对应用服务中所使用的数据字典的管理。主要信息有编码、编码名称、编码值、是否可用
对数据字典进行新增、修改、删除。

7.1.6. 国际化

国际化管理主要对应用服务中所使用的国际化的管理。主要信息有编码、编码值、国际化（中文、ENGLISH）
对国际化进行新增、修改、删除。

7.1.7. 定时任务

配置系统定时任务，可配置任务执行时间，执行周期，上下线任务，对任务执行状态进行监控，并且能够控制任务的执行等。

7.2. 运营管理服务

专为银行量身订做，能够对银行的所有自助设备，包括ATM、VTM、CDM、CRS、查询机、存折补登机、POS机、非金融类设备等做全面的监控管理，为银行提供高效、快捷、准确的全方位运营管理服务。同时支持多品牌设备运维管理。支持多类终端设备统一运维管。提供多机构终端设备共享运维管理服务。

7.2.1. 终端管理

1) 终端信息
终端新装机、移机、撤机等情况需要在终端管理中对终端情况进行登记管理。涉及的终端信息包括终端基本信息和终端安装信息。
2) 终端品牌
自助设备供应商有多个不同品牌，如 GRGBanking、NCR、Wincor、Diebold、御银、怡化。系统对品牌基本信息进行管理。
3) 终端类型
金融自助终端包括多种不同类型，如ATM、CRS、VTM、STM等， 通过此功能可以定义各种不同的终端类型。
4) 终端型号
不同终端品牌有不同的终端型号，如GRGBanking提供H68N、H22N、P2800、i58等，NCR提供NCR-SelfServ-22e、NCR-SelfServ-25等，系统可对各种不同类型的终端进行管理。在终端型号管理中，需要提前做好终端品牌、终端类型、硬件模块的管理。

7.2.2. 版本升级

1) 升级范围
版本升级负责升级业务版本/平台/后维护升级。
2) 包管理
版本升级分为不同的类型，如：平台升级、业务升级、后维护升级。系统将提供对这些升级包的管理。
3) 创建计划
当需要对一些终端进行升级时，要先创建升级计划。
4) 计划查询
系统提供了对所有计划的查询功能，可以在这里跟踪计划的状态，并且可以管理已经审核的计划。
5) 广告升级
广告升级是推送升级包到V端，V端根据端机信息进行广告主动推送。

7.2.3. 电子流水

电子流水是操作自助终端业务的日志流水文件，由自助设备定时上传至服务器端，系统用户可在系统查看每台自助设备每天的电子流水。

7.2.4. 状态监控

监控为系统的核心模块和功能，保持全面准确的状态监控是系统的关键价值。典型的监控流程是，当终端发生故障时，立即上报故障状态给系统，系统根据状态配置产生对应工单并通知对应人员进行故障处理。
1) 状态上报
自助终端定时发送终端状态报文给到系统。自助终端定时收集终端模块状态并上报给系统，自助终端状态变化时立即把状态上报给系统。终端状态上报后系统能够及时显示终端的模块状态，终端模块发生故障时，系统会根据工单配置产生工单。
2) 模块监控
自助终端收集到模块状态信息后，把信息发送给系统，系统将这些信息展示在系统管理界面上。
3) 钱箱监控
终端收集到状态信息后，发送给运营管理，运营管理将这些信息实时显示在管理界面上 。
4) 工单管理
通过工单管理界面可以查看历史工单信息，当前需要处理的工单，以及图表工单信息。
5) 运维通知
如果设备发生故障或者停止服务，系统发送通知给相关工作人员。
6) 交易监控
当终端有任何交易，通过联机交易服务产生的交易日志流水进行查询。
7) 远程控制
当设备故障时, 管理员可以发送远程指令重启设备。
当设备资源不足时，管理员可以发送指令重启设备。
出现某笔交易有争议，可以通过远程获取当日的流水文件查看交易情况等。
远程控制设备正常服务状态转为暂停服务。
远程控制设备由暂停服务状态转为正常服务。
远程控制设备关机。
远程控制设备重启。
远程控制设备获取文件。
远程控制设备截屏。
远程提取日志文件。

7.2.5. 运维设置

1) 事件管理
事件管理主要是对每一个模块的正常事件和异常事件出现的情况列举,同时配置每一个模块事件对应的终端状态、模块状态、钱箱状态、通讯状态。
2) 工单设置
工单规则主要分为两大类：
一类是记录工单即是不会发送短信或者邮件，配置了工单规则的设备模块故障的时候只会显示在当前工单列表中。
另外一类是故障工单，配置了工单规则的设备模块故障的时候发送短信或者发送邮件提醒管理员，同时可以配置逐级上报的机制（按照设备联系人、分行管理员、支行管理员等逐级上报机制）。
3) 目录设置
目录设置只要是设置客户端等日志文件的路径，设置提取文件的格式。
4) 电子流水设置
电子流水设置的路径是客户端获取电子流水文件在设备上的路径，可以对一组客户端进行设置。
5) 消息模板
消息模板即指发送消息的模板，目前该系统存在默认的两类消息模板：一类是设备故障工单告警,另外一类是设备缺满钞工单告警。

7.2.6. 报表统计

1) 终端开机率
终端开机率统计报表在某一段时间内，对终端正常运转和非正常运转的情况进行统计，主要统计了终端的应工作时间、报停时间、开机率、关机率、维护率等主要信息，按照终端、机构、品牌、维护商分为4个报表，系统用户可以通过该报表及时了解各终端的运转情况。
2) 故障率统计报表
故障率报表是对设备在某一段时间内不同类型的故障时间和比例的统计，主要统计设备的应工作时间、设备总故障时间，故障次数、总故障率、以及各种类型的 故障，按照设备、机构、品牌、服务商、维护人员分为5个子报表，管理人员通过该报表可以及时了解各设备在某段时间内的运转情况。
3) 交易信息统计报表
交易信息统计报表是对设备在一段时间内交易笔数和金额的统计，主要统计 总交易笔数，总交易金额，以及各种交易类型的金额和笔数 ，管理人员通过该报表可以及时了解各设备在某段时间内的交易情况。
4) 设备开机率
设备开机率信息按照设备编号进行分类，显示每一台设备的开机率信息。
5) 机构开机率
机构开机率信息按照设备所在的机构进行分类，通过左侧的机构树查看下属分行，支行的开机率信息。
6) 品牌开机率
品牌开机率信息按照设备的品牌进行分类。
7) 服务商开机率
维护商开机率信息按照设备的维护商进行分类。
8) 维护人员开机率
维护人员开机率信息按照设备的维护人员进行分类。
9) 设备故障率
设备故障率信息按照设备编号进行分类，统计每一台设备的不同类型的故障和次数。
10) 机构故障率
机构故障率信息按照设备所在的机构进行分类，通过左侧的机构树查看下属分行，支行的开机率信息。
11) 品牌故障率
品牌故障率信息按照设备的品牌进行分类。
12) 服务商故障率
维护商故障率信息按照设备的维护商进行分类。
13) 维护人员故障率
维护人员故障率信息按照设备的维护人员进行分类。

7.2.7. 参数管理

维护人员可以通过运营管理服务，远程管理自助终端的参数，控制自助终端的参数值。例如，把自助终端的参数值设置为开或关。系统和终端网络通讯良好的情况下，系统将参数下发至指定的终端，终端实时对参数做出响应。在无法正常通讯的情况下，系统下发参数后无法到达终端。但系统会把参数值保存到数据库，当终端重启或签到时，会一次性从终端接入服务中获取所有的参数，包括此前系统下发的参数值。终端接入服务的参数列表和系统维护的参数列表是一致的。
系统可以下发参数至指定的终端，终端亦会把当前的参数值上传至系统，使得二者的参数值保持一致。当维护员在终端修改参数值，就会触发终端把当前的参数值上传至系统，此时系统会实时更改留存在系统的参数值。

7.2.8. 生命周期管理

“生命周期管理就是综合管理以提高终端设备效率和实现寿命周期费用最佳化为目标，主要从终端设备采购入库、接入系统、对外服务、撤机、迁址、报废、调拨等阶段进行全过程的管理，,采取有效的申请和审批控制手段,形成一个相互联系、相互衔接、相互协调的管理体系。

7.3. 联机交易服务

7.3.1. 平台功能

1) 多通信/报文适配
系统支持各种通信协议适配、报文适配、编码适配、交易路由、报文转换、报文解析、报文组解包等功能，并支持扩充新的协议、格式和规则。
2) 通讯协议支持：
l TCP通讯，包含单工长连接，双工长连接，同步短连接，异步短连接
l HTTP通讯，包含长连接、短连接
l HTTPS通讯，包含长连接、短连接
l WebService通讯
l MQ通讯
3) 报文协议支持：
l 8583/类8583
l 结构体
l XML(目前来看国内需求格式多样，有属性的，有循环节点的)
l Sop
l 分隔符
l JSON
4) 多渠道接入管理功能
系统支持多渠道接入，传统终端要求有设备管理、密钥管理、风控管理，第三方系统要有清算对账。
l 传统ATM、CRS、查询机
l POS，i58(带商户管理、分润、清算)
l VTM、STM(业务量大、有业务分步、业务会签)
l 手机银行、微信银行、网银前置、柜面前置
l 第三方代缴费平台
l 银联、visa、mastcard等卡组织
5) 报文加密认证功能
系统支持各种报文加解密（算法包括MD5、SHA、DES、3DES、AES、RSA、DSA等）、报文校验（MAC校验）、存放保护证书、增加报文签名、验证报文签名功能。
l PIN
l MAC
l 关键域加密
l 全报文加密
l 日志加解密
l 数据库数据加解密
l SSL证书
l 支持国密算法

7.3.2. 业务功能

联机交易处理能满足银行系统内现有及将来各种自助设备、自助渠道，现金类、卡类、中间业务和增值业务的发展要求，系统提供成熟的业务模型和产品或引入符合系统规范的第三方组件和模块，通过业务模块和服务流程的组合，进行产品封装，在系统内全渠道快速实现业务的部署上线。增值业务统一服务平台可以提供和实现的主要业务功能和业务种类包括但不限于如下：

7.4. 移动运维服务

打造线上工单维护跟踪场景，通过从终端运行情况展示，工单的派送提醒，银行工作人员对工单的维修进度的查看以及工单服务结果的评价，同时绑定维修工程师维护管理者，推送工单信息，维修超时上报提示，工单转派。三位一体保证工单发出可追溯，修完有反馈的完整维修工单管控业务流程，有效提高售后维护服务保障体系。

7.5. Pad授权服务

行网点客户经理通过手持pad对于当前银行网点内自助设备提交的开卡、转账、大额存取款，存单开立，存单支取等业务办理进行授权审核。
用户使用自助设备选择办理的业务，在终端根据提示填写相关信息后提交审核，网点客户经理通过pad来对客户提交的信息进行人工审核。

8. 终端运维

8.1. 例行停机方案

iBank4终端业务服务支持计划性和非计划停机操作。
计划性停机，由监控管理系统发出停机命令，终端设备接受停机命令后，判断设备目前状态，如果设备处于交易状态，停机命令会等待中。当设备进入空闲时，停机命令立即生效，设备进入展厅服务状态。
非计划性停机，一般由签到情况、监控设备关键模块状态、操作系统状态、交易数据状态等达到停机条件时，设备会进入展厅服务状态。然后设备定期（默认配置6分钟）进行重新签到、检查关键设备、操作系统、交易状态等，确定是否可进入服务状态。

8.2. 终端升级

iBank4平台（以下简称平台）使用B+C/S架构。其中B/S部分通过请求服务端最新业务版本地址并跳转的方式，确保业务版本为指定版本。C/S部分通过下发版本的方式进行更新。

8.2.1. 模块化升级方案

下发的平台升级包可以全量替换平台的文件，也可以根据厂商、机型等信息动态更新部分文件或者配置文件的部分内容。最终达到不同厂商，不同机型统一使用一个升级包，更新部分模块的功能。

8.2.2. 自动化部署升级方案

平台支持自动化部署脚本，利用现有平台的相关接口，可以通过编写自动化部署升级脚本，完成新旧平台迁移工作。目前已在工商银行、广发银行通过原有系统下发新平台安装包的方式完成了旧平台自动卸载、新平台自动安装、运行环境自动迁移功能，降低了运维人员工作量。

8.2.3. 升级过程

平台在启动时会向服务器发送版本查询请求。如果有新的平台版本，服务端会返回新版本下载地址。平台下载后，自动生成升级脚本，重启。重启后在启动时执行升级脚本，完成升级操作。如果是在运行期间收到升级指令，则会先尝试暂停服务。成功后再进行升级包的下载、生成升级脚本以及重启。同样，重启后在启动时执行升级脚本，完成升级操作。

8.2.4. 升级回滚机制

平台在每一次升级前都会备份当前的版本，并清理之前备份的旧版本。在升级后，如果有发现问题，可以下发版本回滚指令，回滚到升级之前的版本。

8.2.5. 升级过程中对外提供服务情况

目前升级操作最小操作粒度为一台终端，可以实现一个网点多台设备，分不同批次升级，避免同时升级影响客户使用。而且在设备运行期间，可以自动指定凌晨空闲时间进行升级。如果在升级期间有客户进行操作，能够自动等待客户操作完成后再进行升级。

9. 系统运维方案

9.1. 服务管理

服务（接口级）的版本管理机制以及历史变更版本追踪
服务接口版本管理功能支持如下：
1. 支持接口多版本运行
2. 接口消费方可以基于自身的需求、自身的时间限制考虑使用服务方具体的接口版本。综合考虑接口兼容、接口不兼容的场景，不强迫接口消费方同步调整。
3. 支持平台接口具体版本的下线与上线
版本语义化
版本语义化指的是，客户端能够通过查看服务的版本号，就可以知道是否能够与之进行集成。版本格式为：主版本号.次版本号.修订号，版本号递增规则如下：
主版本号：修改后的 API，无法向下兼容。
次版本号：新增了功能，并可向下兼容。
修订号：修正了问题，并可向下兼容。
服务接口版本化管理
服务对外的接口支持多版本。接口版本化通过Annotation标记版本号。接口版本定义标准参照“版本语义化”。
服务提供的接口提供多版本并行运行支持。如客户资料变更接口可能同时存在1.1.0、1.2.0、2.0.0多个版本。

结合版本语义化的规定，接口服务提供方与接口消费方独立安排各自的变更时间等。
接口变更版本跟踪管理
接口的版本通过平台统一管理。可以查看、管理接口的具体版本是否下线等。

9.2. 服务部署

iBank4平台涉及众多服务和组件的部署，支持两种部署方式，基于K8S的服务自动编排部署和原生脚本方式部署，满足不同环境的部署要求。
1. iBank4平台各子系统支持两种部署方式，分别是使用K8s实现自动编排部署和使用脚本实现自动部署运行。在服务安装包上支持DockerFile构建镜像方式和直接使用服务镜像方式。
2. iBank4使用的MySQL、Redis、MQ、ELK、SkyWalking等第三方软件，属于有状态的服务，直接使用各自的部署方式进行部署，不使用Docker或者K8S的方式部署。

9.3. 版本管理

l 源码通过gitlab进行管理，易于分布式协作开发，对代码分支严格其使用方式。
l 应用发布包, 压缩成tar.gz包，通过版本号控制，所用规则是appname-大版本号.小版本号. 修订号.tar.gz。

9.4. 持续集成

iBank4系统采用微服务架构开发，系统根据功能划分了多个工程模块，各个业务模块在开发和单元测试阶段单独发布部署测试，为了实现统一编译打包工程代码，自动发布部署服务到开发和测试环境，节省时间，减少人为操作带来的问题风险，采用jenkins系统实现自动化代码拉取，编译，构建，打包，发布。

图：代码持续集成图
1. 开发人员提交代码到gitlab
2. 开发或测试人员到jenkins服务页面上点击构建发布按钮
3. Jenkins开发运行发布流程
4. 从github服务器拉去指定分支代码到构建服务器，进行编译 构建发布包。
5. 构建完成后，构建好的发布包上传到指定的部署服务器的指定路径上。
6. 部署服务，首先停止运行的服务，备份服务代码，解压新上传的发布包，移动解压后的发布目录到指定目录，通过脚本启动服务。

9.5. 高可用方案

9.5.1. 高可用原则

对于分布式系，通过集群化也即冗余达到集群中某节点出现故障，集群中的其余结点依然可以提供服务，保证系统高可用。一般来说，对于分层实现的系统，会使用分层冗余+自动故障转移技术。

9.5.2. 服务高可用

图：服务高可用表
l 注册中心用Nacos组成的集群，对外提供服务列表，注册服务，配置获取的功能。
l 集群通过注册中心集群，保证服务的高可用。
l 服务间的调用用Feign，结合负载均衡及限流熔断功能，保证服务结点能够稳定可靠的对外提供服务。当服务调用超出某服务的上限，限流熔断功能就生效，实现服务降级，保证在流量超额时，也能提供最小的稳定的可用服务。

9.5.3. 数据库高可用

iBank4系统采用MySQL数据库，使用MySQL-5.7以上版本提供的MGR架构高可用解决方案提供实例级冗余来解决服务器单点故障的问题，
l MySQL采用单主多从部署架构
l 节点数徐采用2个以上
l 如果集群内的一个节点发生故障，只要还有节点在运行，服务就不会间断，实现高可用。

9.5.4. Elasticsearch高可用

通过控制Elasticsearch集群索引的分片副本数达到高可用目的。通过冗余分片的副片数，可以在集群中的某结点或某些结点出现故障后，剩下的集群还能保持完整的数据不间断对外服务。下图是3台机器3分片2副本的例子：

图：ES高可用集群

9.5.5. Redis高可用

图：Redis高可用集群表
Redis采用官方Cluster集群模式部署，Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。Cluster 为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群能正常提供服务。

9.5.6. 7*24小时方案

业务设计不能相互干扰影响
部署方案中采用单服务下线部署上线轮换部署方案

9.5.7. 灰度发布方案

灰度发布是一种常用的系统发布方式，在系统需要迭代升级上线时，设计规则让一部分用户继续使用原来的产品功能，另一部分用户开始启用新的功能，验证新功能的各种指标。在此过度的过程中一旦出现问题或者产品功能需继续完善，可以快速控制局面，简单地说就是一套A/B test系统的流量管控。

1. 灰度发布业务逻辑为新版本发布需更改版本号，不能与旧版本号一致，与旧版本同时注册到注册中心
2. 在管理平台设置灰度发布开关是否启用灰度发布，并且把需要使用新版本的设备号勾选上，同步到分布式缓存，待网关读取
3. 网关在收到请求时从缓存获取灰度发布开关是否开启，如开启则拿到终端设备上送的设备号，到缓存匹配该终端是否在灰度发布列表里，是则从服务注册中心捞取新版本服务进行路由转发，把当前的请求路由到新版本的服务，完成灰度发布整个链路的处理。

9.6. 负载均衡方案

9.6.1. 网关负载均衡

网关部署多个服务节点，通过F5实现服务的高可用。
F5在转发请求的时候，能通过自身的分发算法（如轮询、比率、最小连接数），把请求均衡地分发到web服务器上。
通过Monitor机制，实时地检测后端服务器的状态，如果发现单点故障，便终止向此服务器发送请求。当故障解决后，F5又会自动重新发送请求给它。

9.6.2. 应用负载均衡

系统内部通过分层，分服务设计的微服务架构，采用SpringCloud技术框架，服务功能实现用SpringBoot框架开发，注册中心用Nacos，负载均衡用Ribbon技术，服务调用用Feign技术。

图：应用负载均衡图

9.6.3. 数据库负载均衡

图：数据库负载均衡图
通过MySQL官方提供的MGR高可用部署方案，如上图，采用单主多从架设，Master提供写能力，Slave提供读能力，提供高可用的同时实现读写分离。

9.7. 备份方案

9.7.1. 备份策略

l 每天定点备份数据，在流量较低的时段，尽量不影响正常访问的情况下，定时备份数据。
l 对于大数据量的每隔一段时间做一次全量备份，每天做一个增量备份。
l 备份数据采取多处存放，避免介质故障导致丢失备份数据的丢失。

9.7.2. 数据库备份

MySQL数据库采用官方MGR高可用的同时，提供Slave节点实现数据冗余，间接提供了数据的备份，在此基础上，iBank4提供每天定时导出备份到指定目录，备份方式提供增量备份与全量备份。

9.7.3. 文件备份

文件服务Minio天然支持分布式，通过部署多节点进行冗余服务数据，从而达到数据备份安全。

9.7.4. 日志备份

iBank4系统各子系统中的日志框架Logback提供了日志归档和备份。系统按日期和大小进行切割并且进行压缩备份。备份的日志文件最少保留180天，过期数据自动删除，以防止数据占用磁盘空间。
ELK日志服务系统会实时采集个业务系统日志，将采集的日志信息存储在ES中，ES采用集群和多副本模式进行日志存储，多副本模式保证采集的日志进行备份。同时，ES也可以通过设置数据失效时间，以减少无用数据占用磁盘空间。

9.8. 容灾方案

9.8.1. 服务器容灾方案

图：服务器容灾方案
服务器物理双服务器或多服务器方式，它们都跑一样的应用服务。例如是服务器A，B组成双服务器架构，A或B其中之一出现故障，也至少有一台服务器在服务，保证服务的正常运行。

9.8.2. 应用容灾方案

iBank4系统采用微服务架构，服务采用多副本部署，至少有两个副本实例是分布在不同机器上，注册到同一注册中心，利用注册中心实现的高可用功能保证其中某一或某些副本意外退出后，服务调用者仍可在注册中心获取到可用的副本服务，从而保证系统功能不受个别应用副本不工作的影响而正常使用。

图：应用容灾方案
服务3分别布署在服务器A、B两服务器上，当B上的服务3意外宕掉失联后，注册中心将仍有服务3的一个副本在A运行，从而不中断系统中的服务3的对外服务。

9.8.3. 数据库容灾方案

图：数据库容灾方案
数据库采用不同物理服务器形成数据同步冗余，当一部分服务器出现故障时，另外服务器还能正常提供服务，不影响业务的正常运行。

9.8.4. 同城双活及服务

iBank4系统采用同城双活的部署方案，同一个城市两个机房内都有流量进入，通过F5设备分配流量到两个机房，主机房流量大，副机房流量小。如果其中一个机房不能对外提供服务，只需要修改F5设备将流量全部切换到正常机房即可。

10. 数据库备份方案

iBank4系统备份按备份类型与方式，综合考虑到数据库类型、数据内容、数据恢复要求、投入产出比等综合考虑不同方式备份组合。下面设计到具体数据库类型是以MYSQL为例。
定期的备份推荐以数据库管理员为准，制定定期备份方案与计划等。
临时的备份主要是业务、技术等需求变化触发的，建议参照数据库管理的建议，指定备份方法与操作。

10.1. 备份类型

数据库备份按类型分为：冷备、温备、热备。
冷备：如果可以关闭数据服务器，则可以进行物理备份。好处是可以保证数据库的完整性，备份过程简单且恢复速度相对较快。但前提是停掉数据库服务器的影响。
温备：在数据库运行过程中进行的，但是会对当前数据库的操作有所影响。如加一个全局读锁以保证备份数据的一致性。
热备：与冷备相反，热备就是数据库处于运行状态下的备份，不影响现有业务的进行。热备又细分为逻辑备份和裸文件备份。
逻辑备份是指备份出的文件的内容是可读的，一般是文本文件。内容由一条条SQL语句，或者是表内实际数据组成，这种方法的好处是可以观察导出文件的内容，一般适用于数据库的升级、迁移等工作。但其缺点是恢复所需要的时间往往较长。
裸文件备份是指复制数据库的物理文件，既可以是在数据库运行中的复制，也可以是在数据库停止运行时直接的数据文件复制。由于是在底层复制数据文件的，所以速度上比逻辑备份一条条的插入SQL语句更快。裸文件备份的代表作就是 XtraBackup。
按备份数据库的内容来分，备份又可以分为：完全备份、增量备份、日志备份。
完全备份是指对数据库做全量备份；
增量备份是指在上次完全备份的基础上，对于更改的数据进行备份；
日志备份主要是指对 MySQL 数据库 binlog 的备份，通过对一个全量备份进行 binlog 的重做(replay) 来完成数据库的 point-in-time 的恢复工作。MySQL 数据库复制的原理就是异步实时的将 binlog 重做传送应用到从数据库。
按备份性质划分为固定计划的备份和临时性备份。
临时性备份主要是临时性工作中为了控制影响来执行的备份操作。如：（1）业务系统变更带来的数据表调整、（2）数据库类变更等

10.2. 备份操作

通过类型下列配置方式定时对数据库、数据表等进行备份

注意：
l 建议数据库管理员与业务系统双方协商选择合适的备份方式组合满足不同场景的需求。
l 建议数据库级别的备份方式以数据库管理员定义为准、有数据库管理组执行备份。
l 业务应用级别的特定表等逻辑备份方式参考数据库管理规则，指定有效机制备份。

10.3. 备份方案

10.4. 备份数据管理与清理

根据银行数据备份管理规则、应用系统数据的等级要求指定备份数据管理与清理具体规则

10.4.1. 数据库级别备份清理

近期的备份数据必须保存备份管理暂存存储中，同时长期保留在备份磁带等廉价存储中。
由银行磁盘备份库等清理机制完整可以清理的备份数据。

10.4.2. 业务逻辑备份管理与清理

业务逻辑备份由业务系统通过脚本来执行，逻辑备份的数据存储在数据库服务所在的备份专用在线存储规定的位置。在行方的定时作业系统或定时任务执行业务方提供的清理脚本清理冗余的数据备份。

11. 双活方案

11.1. 异地主备双活设计

根据异地主备双活分析，主要处理包同步、数据缓存同步、服务同步三部分的设计。

11.1.1. 整体设计

l 整体设计流程

图：双活同步整体流程
执行步骤：
1. 在管理端操作相关内容；
2. 向任务表记录本服务相关的操作；
3. 另一边服务器定时扫描日志记录表，发现对方服务器存在操作记录；
4. 向指定的服务处理；
5. 根据业务操作，给PV发送同步指令。

11.1.2. 文件同步

图：文件包双活设计流程
文件处理涉及的内容包含：C端版本包、SP包、Native包、iXT工程升级包。
l 在管理端（任一中心）上传文件后，将操作记录写入到操作记录表，并标记写入的服务节点信息；
l 另一中心检测操作记录表，存在对方中心的操作记录时；
l 获取对方指定的文件信息；
l 将此文件按指定名称存储在本中心的文件服务中；
l 向PV发送文件升级指令；
Ø V处理：
提供定时任务获取：将指定的文件从本地文件服务器，下载该文件（C端版本包、SP包、Native包）并解压到静态资源服务器供C端访问。
提供定时任务获取：将指定的文件从本地文件服务器，下载该文件（P端工程版本包）并解压到本地，将此文件内容内容同步到redis缓存中。
l 同步成功后，将此记录中数据状态改为已处理。

11.1.3. 数据缓存同步

图：数据缓存双活设计流程
数据缓存同步处理涉及的内容包含：P端工程升级包（文件同步已处理）、设备信息、卡bin、卡图片、协议文档。
l 在管理端（任一中心）更新相关信息后，将操作记录写入到操作记录表，并标记写入的服务节点信息；
l 另一中心检测操作记录表，存在对方中心的操作记录时；
l 向V发送同步缓存指令；
Ø V处理：V端收到指令后，从数据库里加载相关数据（设备信息、卡bin、卡图片、协议文档）刷新到redis缓存。
l 同步成功后，将此记录中数据状态改为已处理。

11.1.4. 服务同步

图：服务升级双活设计流程
服务同步处理涉及的内容包含：P端渠道服务同步。
l 在管理端（任一中心）更新指定服务版本升级信息后，将操作记录写入到操作记录表，并标记写入的服务节点信息；
l 另一中心检测操作记录表，存在对方中心的操作记录时；
l 向P端服务发送同步缓存指令；
Ø P处理：主中心与副中心有映射关系，当主中心/副中心有一个服务进行升级到指定版本时，另副中心/主中心则升级到指定的版本。
l 同步成功后，将此记录中数据状态改为已处理。

11.2. 异地主备双活部署

图：ITMP双活部署

11.2.1. 部署要求

主中心部署定时任务的服务器，需要开通访问副中心文件服务器的网络权限；副中心部署定时任务的服务器，需要开通访问主中心文件服务器的网络权限。

11.2.2. 主中心

l 在mam服务中，更新发布mam服务；

11.2.3. 灾备中心

l P端服务首次部署时，需更上传一次全量版本包（后置服务地址不同）；
l 参考部署手册，进行部署灾备环境。

12. 终端测试

虚拟设备，就是在PC机硬件的基础上，用软件方式实现物理硬件的功能，来模拟硬件的实际行为。虚拟设备相对真实硬件，有两个优势：软件设计的灵活性可以弥补真实硬件的“硬”特性（操作上的）；软件虚拟真实硬件可快速模拟真实硬件的特性，辅助我司完善软件逻辑、健壮性、可靠性设计，提升软件测试的效果和效率，对提升我司软件产品的质量起到举足轻重的作用。
虚拟设备立足于完全实现真实硬件特性，方便模拟真实硬件的各种故障，运行稳定可靠，界面友好，使用方便。虚拟设备具备以下基本功能：兼容真实硬件的串口通信、模拟真实硬件特性、人机交互、指令响应方式配置、错误码返回、指令执行返回参数配置、设备状态管理和维护等
下面针对读卡器模拟做个简单介绍
读卡器主菜单包括下图的菜单项，CardInfo、Status、ErrorSimulating、InsertCard、TakeCard、CommandSet、CloseDevice、AboutVirDev和ExitProgram。

图指令菜单

12.1. TakeCard话框

TakeCard对话框提供了两个按钮，“取卡”和“不取卡”按钮。如图所示。

取卡对话框
l Take Away Card：取卡按钮，该按钮表示取卡，点击完后取卡对话框自动消失。
l Not Take Card：不取卡按钮，该按钮表示不取走卡，卡停留在插卡口，点击完后取卡对话框也会自动消失。

12.2. InsertCard对话框

InsertCard对话框有两种表现形式，如图3-3和图3-4所示。 点击图3-3的关闭按钮后会缩小成图3-4的形式，其位置会移到屏幕顶部，这样可以防止不干扰其他操作。图3-4也可被双击还原成图3-3。
该对话框模拟用户插入磁卡。当有收到插卡指令后，该对话框会自动弹出，用户选择要插入的磁卡信息后，点击[InsertCard]按钮就表示插入磁卡，对话框会自动隐藏。编辑框表示的磁道信息可编辑。用户也可以选择主菜单的[InsertCard]菜单项使该对话框弹出。

插卡对话框1

插卡对话框2
l MagCard复选框：该框选定表示插入的是磁卡；只有该框选定后，Select Card下拉列表、Track1编辑框、Track2编辑框、Track3编辑框才可用
l IC Card复选框：该框选定表示插入的是IC卡
l Invalid Card复选框：该框选定表示插入的是非法磁卡;该框选定后,只有InsertCard按钮可用
l Select Card下拉列表：卡名选择下拉列表,列出存放所有卡的信息，用户可以编辑该列表框，输入自己想要的卡名。当卡名被选定后，会在下面的编辑框显示出相应磁卡的信息。
l Track1编辑框：被选定卡的磁道1数据，可编辑
l Track2编辑框：被选定卡的磁道2数据，可编辑
l Track3编辑框：被选定卡的磁道3数据，可编辑
l InsertCard按钮：点击该按钮表示插入磁卡；在没有收到插卡指令时该按钮是不可用的。

12.3. ErrorSimulating对话框

错误选择对话框
该对话框提供错误码模拟功能。由于读卡器需要在较短时间内返回，因此无法用弹出对话的形式让用户进行选择，而是要在指令发送之前设定好。比如要模拟退卡时卡被堵住这个错误，需要再发送退卡指令之前点击主菜单的[ErrorSimulating]选项，设定错误码1283。

12.4. Status对话框

状态对话框
该对话框提供查看及修改读卡状态功能。由于读卡器状态位难以理解，所以本对话框只提供下拉列表让用户选择，而没有提供直接修改状态位的功能。

12.5. CardInfo对话框

该对话框提供增删改及查找磁卡信息功能。

卡信息维护对话框

13. 性能测试内容

13.1. 测试环境

软/硬件资源

表：测试软/硬件环境

13.2. 测试策略

本次测试计划为：首先对每个交易报文进行100用户并发的压力测试，再进行交易混合模型压力测试，最后进行稳定性测试，并根据压测场景按需设置思考时间。
数据库覆盖达梦（dm8）、人大金仓（kingbase8）及华为（opengauss2.0）三大国产化数据库。
前置渠道网络协议覆盖HTTP、TCP短连接，后置渠道网络协议覆盖HTTP、HTTPS、TCP短连接及银联网络模型（二进二出）。
报文协议覆盖xml、json、8583、结构体以及分隔符五大报文。
前后置通信/报文（七大）组合：

表：前后置通信/报文组合

13.2.1. 基准/混合场景测试

基准场景测试方法：
采用基准测试的脚本及场景，设置100个虚拟用户，固定运行时间30分钟，不设置并发点和思考时间，记录交易平均响应时间，交易正确率，应用服务器CPU利用率、内存使用情况等参数，并查看服务器日志文件和数据库交易日志表的入库情况。
混合场景测试方法：
根据混合测试业务模型，配比各功能点脚本，置于同一场景中运行，运行时每次迭代中没有时间间隔，测试脚本中不设并发点，固定运行时间为30分钟，记录交易平均响应时间，交易正确率，应用服务器CPU利用率、内存使用情况等参数。
混合场景配比：五大报文协议组合各占比20%。

13.2.2. 稳定性测试

稳定性测试重点测试系统查看各项性能指标没有明显变化。
测试方法：
采用混合交易负载测试的脚本及场景设置，设置思考时间400毫秒，连续运行12小时，记录交易平均响应时间，交易正确率，应用服务器CPU利用率、内存使用情况等参数，考察应用服务器是否出现宕机、交易正确率大于99.99%等情况。

13.2.3. 异常测试

异常测试重点测试应用高负载下运行模拟银行主机发生各种异常时，系统进程不崩溃，队列不堵死。
采用混合交易负载测试的脚本及场景设置，记录交易平均响应时间，交易正确率，应用服务器CPU利用率、内存使用情况等参数，考察应用服务器是否出现宕机、交易正确率大于99.99%等情况。

13.3. 测试结果

13.3.1. 基准场景结果

DM8测试结果分析
依据策略采用单交易基准场景，分别模拟各种报文协议解析器、网络协议模型（短链接）的使用场景对系统进行加压压测，不设置思考时间，各运行30分钟。测试结果及分析见下：
测试结果：

表：基准测试并发性能测试结果记录

基准场景测试平均响应时间

基准场景测试TPS

基准场景测试内存使用率

基准场景测试CPU使用率

基准场景测试磁盘I/O

基准场景测试网络I/O

13.3.2. 混合场景测试结果

依据混合场景测试策略采用（json、xml、8583、结构体、分隔符五大报文的业务模型配比）混合交易场景，设置100并发用户数对系统进行加压，不设置思考时间，运行时间30分钟。测试结果及分析见下
测试结果：

表：混合测试并发性能测试结果记录

混合场景测试TPS

混合场景测试内存使用率

混合场景测试CPU使用率

混合场景测试磁盘I/O

混合场景测试网络I/O

13.3.3. 稳定性测试结果

采用混合所有报文协议并发负载测试场景设置.
依据稳定性测试策略采用（json、xml、8583、结构体、分隔符五大报文组合）混合场景设置，设置思考时间400毫秒，连续运行12小时。测试结果及分析见下：
测试结果：

表：稳定性测试结果记录

稳定性测试平均响应时间

稳定性测试TPS

稳定性测试内存使用率

稳定性测试CPU使用率

稳定性测试磁盘I/O

稳定性测试网络I/O

13.3.4. 异常测试结果

依据异常测试策略采用（json、xml、8583、分隔符四大报文组合）混合交易场景，模拟主机延迟响应情况，设置并发用户数80，先正常运行5分钟，然后主机延迟10秒响应5分钟，最后主机恢复正常运行5分钟。测试结果及分析见下
测试结果：

表：主机延迟响应性能测试记录

主机延迟响应的平均响应时间

主机延迟响应的TPS

主机延迟响应的内存使用率

主机延迟响应的CPU使用率

主机延迟响应的磁盘I/O

主机延迟响应的网络I/O

14. 知识转移策略

本次项目中，广电运通为贵行提供以下知识转移、培训及售后服务承诺：
（一）知识转移
1、系统上线前，我司将项目合同工作内容所涉及的所有成果无条件转移给招标方，包括但不限于设备、平台级和项目级的源代码、系统软件、工具、方案、完整的技术文档等，移交结果需经招标方审核确认。文档包括但不限于：项目实施方案、软硬件配置清单、安装部署手册、项目和平台级的API文档、产品基础API文档、产品说明文档、完整的需求分析文档、架构设计文档、概要设计文档、详细设计文档、对外渠道接口文档、完整准确易用的数据库设计文档、数据库字典、平台二次开发手册、测试计划、培训资料、用户操作手册、系统安装部署手册、运维手册（含应急处置）、性能测试报告、高可用测试报告等，并保证提交的源代码和相关技术文档与其提交的系统软件的可执行程序一致，如我司的软件系统包含了第三方软件产品，则提交第三方软件产品的使用许可合法证明。
2、我司将所有项目实施内容（包括但不限于代码、系统架构、方案等）通过以培训为主，结合项目会议、项目讨论、书面文档移交、技术答疑等形式知识转移给招标方人员，直至招标方人员完全理解和掌握，才视为完成知识转移和培训服务。
（二）培训要求
1、所有培训均为招标方体系内培训。
2、项目实施过程中，我司免费提供包括面向招标方管理、业务人员的系统培训和面向招标方技术人员的系统结构、功能、模型、软件开发等方面的培训。我司负责制定培训方案和培训计划，在得到招标方确认后，合理地分期、分批对招标方人员进行现场培训。
3、对于在招标方现场举办的培训，我司承担培训资料、师资（含讲师食宿、交通）等费用；对于在我司现场举办的培训，我司承担培训资料、场地租用、师资（含讲师食宿、交通）等费用。
4、培训讲师具有相应领域的实施经验和持有相应领域的资质，对培训内容有深入的理解，并能解答参训人员提出的具体问题。
5、我司提供分期、分层次的用户使用培训和集中的系统管理员、运维人员培训。负责使用户达到能正确熟练地操作、系统管理员能正常维护系统运行。培训讲师提供累计授课时长不少于2人天的本项培训。
6、我司提供针对软件开发人员的二次开发培训和配套软件使用培训。负责使招标方开发人员能完全独立进行平台和平台功能的二次开发。培训讲师提供累计授课时长不少于2人天的本项培训。
（三）售后服务整体要求
我司承诺在合同有效期提供维保服务，我司承担因未能按照维保服务要求造成生产系统故障的责任。如系统出现故障，我司在接到行方的报障电话后按应急服务要求作出响应，予以解决问题。
（四）免费维保期
1、免费维保期的起始日期为双方签署《项目终验验收报告》的日期，我司按照《报价表》中的免费维保期提供系统的免费维保。免费维保期后的维保要求，按维保合同的约定执行。
2、所有软件产品提供一年的免费维保期。
3、免费维保期结束后，我司有义务在本项目的维保、运行管理和开发方面继续给予技术协作和咨询。

14.1. 技术转移安排

确保在项目合同实施工作结束时能够与贵行一起完成技术转移的工作任务，目标是使贵行技术人员能够获得独立进行开发、升级和维护的能力，技术转移内容要包含产品转移与技能转移两部分。

14.2. 产品转移

(1)、提供在项目实施过程中产生的相关文档，含招、投标文件，系统需求说明书、系统概要、详细设计说明书、系统应用源码、系统数据库设计说明书、系统使用和操作说明书、系统（含子系统）测试案例、验收方案、系统（含子系统）测试、验收报告等。我司所提供的文档保持完整性和准确性。所有文档都采用简体中文

说明：有“*”表示由贵行提供
(2)提交项目相关的所有应用层源代码，包括前端业务服务和后端管理相关，供行方自主升级开发。

14.3. 技能转移

(1)、通过培训、参与开发以及其它应答人认为合适的方式实现iBank4的技能转移，技能转移内容包含但不限于：软件开发生命周期方法、软件工程方法、开发语言及工具的使用、相关中间件的使用等。
(2)、通过培训以及其它合适的方式实现业务需求分析方面的技能转移，技能转移内容包含但不限于：业务需求分析方法、业务流程描述方法等。
(3)、通过培训以及其方式实现业务需求开发方面的技能转移，技能转移内容包含但不限于：数据结构设计实现、应用接口开发方法等。
(4)、通过培训以及其它应认为合适的方式实现项目集成、实施方面的技能转移。技能转移内容包含但不限于：项目管理、整体实施架构设计、质量控制、集成测试、数据迁移以及用户验收测试等方法。
(5)、通过培训以及其它认为合适的方式实现应用投产维护方面的技能转移，技能转移内容包含但不限于：产品投产流程、日常运行维护、出错的处理与解决、数据备份与恢复等。