银行业务连续性管理与异地多活架构

银行业务连续性管理与异地多活架构一、背景业务连续性管理 BCM，对于金融行业来说有着重要意义，特别是银行和证券行业，ATM或者柜面系统取不出钱就意味着挤兑，如果证券交易瞬间无法执行着意味着巨大投资损失。2011年银监会就出台了BCM监管指引，对商业银行的RTO和RPO提出了明确的量化指标。以前银行都采用同城与异地灾备的模式来解决，现在云技术、高容错的分布式技术为BC带来了新思路。越来越多的金融科技公司选择分布式技术实现无停机服务。二、业务连续性管理1、ISO 22301ISO22301是已开发的一套国际框架和基准，用来引导企业识别对公司关键业务功能的潜在威胁，并建立有效的备用体系和流程，以保障利益相关者的利益。它指定了计划、实施、监督、审查和改进企业的业务连续性管理体系的具体要求，从而最大限度地减少突发事件造成的影响。ISO22301提供正规的业务连续性指南，将在突发事件发生期间和之后，保持业务运营。它的目的是尽量降低对产品和服务的影响，确保仍然能够交付产品，或及时恢复运营。该标准适用于在任何行业的各种规模的企业，尤其是在高风险或复杂的环境中运营的全球性企业，立即恢复运营对这类公司是最为重要的。总体上人们对于小概率大影响的事件偏向于过分乐观。尤其是华人的社会文化特点是比较忌讳谈论“天灾人祸”这些我们不太认为可能发生在自己身上的事件。这种意识反映在认识方面就是要么认为风险绝对不可能发生，要么设定业务绝对不可以中断(MTPD=0和 RPO=0)的不合理或不现实持续目标。从技术上看，衡量容灾系统有两个主要指标：RPO（Recovery Point Object）和RTO（Recovery Time Object），其中RPO代表了当灾难发生时允许丢失的数据量；而RTO则代表了系统恢复的时间。最好的情况是RPO=0，RTO=0，但显然这种情况是个理想状态。2、国内银行业BCM要求2011年银监会就出台了BCM监管指引，对商业银行的RTO和RPO提出了明确的量化指标。根据业务重要程度实现差异化管理，确定各业务恢复优先顺序和恢复指标。商业银行应当至少每三年开展一次全面业务影响分析。商业银行应当识别重要业务，明确重要业务归口管理部门、所需关键资源及对应的信息系统，识别重要业务的相互依赖关系，分析、评估各项重要业务在运营中断事件发生时可能造成的经济损失和非经济损失。原则上，重要业务恢复时间目标不得大于4小时，重要业务恢复点目标不得大于半小时。通过分析业务与信息系统的对应关系、信息系统之间的依赖关系，根据业务恢复时间目标、业务恢复点目标、业务应急响应时间、业务恢复的验证时间，确定信息系统恢复时间目标（信息系统RTO）、信息系统恢复点目标（信息系统RPO），明确信息系统重要程度和恢复优先级别，并识别信息系统恢复所需的必要资源。3、国外银行业BCM要求英国BSI（British StandardInstitution）出台了世界上第一个关于业务连续性管理 (BCM) 的英国标准BS 25999，该标准的目的是在最棘手和意外的情况下保证企业的业务持续运行，从而保护企业的员工、维护企业的声誉并提供持续运营的能力。 该标准为在组织内了解、开发和实施业务持续性提供了基础，它包含一套基于 BCM 最佳做法的全面控制措施，涵盖整个 BCM 生命周期。 BS 25999 分两部分制定：o 第 1 部分BCM实践指南于2006年底公布o 第 2 部分BCM规范于 2007 年底公布 BS 25999 适合于各种规模及各行各业的任何组织，尤其适合在高风险环境中运营的组织，例如金融、电信、运输和公共行业。 BSI（British StandardInstitution）成立于1901年，它是世界领先的业务标准服务提供者。4、BCM最佳实践与演练要求灾难恢复国际行业协会 DRII（Disaster RecoveryInstitute International）制定了业务连续管理最佳实践的十个领域。保障重要业务持续运营的一整套管理过程，包括策略、组织架构、方法、标准和程序。将业务连续性管理纳入全面风险管理体系。重要业务是指面向客户、涉及账务处理、时效性要求较高的银行业务，其运营服务中断会对商业银行产生较大经济损失或声誉影响，或对公民、法人和其他组织的权益、社会秩序和公共利益、国家安全造成严重影响的业务。将业务连续性管理融入到企业文化中，使其成为银行机构日常运营管理的有机组成部分。主要干系人要求如下图：应当至少每三年对全部重要业务开展一次业务连续性计划演练，国内审计要求一般是每年至少一次。商业银行应当至少每年对业务连续性管理体系的完整性、合理性、有效性组织一次自评估，或者委托第三方机构进行评估，并向高级管理层提交评估报告。对于交易所和登记结算公司还可能每季度要求全网参与机构进行一次切换演练。商业银行在完成业务连续性计划的全行性演练后，应当在45个工作日内向监管机构提交演练总结报告。运营中断事件发生后2小时内上报，对于特别重大（I级）的运营中断事件，上报国务院。特别重大（I级）和重大（级）运营中断事件，银监会处置工作小组可以赴事发银行现场进行督导。必要时，可以协调国家专业技术队伍或外部专家提供技术支援。三、建立多活保证高可用1、目标 满足监管要求 满足全行业务连续性要求 实现一键切换 缩短计划内停机时间我们可以看一下业界比较主流的灾备是怎么做的？最主流的灾备技术是两地三中心，数据中心A和数据中心B在同城作为生产级的机房，当用户访问的时候随机访问到数据中心A或B。之所以随便访问，因为A和B会同步做数据复制，所以两边的数据是完全一样的。但是因为是同步复制的，所以只能在同城去做两个数据中心，否则太远的话同步复制的延时会太长。在两地三中心的概念里，一定会要求这两个生产级的数据中心是必须在同一个城市，或者在距离很近的另外一个城市也可以，但是距离是有要求的，一般要求在60公里之内，比如雄安和北京城区。异地备份数据中心通过异步数据复制来实现，银行两地三中心的特点是异地备份数据中心一般不作为关键应用宿主地，某些情况下是完全冷备，有些机构的做法是将统计分析和非关键的内部管理系统放到灾备机房。对于关键业务应用异地灾备中心不对外服务，所以用户不会访问到异地的点。原因是因为数据从生产级数据中心到异地的节点是异步去复制，所以整个有延时。这个模式在灾难到来的情况下可能会出现冷切换的问题，不能很顺畅的切换，虽然在平时的演练中，已经模拟了生产切换，但往往是众多情况中比较乐观的设定。另外一种模式为异地多活模式，也是目前正在兴起的一种模式，对于某些大型银行的核心关键应用已经在此模式下进行了成功验证。异地多活首先是要做到同城双活或者同城多活，就是数据在同城网络环境下进行高速备份，也可以在做楼宇级同步，一般在10ms类的数据差异。异地多活需要多个跨地域的数据中心。异地多活是跨地域的，而且距离一定要做到1000公里以上的范围，其实在中国范围内全国城市都可以去部署了。降低数据同步量，同步服务根据一定业务键通过ZooKeeper路由到对应的主数据中心，备数据中心可以通过旁路报文或者异步数据同步方式补全。2、互联网行业多活架构最近十年，互联网发生了翻天覆地的变化，现在的互联网服务相比于银行系统有以下几个特点：访问量大、并发量大、非强一致要求、RTO和RCO要求都非常高、低成本。在这些要求的前提下，产生了一套适用于互联网行业的多活架构。互联网的多活架构通常是双活双中心+混合云的方式，基于各种自研组件，开源组件和MySQL数据库来实现多活。下图是多活双中心示意图。下图是多活双中心与公有云示意图。双中心主要实现业务架构的双活，任意一个机房挂掉，可以快速地切换到另外一个机房。混合云的架构主要为机房提供快速扩容的弹性能力。在实践这个架构时，有几个关键点： 单元化 前端路由 数据路由 数据同步单元化单元化是多活架构的基石。单元化通常有几个维度：用户维护，功能维度，用户与功能的混合模式，作为电商，核心业务只有一个，就是购物流程。我们一定要确保购物流程的高可用。因此购物流程功能肯定不能拆分成更细的单元,如果拆分后，那么购物流程的一个单元不能用，整个购物流程就不通了。咱的双活也就失败了。所以我们会选择用户维度的单元化。前端路由前端路由的主要目的是解决如何快速地将用户切换到正常服务的机房，传统是通过DNS来切换，但是这个切换受限于DNS缓存的生效周期，并且最多只能做到地区，很难做到细粒度的路由控制。现在常用的有两种方案：一、通过中间件的方式，所有用户进入同一的用户端路由中间件，有中间件去决定用户走什么路由。优点是控制力非常好，缺点是如果用户量和请求量太大，中间件存在性能瓶颈。二、通过APP端路由的方式，下发路由策略到APP端，由APP端完成用户路由，选择正确的机房。数据路由虽然我们有一层前端路由，但是由于现在入口非常多，H5、APP、PC、小程序等等。 我们很难将所有的入口都能做到100%走路由，甚至还有一部分路程是在后台或者service层自己发起的。那么问题来了，这部分没有经过前端路由的用户数据是否会出现异常？答案是：肯定会的。因为我们的数据是异地多份存储的，考虑到数据库的性能，我们在写入数据的时候是不能去给所有机房的这条数据上锁，也就是我们的ACID是在本地机房级别的。为了避免不同机房出现数据最终不一致的问题，我们需要限制数据的写入点，一条数据只能在一个机房写入，避免两个机房同时写一条数据导致的数据最终不一致问题。为了实现这个目的，我们需要一层数据路由。所谓数据路由，就是在程序链接数据库之前，在DAL层，或者驱动层，或者框架，ORM层等上面的一层路由。确保落地的数据是能落到正确的机房，以保证数据的最终一致性。数据同步根据我们的需求，做了基础调研以后，发现有以下几种方法可以实现我们需要的数据同步功能。1. 基于MySQL的原生复制，做主主架构，两边都开启写入2. 基于PXC类似的数据库集群方案3. 基于OTTER的数据同步方案4. 自己开发一套数据库同步系统在有现有软件满足我们需求的前提下，我们是不优先考虑自己开发的。毕竟重复自造轮子的开销不小，而且需要比较长的一个时间来验证轮子的稳定性。所以优先在前面三个方案里面做了深度调研。OTTER：优点：1. 两个机房的MySQL独立，本地机房做维护切换架构清晰，简单2. 如果数据同步异常的时候，推移位点可以保证数据的一致性3. 与MySQL版本无关，可实现低版本往高版本复制，方便升级4. 在公司的汇总库中使用，已经有比较深的使用经验缺点：引进了新的技术，存在风险，需要评估风险是否可控。MySQL原生复制：优点：原生的复制协议，大家都熟悉，可控度比较好缺点(未使用GTID)：1. 会增加架构的复杂度，级联复制2. 如果数据同步异常的时候，寻找同步位点比较麻烦3. 如果其中一个master的机器坏掉，会导致同步的位点丢失4. 三机房以后架构不支持PXC：优点：1. 通过Galera实现的无共享的分布式数据库2. 使用同步复制，可以完全保证数据的一致性3. 节点自动配置缺点：1. PXC我们团队还没有使用案例，在核心的双活架构中使用，存在很大的不可控风险2. Galera对网络延时比较敏感，在跨机房应用中，这是一个很大的性能瓶颈。