CN110225138B

CN110225138B - 一种分布式架构

Info

Publication number: CN110225138B
Application number: CN201910553289.2A
Authority: CN
Inventors: 卢道和; 杨军; 陈广胜; 胡盼盼; 杨俊杰; 饶俊明
Original assignee: WeBank Co Ltd
Current assignee: WeBank Co Ltd
Priority date: 2019-06-25
Filing date: 2019-06-25
Publication date: 2021-12-14
Anticipated expiration: 2039-06-25
Also published as: WO2020259086A1; CN110225138A

Abstract

本发明涉及金融科技领域，并公开了一种分布式架构，分布式架构包括：N个数据中心和M组数据中心节点。每个数据中心包括X个数据中心节点，每组数据中心节点包括Y个数据中心节点，每组数据中心节点中的Y个数据中心节点位于Y个不同的数据中心，每个数据中心节点包括用于存放Z个客户的客户数据的数据库服务器和/或存放处理Z个客户所有业务的应用系统的应用服务器。由于分布式架构的每个数据中心包括的数据中心节点都是以客户为维度，分组划分的，每个数据中心节点都拥有独立的业务处理需要的应用系统，可以实现分布式架构中数据中心节点发生故障时，依然保持高可用性，分散单个数据中心处理压力和故障风险，有效降低故障的影响范围。

Description

一种分布式架构

技术领域

本发明实施例涉及金融科技(Fintech)领域，尤其涉及一种分布式架构。

背景技术

随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变，消息存储技术也不例外，但由于金融、支付行业的安全性、实时性要求，也对技术提出的更高的要求。

目前，常见的分布式架构主要采用集中式松耦合架构，针对于该集中式松耦合架构，由于客户业务高度相互依赖，根据木桶原理，整个架构的可用性和性能取决于最短板的节点，因此，每个节点的性能只能解决自身应用的处理性能而无法实现节点间系统负载和资源的共享。其次，目前网络技术不能保证长距离通讯质量的绝对稳定与可用，当网络出现故障或者数据同步因为其它原因出现异常时，集中式松耦合架构可能会导致客户数据无法访问，存在故障风险。

发明内容

本发明实施例提供一种分布式架构，用以保证架构整体可用性、可扩展性，降低故障风险影响范围。

第一方面，本发明实施例提供的一种分布式架构，包括：N个数据中心和M组数据中心节点；

每个数据中心包括X个数据中心节点，每组数据中心节点包括Y个数据中心节点，每组数据中心节点中的Y个数据中心节点位于Y个不同的数据中心；每个数据中心节点包括用于存放Z个客户的客户数据的数据库服务器和/或存放处理所述Z个客户所有业务的应用系统的应用服务器；

其中，存放每个客户的客户数据的数据库服务器和/或存放处理所述Z个客户所有业务的应用系统的应用服务器都存放于一个数据中心节点中，所述N个数据中心中至少Q个数据中心位于不同城市，所述每组数据中心节点中的Y个数据中心节点包括一个主数据中心节点和至少两个从数据中心节点，N、M、X、Y、Z、Q为正整数。

上述技术方案中，由于分布式架构的每个数据中心包括的数据中心节点都是以客户为维度，分组划分的，每个数据中心节点都拥有独立的业务处理需要的应用系统和/或存放客户数据，可以实现分布式架构中数据中心节点发生故障时，依然保持高可用性，分散单个数据中心处理压力和故障风险，有效降低故障的影响范围，并且，Y个不同的数据中心都存放有客户数据和/或应用系统，也实现了客户数据多活和/或应用多活，即使出现故障也能无缝提供服务，降低了故障的风险影响范围。

可选的，所述每组数据中心节点中的Y个数据中心节点包括一个所述主数据中心节点，至少一个与所述主数据中心节点同城的从数据中心节点和至少一个与所述主数据中心节点异地的从数据中心节点。

可选的，所述主数据中心节点和从数据中心节点中存放的Z个客户的客户数据相同，和/或存放的处理所述Z个客户所有业务的应用系统相同。

