CN109819004A - 用于部署多活数据中心的方法和系统 - Google Patents

Abstract

本公开内容涉及一种用于部署多活数据中心的方法和系统。该方法包括基于多活数据中心的高可用或灾备需求来选择相应级别多活架构，其中多活数据中心能够被部署在多种标准级别的多活架构中的任一级别多活架构。该方法还包括根据所选择的相应级别多活架构来部署多活数据中心，并且在一个数据中心发生故障时，基于相应级别多活架构来将一个数据中心的业务切换到另一个数据中心。本公开的实施例通过将多活数据中心划分成多个标准级别，能够根据应用系统的高可用或灾备需求部署多活数据中心，使得多活数据中心的部署和运行更标准并且更规范。

Description

用于部署多活数据中心的方法和系统

技术领域

本公开的实施例总体上涉及信息技术领域，更具体地涉及用于部署多活数据中心的方法和系统。

背景技术

多活数据中心是指两个或两个以上数据中心同时承载企业的各类业务生产运行功能，以提高这些数据中心的整体服务能力和系统资源利用率。也即，多个数据中心都是生产中心，数据中心的地理位置对用户透明并且与用户客户端访问无关。在多活数据中心的架构中，当某个数据中心出现重大灾难或故障，或紧急需要迁移生产运行负载到另一数据中心时，能够在较短时间内比较平滑地在多个数据中心之间切换应用负载，以达到数据中心的灾难恢复、故障应急切换或者负载平衡等目的。

多活应用系统是指能够在多个数据中心部署并且应用负载可以在多个数据中心间切换或在多个数据中心可以同时处理应用负载的系统，也就是说，应用系统是多活的。多活数据中心通过基础平台进行运维管理，基础平台承载所有应用系统的运行，是系统稳定运行、高可用且高效的重要保障。基础平台通常包括系统软件平台(例如操作系统、数据库等)、硬件平台(服务器、存储装置等)以及系统架构这三个部分。

发明内容

本公开的实施例提出了一种用于部署多活数据中心的方法和系统。本公开的实施例通过将多活数据中心划分成多个标准级别，能够根据系统的高可用或灾备需求部署多活数据中心，使得多活数据中心的部署和运行更标准并且更规范。

根据本公开的第一方面，提供了一种用于部署多活数据中心的方法，其中多活数据中心至少包括第一数据中心和第二数据中心。该方法包括：基于多活数据中心的高可用或灾备需求，选择相应级别多活架构，其中多活数据中心的多活标准架构至少包括第一级别多活架构、第二级别多活架构以及第三级别多活架构；根据所选择的相应级别多活架构，部署多活数据中心；以及响应于第一数据中心发生故障，基于相应级别多活架构来将第一数据中心的业务切换到第二数据中心。其中，在第一级别多活架构中，多活数据中心通过分布式数据库实现数据同步；在第二级别多活架构中，第一类型的数据被写入到第一数据中心并且被同步到第二数据中心，而第二类型的数据被写入到第二数据中心并且被同步到第一数据中心；以及在第三级别多活架构中，数据仅被写入到第一数据中心并且在数据层被同步到第二数据中心。

根据本公开的第二方面，还提供了一种用于部署多活数据中心的系统，其中多活数据中心包括：第一数据中心，其包括第一服务器和第一数据库；以及第二数据中心，其包括第二服务器和第二数据库。其中该系统至少能够将多活数据中心部署在第一级别多活架构、第二级别多活架构或第三级别多活架构，并且系统被配置为响应于第一数据中心发生故障来将第一数据中心的业务切换到第二数据中心，其中，在第一级别多活架构中，多活数据中心通过分布式数据库实现数据同步；在第二级别多活架构中，第一类型的数据被写入到第一数据中心并且被同步到第二数据中心，而第二类型的数据被写入到第二数据中心并且被同步到第一数据中心；以及在第三级别多活架构中，数据仅被写入到第一数据中心并且在数据层被同步到第二数据中心。

附图说明

结合附图并参考以下详细说明，本公开的各实施例的特征、优点及其他方面将变得更加明显，在此以示例性而非限制性的方式示出了本公开的若干实施例，在附图中：

图1图示了根据本公开的实施例的多活数据中心的架构的示意图；

图2图示了根据本公开的实施例的用于部署多活数据中心的方法的流程图；

图3图示了根据本公开的实施例的应用系统的七层基础平台架构的示图；

图4图示了根据本公开的实施例的被部署在第一级别多活架构的多活数据中心的示意图；

图5图示了根据本公开的实施例的被部署在第二级别多活架构的多活数据中心的示意图；

图6图示了根据本公开的实施例的被部署在第三级别多活架构的多活数据中心的示意图；

图7图示了根据本公开的实施例的被部署在第四级别多活架构的多活数据中心的示意图；以及

图8图示了根据本公开的实施例的被部署在第五级别多活架构的多活数据中心的示意图。

具体实施方式

以下参考附图详细描述本公开的各个示例性实施例。附图中的流程图和框图示出了根据本公开的各种实施例的方法和系统的可能实现的体系架构、功能和操作。应当注意，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，所述模块、程序段、或代码的一部分可以包括一个或多个用于实现各个实施例中所规定的逻辑功能的可执行指令。也应当注意，在有些作为备选的实现中，方框中所标注的功能也可以按照不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，或者它们有时也可以按照相反的顺序执行，这取决于所涉及的功能。同样应当注意的是，流程图和/或框图中的每个方框、以及流程图和/或框图中的方框的组合，可以使用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以使用专用硬件与计算机指令的组合来实现。

