三地六中心多点多活

• 北上深三个城市，每个城市都部署2个IDC，实现lass层IDC级的多点多活和城市级容灾。

• 6IDC通过骨干网络连接，形成一个环，可以理解为一个大的局域网。

• 支付机构和银行通过专线接入6IDC，每家机构/银行最少需要接入3条专线，分别对应三大运营商，实现运营商级别的网络灾备。

• 专线接入可以根据机构/银行所在城市就近接入，可以降低拉专线成本。

• 对于交易体量大的机构/银行每个IDC都需接入3条专线（三个运营商），6IDC需要18条专线。专线带宽根据具体交易体量评估。

分布式部署

按照业务处理特性，整体上拆分为实时交易业务和离线批处理业务两大块模块，每个模块之间按照交易过程所承担不同的业务处理功能，拆分为多个子系统。

实时交易业务

• 机构前置应用：承接入访请求交易的身份认证、报文处理、权限管理、限流、路由等功能。

• 交易转接应用：负责处理实时业务，实时交易落库。

• 银行前置应用：组装报文选取路由专线发送出访交易。

• 备付金管理应用：备付金集中存款管理系统，实时更新机构备付金账户余额。

离线批处理业务

• 清算应用：基于交易主库，在固定时点触发前一小时的清分任务，将清分轧差数据保存到清算库，每天固定时段上报大额系统。

• 对账应用：基于交易主库，在固定时点触发前一小时的对账任务，将对账明细和对账汇总摘要上传到SFTP服务，供需求方获取。

• 差错应用：交易业务兜底，当账务不平时，通过差错系统，人工调账等方式实现账务平等。

• 大数据核对：大数据基于交易链路中的应用日志和落库的交易日志进行批量比对数据量是否一致。

业务连续性保障

业务连续性要比系统稳定性的概念更大，系统稳定性也是业务连续性的一种保障手段。在系统稳定性无法得到保障时，业务连续性仍需要得到保障，此时需要各种应急手段或者业务兜底方案来处理。

为什么要做系统稳定性工作

由于承载了全国范围内的网上支付（快捷）交易，做为金融基础设施平台其稳定性异常重要。平台的建设目标为18万TPS，任何一个抖动都会影响成千上万笔交易，影响到全国用户的支付体验。本着让支付更美好的行业价值观，提升系统平台的稳定性属于势在必行的一条路。

实现什么样的目标

• 目前平台建设在安全层面实现了等保四级的要求

• 在性能方面支持超过18万TPS的业务处理能力，系统成功率指标超过四个九(99.99%)，交易平均耗时低于200毫秒，全年不连续的系统故障不得超过5分钟。

• 异常场景应急处置方案（EOP/SOP）实现生产全范围覆盖，并持续迭代完成定期演练。

都做了哪些工作

全链路梳理

从最外层网络设备开始，梳理平台全链路（实时/批量）应用服务链路图，识别风险点，制定整改计划。

收敛强依赖

无论是基础组件还是业务系统，在任何环节都不允许出现强依赖的问题，避免单点故障影响整个交易链路。对于特殊业务的强依赖需要具备降级能力。比如：配置类数据的获取需要经过缓存(redis)和数据库(mysql)两层，schedule定时组件故障需要支持手动下发指令能力等。

离散计划

应用部署不能出现任何维度的单点：

• 所有应用最少支持3机房部署，建议为本地、同城、异地机房部署。

• 所有应用单机房不能少于3个节点部署。

• 所部署应用的虚机不能在同一台物理机、同一个机柜、同一个leaf交换机上，尽量打散。

实现机房动态摘除和回切能力

为了体现IDC多点多活的价值，同时也为了更好的做系统升级维护，需要具备主动踢除任意机房和快速恢复的能力。联动所有团队设计相关方案，落地开发任务，并联动所有接入的成员机构实现引流能力。

扩容

按照同时可以踢除两个机房计算4机房运行需要多少资源，各应用根据计算结果进行资源申请和扩容。

制定EOP/SOP

• 所有生产EOP/SOP都要按照不同级别I类、II类、III类进行周期性生产演练。

• 随机抽查演练过程，总结演练报告。

• EOP/SOP要持续迭代评审

性能压测

• 影子流量压测

影子流量为平台内部发起的模拟交易，交易会通过负载设备向后分发，为尽量真实影子流量将会贯穿所有交易链路。通过交易流量的特殊标识（流水号的倒数第7位为测试标识）用于区分后续业务处理场景，比如清分后生成的对账文件将不对外提供。

• 全链路压测