可选的，所述Y个数据中心节点之间的物理资源相互隔离。

可选的，所述Y个数据中心节点预设一个数据中心节点进行灰度发布。

可选的，每个数据中心节点中的物理资源包括多个数据库服务器和多个应用服务器；

所述应用系统按照不同的应用域进行分组，不同的组不共享应用服务器以及不共享数据库服务器。

可选的，通过增加所述每组数据中心节点中的数据中心节点的数量，对所述分布式架构进行横向扩容。

可选的，通过增加所述每组数据中心节点中的预设数据中心节点的计算资源，对所述分布式架构进行纵向扩容；或通过将预留的计算资源池中的计算资源临时分配给所述每组数据中心节点中的预设数据中心节点，对所述分布式架构进行纵向扩容。

可选的，所述分布式架构还包括全局定位系统；

所述全局定位系统采用预设的加权随机算法对所述客户进行分片策略管理，和对所述客户数据存放的数据中心节点进行定位。

可选的，所述全局定位系统通过消息总线分别与每个数据中心节点中的应用系统进行通信。

附图说明

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

图1为本发明实施例提供的一种分布式架构的结构示意图；

图2为本发明实施例提供的一种分布式架构的结构示意图；

图3为本发明实施例提供的一种数据中心节点的示意图；

图4为本发明实施例提供的一种全局定位系统的示意图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

图1示例性的示出了本发明实施例提供的一种分布式架构的结构示意图，如图1所示，该分布式架构可以包括N个数据中心(Internet Data Center，IDC)和M组数据中心节点(Data Center Node，DCN)。

在本发明实施例中，数据中心(Internet Data Center，IDC)为金融领域新一代互联网架构规划与管理的物理单元，其具有网络吞吐能力以及安全防护能力，数据中心根据本中心定位，可以选择需要的模块组成数据中心的物理架构，每个模块的标准化包括其网络架构、物理部署、硬件设备型号等，但不包括其容量；模块的容量可按需横向扩展。

数据中心节点是金融领域新一代互联网架构规划与管理的逻辑单元。每个数据中心节点是一个物理资源独立、应用逻辑自包含的节点，用于承载一个特定的客群或者提供一组特定的服务。数据中心节点拥有独立的物理计算和存储资源，不同节点之间不共享物理计算和存储资源，不同节点间共享数据中心级的资源，主要包括：数据中心的基础设施、基础网络和数据中心级的公共服务(例如：消息总线等)。

在具体实现过程中，数据中心节点根据服务对象的不同，可以分为两种类型的服务：一种是对客户服务：银行对各种不同类型的银行客户提供的对外服务；另一种是银行后台管理服务：银行自身使用的内部服务，例如总账、管理会计等。

在本发明实施例中，如图1所示，每个数据中心包括X个数据中心节点，每组数据中心节点包括Y个数据中心节点，每组数据中心节点中的Y个数据中心节点位于Y个不同的数据中心；每个数据中心节点包括用于存放Z个客户的客户数据的数据库服务器和/或存放处理Z个客户所有业务的应用系统的应用服务器。其中，存放每个客户的客户数据的数据库服务器和/或存放处理Z个客户所有业务的应用系统的应用服务器都存放于一个数据中心节点中，N个数据中心中至少Q个数据中心位于不同城市，每组数据中心节点中的Y个数据中心节点包括一个主数据中心节点和至少两个从数据中心节点，N、M、X、Y、Z、Q为正整数。主数据中心节点和从数据中心节点中存放的Z个客户的客户数据和处理Z个客户所有业务的应用系统相同。

在本发明实施例中，同城的数据中心数量可选为多个(如N个或者少于N个)，在同城的数据中心数量为多个的情况下，为了降低资源的过度耗费，可选Y的数量小于N，这样在M组数据中心节点中，每组数据中心节点只要包括Y个数据中心节点即可，无需每组数据中心节点都含有N个数据中心节点，既可以保证在某一个数据中心节点故障时，有备份的数据中心节点提供服务，又可以防止资源的过度耗费。