本文所使用的术语“包括”、“包含”及类似术语应该被理解为是开放性的术语，即“包括/包含但不限于”，表示还可以包括其他内容。在本公开内容中，术语“基于”是“至少部分地基于”；术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”。

应当理解，给出这些示例性实施例仅是为了使本领域技术人员能够更好地理解进而实现本公开的实施例，而并非以任何方式限制发明的范围。

传统地，为了保证数据的可靠性，通常建设双活或更多活的数据中心，以用于灾备、负载均衡等需求。然而，传统的技术中对多活的架构缺少相关标准和规范，因而无法准确且高效地对多活数据中心进行分级和部署。

本公开的实施例提出了一种用于部署多活数据中心的方法和系统，其目的在于为企业或组织的应用系统进行多活部署实施提供分级分类依据和相应的架构参考模型,为关键系统实现数据中心级的高可用部署提供相关的规范指引。因此，本公开的实施例通过将多活数据中心划分成多个标准级别，能够根据系统的高可用或灾备需求部署多活数据中心，使得多活数据中心的部署更标准并且更规范。

此外，根据本公开的实施例，使用全局负载均衡器来实现数据中心之间的负载平衡，并且使用本地负载均衡器来实现单个数据中心内部的负载平衡。负载均衡是一种服务功能，利用这种服务可以通过横向扩展(即增加服务器数目)的方式来增加服务器的总体处理能力和吞吐量。按照不同的分类方式，负载均衡可分类为全局负载均衡和本地负载均衡、软件负载均衡和硬件负载均衡、路由模式以及桥接模式，等等。

以下参考图1-8描述了本公开的实施例的一些示例实现。

图1图示了根据本公开的实施例的多活数据中心100的架构的示意图。如图1所示，多活数据中心100包括数据中心110(也称为“第一数据中心”)和数据中心120(也称为“第二数据中心”)，这两个数据中心通过网络130相连接，其中网络可以是任何有线和/或无线网络。可选地，网络可以包括但不限于因特网、广域网、城域网、局域网、虚拟专用网络(VPN)网络、无线通信网络，等等。

每个数据中心可以包括服务器、数据库以及网络交换设备等，如图1所示，数据中心110包括服务器111、112、数据库113以及网络交换机114，而数据中心120包括服务器121、122、数据库123以及网络交换机124。本领域技术人员应当理解，虽然图1中仅示出了两个数据中心110和120，但是多活数据中心100可以包括更多个数据中心；此外，数据中心110和120也可以包括未示出的其他硬件元件和/或软件模块。

与传统的主备方式灾备不同之处在于，图1中的数据中心110和120同时承载业务生产运行功能，也就是说，应用系统可以同时在多个数据中心提供服务，因此多活的分级就以应用系统在各数据中心“活”的程度(即同一个应用系统在各个数据中心的访问处理量的比例)作为主要依据。另外，还以应用系统在中心之间可切换的访问流量的“粒度”或单位大小作为参考依据，单位大小越小，级别越高。一般来说，可切换访问流量的单位越小，切换的速度越快。当其中一个数据中心发生重大灾难(例如地震)或重大故障等时，多活数据中心100中的业务负载可以切换到另一个数据中心，从而达到灾难恢复、故障应急切换等目的。

图2图示了根据本公开的实施例的用于部署多活数据中心的方法200的流程图。在202，基于多活数据中心的高可用或灾备需求，选择相应级别多活架构，其中多活数据中心可以被部署在多个标准的多活架构中。例如，如果对于灾备需求过高，可以选择较高级别的多活架构，以保证应用系统的可靠性和灾备切换效率。

在一些实施例中，多活数据中心(例如多活数据中心100)可以被部署在第一级别多活架构(以下参考图4描述了第一级别多活架构的示例实现)，其中多活数据中心通过分布式数据库实现数据同步。在一些实施例中，多活数据中心100可以被部署在第二级别多活架构(以下参考图5描述了第二级别多活架构的示例实现)，其中第一类型的数据被写入到第一数据中心110并且被同步到第二数据中心120，而第二类型的数据被写入到第二数据中心120并且被同步到第一数据中心110。在一些实施例中，多活数据中心100可以被部署在第三级别多活架构(以下参考图6描述了第三级别多活架构的示例实现)，其中数据仅被写入到第一数据中心110并且在数据层被同步到第二数据中心120。

在一些实施例中，多活数据中心100还可以被部署在第四级别多活架构(以下参考图7描述了第四级别多活架构的示例实现)，数据仅被写入到第一数据中心110并且在存储层被同步到第二数据中心120，其中在第四级别多活架构中，第一数据中心110和第二数据中心120均部署应用层和数据层环境。在一些实施例中，多活数据中心100可以被部署在第五级别多活架构(以下参考图8描述了第二级别多活架构的示例实现)，其中数据仅被写入到第一数据中心110并且在存储层被同步到第二数据中心120，其中在第五级别多活架构中，第一数据中心110部署应用层和数据层环境，而第二数据中心120没有部署应用层和数据层环境。

在204，根据所选择的相应级别多活架构，部署多活数据中心。例如，可以根据相应级别多活架构的标准，自动地部署多活数据中心100。备选地，也可以根据标准人工地进行部署。在一些实施例中，在部署多活数据中心的过程中，可以根据相应的架构标准，构建相应的软硬件环境。

