主持人：谢谢赵总带来的精彩分享，接下来有请原中国工商银行总行恒丰银行科技部总经理张晓丹，她将跟我们分享新一代两地三中心多活系统规划设计。

恒丰银行科技部总经理 张晓丹

 

张晓丹：大家下午好!开始我的演讲之前，我先问一个问题，在座各位有多少人听说过恒丰银行。基本上还可以看到一半的人，很不幸的是我自己来恒丰银行前半年我都不知道。恒丰银行是我们国家12家全国性股份制银行之一，它一直在默默无闻的经营，经营的整体情况还是不错的，这两年新任董事长过来开始大手笔的弯道超车和快速发展，所以最近可能知名度高一些，在北京的一些1039各方面做一些广告，业务也在拓展。

 

今天我分享的就是两地三中心多活建设的题目。之所以谈这个题目也是说我本人最早从2000年开始参与了当时中国金融界第一代数据中心，也是第一个数据中心的建设，当时在北京的西三旗。从那时开始到现在总体来说应该是第一代、第二代，已经进入到第三代的建设。其实是第三代建设，这一代的数据中心我们到底该怎么建?BAT企业这些云数据中心建设的一些经验和想法对传统金融行业的高可用性、高安全性、高一致性的两地三中心的架构有什么挑战?我们这次开展恒丰银行新的两地三中心建设过程中我们又重新思考了这个课题，做了一些总结，今天也和大家做一些分享。这里面有一些不当的地方，希望大家多提意见，多提建议。

 

首先，为什么要做两地三中心建设?首先有监管要求，要求一千亿资产的银行进行两地三中心的建设，一千亿以上要建设异地数据中心，一千亿资产规模以下建立同城的数据中心，主要满足异地灾难性的要求。同时目的也是会提高可用性，还有包括如何高效的利用它的容量和资源控制成本。有些同事可能认为做一些多活数据中心系统可能用就提高了，面对灾难的能力也提高了。这里其实有一个误区，把连续性和可用性这两个话题没有清晰的界定出来。其实连续性从大的角度来看也是讲可用性，可用性也不是指一个数据中心的可用性。所以，这两个概念到底怎么划分?在我们具体实践中，我个人建议连续性把它界定为主要是考虑应付同城的一个园区级，或者一个地域级的大型的灾难概念，可用性面对的是一个业务应用系统整个的可用性。我们为什么要这样设计?我们设计灾备的时候一定要进行数据的同步控制，而且它会带来耦合性。大家知道一个相对独立的系统肯定不会受另外一个系统的影响，如果两个系统做数据的高度的同步复制，一定是耦合在一起，中间吃先一些问题反而会影响整体的可用性。所以，连续性的发展，过渡重视了灾备，强调了灾备的RTO、RPO的时间一定会反过来影响可用性。

 

另外一个方面，如果我们想提高可用性，像银行这样的传统架构一直是在强调要提高可用性。为了提高可用性，就从不同层次上不断的增加冗余，这种不断的增加冗余以后，最后带来的问题一个是成本很高，冗余容量很大，可能10%的最终冗余容量都用不掉。还有冗余点越多，每个系统的耦合点越多，本质上降低了这个系统的可用性。所以，如何提高可用性，平衡连续性，高效利用容量资源控制成本，这些都是两地三中心建设中要考虑的问题。我们的总体思路仍然是建设两地三中心，而不是强调三个中心一定多活。在传统数据复制的技术无法消除一些本身的技术缺陷之前，三个中心的地位还是有区别的。知生产中心地位最为重要，同城数据中心相对次要，然后异地的中心更加地位低一些。这样的两地三中心来实现我们的一个相对多活的架构。

 

同时，要尽可能的消除各个数据中心与中心之间的网络、应用、数据，各方面的耦合度，避免一个中心的问题会影响另外一个中心。同时，我们要对我们的应用系统进行连续性和可用性的这些方面的分析，对于不同级别的要求，赋予它不同的技术方案、运维方案，来提供不同成本的一个解决方案。所以，这里简单说的连续性，连续性本身防止站点级的灾难。地域级就是这个城市整体出现海啸、地震，大面积的停电、停水这样一个地域级的问题。连续性分为技术的连续性和业务的连续性，业务的连续性就是当你的技术无法解决，要通过业务人员手工补数据等进行解决。用到的一些技术在右边进行了一些罗列。

 

连续性的分级国家有一些标准，一般分为0到5级这样6级的分类，里面核心的指标，一个是RTO，一个是RPO。就是当出现一个灾难，另外一个地方进行恢复的时候有没有丢失。所以，最高级别一般来说RPO就是数据是零，或者接近零。基于这两个指标我们采用同城和异地的方案来满足这个战略的要求。

 