为更好理解，如图1所示，当前有N个数据中心(IDC)，例如5个,M组数据中心节点(DCN)，在DCN组1中可选包括三个DCN，其中一个位于IDC1中，一个位于IDC2中，还有一个位于IDC3中，其中，IDC1和IDC2中的DCN都各自包含有存放客户数据的数据库服务器和存放处理客户所有业务的应用系统的应用服务器，IDC3中只包含存储客户数据的数据库服务器，通过这种方式，使得每组数据中心节点包含的数据中心节点个数少于数据中心的个数，既可以保证在某一个数据中心节点故障时，有备份的数据中心节点提供服务，又可以防止资源的过度耗费。这仅是一种可以实现的实施方式，在具体实施时，IDC3也是可以部署应用服务器。

在本发明实施例中，需要重点强调的是，一个数据中心节点包括数据库服务器和/或应用服务器，数据库服务器和应用服务器在两个不同的层面上相互独立，互不响应。此外，通过将应用系统部署在同一个DCN组中的不同DCN上，可以实现应用系统的多实例多活部署，即使是某一个DCN中的应用系统故障，也可以由其他DCN的应用系统继续提供服务，可以确保各种容灾场景下的业务连续性。而现有的分布式架构中，当某一个应用系统故障时，只能人工手动启动备份应用系统，需要花费较长等待时间，明显故障收到的影响范围大。

在本发明实施例中，每个数据中心节点都有独立的处理客户所有业务的应用系统，当前数据中心节点出现问题，无法处理该客户的业务时，可以由位于同一组中的其它数据中心节点的应用系统接替处理，无需在一个数据中心节点中设置主备应用系统，节省数据中心节点的资源。

进一步地，N个数据中心至少Q个数据中心位于不同城市，例如，如图2所示的分布式架构，总共有三个数据中心，其中同城有两个数据中心，异地容灾有一个数据中心。该种架构可以称为“两地三中心”的部署架构，在该种架构下，单个数据中心从供电、制冷到网络连通性均按照最低2N级别的冗余度进行设计，并要求所有线路物理隔离，确保一个工程施工点不对单个数据中心的连通性造成致命影响。因此，在同城任一数据中心出现故障时，该架构可支持同城跨数据中心的切换。

可选的，每组数据中心节点中的Y个数据中心节点包括一个主数据中心节点，至少一个与主数据中心节点同城的从数据中心节点和至少一个与主数据中心节点异地的从数据中心节点。深入到数据中心内部，每个数据中心均由多个数据中心节点组成。每组数据中心节点由一个主节点、一个同城备节点和一个异地容灾节点构成，这也意味着每组数据中心节点也都独立形成“两地三中心”的结构，确保在主节点出现故障时，能快速切换到备节点，支持业务不间断运行，以满足RTO(Recovery Time Object，恢复时间目标)和RPO(Recovery Point Object，恢复点目标)相关要求。同时，在正常情况下，两个数据中心均有数据中心节点的主节点存活并同时对外提供服务，可以分散单个数据中心处理压力和故障风险，有效降低故障的影响范围。

可选的，同一组数据中心节点中可以设有三个数据中心节点，其中两个数据中心节点可以位于同一城市，另一个数据中心节点可以位于异地城市，这样每组数据中心节点也可以独立形成“两地三中心”的结构，这种结构可以分散单个数据中心的处理压力，节省系统开销。