在206，响应于第一数据中心发生故障，基于相应级别多活架构来将第一数据中心的业务切换到第二数据中心。根据不同级别的多活架构，对故障的处理方式也不同。其中，在第一级别多活架构中，由全局负载均衡器直接将第一数据中心110中的业务切换到第二数据中心120。在第二级别多活架构中，将由第一数据中心110中可读写且由第二数据中心120仅可读的第一类型的数据切换到由第二数据中心120可读写，以及由全局负载均衡器将第一数据中心110中的业务切换到第二数据中心120。在第三级别多活架构中，在数据层将多活数据中心的主数据中心从第一数据中心110切换到第二数据中心120，以及由全局负载均衡器将第一数据中心110中的业务切换到第二数据中心120。

在第四级别多活架构，在存储层将多活数据中心的主数据中心从第一数据中心110切换到第二数据中心120，以及由全局负载均衡器将第一数据中心110中的业务切换到第二数据中心120。在第五级别多活架构中，在存储层将多活数据中心的主数据中心从第一数据中心110切换到第二数据中心120，在第二数据中心120中部署应用层和数据层环境，以及由全局负载均衡器将第一数据中心110中的业务切换到第二数据中心120。以下参考图4-8将详细描述不同级别的多活架构对于故障的处理过程。

因此，根据本公开的实施例，通过将多活数据中心划分成多个标准级别，能够根据系统的高可用或灾备需求部署多活数据中心，使得多活数据中心的部署更标准并且更规范。本领域技术人员应当理解，在不超出所附的权利要求的范围的情况下，不排除有各种其他的实现方式，只要其能够实现满足根据本公开的实施例的各个级别的多活架构的概念即可。

图3图示了根据本公开的实施例的应用系统300的七层基础平台架构的示图。应用系统300包括数据中心310、320以及330，其分别包括基础平台架构的七层，即访问接入层311、321、331、Web层312、322、332、应用层313、323、333、数据层314、324、334、系统平台层315、325、335、存储层316、326、336以及网络层317、327、337。不同级别多活架构的多活应用系统具有不同的业务特点和技术特点，对多活部署架构有不同的要求，具体技术实现方式会体现在七层中不同的层次，因此各级多活应用系统需要按照不同的多活建设标准进行部署。

如图3所示，访问接入层311、321、331是将客户端导向不同的多活中心web服务器/应用服务器的技术层，通常是指数据中心之间的负载均衡。web层312、322、332是指应用系统中的web服务器部分；应用层313、323、333是指应用系统中的应用服务器部分；数据层314、324、334是指应用系统中的数据服务器部分，一般是指数据库服务器，也可以是文件数据；系统平台层315、325、335是指应用系统中的服务器及操作系统部分；存储层316、326、336是指应用系统中的数据所存储的存储设备部分，例如磁盘阵列；以及网络层317、327、337是指支撑应用系统的网络架构部分。根据本公开的实施例，应用数据的多活部署实施主要在数据层314、324、334或存储层316、326、336来进行实现。

本公开的实施例所提出的针对多活数据中心的标准架构可以被分为五个级别，分别为以下参考图4所描述的第一级别多活架构、参考图5所描述的第二级别多活架构、参考图6所描述的第三级别多活架构、参考图7所描述的第四级别多活架构以及参考图8所描述的第五级别多活架构。应用系统多活分级由高到低分为从第一到第五共五个级别(第一级别要求最高)。多活级别越高，应用系统的访问流量在多活中心的分布越均衡，可切换的访问流量的单位越小，切换的速度越快，整体切换速度越快，即恢复目标时间(RTO)越小。

第一级别多活架构

图4图示了根据本公开的实施例的被部署在第一级别多活架构的多活数据中心400的示意图。在第一级别多活架构中，应用系统在多活的三个数据中心中的至少两个数据中心，可分配均衡的可读写数据的访问流量。当某数据中心发生重大故障、或根据个数据中心的资源情况等其他需要，可灵活快速地切换任意数量的访问流量到其他数据中心。可以将这级多活看作跨数据中心部署的应用系统集群，并且负载均衡策略基本没有受到地域的限制和影响。

如图4所示，多活数据中心400包括数据中心410、420以及430。这些数据中心在接入层分别包括全局负载均衡器411、421以及431，在web层分别包括web服务器412、422以及432，在应用层分别包括应用服务器413、423以及433。如图4中的实线441、442以及443所示，外部用户设备的客户端450可以访问多活数据中心400中的任一个数据中心以进行数据通信。如图4中的虚线444和445所示，全局负载均衡器411可以对全局访问进行负载均衡，例如可以将访问数据中心410的流量导到数据中心420或430。应当理解，数据中心410、420以及430中还可以包括本地负载均衡器(未示出)，以用于对本地的软件和/或硬件设备进行负载均衡。

如图4所示，在数据层，数据中心410还包括数据库414，数据中心420还包括数据库424，数据中心430还包括数据库434。如箭头461和462所示，不同数据中心中的数据库通过分布式数据库技术来同步数据。因此，在第一级别多活架构中，各个数据中心都能读写数据，并且通过分布式数据库技术实现实时同步，相应地，多活数据中心400也能够非常均衡。

实现第一级别多活架构的应用系统，在各个数据中心都可进行读写访问，可以灵活地在数据中心间实现负载均衡，理论上可以不考虑地域的因素，从而实现在多个数据中心的多活部署。

在数据层采用跨中心的分布式数据库来提供数据服务。分布式数据库作为一个统一的实例运行在各个数据中心。各数据中心的数据节点都是整体实例的一部分，都可以处理读写访问请求。数据库实例自动实现数据中心间的数据同步、数据一致性、可用性等特性，应用层不需了解这些特性，只需当作本地数据库来进行正常读写访问。理论上客户访问流量可以灵活地按照任意的策略在各个数据中心间进行分配。通过全局负载均衡设置相应的策略，将客户端的访问流量导向各个数据中心。

