CN111181789B - 基于分区的应用容灾系统 - Google Patents

Abstract

本发明公开了一种基于分区的应用容灾系统，包括产品业务层、中台服务层和全局支撑层；产品业务层和中台服务层均包括至少一个业务独享分区，每个业务独享分区的多个分区包括相互备份的第一分区和第二分区，全局支撑层用于提供辅助支撑；其中，产品业务层、中台服务层和全局支撑层通过分区中间件进行业务隔离和分层。通过上述技术方案，能够实现资源隔离、故障影响范围缩小、定位问题清晰、资源配置精准、弹性伸缩方便。

Description

基于分区的应用容灾系统

技术领域

本发明涉及互联网技术领域，具体来说，涉及一种基于分区的应用容灾系统。

背景技术

支付作为互联网各行各业发展的基础支撑，目前对支付的高可用要求变得越来越高，甚至是大家慢慢忘记了支付不可用的场景。但作为一家为支付提供水电煤的第三方支付公司，对支付场景的要求更是非常严苛，业务需要在任何环境下24小时不间断运行，并且数据一笔不能丢弃，不能错乱。所以作为为公司全部业务支撑的微服务框架上，如何对应用进行深度隔离和容灾的方法变的尤为重要。

目前主流的应用微服务应用框架，服务路由是通过条件、脚本路由来进行过滤，从而让应用发布或者出现故障的时候能够快速切换，达到容灾的目的。在简单路由方面，目前主流的微服务框架都达到了一定的能力，还有一些也达到了简单分组路由，并且这种分组路由是基于单体应用场景，主要针对版本发布，变更。主要用于非常简单的业务场景，业务功能比较单一，上下游依赖也比较少，并且其本身的集群规模也比较小。

在容灾方面，目前所有的系统只考虑单层中间件集群高可用，并没有考虑业务经过的所有中间件整体业务的高可用，导致容灾时候只是一个理想化的架构，真正出问题的时候，无法进行定位和切换，也无法保证后续业务持续进行。

但是，现有的上述方案具有以下问题：

无法通过配置简单运维实现自动路由，需要大量在特定的标签中打上路由标识，开发人员需要写很多额外代码和配置；无法进行动态路由；无法将多个应用整体结合在一起，进行整体业务的隔离；无法整体进行简单隔离；无法处理服务依赖中下层业务路由的传递，并保持有效的追踪；无法整体进行容灾，并快速保持业务可用。

上述缺陷就会导致，业务在进行日常发布、灰度发布、容灾切换的时候，稍有不慎，业务就会发生故障，导致影响业务高可用。

发明内容

针对相关技术中的上述问题，本发明提出一种基于分区的应用容灾系，以保证业务高可用，并且容灾切换要求在5分钟内完成，并保证后续业务持续可用；对业务交易关键路径上应用组进行单元化分区；针对分区内进行精准的容量规划。

本发明的技术方案是这样实现的：

根据本发明的一个方面，提供了一种基于分区的应用容灾系统，包括产品业务层、中台服务层和全局支撑层；

所述产品业务层和所述中台服务层均包括至少一个业务独享分区，每个所述业务独享分区的多个分区包括相互备份的第一分区和第二分区，所述全局支撑层用于提供辅助支撑；

其中，所述产品业务层、所述中台服务层和所述全局支撑层通过分区中间件进行业务隔离和分层。

根据本发明的实施例，所述中台服务层还包括默认区，所述默认区用于未指定分区的前端业务。

根据本发明的实施例，其中，每个所述业务独享分区中的多个分区包括顶层分区，所述顶层分区用于定义当前业务的分区，下层业务应用按照所述顶层分区的分区号进行隔离和传递。

根据本发明的实施例，其中，所述业务独享分区中的一个分区包括一个单元组，所述单元组包括多个应用，所述多个应用的分区号相同。

根据本发明的实施例，其中，对于物理分区所述分区中间件通过全局均衡负载模块的域名解析和流量分发来指定分区号；对于顶层分区，所述分区中间件通过网关协议来指定分区号。

