引言
随着金融业务转型步伐加快，业务连续性要求趋严，对金融业信息系统运行稳定性要求日益提升。依据《银行、证券跨行业信息系统突发事件应急处置工作指引》的通知（银监发（2008）50号），影响银证系统日间业务时间超过5分钟（含），不足30分钟的突发事件属于Ⅲ级事件（一般事件），对三方存管系统的业务连续性提出更高要求。
G行三方存管系统用于承载银行方三方存管银证业务，遵循“券商管证券，银行管资金”原则，将投资者的证券账户与证券保证金账户严格进行分离管理。本文以G行三方存管系统云原生改造为切入点，从业务上云方案设计、业务上云风险评估、业务上云问题发现、业务上云带来的收益四个方面进行总结。
image.png
一、业务上云方案设计--云原生架构打基础
在金融行业蓬勃发展和技术高速迭代的大背景下，传统集中式架构暴露出的短板愈发突出：1）扩展性不足，难以灵活应对业务规模的快速扩张；2）容错能力欠佳，一旦关键节点出现故障，易引发系统性风险；3）代码耦合度过高，使得系统维护与功能升级变得异常复杂。
为紧跟技术发展潮流，积极赋能业务创新，自 2019 年起，G 行启动新一代三方存管系统上云项目建设，该项目实现了容器化微服务改造和国产化分布式改造。下面从上云应用架构设计与上云业务迁移两大核心维度展开，全面推动系统的升级转型。
1.1 上云应用架构设计
应用上云的关键在于全面合理地架构拆分，为后续业务迁移打好基础。架构拆分不能只追求数量，要结合系统实际业务场景和业务量变化综合考量。G行三方存管系统架构拆分时，先按交易方向将网关层分为银行方和证券方，保证交易独立，减少干扰，提升稳定性和效率；再根据交易重要程度，拆分银行方与证券方的金融交易，实现资源分配和业务保障的差异化管理，保障关键交易；最后依据业务运行特点，对查询、签约等业务针对性拆分。其中，签约业务因占比较低，基于 “非必要不拆分”原则，不做交易方向拆分，避免复杂性和成本增加，体现拆分策略的合理性。
1.2 上云业务迁移
为确保云上业务平稳迁移，G行在三方存管系统业务迁移过程中采取一系列谨慎有序的迁移策略。首先按照应用业务迁移，设计新老系统并行场景，优先将银行端全部查询业务迁移至新系统，让新系统同时对接新、老数据库，实现最小风险下对查询业务的最大化接入。待新系统稳定后，再以合作机构为业务对象，分批迁移重要业务。由于银证业务合作机构较多，一次性整体迁移风险较高，因此按照券商签约客户量维度，遵循先少后多的原则，逐步对接新系统，完成云上容器化业务迁移。在国产化分布式架构改造阶段，基于前期容器化微服务底座，通过控制云上流量进行业务迁移，可谓水到渠成。在保证业务平稳运行的前提下，按照5%、20%、50%、100%精控流量比例，最终实现无感化云上业务流量迁移。
二、业务上云风险评估--风险评估保平稳
系统上云过程中风险贯穿始终，核心目标是确保系统上云安全平稳运行。从架构设计到上线，需全程做好风险评估，降低运行隐患。以下是G行在上云过程中遇到的突出风险点及应对方法：
批量并行运行风险：新老系统并行期的批量运行风险控制依据架构特性进行优化。传统架构向容器微服务化迁移时，为保障合作机构清算准确唯一，避免资金风险与数据混乱，各合作机构清算任务必须相互独立、彼此隔离。从容器化向国产化分布式迁移时，为合理利用资源、确保任务有序，批量仅在一套环境运行，通过为每个任务生成唯一标识来监控批量状态，防止重复执行，避免数据不一致和资源浪费。
云上业务引流风险：在国产化分布式业务迁移阶段，云上业务引流风险不容小觑，其中关键在于保证流量精准控制。为达成这一目标，在架构设计阶段进行埋点，对网关层实施精简化和去状态化处理，实现通过连接云上实例数比例精确控制接入流量，有效降低引流风险，保障业务迁移的平稳进行。
流量回切风险：流量回切的高效性是业务迁移无影响的最后一道防线。迁移前要充分考虑异常场景，制定快速回切策略。三方存管系统以快速恢复业务为原则，将回切流程拆分为关键和非关键步骤，优化每步执行逻辑，借助自动化技术实现流程精简化、自动化，确保业务异常时能迅速回切流量，减少业务中断时间，降低对用户和业务的影响。
系统容量风险：系统容量风险涵盖业务容量风险以及应用与平台支撑能力风险。新系统上线前评估需贴近生产实际，例如在新、老系统并行期，新系统访问老系统数据库时，老系统数据库连接实例数的容量风险易被忽略。因此，非功能测试阶段要克隆生产环境，保证一致性。同时管理员要长期积累容量风险识别经验，上线前逐项评估系统容量风险。
数据迁移风险：在分批业务转移过程中，因新旧数据库间的异构性差异，面临着显著的风险挑战。这些风险主要体现在以下三个方面：
1. 数据一致性与完整性风险：迁移前后可能出现数据丢失、字段内容被截断、字符集与编码方式转换引发的数值偏差、表结构变动以及索引丢失等问题。为有效应对此类风险，关键在于构建详尽的数据与表结构迁移前后的比对及校验机制，并开发或采用专业的校验比对工具来确保数据的精确无误。
2. 性能与稳定性风险：异构数据库间在性能和稳定性方面存在显著差异，且数据存储与使用规则也各不相同。针对这一风险，核心策略是在迁移前进行广泛而深入的测试，充分考虑各种可能的使用场景，以确保迁移后的系统能够满足性能需求并保持高度稳定。
3. 脏数据风险：在迁移过程中，若未对迁移数据进行全面深入的分析，而盲目采用全量迁移的方式，可能会将非必要数据一并带入新系统，从而为后续系统运行埋下隐患。为规避此类风险，在制定数据迁移方案时，必须对数据进行全面系统的分析，严格遵循最小化迁移数据原则，并在迁移后仔细核查迁移数据的内容，确保数据的纯净与有效性。
三、业务上云问题发现 --监控灵敏排隐患
为保障三方存管业务上云后平稳运行，在容器微服务化云上业务迁移初期，通过细化监控指标，利用智能监控技术，提升监控灵敏度，及时捕捉潜在风险隐患。发现风险隐患后，迅速组织研发、运维等各领域专家组成攻坚组，通过数据分析、日志回溯、网络抓包和模拟测试等手段排查问题原因，制定有效解决方案，并建立长效风险预警和应对预案，为后续业务平稳迁移及运行筑牢基础。
3.1 联机交易响应耗时长
程序代码处理机制引起交易偶发停顿：通过细化监控策略，增设联机交易响应时间最大阈值策略，并将敏感度提高到单笔报警，发现存在偶发联机交易响应超时。经排查各阶段交易耗时，问题锁定在网关层接收网络报文到开始处理之间。经深入分析和测试环境复现，确定网关层反向解析请求报文源地址时，存在异常等待超时，致使联机交易偶发卡顿。
外围系统引起应用短时暂停：通过优化联机交易响应时间基线波动率监控策略，成功捕捉到偶发响应时间偏离场景。针对告警时间段内的交易情况展开全面排查与细致分析，发现存在交易异常暂停现象。为深挖问题根源，进一步扩展了排查范围，发现辅助运营监控平台在进行信息采集时，引发应用线程短时暂停，停止信息采集任务后，交易异常暂停现象消失。
3.2 系统资源消耗异常
外围系统引起pod内存消耗异常：通过对运行服务巡检发现，某类对内存要求高的服务pod存在内存异常缓慢增长。对内存使用情况分析发现辅助运营的平台进行信息采集时存在内存占用不释放现象。
服务内存配置不合理：在系统持续运行一段时间后，我们观察到批量服务出现内存使用率高于阈值的情况。通过深入的内存使用情况分析，并结合该服务功能的特性-批量频繁读取文件操作场景。经综合判断，确定当前内存的增长属于正常业务范畴。当内存增长至特定区间时，系统会自动进行动态内存的释放。由此可见，内存使用率过高是资源初始分配不合理导致。
四、业务上云带来的收益
相较于传统单体架构应用系统，云上系统在业务连续性、应用变更复杂度、生产环境一致性等方面展现出显著优势。
业务连续性能力提升：多副本特性降低业务中断概率，运维关注重点转向上下游系统可靠性。
投产流程复杂度降低：借助镜像制品库，实现标准化拉取与部署，减少人为干预风险。
生产环境一致性提升：容器化部署依靠镜像版本控制，确保多环境信息一致。
在金融行业蓬勃发展和技术高速迭代的大背景下，传统集中式架构暴露出的短板愈发突出：1）扩展性不足，难以灵活应对业务规模的快速扩张；2）容错能力欠佳，一旦关键节点出现故障，易引发系统性风险；3）代码耦合度过高，使得系统维护与功能升级变得异常复杂。
为紧跟技术发展潮流，积极赋能业务创新，自 2019 年起，G 行启动新一代三方存管系统上云项目建设，该项目实现了容器化微服务改造和国产化分布式改造。下面从上云应用架构设计与上云业务迁移两大核心维度展开，全面推动系统的升级转型。
4.1 上云应用架构设计
应用上云的关键在于全面合理地架构拆分，为后续业务迁移打好基础。架构拆分不能只追求数量，要结合系统实际业务场景和业务量变化综合考量。G 行三方存管系统架构拆分时，先按交易方向将网关层分为银行方和证券方，保证交易独立，减少干扰，提升稳定性和效率；再根据交易重要程度，拆分银行方与证券方的金融交易，实现资源分配和业务保障的差异化管理，保障关键交易；最后依据业务运行特点，对查询、签约等业务针对性拆分。其中，签约业务因占比较低，基于 “非必要不拆分”原则，不做交易方向拆分，避免复杂性和成本增加，体现拆分策略的合理性。
4.2 上云业务迁移
为确保云上业务平稳迁移，G 行在三方存管系统业务迁移过程中采取一系列谨慎有序的迁移策略。首先按照应用业务迁移，设计新老系统并行场景，优先将银行端全部查询业务迁移至新系统，让新系统同时对接新、老数据库，实现最小风险下对查询业务的最大化接入。待新系统稳定后，再以合作机构为业务对象，分批迁移重要业务。由于银证业务合作机构较多，一次性整体迁移风险较高，因此按照券商签约客户量维度，遵循先少后多的原则，逐步对接新系统，完成云上容器化业务迁移。在国产化分布式架构改造阶段，基于前期容器化微服务底座，通过控制云上流量进行业务迁移，可谓水到渠成。在保证业务平稳运行的前提下，按照5%、20%、50%、100%精控流量比例，最终实现无感化云上业务流量迁移。
五、总结
通过云原生改造极大提升了对业务发展的支撑能力，但也给运维带来新挑战。一方面，系统架构变得更复杂，节点连接繁多，运维难度增大，故障排查定位困难；另一方面，单 pod 故障概率高于传统服务器，在途交易差错账处理要求提高，而且运维所涉猎技术领域更广，对运维人员技术能力要求更高。
未来，我们将着力继续探索在复杂服务中快速定位故障的方法，加强标准化建设持续提升可观测水平，不断提升智能运维能力，保障系统平稳运行，赋能业务快速发展。
作者：郭红斌
深耕金融科技安全运营领域多年，目前主要负责金融类存管系统的应用运维建设工作。面对万千技术的更新迭代，打造规范化、可视化、快速响应的安全运营能力，是我们亘古不变的目标。