第一级别多活架构中的正常多活处理

接入层处理：客户端的访问进入接入层后，应用访问的地址域名通过域名服务器(DNS)服务器进行解析，DNS指向全局负载均衡器(三个数据中心的全局负载均衡为主备模式)，全局负载均衡根据策略进行地址解析，将主要访问流量导向三个数据中心的web层/应用层。

Web层/应用层处理：客户端访问进入web层(或应用层)后，本地负载均衡器负责在中心内部的负载均衡，根据策略将访问流量分担到web服务器群(或应用服务器群)，实现本地的负载均衡处理。

数据层的处理：数据层处理来自应用层的数据访问请求，并将对数据的修改更新到分布式数据库实例，分布式数据库实例在每个中心都能处理数据读写的请求。数据实例自动实现在各个数据中心的数据更新同步、数据一致性等功能。

第一级别多活架构中的故障切换处理

故障切换的处理过程以数据中心410发生重大故障，应用流量切换到其他数据中心为例进行说明。切换过程包括数据层的切换和接入层的切换两部分，下面分别进行说明。

在数据层的切换方面，当数据中心410发生重大故障不可用时，分布式数据库在数据中心410的部分不能提供服务。由于数据在各个数据中心都有实时副本，分布式数据库在其他两个数据中心420和430的实例仍然能够实时的读写访问服务，切换由数据库实例自动完成。

在接入层的切换方面，在接入层对客户端的访问流量进行切换。如果是在数据中心级故障情况下，全局负载均衡器自动切换至数据中心420，全局负载均衡器能够根据策略自动解析应用程序地址到正常的两个中心，因此原数据中心410的流量就被另外两个数据中心420和430接管。如果是主动进行的数据中心410的负载切换移出，需要在全局负载均衡设备调整策略，将数据中心410的地址移除，则后续客户端访问流量都导入另外两个数据中心。

第二级别多活架构

图5图示了根据本公开的实施例的被部署在第二级别多活架构的多活数据中心500的示意图。在第二级别多活架构中，应用系统在多活的三个数据中心中的至少两个数据中心，可分配基本均衡的可读写数据的访问流量。应用系统的访问流量，都按某种单位(比如：地域、机构、存储单元等)分组，每个数据中心分成若干组。并且当某个数据中心发生重大故障、或根据两个数据中心的资源情况等其他需要，可灵活快速地切换某一组或多组可读写数据的访问流量到其他数据中心。

如图5所示，多活数据中心500包括数据中心510、520以及530。这些数据中心在接入层分别包括全局负载均衡器511、521以及531，在web层分别包括web服务器512、522以及532，在应用层分别包括应用服务器513、523以及533。如图4中的实线541、542以及543所示，外部用户设备的客户端550可以访问多活数据中心500中的任一个数据中心以进行数据通信。如图4中的虚线544和545所示，全局负载均衡器511可以对全局访问进行负载均衡，例如可以将访问数据中心510的流量导到数据中心520或530。应当理解，数据中心510、520以及530中还可以包括本地负载均衡器(未示出)，以用于对本地的软件和/或硬件设备进行负载均衡。

如图5所示，在数据层，数据中心510还包括数据库514、515、516、517、518以及519，数据中心520还包括数据库524、525、526、527、528以及529，以及数据中心530还包括数据库534、535、536、537、538以及539。其中数据库514和515是由数据中心510可读写，并且如箭头561所示，被复制到数据中心520中形成数据库524和525，如箭头562所示被复制到数据中心530中形成数据库534和535。因此，数据库524和525、数据库534和535是数据库514和515的拷贝，但是数据中心520数据库524和525可读，数据中心530仅对数据库534和535仅可读，而不能进行写入。类似地，数据中心520中可读写的数据库526和527如箭头563和564所示被复制到数据中心510和530，数据中心530中可读写的数据库538和539如箭头565和566所示被复制到数据中心510和520。

实现第二级别多活架构的应用系统，在各个数据中心都可进行读写访问，应用系统的访问流量按照一定的规则形成若干分组，每个中心都分配一定数量的分组访问流量，从而实现在多个数据中心的多活部署。

实现第二级别多活架构，关键点是需要将应用系统的数据也进行相应的切分，切分的可以按照地域、机构等单位进行。数据切分后的各个部分，分布在各个多活中心，可读写访问。如果数据层采用的是数据库系统，数据切分还需要通过分库分表的中间件技术来实现。如果数据层是文件数据等其他形式，则简单地按照切分单位分开部署数据即可。

实现多活部署，数据必须在每个中心都有副本。因此实现上文数据切分后的一部分数据在一个中心可读写访问，则该部分数据需要实时复制到其他数据中心，可只读访问。如果数据层是数据库系统，可采用数据库系统的数据复制技术。如果数据层是其他数据形式，则通过存储系统的远程复制技术。

与数据切分后的分布相对应，客户访问流量也按照相同的单位分成组。流量分组在接入层通过全局负载均衡来实现。每个数据中心都分配有若干个分组(比如：按照客户所属的地域分组)，通过全局负载均衡设置相应的策略，将客户端的访问流量导向各数据中心。