根据本发明的实施例，对于所述物理分区中的故障，通过所述全局均衡负载模块进行路由切换；对于所述多个分区的分区故障，通过网关将第一分区的流量切换到第二分区；对于所述单元组的分区故障，通过所述网关将第一单元组的流量切换到第二单元组。

根据本发明的实施例，所述中台服务层的所述分区通过所述分区中间件的上下文指定分区号并传递到下层。

根据本发明的实施例，通过分区号将多个应用相关联，并通过分区映射路由和指定灰度流量来发布所述多个应用。

本发明的上述技术方案，通过域名和分区中间件(例如API网关、微服务框架、消息系统)，使系统从各个维度可以进行业务隔离和分层，从而达到业务各层之间的灵活路由请求，并规范各层之间的调用规范，最终实现资源隔离、故障影响范围缩小、定位问题清晰、资源配置精准、弹性伸缩方便。通过A区和B区相互备份的方式，可以从另外一个层面来保证高可用。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是根据本发明实施例的一种基于分区的应用容灾系统的示意图；

图2是根据本发明一个实施例的基于域名的容灾模式的效果图；

图3是根据本发明一个实施例的基于API网关的分区故障场景时的容灾模式的效果图；

图4是根据本发明一个实施例的基于API网关的单元故障场景时的容灾模式的效果图；

图5是根据本发明一个实施例的基于微服务通讯框架的分区故障场景时的容灾模式的效果图；

图6是根据本发明一个实施例的基于微服务通讯框架的单元故障场景时的容灾模式的效果图；

图7A和图7B分别是根据本发明一个实施例在简单模式下的前端业务和中后台的示意图；

图8A和图8B分别是根据本发明一个实施例在普通模式下的前端业务和中后台的示意图；

图9是根据本发明一个实施例在泳道模式下的示意图；

图10是根据本发明一个实施例在消峰模式下的示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示，根据本发明的实施例，提供了一种基于分区的应用容灾系统，包括产品业务层、中台服务层和全局支撑层。全局支撑层一般为一些共性的辅助支撑，这层通常业务属性比较少，一般不做区域划分。分区主要围绕产品业务层和中台服务层开展。

其中，所述产品业务层和所述中台服务层均包括至少一个业务独享分区，每个业务独享分区里再划分成子区域，A区(第一分区)和B区(第二分区)，A区和B区采用一种相互备份的方法。其中，所述产品业务层、所述中台服务层和所述全局支撑层通过分区中间件进行业务隔离和分层。业务独享分区也是可以存在多个，多个业务独享分区相互之间也是对等的，可以用来随时切换。

本发明的上述技术方案，可以通过域名和分区中间件(例如API网关、微服务框架、消息系统)，使系统从各个维度可以进行业务隔离和分层，从而达到业务各层之间的灵活路由请求，并规范各层之间的调用规范，最终实现资源隔离、故障影响范围缩小、定位问题清晰、资源配置精准、弹性伸缩方便。通过A区和B区相互备份的方式，可以从另外一个层面来保证高可用。

继续参考图1所示，所述中台服务层还包括默认区。当前端业务不指定分区的时候，就会进入默认区。默认区有两个作用，一个是业务高可用的保底策略，来防止误传或漏传分区号。默认分区还可以在进行老系统从传统的集群模式迁移到分区模式，用来进行迁移过度。

分区中间件是本发明分区的核心代码部分。对于分区中间件功能：物理分区使用GSLB；顶层分区使用API(应用程序接口)网关；中台业务分区使用微服务框架和消息系统。GSLB(Global Server Load Balance，全局负载均衡)实现在广域网(包括互联网)上不同地域的服务器间的流量调配，保证使用最佳的服务器服务离自己最近的客户，从而确保访问质量。

其中，物理分区指的是机房层面，可以通过GSLB中二级域名解析和流量分发来指定分区号。顶层分区一般采用入口的API网关，在网关HTTP协议(HyperText TransferProtocol，超文本传输协议)中Head中来指定分区号。中台业务分区对两类通讯框架进行改造，一类同步RPC通讯微服务框架，第二类型消息系统MQ(消息队列)，主要在通讯框架的上下文中进行指定分区号，并传递到下层。