对于单个数据中心节点，其组成的物理资源包括多个数据库服务器和多个应用服务器。应用系统按照不同的应用域进行分组，不同的组不共享应用服务器以及不共享数据库服务器。数据中心节点之间的物理资源相互隔离。也就是说，数据中心节点可以从组成的硬件资源以及部署的数据和应用系统来分析。在数据中心节点的硬件资源构成方面。如图3所示，一个数据中心节点内包含了应用服务器、数据库服务器等硬件资源。在基础设施建设初期，经过对业务量的充分评估，且出于谨慎管理的角度考虑，一个数据中心节点的相关硬件资源采用集中部署的方式，固定由2个应用服务器机柜与3个数据库服务器机柜构成。2个应用服务器机柜，提供了双机柜的冗余，确保应用实例有条件部署到2个不同机柜，避免单机柜故障的风险。对于数据库，每个SET(数据集合)由3个SET节点组成，3个SET节点分散部署在3个数据库服务器机柜上。对于应用系统而言，相应的数据都是采用3个副本进行存储，3份数据分布在3个不同的机柜上。这样的数据库部署结构，可充分保证数据的高可用性。经过多年实践，结合配置信息管理等运维管理工具，银行对数据中心节点的管理日趋成熟，可以随时、快速从运维管理工具中读取和筛选一个数据中心节点相关的所有资源信息。同时，随着业务进一步发展，数据中心节点也面临着一定的扩展需求。因此，目前数据中心节点不再局限于集中式的机柜上，而是更加开放，转变为逻辑上的区域划分，数据中心变为一个巨大的资源池，可以根据实际建设需求，随时将一个数据中心的任何一台服务器加入或移出一个数据中心节点，可快速实现数据中心节点的弹性扩容和缩容。

在数据中心节点部署的客户数据和应用系统方面。从物理资源相互隔离的角度看，由于每个数据中心节点的物理资源相互隔离，因此每个数据中心节点上的客户数据和应用系统自然也相互隔离。这种隔离就像是一道防护网，可避免数据中心节点之间的相互影响，令每个数据中心节点就像是一个独立的BOX，在出现问题时能够有效地避免影响的扩散。同时，这种隔离结构也为应用版本更新时实施灰度发布带来了便利，应用无需在逻辑层面做灰度发布的适配改造，直接可以按数据中心节点级别进行灰度发布，大大降低了灰度发布的设计和开发成本。从应用部署的角度来看，为尽量隔离业务产品间的相互影响，降低部门间的交叉协作的复杂度，银行在实践中将应用按不同的应用域进行分组，不同的组不共享应用服务器，也不共享数据库服务器。在应用架构的设计上，银行目前更多按不同业务产品进行竖井式划分，除一些公共平台类的系统，对于不同应用域下的应用子系统，其对应的业务产品系统在大部分情况下也不相同，因此将资源按不同应用域分组后，资源出现问题时的影响范围可被控制在单个应用域内，尽可能减少跨业务产品的影响。

每组数据中心节点可以预设一个数据中心节点进行灰度发布。通过以客户为单位的分布式架构，可以把其中一个节点的客户分配权重调低，使得这个节点拥有和所有其他节点完全相同的应用架构、部署架构和资源配置，但是低于其他节点的客户负载。

所有应用版本发布、基础组件升级，均在这个节点上进行灰度验证。由于其完全部署于生产环境，并且拥有和其他节点完全相同的配置，其灰度结果可以真实的反映该变更在其他节点上的效果。同时，由于其拥有较低的客户占比(低于10％)，因此即使灰度验证出现异常，也可以将相关影响控制在很小的一个客户群体中。

对比传统集中式松耦合架构，由于部署方式和技术框架的差异性，在一个完整的端到端环境中实现灰度发布是比较困难的。因为一个系统需要通过深度定制，才能识别到底是灰度验证的交易还是正常交易。一般的做法是在一个系统的入口处做一个区分，根据灰度配置，把灰度验证名单中的客户交易分发到灰度验证版本中，而其他交易发布到正常生产版本。这样做，在技术层面大大加大了实现的复杂度和风险，一旦出现失误，可能会影响全部的正常交易。同时，如果灰度版本涉及数据库的变更，则整个灰度方案会更加的复杂。