例如，数据层的六个数据库分别表示六个省的数据，其中数据中心510承载第一省和第二省的可读写数据(表示为数据库514和数据515)，数据中心520承载第三省和第四省(表示为数据库526和数据527)的可读写数据，数据中心530承载第五省和第六省(表示为数据库538和数据539)的可读写数据。也就是说，数据库514、524和534存储第一省的数据，数据库515、525和535存储第二省的数据，数据库516、526和536存储第三省的数据，数据库517、527和537存储第四省的数据，数据库518、528和538存储第五省的数据，以及数据库519、529和539存储第六省的数据。

第二级别多活架构中的正常多活处理

接入层的处理：客户端的访问进入接入层后，应用访问的地址域名通过DNS服务器解析，DNS指向全局负载均衡器(三个数据中心的全局负载均衡为主备模式)，全局负载均衡根据客户端源地址策略进行地址解析，从而将六个省的访问流量导向对应的三个数据中心的web层/应用层。

Web层/应用层：客户端访问进入web层(或应用层)后，本地负载均衡器负责在中心内部的负载均衡，根据策略将访问流量分担到web服务器群(或应用服务器群)，实现本地的负载均衡处理。

数据层的处理：数据层处理来自应用层的数据访问需求，应用服务器将数据更新储存到本中心对应的两个省的数据实例，即在每个中心可读写访问应用系统的两个省数据。数据多活必须要做到每份数据在各个数据中心有实时副本，因此每个省的数据要通过实时复制数据技术复制到其他两个数据中心，可以是只读访问。

第二级别多活架构中的故障切换处理

故障切换的处理过程以数据中心510的第二省的访问流量切换到数据中心520为例进行说明，数据中心全部故障的切换过程原理基本相同。切换过程包括数据层的切换和接入层的切换两部分，下面分别进行说明。

在数据层的切换方面，现假设因为故障或某种原因决定切换第二省的访问流量到中心520。数据层的切换步骤：将第二省对应的据库515实例的复制关系，从以数据中心510为主、数据中心520和数据中心530为从的复制关系，切换到以数据中心520为主、数据中心510和数据中心530为从的复制关系。在切换完成之后，数据中心510的可读写数据库实例包括“数据库514”，而数据中心520的可读写数据库实例包括“数据库525”、“数据库526”以及“数据库527”。

在接入层的切换方面，在接入层对客户端的访问流量进行切换。如果是在数据中心级故障情况下，全局负载均衡器自动切换至数据中心520，全局负载均衡器能够根据策略自动解析应用程序地址到数据中心520。如果是主动进行的切换，需要在全局负载均衡设备调整策略，将原来第二省的访问请求，解析的IP地址从数据中心510切换到数据中心520的地址，从而实现客户端的访问的切换。

第三级别多活架构

图6图示了根据本公开的实施例的被部署在第三级别多活架构的多活数据中心600的示意图。在第三级别多活架构中，应用系统在多活的三个数据中心中的至少两个数据中心，在其中的主数据中心分配可读写数据的访问流量，在从数据中心仅分配只读数据的访问流量，从数据中心的数据为实时与主数据中心同步并且实时可访问的。并且当主数据中心发生重大故障、或其他需要紧急切换的情况，可快速地将主数据中心的全部可读写的访问流量切换到从数据中心。

如图6所示，多活数据中心600包括数据中心610、620以及630。这些数据中心在接入层分别包括全局负载均衡器611、621以及631，在web层分别包括web服务器612、622以及632，在应用层分别包括应用服务器613、623以及633。如图6中的实线641、642以及643所示，外部用户设备的客户端650可以访问多活数据中心600中的任一个数据中心以进行数据通信。如图6中的虚线644和645所示，全局负载均衡器611可以对全局访问进行负载均衡，例如可以将访问数据中心610的流量导到数据中心620或630。应当理解，数据中心610、620以及630中还可以包括本地负载均衡器(未示出)，以用于对本地的软件和/或硬件设备进行负载均衡。

如图6所示，在数据层，数据中心610还包括数据库614，数据中心620还包括数据库624，以及数据中心630还包括数据库634。如箭头661和662所示，数据库614中的数据被单向地复制到数据库624和634。由于数据中心610是主数据中心而数据中心620和630是从数据中心，所有的数据都在数据中心610可读写，而在数据中心620和630仅可读。

实现第三级别多活架构的应用系统，在主数据中心可进行读写访问，在从数据中心可以进行只读数据的访问，从而实现在多个数据中心的多活部署。

整个应用系统的数据作为一个整体实例，在三个数据中心中选择一个中心作为主数据中心(数据中心610)，其他两个中心作为从数据中心(数据中心620和数据中心630)。数据实例在主数据中心可读写访问，在从数据中心可只读访问。主数据中心的数据需要实时复制到从数据中心的数据实例。如果数据层是数据库系统，可采用数据库系统的数据复制技术。

客户端的流量分配策略同数据的主从分离相匹配，通过全局负载均衡来实现。通过全局负载均衡的策略，应用系统对数据的读写类型的客户访问流量，全部导向主数据中心(数据中心610)，从数据中心为备份。其他对数据仅有只读访问需求的应用程序，客户访问流量可导向从数据中心(数据中心620和中心630)。

第三级别多活架构中的正常多活处理

接入层处理：客户端的访问进入接入层后，应用访问的地址域名通过DNS服务器解析，DNS指向全局负载均衡器(三个数据中心的全局负载均衡为主备模式)，全局负载均衡根据策略进行地址解析，将主要访问流量导向主数据中心(数据中心610)的web层/应用层。

web层/应用层：客户端访问进入web层(或应用层)后，本地负载均衡器负责在中心内部的负载均衡，根据策略将访问流量分担到web服务器群(或应用服务器群)，实现本地的负载均衡处理。

