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