根据本发明的实施例，引入了顶层分区、分区分层和分区单元的概念。顶层分区是指最先调用分区的那个应用，它来定义当前业务的分区应该是哪个，然后通过全局调用链路，一路传递到下层业务应用，下层业务应用都可以按照顶层分区号来进行隔离和传递。分区分层是将每个应用所在的分区规划一个分层，例如L1、L2等，这样可以做到上层和下层明确的调用关系，防止回路调用。每个分层中可以绑定多个应用。分区单元是指每个分区可以规划成一个单元组，单元组内可以包含多个应用，并且这些应用都是用同一个分区号。根据顶层分区、分区分层、分区单元，将业务应用从上到下整体进行规划，为后续容灾提供非常清晰的架构。

分区中间件围绕分区模块的设计进行调用。整体的分区设计结构如下：

客户端指定分层(例如L1)；

客户端指定一个服务端的分区服务；

客户端指定分区服务调用到服务端应用的哪个分区；

服务端进行分层规划(例如L2)，并绑定多个应用到分层；

服务端将分区映射到分层(例如L2)；

服务端指定的IP地址，绑定到分区服务上，并规划期指定的分区

客户端和服务端进行分区映射，配置分区路由和权重。

对于分区发布，根据本发明的实施例，在分区发布中将分区整体规划成A区、B区，A区和B区在发布的时候，可以相互备份。A区和B区发布的具体流程如下：

步骤*_GRAY，灰度区发布(流量控制：0％->1％->0％)；

步骤*_A，A区发布(流量控制：A 50％->A 0％B 100％->A 1％B 99％->A 50％B50％)；

步骤*_B。B区分布(流量控制：B 50％->B 0％A 100％->B 1％A 99％->B 50％A50％)。

发布功能包括：*_GRAY、强制停止、停止、发布、1％流量接入、*_A(A区发布)、停止、发布、回滚、关闭流量、验证流量接入(1％)、正常流量接入、*_B(B区分布，与*_A相同)。

根据本发明的实施例，在分区发布中又提出了灰度区域的发布概念。灰度区域发布是对多应用系统集成灰度发布的一种方法，通过分区号，将多个应用关联在一起进行集中灰度发布，在通过分区映射路由，指定灰度流量，达到整体灰度发布。灰度区域发布一般用于重大项目升级改造，上下游系统依赖比较紧密，但组织结构上又从属于多个系统。这种情况下，传统的灰度发布方式无法进行有效的验证，只能验证到自己是否正确，无法证明本次重大改动中，所有的业务改动经过的相关系统是否正确。灰度区域发布通过分区路由映射逻辑，通过灰度区域引流策略，实现了这个功能。

对于容灾方式，根据本发明的实施例，从分区划分层次来说，可以包括三种容灾模式，分别基于域名，基于API网关，基于通讯微服务框架：

(1)基于域名(例如.com)，主要场景为机房故障，通过GSLB进行二级域名路由切换，该模式的效果图如图2所示。

(2)基于API网关，当场景为分区故障时，通过API网关，将A区流量切换到B区，该模式的效果图如图3所示；当场景为单元故障时，单元Main01流量切换到单元Main02，该模式的效果图如图4所示。

(3)基于微服务通讯框架，当场景为分区故障时，A区流量切入B区，该模式的效果图如图5所示；当场景为单元故障时：单元Main01流量切入单元Main02，该模式的效果图如图6所示。

根据本发明提出的分区容灾系统，可具有简单模式、普通模式、泳道模式、消峰模式这四种模式。

简单模式：通过API网关和Pegasus单元化和分区技术，快速实现业务分区隔离。一般适用在老项目数据库集中管理，流量相对稳定，拆分难度比较大，但也需要分区来保证高可用和基本发布和容灾要求。简单模式下的前端业务和中后台分别如7A和图7B所示。