数据层的处理：数据层处理来自应用层的数据访问需求，并将对数据的修改更新到主数据中心对应的数据实例。数据多活必须要做到数据在各个数据中心有实时副本，因此数据要通过实时复制数据技术复制到其他两个数据中心，副本数据可供其他应用程序只读访问需求。

第三级别多活架构中的故障切换处理

故障切换的处理过程以数据中心610的访问流量切换到数据中心620为例进行说明。切换过程包括数据层的切换和接入层的切换两部分，下面分别进行说明。

数据层的切换方面，现假设因为故障或某种原因决定切换主数据中心(数据中心610)整体应用访问流量到从数据中心(数据中心620)。首先实现数据层的切换，将数据实例的主从复制关系，从以数据中心610为主、数据中心620和数据中心630为从的复制关系，切换到以数据中心620为主、数据中心610和数据中心630为从的复制关系。切换完成后，数据中心620的数据实例为主实例，可提供应用程序读写访问，数据中心610和数据中心630的数据实例为从实例。

接入层的切换方面，在接入层对客户端的访问流量进行切换。如果是在数据中心级故障情况下，全局负载均衡器自动切换至数据中心620，全局负载均衡器能够根据策略自动解析应用程序地址到数据中心620。如果是本例中主动进行的数据中心610到数据中心620的切换，需要在全局负载均衡设备调整策略，将原来用户客户端的访问请求，解析的IP地址从数据中心610切换到数据中心620的地址，从而实现应用客户端的访问的切换

第四级别多活架构

图7图示了根据本公开的实施例的被部署在第四级别多活架构的多活数据中心700的示意图，在第四级别多活架构中，应用系统在多活的三个数据中心中的至少两个数据中心，在其中的主数据中心分配可读写数据的访问流量，从数据中心的数据实时与主数据中心同步但不可实时访问，可通过存储克隆等技术提供给某些应用系统进行准实时数据的访问。并且当主数据中心发生重大故障、或其他需要紧急切换的情况，可快速切换主数据中心的全部可读写的访问流量到从数据中心

如图7所示，多活数据中心700包括数据中心710、720以及730。这些数据中心在接入层分别包括全局负载均衡器711、721以及731，在web层分别包括web服务器712、722以及732，在应用层分别包括应用服务器713、723以及733，在数据层分别包括数据库714、724以及734。如图7中的实线741、742以及743所示，外部用户设备的客户端750可以访问多活数据中心700中的任一个数据中心以进行数据通信。如图7中的虚线744和745所示，全局负载均衡器711可以对全局访问进行负载均衡，例如可以将访问数据中心710的流量导到数据中心720或730。应当理解，数据中心710、720以及730中还可以包括本地负载均衡器(未示出)，以用于对本地的软件和/或硬件设备进行负载均衡。

如图4所示，在存储层，数据中心710包括存储装置715，数据中心720包括存储装置725，以及数据中心730包括存储装置735，其中存储装置可以例如为盘阵列。如箭头761和762所示，存储装置715中的数据被单向复制到存储装置725和存储装置735。与参考图6所描述的第三级别多活架构的不同之处在于，第四级别多活架构在存储层(而不是数据层)实现数据的拷贝。

实现第四级别多活架构的应用系统，在主数据中心可进行读写访问，在从数据中心可以进行只读数据的访问，但数据属于准实时的数据，从而实现在多个数据中心的多活部署。与第三级别多活架构相比，数据在多中心的复制同步不是在数据层，而是在底层存储层来实现。

整个应用系统的数据存储，在三个数据中心中选择一个中心作为主数据中心(数据中心710)，其他两个中心作为从数据中心(数据中心720和数据中心730)。主数据中心的存储数据需要实时复制到从数据中心的存储设备(通过存储设备的远程复制功能)。在主数据中心的存储数据可进行读写访问，在从数据中心的存储由于在处于实时复制状态下不能挂载，因此不能实时访问。从数据中心的存储数据可通过克隆等方式，提供有需要的应用程序某时间点的准实时数据访问。

客户端的流量分配策略同数据存储的主备相匹配，通过全局负载均衡来实现。通过全局负载均衡的策略，应用系统对数据的读写类型的客户访问流量，全部导向主数据中心(数据中心710)，从数据中心为备份。其他对数据仅有只读访问需求的应用程序，客户访问流量可导向从数据中心(数据中心720和数据中心730)。

第四级别多活架构中的正常多活处理

接入层处理：客户端的访问进入接入层后，应用访问的地址域名通过DNS服务器解析，DNS指向全局负载均衡器(三个数据中心的全局负载均衡为主备模式)，全局负载均衡根据策略进行地址解析，将主要访问流量导向主数据中心(数据中心710)的web层/应用层。

Web层/应用层：客户端访问进入web层(或应用层)后，本地负载均衡器负责在中心内部的负载均衡，根据策略将访问流量分担到web服务器群(或应用服务器群)，实现本地的负载均衡处理。正常情况下，只有主数据中心的web层/应用层的服务器处理用户请求，从数据中心的web层/应用层的服务器处于就绪状态。仅当发生中心切换时，从数据中心才处理用户请求。

数据层的处理：数据层处理来自应用层的数据访问需求，并将对数据的修改更新到主数据中心对应的数据实例。从数据中心的数据实例平时处于就绪状态，仅当发生中心切换时，数据实例才能处理来自应用层的访问。