因此，以客户为单位的分布式架构，通过各个客户节点的隔离，通过标准化的节点部署以及客户分配权重的控制，可以方便的做到真实有效的灰度验证，从而大大提升应用发布的周期，降低了对测试过程的依赖，通过灰度的生产流量，直接在生产环境完成了软、硬件更新的最后一个测试环节。

在本发明实施例中，该分布式架构有两种扩容方式，具体为：

一、通过增加每组数据中心节点中的数据中心节点的数量，对分布式架构进行横向扩容。

二、通过增加每组数据中心节点中的预设数据中心节点的计算资源，对分布式架构进行永久纵向扩容；或通过将预留的计算资源池中的计算资源临时分配给每组数据中心节点中的预设数据中心节点，对分布式架构进行临时纵向扩容。

在横向扩展策略中，可以通过快速部署相应类型的标准数据中心节点来提升银行的客户服务容量；在纵向扩容策略中，我们又有两种不同的模式：一种是永久性扩容，一种是临时性扩容。永久的扩容指的是通过增加逻辑节点的计算资源进行纵向扩容升级。例如，一个模块原定服务500万客户。随着业务不断发展、新的产品不断推出，在服务500万客户不变的情况下，多个节点普遍出现性能瓶颈。那么，这个时候会按照一定的策略为这些节点增加计算资源，永久的提升节点的处理能力。另一种情况是，在互联网带来的新的运营理念下，会遇到很多类似“电商618”、“双11”、“双12”等等临时性营销活动。对于临时性的资源和性能需求，将从预留的资源池按需将计算资源挂载到对应的节点上，对这个节点进行临时性的纵向扩容。

进一步的，该分布式架构还包括全局定位系统，该全局定位系统采用预设的加权随机算法对客户进行分片策略管理，和对客户数据存放的数据中心节点进行定位。全局定位系统通过加权随机算法，在创建新客户时，决定将新客户的数据存放在哪个数据中心节点中，并且，在该新客户后续的业务处理中，通过基于客户信息的分片信息检索机制对业务处理需要的客户数据存放的数据中心节点进行定位，即使用该全局定位系统做客户分片管理及客户定位。

在本发明实施例中，通过全局定位系统对客户数据存放节点进行分配，通过加权随机算法实现在分布式架构中，各数据中心节点间具有合理的客户分布，在充分利用分布式架构中各数据中心节点的计算资源的情况下，同时使得客户分散分布，减少某个数据中心节点故障时对分布式架构的影响。

如图4所示，全局定位系统通过消息总线分别与每个数据中心节点中的应用系统进行通信。

以上模式与传统银行所采用模式最大的差异在于引入了数据中心节点的维度，将一个数据中心拆分成多个数据中心节点。在架构设计上，这种差异带来的最大挑战是如何有效解决系统间的通讯问题，即一个应用子系统将同时分布在多个数据中心节点上，上游调用方如何知道应该访问哪一个数据中心节点的下游子系统。针对这个问题，不可能让所有的应用做大量改动来适配这个架构，最佳的办法是将问题收敛解决。消息总线是很早就已经被提出的设计方案，通过消息总线可以收敛各应用子系统间的通讯。但仅仅采用消息总线还不够，还需要解决上游子系统快速找到合适的下游子系统的应用服务定位问题。因此，本发明实施例引入了一个全局定位系统，该系统提供全行统一的客户和服务寻址功能，根据输入的客户号、卡号或账号等客户识别信息，返回客户所在的数据中心节点编号，使得系统间调用时可获取被调用方所在的数据中心节点，通过全局定位系统提供的标准接口，告知上游子系统该访问哪个数据中心节点的下游子系统。

综上，基于上述分布式架构，本发明实施例不仅实现了“两地多中心”的整体架构，而且还取得了以下三个方面的具体成效：通过数据中心节点的设计将应用分散到多个同构的BOX中，实现了单个数据中心节点的灵活的扩容和缩容能力；实现了应用的多实例多活部署，结合“两地多中心”方案，确保了各种容灾场景下的业务连续性；通过消息总线和全局定位系统，解决了系统间的通讯问题，尽可能减小架构对应用的改动影响。