普通模式：通过API网关和微服务通讯架构单元化和分区技术，实现业务单元隔离。需要业务进行无状态化深度改造，数据库独立运行，能应对流量爆发性增长，快速整体水平扩容，带来更高可用性、发布、容灾要求。普通模式下的前端业务和中后台分别如8A和图8B所示。

参考图9所示，泳道模式：是一种严格的分区隔离模式，通过顶层分区分区号的设定，一路通过API网关，微服务通讯框架，进行业务分区的深度逻辑隔离，并且严格规定不能跨分区调用。一般使用在业务本身独立性和完整性比较强，需要整理独立部署的场景。

参考图10所示，消峰模式：通过顶层分区识别分区号以后，由API网关通过Head(头部)解析分区号，配置消息路由到不同的MQ服务器或者不同的消息队列，来完成异步解耦和消峰，在通过MQ指定的监听策略，识别分区号来完成分区路由。一般用在业务异步化场景中，批量异步处理。

以下表1示出了简单模式、普通模式、泳道模式、消峰模式四种模式在多个方面的比较结果。

表1

综上所述，本发明通过域名和中间件通讯框架(API网关、微服务框架、消息系统)，使系统从各个维度可以进行业务隔离和分层，从而达到业务各层之间的灵活路由请求，并规范各层之间的调用规范，最终实现资源隔离、故障影响范围缩小、定位问题清晰、资源配置精准、弹性伸缩方便；

另外，将容灾整体考虑，从物理层，业务逻辑顶层，中台层三个维度进行容灾。并且创新出三种容灾方式：基于域名，基于API网关，基于微服务通讯框架；

提出了一种新的发布模式，A区、B区发布模式，来保证发布过程多应用，多数据库无损发布策略；

提出了一种新的灰度发布模式，分区灰度发布，从全链路层面考虑应用灰度策略；

提出普通模式、简单模式、泳道模式、消峰模式，用来适用于业务的各种场景。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (5)

1.一种基于分区的应用容灾系统，其特征在于，包括产品业务层、中台服务层和全局支撑层；

所述产品业务层和所述中台服务层均包括至少一个业务独享分区，每个所述业务独享分区的多个分区包括相互备份的第一分区和第二分区，所述全局支撑层用于提供辅助支撑；

其中，所述产品业务层、所述中台服务层和所述全局支撑层通过分区中间件进行业务隔离和分层，

所述业务独享分区中的一个分区包括一个单元组，所述单元组包括多个应用，所述多个应用的分区号相同，

对于所述多个分区的分区故障，通过网关将第一分区的流量切换到第二分区，

对于所述单元组的分区故障，通过所述网关将第一单元组的流量切换到第二单元组，

所述中台服务层还包括默认区，所述默认区用于未指定分区的前端业务，所述默认区还用于在系统从集群模式迁移到分区模式时进行迁移过度，

所述中台服务层的所述分区通过所述分区中间件的上下文指定分区号并传递到下层，其中所述中台服务层的所述分区使用的所述分区中间件为微服务框架和消息队列，在所述微服务框架和所述消息队列的上下文中进行指定分区号，并传递到下层。

2.根据权利要求1所述的基于分区的应用容灾系统，其特征在于，其中，每个所述业务独享分区中的多个分区包括顶层分区，所述顶层分区用于定义当前业务的分区，下层业务应用按照所述顶层分区的分区号进行隔离和传递。

3.根据权利要求1所述的基于分区的应用容灾系统，其特征在于，其中，对于物理分区所述分区中间件通过全局均衡负载模块的域名解析和流量分发来指定分区号；对于顶层分区，所述分区中间件通过网关协议来指定分区号。

4.根据权利要求3所述的基于分区的应用容灾系统，其特征在于，对于所述物理分区中的故障，通过所述全局均衡负载模块进行路由切换。

5.根据权利要求1所述的基于分区的应用容灾系统，其特征在于，通过分区号将多个应用相关联，并通过分区映射路由和指定灰度流量来发布所述多个应用。

Images