可用性我们更多考虑这个架构从基础设施方面，水冷的水，制冷的功能，还有电力这些方面整个的一些冗余，甚至可能我们要关心到数据中心的上游，用水冷，上游的水源是不是来自两个不同的水库，供电是不是来自两个不同的发电站，甚至要考虑整个数据中心是不是在飞机的主航线下，也担心一些问题。存储级别、服务器系统级别、数据库中间件级别，运营级别分别进行不同的高可用的保证，最终达到高可用的指标。如果一个系统运行达到5个9的可用性，一年停机时间要达到多少?一年系统只能停机5分钟，4个9的可用性，一个系统一年停机时间50分钟，如果想达到4个9和5个9这样的指标不是靠我们的运维，简单靠我们的运维来解决的。必须靠系统的冗余设计来去解决。我们进行可用性的设计主要考虑不同的冗余时间，有些7×24，有些5×8。容量又是一个问题，冗余资源越来越多，最后成本会难以控制。

 

所以，对于不同的连续性级别，在主中心配多少容量，同城配多少容量，异地配多少容量，要有一个总体的规划。所以，总结下来我们做数据中心的设计无外乎就是平衡这三个方面的技术要求，连续性、可用性和容量。刚才可能有一点说的不清楚，这里可能补充一下。我们做数据同步的时候本质上有三种方式，也就是Oracle数据库里面经常用到的一个概念，叫最大保护模式，最大可用是，最大性能模式，最大性能模式是两个数据库异步，这样的数据无法保障RPO的引领。第二种技术叫最大保护，所有的一笔交易写下来，还要同时写到异地的数据中心，这个数据中心是同城的几十公里，或者异地的上千公里，另外一个写完才可以回复上层应用我完成了。但是如果跨度大，性能会急剧下降，所以不可能上千公里的进行部署。在同城50公里范围内可以勉强支持，如果一笔交易中间出现问题，两个系统的耦合点出现一些异常模式，不是完全这边死掉了，这笔交易不成，后续交易全部停在那儿。所以，一般来说，基本上没人太敢用这种模式。

 

第二、最大可用模式，平时是双写，一旦侦测到同步的数据库有一些问题，或者两边的耦合线路有一点问题，质量下降，就把这个同步停下来，所以大部分用这个技术。实际上本质上也是做不到RPO的。银行很多交易量，大的银行，比如工商银行、建设银行，一天的交易量达到三亿笔，如果数据不一致，几乎无法保障。原来传统的银行都是柜面上依据凭条进行交易的目录，出问题大不了把这个重新录一遍。一旦这些数据没有了，你想从这些方面进行慢慢的保障是非常艰难的。

 

所以，在现有的数据库的复制技术环节下，我们很难做到三个中心的同等地位，在同城的两个中心也无法保证同样的地位。现在阿里有一些技术基本可以在同城之间实现数据的多活，是在应用层能实现应用的多写。同时在多写的过程中能实现三写两同步，这个概念实际上就是它在同城有三个数据中心，一笔交易下来，同时往三个中心写，只要任意两个中心回来，他就认为这个交易完成了，可以往下走了。当三个中心之间的耦合，如果任意两个中心出现了它们之间的互通有点不稳定，或者一个中心出现问题了，它不会波及到另外两个中心说不能对外提供业务，原来两个中心就有问题。如果三个中心的耦合一块儿出了问题，也不能对外提供服务了。现在底层的数据库和磁盘都没有这样的技术。我听说下一代的MySql好像往这个方面在考虑，是一个主数据库Master和两个sliver，我们把主中心的高可能性提高的更高，T4级的机房，应用尽可能的双，模块的部署，在主机房里数据库尽量的双Read节点，双磁盘的系统，同城就可以适当在数据库方面只做一个热备。平常可以同步，出问题可以监管，但是在APP层可以进行自动的负载均衡，实现应用服务器和Web服务器层的自动切换和冗余。如果想做到数据的多活其实数据非常大，行业里有人在局部的应用上试，实际上是得不偿失的。

 

所以，基于这些思路，我们总结了一些案例。像这张图，最上层我们用一个全球的负载均衡，靠DNS自动把流量和数据分解到两个数据中心，如果需要有些流量也可以分解到异地的第三个中心，Web层面，APP都是负载均衡，外面用户的访问可以均衡的分在两个中心和三个中心，每个中心可以均衡的负载多个节点，写节点又可以分在两个相对独立的中心模块，但是数据库尽可能解决多可用性，但是同城之间是一个热备，到异地甚至是冷备。这样一个整体的考虑平衡它的连续性要求，还有可用性要求，以及容量方面的一些考虑。所以级别低的应用连续性要求是二级，就是只需要同城灾备，不需要建异地灾备。我的介绍就到这里，谢谢大家!