由机构、平台、银行三方联动，共同完成压测任务。通常是在重保大促活动场景前进行（双十一、春节红包等）。银行提供压测卡，机构使用压测账户发起交易(通常每笔交易为1分钱)，平台正常受理。压测前需要明确好压测模型，所谓的压测模型主要包括：

• 压测性能目标：成功率99.99%，系统平均耗时500ms。

• 压测范围：账户类型（借记账户、贷记账户），通常银行内部借贷记是独立的两套系统。

• 压测步长：压测轮次，每一轮的压测起始TPS和每分钟流量变动。

• 压测报告：总结压测结果，生产压测报告。对于没有通过的场景适当的调整压测方案。

封网

封网一般也是在重保活动期间关闭生产环境变更操作，比如十一假期、两会等重保场景。封网更多的是为了避免由于生产变更导致的故障场景。

流量控制

• 限流

提供单中心限流能力，支持机房总量限流、按业务维度配置限流、按机构和银行配置限流。平台限流属于快速失败的一种方式，交易最终会以失败返回发起方。

• 路由

路由是为了应对在6机房流量不均或者机构没有按照规则将交易发往故障机房的场景，平台应按照指定规则将流量路由到其他机房受理。也算是一种负载均衡策略。

工程能力提升

由于初创阶段的业务快速发展，为实现快速迭代很多场景在质量保障上做的不够充分，技术债积累了到了一定程度后需要清理，否则会对业务连续性产生较大影响。在此之前已经发生多次生产故障，已经充分体现了“灰犀牛”和“黑天鹅”理论的真实性。工程能力的提升要避免2大误区，同时要具备3大条件。

两大误区

• 工程能力不是技术人员的事情，是整个公司的事情。

从管理层到具体项目的实施（需求、开发、测试、运维）都要具备工程能力思维。这一阶段最忌讳的就是管理者打破规矩，导致流程不能得到具体的执行。举个例子：正常一个需求的敏捷开发周期是2周，那么很多时候需求人员周一会找到开发人员对需求，然后说上一句“xx总很关系这个项目进展，要求本周完成开发测试，下周一上线”，更有的时候xx总直接倒排期，都不用下面的人拿鸡毛当令箭了。开发为了尽快完成任务，同时还有给测试流出足够的时间，往往把功能代码写完，直接就提测了。测试也会因为工期的原因只准备了正向案例，测试案例覆盖度不够。最终上线后，造成生产事故。

在这个案例中我们需要反思的事，这个需求是否真的要一周完成，着急上线是否真的有价值。在业务高速发展过程中难免会遇到这种情况，但是这种情况一是要控制好频率，二是要有明确的业务价值。而往往管理者和需求人员都不关心工程质量，认为那是技术人员的事情，着急上线的需求也并不是那么具有价值必须压缩工期投产。这种情况如果太过频繁那么工程能力是得不到提升的，长此以往只能拖垮系统，累垮技术。

• 工程能力的价值很虚，只要技术人员写好代码就可以了

其实工程能力的概念并不虚，甚至可以说针对不同岗位也有不同的衡量指标。但是工程能力的价值体现上并不太好量化，很多时候短期内都看不到成果的。技术人员写好代码并不能算是工程能力的体现，充其量也就属于代码质量的范围。

三大条件

• 政策上的支持

主要还是因为工程能力的价值并不好量化，需要长时间的积累方可体现，而在落实方案过程中会遇到各种阻力，甚至会影响到一些之前的计划排期。此时，需要管理者坚信其长远价值，并对工程能力的落实给与足够的资源支持。

• 要有一套完成的落地方案

工程能力是要贯彻整条业务线，从项目管理、需求管理、开发测试在到生产运维，每一个环节都要有明确的落地方案，这些方案并不一定是要串行连续的，每个环节都可以独立落地实施。虽然可以分环境落地但是前期就要规划好整条线路，否则工程能力的价值更无法得到体现，发挥不出预期效果。

• 要有对应的工具支撑

工程能力完全靠规章制度就行的，每一个环节都需要有对应的工具支撑。比如，项目管理上需要有一套敏捷开发的计划跟踪系统来支持，告别传统的离线文档；需求管理阶段也要有需求拆分、评审和投产后的量化指标反馈系统来支持，让每一个需求的生命周期得到充分的展示和价值体现；开发测试阶段要有良好的持续交付工具，释放技术资源提高工程质量；生产运维阶段要有良好的灰度能力和应急处置能力平台，同事要有高效的监控告警平台支撑。

工作内容