存储层的处理：数据层的数据在底层由存储层存储设备进行存储。三个数据中心中仅主数据中心的存储设备能够挂载，并实时保存数据实例的更新。数据多活必须要做到数据在各个数据中心有实时副本，存储数据通过存储设备的实时复制技术复制到其他两个中心。由于从数据中心处于复制状态中的存储不能挂载，因此不能提供实时的访问。但可通过存储克隆等方式，提供有需要的应用程序某时间点的准实时数据访问。

第四级别多活架构中的故障切换处理

故障切换的处理过程以数据中心710的访问流量切换到数据中心720为例进行说明。切换过程包括数据层的切换和接入层的切换两部分，下面分别进行说明。

在数据层的切换方面，现假设因为故障或某种原因决定切换主数据中心(数据中心710)整体应用访问流量到从数据中心(数据中心720)。首先需要完成存储层的切换，将存储设备的主从复制关系，从以数据中心710为主、数据中心720和数据中心730为从的复制关系，切换到以数据中心720为主、数据中心710和数据中心730为从的复制关系。存储切换完成后，主数据中心(数据中心720)的存储可挂载，数据实例正常启动后，主数据中心数据实例可提供应用程序读写访问。

在接入层的切换方面，在接入层对客户端的访问流量进行切换。如果是在数据中心级故障情况下，全局负载均衡器自动切换至数据中心720，全局负载均衡器能够根据策略自动解析应用程序地址到数据中心720。如果是本例中主动进行的数据中心710到数据中心720的切换，需要在全局负载均衡设备调整策略，将原来用户客户端的访问请求，解析的IP地址从数据中心710切换到数据中心720的地址，从而实现应用客户端的访问的切换。

第五级别多活架构

图8图示了根据本公开的实施例的被部署在第五级别多活架构的多活数据中心800的示意图。在第五级别多活架构中，主数据中心分配可读写数据的访问流量，从数据中心的数据实时与主数据中心同步但不可实时访问。由于在从数据中心没有部署相关的备用设备等各类资源，因此当主数据中心发生重大故障、或其他需要紧急切换的情况，不能在短时间内切换主数据中心的访问流量到从数据中心。

如图8所示，多活数据中心800包括数据中心810、820以及830。数据中心810在接入层包括负载均衡器811，在web层包括web服务器812，在应用层包括应用服务器813，在数据层包括数据库814。如图4中的实线841所示，外部的客户端850可以访问数据中心810。

如图8所示，在存储层，数据中心810包括存储装置815，数据中心820包括存储装置825，以及数据中心830包括存储装置835，如箭头861和862所示，存储装置815中的数据被单向地复制到存储装置825和835以进行备份。

第五级别多活架构中的正常多活处理

与参考图7所描述的第四级别多活架构相比，都是仅实现存储层面的多数据中心复制，不同点在于第五级别多活架构中的web层/应用层/数据层等各层次的设备资源并没有部署就位，因此当出现数据中心级的故障时短时间内不能实现故障切换，但能保证数据级的安全保障。

第五级别多活架构中的故障切换处理

当主数据中心810发生故障时候，由于从数据中心820在存储层有实时的数据级的备份，因此数据没有丢失。如果要恢复业务，需要在从数据中心820分配服务器设备资源，重新部署搭建应用层和数据层等环境，挂接存储设备，恢复应用系统服务，恢复时间较长。

本领域技术人员应当理解，虽然以上参考图4-8描述的多活数据中心中示出了异地多活的三个数据中心，但是其也可以只包括两个数据中心或者更多个数据中心。

以上所述仅为本公开的实施例可选实施例，并不用于限制本公开的实施例，对于本领域的技术人员来说，本公开的实施例可以有各种更改和变化。凡在本公开的实施例的精神和原则之内，所作的任何修改、等效替换、改进等，均应包含在本公开的实施例的保护范围之内。

虽然已经参考若干具体实施例描述了本公开的实施例，但是应该理解，本公开的实施例并不限于所公开的具体实施例。本公开的实施例旨在涵盖在所附权利要求的精神和范围内所包括的各种修改和等同布置。所附的权利要求的范围符合最宽泛的解释，从而包含所有这样的修改及等同结构和功能。

Claims (16)

1.一种用于部署多活数据中心的方法，所述多活数据中心至少包括第一数据中心和第二数据中心，所述方法包括：

基于多活数据中心的高可用或灾备需求，选择相应级别多活架构，其中所述多活数据中心的多活标准架构至少包括第一级别多活架构、第二级别多活架构以及第三级别多活架构；

根据所选择的相应级别多活架构，部署所述多活数据中心；以及

响应于所述第一数据中心发生故障，基于所述相应级别多活架构来将所述第一数据中心的业务切换到所述第二数据中心，

其中，在所述第一级别多活架构中，所述多活数据中心通过分布式数据库实现数据同步；

在所述第二级别多活架构中，第一类型的数据被写入到所述第一数据中心并且被同步到所述第二数据中心，而第二类型的数据被写入到所述第二数据中心并且被同步到所述第一数据中心；以及

在所述第三级别多活架构中，数据仅被写入到所述第一数据中心并且在数据层被同步到所述第二数据中心。

2.根据权利要求1所述的方法，其中所述多活标准架构还包括第四级别多活架构以及第五级别多活架构，

并且其中在所述第四级别多活架构中，数据仅被写入到所述第一数据中心并且在存储层被同步到所述第二数据中心，并且所述第一数据中心和所述第二数据中心均部署应用层和数据层环境；以及