本发明实施例表明，分布式架构包括：N个数据中心和M组数据中心节点。每个数据中心包括X个数据中心节点，每组数据中心节点包括Y个数据中心节点，每组数据中心节点中的Y个数据中心节点位于Y个不同的数据中心；每个数据中心节点用于包括存放Z个客户的客户数据的数据库服务器和/或存放处理Z个客户所有业务的应用系统的应用服务器；其中，存放每个客户的客户数据的数据库服务器和/或存放处理所述Z个客户所有业务的应用系统的应用服务器都存放于一个数据中心节点中，所述N个数据中心中至少Q个数据中心位于不同城市，所述每组数据中心节点中的Y个数据中心节点包括一个主数据中心节点和至少两个从数据中心节点，N、M、X、Y、Z、Q为正整数。由于分布式架构的每个数据中心包括的数据中心节点都是以客户为维度，分组划分的，每个数据中心节点都拥有独立的业务处理需要的应用系统，可以实现分布式架构中数据中心节点发生故障时，依然保持高可用性，分散单个数据中心处理压力和故障风险，有效降低故障的影响范围，并且，Y个不同的数据中心都存放有客户数据和/或应用系统，也实现了客户数据多活和/或应用多活，即使出现故障也能无缝提供服务，降低了故障的风险影响范围。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

1.一种分布式架构，其特征在于，包括：N个数据中心和M组数据中心节点；

每个数据中心包括X个数据中心节点，每组数据中心节点包括Y个数据中心节点，每组数据中心节点中的Y个数据中心节点位于Y个不同的数据中心；

其中，存放每个客户的客户数据的数据库服务器和/或存放处理Z个客户所有业务的应用系统的应用服务器都存放于一个数据中心节点中，所述N个数据中心中至少Q个数据中心位于不同城市，所述每组数据中心节点中的Y个数据中心节点包括一个主数据中心节点和至少两个从数据中心节点，所述主数据中心节点和至少一个从数据中心中各存放所述Z个客户所有业务的应用系统的应用服务器；N、M、X、Y、Z、Q为正整数；当前数据中心节点出现问题，无法处理客户的业务时，可以由位于同一组中的其它数据中心节点的应用系统接替处理。

2.如权利要求1所述的分布式架构，其特征在于，所述每组数据中心节点中的Y个数据中心节点包括一个所述主数据中心节点，至少一个与所述主数据中心节点同城的从数据中心节点和至少一个与所述主数据中心节点异地的从数据中心节点。

3.如权利要求1所述的分布式架构，其特征在于，所述主数据中心节点和从数据中心节点中存放的Z个客户的客户数据相同，和存放的处理所述Z个客户所有业务的应用系统相同。

4.如权利要求1所述的分布式架构，其特征在于，所述Y个数据中心节点之间的物理资源相互隔离。

5.如权利要求4所述的分布式架构，其特征在于，所述Y个数据中心节点预设一个数据中心节点进行灰度发布。

6.如权利要求1所述的分布式架构，其特征在于，每个数据中心节点中的物理资源包括多个数据库服务器和多个应用服务器；

7.如权利要求1至6任一项所述的分布式架构，其特征在于，通过增加所述每组数据中心节点中的数据中心节点的数量，对所述分布式架构进行横向扩容。

8.如权利要求1至6任一项所述的分布式架构，其特征在于，通过增加所述每组数据中心节点中的预设数据中心节点的计算资源，对所述分布式架构进行纵向扩容；或通过将预留的计算资源池中的计算资源临时分配给所述每组数据中心节点中的预设数据中心节点，对所述分布式架构进行纵向扩容。

9.如权利要求1至6任一项所述的分布式架构，其特征在于，所述分布式架构还包括全局定位系统；

10.如权利要求9所述的分布式架构，其特征在于，所述全局定位系统通过消息总线分别与每个数据中心节点中的应用系统进行通信。