涉及项目跟踪管理和需求卡片的相关方案落实就不在描述了，通过不同工具都可实现，最主要的就是团队在落实过程中的坚持。平台使用的是百度效率云服务，分为icafe、icode两大块，分别对应需求卡片管理和代码库管理。官网链接：https://xiaolvyun.baidu.com/#page1。这里主要介绍下涉及到技术相关落地方案内容，本着开发、测试平行线原则，即开发对自己的代码质量负责不需要依赖测试的结果，测试需要对整个交付流程负责，除要关心提测内容还有关心整体案例回归和快速实现集成测试。关于集成测试依赖效率云的ipipe集成案例回归来实现，开发通过单元测试和自建的案例回归平台来保证提测前代码的质量。

单元测试

前期应用开发过程中单元测试不做为上线投产的前置要求，很多应用都不存在单元测试代码。经过评估最后将单元测试作为开发提测前的必经环节，要求开发在提测前要达到85%的单测覆盖率(行级)、80%的分支覆盖率、100%的单测成功率。并在持续交付流程中配置自动扫描，通过sonar统计分析相应指标数据。

这一阶段推行最大的阻力就是写单侧可能要比需求开发代码还费时间，技术人员很难接受，并且单测质量上来了并不能直接转换成价值指标，不能清晰的量化。对于这一阶段的阵痛，前置只能靠政策的支持和工程能力意识的宣贯，并且提供一些好用的单测框架和手段，尽量减轻开发人员投入太多精力在单测上。而且要已应用为维度出一些单测的统计数据，定期的发送周报，让其进展透明化，倒逼开发团队坚持落实。

主干开发，持续交付

主干开发的好处在于避免上线前合并分支造成的冲突，能够将问题提前暴露出来。推行主干开发的主要目的是为了：

• 日清日结：所谓的日清日结就是开发不要过多的在本地积压代码，要把当天的工作量都提交到master上，这对开发来说是要有很高要求的，需要开发人员将开发任务做好分层解耦，很多开发提交不上去代码就是因为整个流程一起开发，对应单测还没有跟上，程序编译都失败只能等到开发完一次提交。

• 快速提交，尽早解决冲突代码

• 随时发布：最终的目的是要有一个干净且随时可以投产的master，实现随时入库随时发布。

主干开发有一个致命的问题就是，多需求并行阶段存在不同需求代码由于上线周期不同导致夹带代码提前上线的问题，面对这种问题通常可以从以下几个方面解决：

• 反思我们的分布式系统拆分粒度是否合理，是不是可以继续拆分；

• 两周一迭代的敏捷需求控制的是否合理，正常情况下如果需求迭代周期控制的合理，需求卡片拆分的足够明确是可以避免这种情况的，但是就怕“领导关注的需求，着急上线”这种情况。

• 通过开关控制，对于夹带的代码要有开关控制。这也是通用的解决方式，但是存在开关维护的成本。

• 开发人员尽量要保证每次提交的代码能够独立运行，可以支持夹带上线。

CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题（亦称：“集成地狱”）。具体而言，CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期（从集成和测试阶段，到交付和部署）。这些关联的事务通常被统称为“CI/CD 管道”，由开发和运维团队以敏捷方式协同支持。

平台基于效率云ipipe流程实现集成测试和版本发布，而对于整个效率云的CD价值其实平台落实的并不好，还是有所欠缺的。

搭建案例回归平台

为了模拟生产真实情况，提高案例的覆盖度和准确性，平台从对生产环境的交易基础数据进行脱敏处理后，组装成测试案例在测试环境用于回归。

意识培养

邀请外部专家进行工程能力意识的宣贯培训，提升工程能力理解。并定期组织相关文章竞赛或技术沙龙活动。

应用安全

随着互联网安全越来越重要，尤其是平台这种金融基础设施安全的重要性不言而喻。

通用方案

系统安全涉及多个方面，前期对国内一些头部机构进行调研得出一些通用的解决方案：

• 区域划分：对于专线接入和公网接入的场景要有不同的物理隔离区域，想对应的安全策略也会不同。

• DMZ区建设：流量要在DMZ区落地，在此区域可以做流量的清晰，避免攻击直接渗透到内网，提升攻击成本。

• 安全工具采购：IPS、WAF、HIDS(系统安全扫描工具)、防火墙等设备。

• 风控分析：除对于业务能力外还要具备对于安全攻击的一些风控规则进行分析拦截。

下图是诸多方案中的一种，助于理解。

护网行动

参与护网行动，深度理解攻击场景并作出整改。