在所述第五级别多活架构中，数据仅被写入到所述第一数据中心并且在所述存储层被同步到所述第二数据中心，并且所述第一数据中心部署所述应用层和数据层环境，而所述第二数据中心不部署所述应用层和数据层环境。

3.根据权利要求1所述的方法，其中将所述第一数据中心的业务切换到所述第二数据中心包括：

响应于所述相应级别多活架构是所述第一级别多活架构：

由全局负载均衡器直接将所述第一数据中心中的所述业务切换到所述第二数据中心。

4.根据权利要求1所述的方法，其中将所述第一数据中心的业务切换到所述第二数据中心包括：

响应于所述相应级别多活架构是所述第二级别多活架构：

将由所述第一数据中心中可读写且由所述第二数据中心仅可读的所述第一类型的数据切换到由所述第二数据中心可读写；以及

由全局负载均衡器将所述第一数据中心中的所述业务切换到所述第二数据中心。

5.根据权利要求1所述的方法，其中将所述第一数据中心的业务切换到所述第二数据中心包括：

响应于所述相应级别多活架构是所述第三级别多活架构：

在所述数据层将所述多活数据中心的主数据中心从所述第一数据中心切换到所述第二数据中心；以及

由全局负载均衡器将所述第一数据中心中的所述业务切换到所述第二数据中心。

6.根据权利要求2所述的方法，其中将所述第一数据中心的业务切换到所述第二数据中心包括：

响应于所述相应级别多活架构是所述第四级别多活架构：

在所述存储层将所述多活数据中心的主数据中心从所述第一数据中心切换到所述第二数据中心；以及

由全局负载均衡器将所述第一数据中心中的所述业务切换到所述第二数据中心。

7.根据权利要求2所述的方法，其中将所述第一数据中心的业务切换到所述第二数据中心包括：

响应于所述相应级别多活架构是所述第五级别多活架构：

在所述存储层将所述多活数据中心的主数据中心从所述第一数据中心切换到所述第二数据中心；

在所述第二数据中心中部署所述应用层和数据层环境；以及

由全局负载均衡器将所述第一数据中心中的所述业务切换到所述第二数据中心。

8.根据权利要求1-7任一项所述的方法，其中所述多活数据中心还包括第三数据中心，并且其中所述第三数据中心与所述第二数据中心位于不同地区。

9.一种用于部署多活数据中心的系统，所述多活数据中心包括：

第一数据中心，其至少包括第一服务器和第一数据库；以及

第二数据中心，其至少包括第二服务器和第二数据库，

其中所述系统能够将所述多活数据中心至少部署在第一级别多活架构、第二级别多活架构或者第三级别多活架构，并且所述系统被配置为响应于所述第一数据中心发生故障而将所述第一数据中心的业务切换到所述第二数据中心，

其中，在所述第一级别多活架构中，所述多活数据中心通过分布式数据库实现数据同步；

在所述第二级别多活架构中，第一类型的数据被写入到所述第一数据中心并且被同步到所述第二数据中心，而第二类型的数据被写入到所述第二数据中心并且被同步到所述第一数据中心；以及

在所述第三级别多活架构中，数据仅被写入到所述第一数据中心并且在数据层被同步到所述第二数据中心。

10.根据权利要求9所述的系统，其中所述系统还能够将所述多活数据中心部署在第四级别多活架构或者第五级别多活架构，

并且其中在所述第四级别多活架构中，数据仅被写入到所述第一数据中心并且在存储层被同步到所述第二数据中心，并且所述第一数据中心和所述第二数据中心均部署应用层和数据层环境；以及

在所述第五级别多活架构中，数据仅被写入到所述第一数据中心并且在所述存储层被同步到所述第二数据中心，并且所述第一数据中心部署所述应用层和数据层环境，而所述第二数据中心没有部署所述应用层和数据层环境。

11.根据权利要求9所述的系统，其中所述系统还被配置为：

响应于所述系统被部署在所述第一级别多活架构：

由全局负载均衡器直接将所述第一数据中心中的所述业务切换到所述第二数据中心。

12.根据权利要求9所述的系统，其中将所述系统还被配置为：

响应于所述系统被部署在所述第二级别多活架构：

将由所述第一数据中心中可读写且由所述第二数据中心仅可读的所述第一类型的数据切换到由所述第二数据中心可读写；以及

由全局负载均衡器将所述第一数据中心中的所述业务切换到所述第二数据中心。

13.根据权利要求9所述的系统，其中所述系统还被配置为：

响应于所述系统被部署在所述第三级别多活架构：

在所述数据层将所述多活数据中心的主数据中心从所述第一数据中心切换到所述第二数据中心；以及

由全局负载均衡器将所述第一数据中心中的所述业务切换到所述第二数据中心。

14.根据权利要求10所述的系统，其中所述系统还被配置为：

响应于所述系统被部署在所述第四级别多活架构：

在所述存储层将所述多活数据中心的主数据中心从所述第一数据中心切换到所述第二数据中心；以及

由全局负载均衡器将所述第一数据中心中的所述业务切换到所述第二数据中心。

15.根据权利要求10所述的系统，其中所述系统还被配置为：

响应于所述系统被部署在所述第五级别多活架构：

在所述存储层将所述多活数据中心的主数据中心从所述第一数据中心切换到所述第二数据中心；

在所述第二数据中心中部署所述应用层和数据层环境；以及

由全局负载均衡器将所述第一数据中心中的所述业务切换到所述第二数据中心。

16.根据权利要求9-15任一项所述的系统，其中所述多活数据中心还包括第三数据中心，并且其中所述第三数据中心与所述第二数据中心位于不同地区。