WO2020259086A1 - 一种分布式架构 - Google Patents
一种分布式架构 Download PDFInfo
- Publication number
- WO2020259086A1 WO2020259086A1 PCT/CN2020/088833 CN2020088833W WO2020259086A1 WO 2020259086 A1 WO2020259086 A1 WO 2020259086A1 CN 2020088833 W CN2020088833 W CN 2020088833W WO 2020259086 A1 WO2020259086 A1 WO 2020259086A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- data center
- nodes
- data
- distributed architecture
- node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
Definitions
- the embodiment of the present invention relates to the field of financial technology (Fintech), in particular to a distributed architecture.
- the common distributed architecture mainly adopts the centralized loosely coupled architecture.
- the centralized loosely coupled architecture because the customer's business is highly interdependent, according to the barrel principle, the availability and performance of the entire architecture depends on the shortest node, so , The performance of each node can only solve the processing performance of its own application and cannot realize the sharing of system load and resources between nodes.
- the current network technology cannot guarantee the absolute stability and availability of long-distance communication quality.
- the centralized loosely coupled architecture may cause customer data to be inaccessible, and there is a risk of failure.
- the embodiment of the present invention provides a distributed architecture to ensure the overall availability and scalability of the architecture, and reduce the scope of the failure risk.
- a distributed architecture provided by an embodiment of the present invention includes: N data centers and M groups of data center nodes;
- Each data center includes X data center nodes, each group of data center nodes includes Y data center nodes, and Y data center nodes in each group of data center nodes are located in Y different data centers; each data center node includes A database server storing customer data of Z customers and/or an application server storing an application system that processes all services of the Z customers;
- the database server storing the customer data of each customer and/or the application server storing the application system processing all the services of the Z customers are stored in one data center node, and at least Q pieces of data in the N data centers The centers are located in different cities, the Y data center nodes in each group of data center nodes include one master data center node and at least two slave data center nodes, and N, M, X, Y, Z, and Q are positive integers.
- each data center node since the data center nodes included in each data center of the distributed architecture are divided into groups based on the customer dimension, each data center node has an independent business processing application system and/or stores customers Data can maintain high availability even when a data center node fails in a distributed architecture, disperse the processing pressure and failure risk of a single data center, effectively reduce the scope of the failure, and all Y different data centers store customer data And/or application system, it also realizes that customer data is more active and/or application is more active, even if there is a failure, it can seamlessly provide services, reducing the scope of the risk of failure.
- the Y data center nodes in each group of data center nodes include one primary data center node, at least one secondary data center node in the same city as the primary data center node, and at least one secondary data center node that is connected to the primary data center node.
- the central node is a remote slave data center node.
- the customer data of the Z customers stored in the master data center node and the slave data center node are the same, and/or the stored application systems that process all the services of the Z customers are the same.
- the physical resources among the Y data center nodes are isolated from each other.
- the Y data center nodes preset one data center node for grayscale publishing.
- the physical resources in each data center node include multiple database servers and multiple application servers;
- the application systems are grouped according to different application domains, and different groups do not share application servers and do not share database servers.
- the distributed architecture is horizontally expanded by increasing the number of data center nodes in each group of data center nodes.
- the distributed architecture is vertically expanded by increasing the computing resources of the preset data center nodes in each group of data center nodes; or by temporarily allocating the computing resources in the reserved computing resource pool to The preset data center nodes in each group of data center nodes perform vertical expansion of the distributed architecture.
- the distributed architecture further includes a global positioning system
- the global positioning system uses a preset weighted random algorithm to manage the fragmentation strategy of the customer, and locate the data center node where the customer data is stored.
- the global positioning system communicates with application systems in each data center node through a message bus.
- FIG. 1 is a schematic structural diagram of a distributed architecture provided by an embodiment of the present invention
- FIG. 2 is a schematic structural diagram of a distributed architecture provided by an embodiment of the present invention.
- FIG. 3 is a schematic diagram of a data center node provided by an embodiment of the present invention.
- Fig. 4 is a schematic diagram of a global positioning system provided by an embodiment of the present invention.
- FIG. 1 exemplarily shows a schematic structural diagram of a distributed architecture provided by an embodiment of the present invention.
- the distributed architecture may include N data centers (Internet Data Center, IDC) and M groups of data Data Center Node (DCN).
- IDC Internet Data Center
- DCN Data Center Node
- the data center (Internet Data Center, IDC) is a physical unit for the planning and management of a new generation of Internet architecture in the financial field. It has network throughput capabilities and security protection capabilities.
- the data center can be selected according to the location
- the modules constitute the physical architecture of the data center.
- the standardization of each module includes its network architecture, physical deployment, hardware equipment models, etc., but does not include its capacity; the capacity of the module can be expanded horizontally as needed.
- the data center node is the logical unit of planning and management of the new generation Internet architecture in the financial field.
- Each data center node is a node with independent physical resources and self-contained application logic, used to carry a specific customer group or provide a set of specific services.
- Data center nodes have independent physical computing and storage resources. Different nodes do not share physical computing and storage resources. Different nodes share data center-level resources, mainly including: data center infrastructure, basic network, and data center level Public services (for example: message bus, etc.).
- data center nodes can be divided into two types of services according to different service objects: one is customer service: the external services provided by the bank to various types of bank customers; the other is the bank Back-end management services: internal services used by the bank itself, such as general ledger, management accounting, etc.
- each data center includes X data center nodes, each group of data center nodes includes Y data center nodes, and Y data center nodes in each group of data center nodes are located at Y Different data centers; each data center node includes a database server for storing customer data of Z customers and/or an application server for storing application systems for processing all services of Z customers.
- the database server that stores the customer data of each customer and/or the application server that stores the application systems that process all the services of the Z customers are stored in one data center node, and at least Q of the N data centers are located in different cities .
- the Y data center nodes in each group of data center nodes include one master data center node and at least two slave data center nodes, and N, M, X, Y, Z, and Q are positive integers.
- the customer data of Z customers stored in the main data center node and the slave data center node are the same as the application system that processes all the services of the Z customers.
- the number of data centers in the same city can be selected as multiple (for example, N or less than N).
- N the number of data centers in the same city
- the number of Y is less than N.
- each group of data center nodes only needs to include Y data center nodes. It is not necessary for each group of data center nodes to contain N data center nodes.
- a backup data center node provides services, which can prevent excessive consumption of resources.
- N data centers such as 5
- M groups of data center nodes DCN
- DCN group 1 can optionally include three DCNs, one of which is located in IDC1 Among them, one is located in IDC2, and the other is located in IDC3.
- the DCNs in IDC1 and IDC2 each contain a database server that stores customer data and an application server that stores application systems that process all customer business.
- IDC3 only contains storage The database server of customer data, in this way, the number of data center nodes in each group of data center nodes is less than the number of data centers, which can ensure that there is a backup data center node when a data center node fails Providing services can also prevent excessive consumption of resources.
- IDC3 can also deploy an application server.
- a data center node includes a database server and/or an application server, and the database server and the application server are independent of each other on two different levels and do not respond to each other.
- multi-instance and active deployment of application systems can be realized. Even if the application system in a certain DCN fails, it can be provided by other DCN application systems. Services can ensure business continuity in various disaster recovery scenarios. In the existing distributed architecture, when a certain application system fails, the backup application system can only be manually started manually, which requires a long waiting time, and the obvious failure has a large impact range.
- each data center node has an independent application system for processing all customer services.
- the application system takes over the processing, and there is no need to set up the main and standby application systems in a data center node, saving the resources of the data center node.
- At least Q data centers of N data centers are located in different cities.
- the distributed architecture as shown in FIG. 2 there are three data centers in total, of which there are two data centers in the same city and one data center for remote disaster recovery.
- This kind of architecture can be called a "two places and three centers" deployment architecture.
- a single data center from power supply, cooling to network connectivity is designed according to the minimum 2N level of redundancy, and requires all lines to be physically Isolation to ensure that a construction site does not have a fatal impact on the connectivity of a single data center. Therefore, when any data center in the same city fails, the architecture can support the switch between data centers in the same city.
- each group of data center nodes include a primary data center node, at least one secondary data center node in the same city as the primary data center node, and at least one secondary data center node that is remote from the primary data center node .
- each data center is composed of multiple data center nodes.
- Each group of data center nodes is composed of a master node, a backup node in the same city, and a disaster recovery node in a remote location.
- each group of data center nodes also independently form a "two places and three centers" structure to ensure that the main node fails It can quickly switch to the standby node and support uninterrupted business operation to meet RTO (Recovery Time Object, Recovery Time Object) and RPO (Recovery Point Object, Recovery Point Object) related requirements.
- RTO Recovery Time Object
- RPO Recovery Point Object, Recovery Point Object
- Two data center nodes can be located in the same city, and the other data center node can be located in a remote city, so that each group of data center nodes can also be formed independently.
- the "two locations and three centers" structure can disperse the processing pressure of a single data center and save system overhead.
- a single data center node its physical resources include multiple database servers and multiple application servers.
- Application systems are grouped according to different application domains, and different groups do not share application servers and do not share database servers.
- the physical resources between data center nodes are isolated from each other.
- data center nodes can be analyzed from the composed hardware resources and deployed data and application systems.
- a data center node contains hardware resources such as application servers and database servers.
- the relevant hardware resources of a data center node are deployed in a centralized manner, fixed by 2 application server cabinets and 3 database server cabinets constitute.
- Each SET (data set) is composed of three SET nodes, and the three SET nodes are scattered on three database server cabinets.
- the corresponding data is stored in three copies, and the three data are distributed in three different cabinets.
- Such a database deployment structure can fully guarantee the high availability of data.
- operation and maintenance management tools such as configuration information management
- banks have become more mature in the management of data center nodes, and can read and filter all resource information related to a data center node from the operation and maintenance management tools at any time and quickly.
- data center nodes are also facing certain expansion requirements.
- the current data center nodes are no longer limited to centralized cabinets, but are more open and transformed into logical regional divisions.
- the data center becomes a huge resource pool.
- a data center can be integrated at any time according to actual construction needs. Any server joining or moving out of a data center node can quickly realize the elastic expansion and shrinkage of data center nodes.
- Each group of data center nodes can preset a data center node for grayscale release. Through the distributed architecture with customers as the unit, the weight of customer allocation of one of the nodes can be reduced, so that this node has exactly the same application architecture, deployment architecture and resource configuration as all other nodes, but lower than the customer load of other nodes .
- the distributed architecture with customers as the unit through the isolation of each customer node, through standardized node deployment and the control of customer distribution weights, can easily achieve true and effective grayscale verification, thereby greatly improving the application release cycle. Reduce the dependence on the test process, through the gray production flow, directly completed the last test link of software and hardware update in the production environment.
- the distributed architecture has two expansion methods, specifically:
- the bank’s customer service capacity can be increased by rapidly deploying corresponding types of standard data center nodes; in the vertical expansion strategy, we have two different modes: one is permanent expansion, the other is Temporary expansion.
- Permanent expansion refers to vertical expansion and upgrade by increasing the computing resources of logical nodes. For example, a module was originally scheduled to serve 5 million customers. With the continuous development of business and the continuous launch of new products, while serving 5 million customers unchanged, multiple nodes generally have performance bottlenecks. Then, at this time, computing resources will be added to these nodes according to certain strategies, and the processing capabilities of the nodes will be permanently improved.
- the distributed architecture also includes a global positioning system, which uses a preset weighted random algorithm to manage fragmentation strategies for customers and locate data center nodes where customer data is stored.
- the global positioning system uses a weighted random algorithm to determine which data center node to store the new customer's data when creating a new customer, and in the subsequent business processing of the new customer, through a fragmented information retrieval mechanism based on customer information To locate the data center node where customer data needed for business processing is stored, that is, use the global positioning system for customer segmentation management and customer positioning.
- the customer data storage nodes are allocated through the global positioning system, and the weighted random algorithm is used to implement in a distributed architecture.
- the weighted random algorithm is used to implement in a distributed architecture.
- the global positioning system communicates with the application systems in each data center node through the message bus.
- the biggest difference between the above model and the model adopted by traditional banks is the introduction of the dimension of data center nodes, which splits a data center into multiple data center nodes.
- the biggest challenge brought by this difference is how to effectively solve the communication problem between systems, that is, an application subsystem will be distributed on multiple data center nodes at the same time, how does the upstream caller know which data center to visit?
- the downstream subsystem of the node To solve this problem, it is impossible to make a lot of changes to all applications to adapt to this architecture. The best way is to converge and solve the problem.
- the message bus is a design scheme that has been proposed for a long time, and the communication between various application subsystems can be converged through the message bus. But just using the message bus is not enough.
- the embodiment of the present invention introduces a global positioning system that provides uniform customer and service addressing functions across the bank, and returns the data center node number where the customer is located based on the customer identification information such as the customer number, card number, or account number entered. This makes it possible to obtain the data center node where the callee is located when calling between systems, and inform the upstream subsystem of which data center node's downstream subsystem to visit through the standard interface provided by the global positioning system.
- the embodiment of the present invention not only realizes the overall architecture of “two places and multiple centers”, but also achieves specific results in the following three aspects: Distribute applications to multiple data center nodes through the design In the homogeneous BOX, the flexible expansion and shrinkage capabilities of a single data center node are realized; the multi-instance multi-active deployment of applications is realized, and the "two-place multi-center" solution is combined to ensure business in various disaster recovery scenarios Continuity: Through the message bus and the global positioning system, the communication problem between systems is solved, and the impact of the change of the architecture on the application is minimized.
- the embodiment of the present invention shows that the distributed architecture includes: N data centers and M groups of data center nodes.
- Each data center includes X data center nodes, each group of data center nodes includes Y data center nodes, and Y data center nodes in each group of data center nodes are located in Y different data centers; each data center node is used for Including a database server that stores customer data of Z customers and/or an application server that stores application systems that process all services of Z customers; among them, a database server that stores customer data of each customer and/or stores and processes the Z customers
- the application servers of all business application systems are stored in one data center node, at least Q data centers in the N data centers are located in different cities, and the Y data center nodes in each group of data center nodes include a master For the data center node and at least two slave data center nodes, N, M, X, Y, Z, and Q are positive integers.
- each data center node Since the data center nodes included in each data center of the distributed architecture are based on the customer dimension and divided into groups, each data center node has an independent business processing application system, which can realize the data center nodes in the distributed architecture In the event of a failure, it still maintains high availability, disperses the processing pressure and failure risk of a single data center, and effectively reduces the scope of the failure. Moreover, Y different data centers store customer data and/or application systems, and customer data is also realized Multi-activity and/or application multi-activity can seamlessly provide services even if there is a failure, reducing the scope of the risk of failure.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明涉及金融科技领域，并公开了一种分布式架构，分布式架构包括：N个数据中心和M组数据中心节点。每个数据中心包括X个数据中心节点，每组数据中心节点包括Y个数据中心节点，每组数据中心节点中的Y个数据中心节点位于Y个不同的数据中心，每个数据中心节点包括用于存放Z个客户的客户数据的数据库服务器和/或存放处理Z个客户所有业务的应用系统的应用服务器。由于分布式架构的每个数据中心包括的数据中心节点都是以客户为维度，分组划分的，每个数据中心节点都拥有独立的业务处理需要的应用系统，可以实现分布式架构中数据中心节点发生故障时，依然保持高可用性，分散单个数据中心处理压力和故障风险，有效降低故障的影响范围。
Description
相关申请的交叉引用
本申请要求在2019年06月25日提交中国专利局、申请号为201910553289.2、申请名称为“一种分布式架构”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
本发明实施例涉及金融科技(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 (10)
- 一种分布式架构，其特征在于，包括：N个数据中心和M组数据中心节点；每个数据中心包括X个数据中心节点，每组数据中心节点包括Y个数据中心节点，每组数据中心节点中的Y个数据中心节点位于Y个不同的数据中心；每个数据中心节点包括用于存放Z个客户的客户数据的数据库服务器和/或存放处理所述Z个客户所有业务的应用系统的应用服务器；其中，存放每个客户的客户数据的数据库服务器和/或存放处理所述Z个客户所有业务的应用系统的应用服务器都存放于一个数据中心节点中，所述N个数据中心中至少Q个数据中心位于不同城市，所述每组数据中心节点中的Y个数据中心节点包括一个主数据中心节点和至少两个从数据中心节点，N、M、X、Y、Z、Q为正整数。
- 如权利要求1所述的分布式架构，其特征在于，所述每组数据中心节点中的Y个数据中心节点包括一个所述主数据中心节点，至少一个与所述主数据中心节点同城的从数据中心节点和至少一个与所述主数据中心节点异地的从数据中心节点。
- 如权利要求1所述的分布式架构，其特征在于，所述主数据中心节点和从数据中心节点中存放的Z个客户的客户数据相同，和/或存放的处理所述Z个客户所有业务的应用系统相同。
- 如权利要求1所述的分布式架构，其特征在于，所述Y个数据中心节点之间的物理资源相互隔离。
- 如权利要求4所述的分布式架构，其特征在于，所述Y个数据中心节点预设一个数据中心节点进行灰度发布。
- 如权利要求1所述的分布式架构，其特征在于，每个数据中心节点中的物理资源包括多个数据库服务器和多个应用服务器；所述应用系统按照不同的应用域进行分组，不同的组不共享应用服务器 以及不共享数据库服务器。
- 如权利要求1至6任一项所述的分布式架构，其特征在于，通过增加所述每组数据中心节点中的数据中心节点的数量，对所述分布式架构进行横向扩容。
- 如权利要求1至6任一项所述的分布式架构，其特征在于，通过增加所述每组数据中心节点中的预设数据中心节点的计算资源，对所述分布式架构进行纵向扩容；或通过将预留的计算资源池中的计算资源临时分配给所述每组数据中心节点中的预设数据中心节点，对所述分布式架构进行纵向扩容。
- 如权利要求1至6任一项所述的分布式架构，其特征在于，所述分布式架构还包括全局定位系统；所述全局定位系统采用预设的加权随机算法对所述客户进行分片策略管理，和对所述客户数据存放的数据中心节点进行定位。
- 如权利要求9所述的分布式架构，其特征在于，所述全局定位系统通过消息总线分别与每个数据中心节点中的应用系统进行通信。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910553289.2A CN110225138B (zh) | 2019-06-25 | 2019-06-25 | 一种分布式架构 |
| CN201910553289.2 | 2019-06-25 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2020259086A1 true WO2020259086A1 (zh) | 2020-12-30 |
Family
ID=67814748
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2020/088833 Ceased WO2020259086A1 (zh) | 2019-06-25 | 2020-05-06 | 一种分布式架构 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN110225138B (zh) |
| WO (1) | WO2020259086A1 (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113347265A (zh) * | 2021-06-18 | 2021-09-03 | 深圳前海微众银行股份有限公司 | 一种服务端灰度发布控制方法及系统 |
| CN114546724A (zh) * | 2022-02-22 | 2022-05-27 | 山东浪潮科学研究院有限公司 | 一种两中心部署的数据中心级别容灾方法与系统 |
| CN117879852A (zh) * | 2023-10-31 | 2024-04-12 | 北京四方继保工程技术有限公司 | 基于电力系统应用分组的跨安全区数据交互方法及系统 |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110225138B (zh) * | 2019-06-25 | 2021-12-14 | 深圳前海微众银行股份有限公司 | 一种分布式架构 |
| CN110990200B (zh) * | 2019-11-26 | 2022-07-05 | 苏宁云计算有限公司 | 一种基于多活数据中心的流量切换方法及装置 |
| CN112698839B (zh) * | 2020-12-30 | 2024-04-12 | 深圳前海微众银行股份有限公司 | 数据中心节点部署方法、装置、系统及计算机存储介质 |
| CN113961400B (zh) * | 2021-12-21 | 2022-03-08 | 唐山启奥科技股份有限公司 | 血液容灾及应急管理系统及方法 |
| CN116069855A (zh) * | 2022-11-23 | 2023-05-05 | 中国工商银行股份有限公司 | 分布式服务路由方法及装置 |
| CN116016094A (zh) * | 2022-12-13 | 2023-04-25 | 平安银行股份有限公司 | 一种分布式架构金融系统及服务调用方法 |
| CN116258502A (zh) * | 2023-03-17 | 2023-06-13 | 中国工商银行股份有限公司 | 支付处理方法、装置、服务器及存储介质 |
| CN117453150B (zh) * | 2023-12-25 | 2024-04-05 | 杭州阿启视科技有限公司 | 录像存储调度服务多实例的实现方法 |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020194015A1 (en) * | 2001-05-29 | 2002-12-19 | Incepto Ltd. | Distributed database clustering using asynchronous transactional replication |
| CN105681401A (zh) * | 2015-12-31 | 2016-06-15 | 深圳前海微众银行股份有限公司 | 分布式架构 |
| CN105763386A (zh) * | 2016-05-13 | 2016-07-13 | 中国工商银行股份有限公司 | 业务处理系统及方法 |
| CN107038192A (zh) * | 2016-11-17 | 2017-08-11 | 阿里巴巴集团控股有限公司 | 数据库容灾方法和装置 |
| CN107391294A (zh) * | 2017-07-28 | 2017-11-24 | 郑州云海信息技术有限公司 | 一种ipsan容灾系统的建立方法及装置 |
| CN109819004A (zh) * | 2017-11-22 | 2019-05-28 | 中国人寿保险股份有限公司 | 用于部署多活数据中心的方法和系统 |
| CN110225138A (zh) * | 2019-06-25 | 2019-09-10 | 深圳前海微众银行股份有限公司 | 一种分布式架构 |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9756184B2 (en) * | 2012-11-08 | 2017-09-05 | Genesys Telecommunications Laboratories, Inc. | System and method of distributed maintenance of contact center state |
| CN104717186B (zh) * | 2013-12-16 | 2019-06-25 | 腾讯科技（深圳）有限公司 | 一种在网络系统中传输数据的方法、装置及数据传输系统 |
| CN105554126A (zh) * | 2015-12-22 | 2016-05-04 | 内蒙古农业大学 | 一种通过cdn加速机制实现多数据中心分布式部署的方法 |
| CN105577675A (zh) * | 2015-12-31 | 2016-05-11 | 深圳前海微众银行股份有限公司 | 多租户资源管理的方法及装置 |
| CN107193546B (zh) * | 2017-04-11 | 2021-05-04 | 国网天津市电力公司信息通信公司 | 一种微服务化业务应用系统 |
| CN107454171B (zh) * | 2017-08-10 | 2021-04-30 | 深圳前海微众银行股份有限公司 | 消息服务系统及其实现方法 |
| CN108989456B (zh) * | 2018-08-11 | 2019-06-25 | 广东易积网络股份有限公司 | 一种基于大数据的网络实现方法 |
| CN208820800U (zh) * | 2018-09-25 | 2019-05-03 | 国家电网有限公司客户服务中心 | 一种基于核心业务灾备的95598异地双活系统 |
| CN109447876A (zh) * | 2018-10-16 | 2019-03-08 | 湖北三峡云计算中心有限责任公司 | 一种市民卡系统 |
| CN109542659A (zh) * | 2018-11-14 | 2019-03-29 | 深圳前海微众银行股份有限公司 | 应用多活方法、设备、数据中心集群及可读存储介质 |
-
2019
- 2019-06-25 CN CN201910553289.2A patent/CN110225138B/zh active Active
-
2020
- 2020-05-06 WO PCT/CN2020/088833 patent/WO2020259086A1/zh not_active Ceased
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020194015A1 (en) * | 2001-05-29 | 2002-12-19 | Incepto Ltd. | Distributed database clustering using asynchronous transactional replication |
| CN105681401A (zh) * | 2015-12-31 | 2016-06-15 | 深圳前海微众银行股份有限公司 | 分布式架构 |
| CN105763386A (zh) * | 2016-05-13 | 2016-07-13 | 中国工商银行股份有限公司 | 业务处理系统及方法 |
| CN107038192A (zh) * | 2016-11-17 | 2017-08-11 | 阿里巴巴集团控股有限公司 | 数据库容灾方法和装置 |
| CN107391294A (zh) * | 2017-07-28 | 2017-11-24 | 郑州云海信息技术有限公司 | 一种ipsan容灾系统的建立方法及装置 |
| CN109819004A (zh) * | 2017-11-22 | 2019-05-28 | 中国人寿保险股份有限公司 | 用于部署多活数据中心的方法和系统 |
| CN110225138A (zh) * | 2019-06-25 | 2019-09-10 | 深圳前海微众银行股份有限公司 | 一种分布式架构 |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113347265A (zh) * | 2021-06-18 | 2021-09-03 | 深圳前海微众银行股份有限公司 | 一种服务端灰度发布控制方法及系统 |
| CN114546724A (zh) * | 2022-02-22 | 2022-05-27 | 山东浪潮科学研究院有限公司 | 一种两中心部署的数据中心级别容灾方法与系统 |
| CN117879852A (zh) * | 2023-10-31 | 2024-04-12 | 北京四方继保工程技术有限公司 | 基于电力系统应用分组的跨安全区数据交互方法及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110225138A (zh) | 2019-09-10 |
| CN110225138B (zh) | 2021-12-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2020259086A1 (zh) | 一种分布式架构 | |
| JP5102901B2 (ja) | データセンタにわたる複数データサーバ間のデータ完全性を保持する方法およびシステム | |
| CN105187464B (zh) | 一种分布式存储系统中的数据同步方法、装置及系统 | |
| CN204859222U (zh) | 同城数据中心双活高可用系统 | |
| CN107707393A (zh) | 基于Openstack O版特性的多活系统 | |
| CN109313564A (zh) | 用于支持多个不同租户的高度可用虚拟桌面的服务器计算机管理系统 | |
| CN101227315A (zh) | 动态服务器集群及其控制方法 | |
| US20090187668A1 (en) | Protocol Independent Server Replacement and Replication in a Storage Area Network | |
| CN114301972B (zh) | 一种基于云边协同的区块链节点分级部署方法和系统 | |
| CN109819004A (zh) | 用于部署多活数据中心的方法和系统 | |
| CN113779143B (zh) | 双活数据中心和业务系统 | |
| CN105681401A (zh) | 分布式架构 | |
| CN109739640A (zh) | 一种基于申威架构的容器资源管理系统 | |
| CN107291821A (zh) | 一种同城双活架构快速切换的方法 | |
| CN101996094A (zh) | 一种分布式资源管理方法及系统 | |
| CN109361777A (zh) | 分布式集群节点状态的同步方法、同步系统及相关装置 | |
| CN104410531A (zh) | 冗余的系统架构方法 | |
| CN110535924A (zh) | 一种轨道交通服务器通信方法及系统 | |
| CN108319618A (zh) | 一种分布式存储系统的数据分布控制方法、系统及装置 | |
| WO2023109062A1 (zh) | 云灾备系统、方法、电子设备及存储介质 | |
| CN108964986A (zh) | 协同办公系统应用级双活灾备系统 | |
| CN105872024A (zh) | 容灾设备、系统及方法 | |
| CN110719282A (zh) | 一种基于统一权限的认证双活系统 | |
| CN107577564A (zh) | 一种基于块同步技术实现双活系统的方法 | |
| CN119904228A (zh) | 交易处理方法、装置、计算机设备和存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 20831503 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 20831503 Country of ref document: EP Kind code of ref document: A1 |
|
| 32PN | Ep: public notification in the ep bulletin as address of the adressee cannot be established |
Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 05/04/2022) |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 20831503 Country of ref document: EP Kind code of ref document: A1 |