Banking system, data processing method, storage medium and program product

Abstract

This application provides a banking system, data processing method, storage medium, and program product. The banking system includes: multiple business layers divided by an application architecture based on the banking business domain; each business layer includes at least one application system; each application system corresponds to an application group; the application group includes: N applications built based on a cloud-native domain model; each application system includes: at least two internal modules deployed using a distributed microservice architecture; each internal module includes a microservice gateway and M microservice modules, each microservice module providing one application from the application group; the cloud includes: resources located in multiple regions; the computing resources in each region include: multiple workspaces, each workspace including: at least one availability zone in a data center, with availability zones within the same workspace communicating via a dedicated network; each availability zone includes: multiple units. The method of this application enables the effective construction of a banking system in the cloud.

Description

Technical Field

[0001] This application relates to the field of cloud computing, and more particularly to a banking system, data processing method, storage medium, and program product. Background Technology

[0002] Cloud-native is a distributed cloud based on distributed deployment and unified operation and management, and is a cloud technology product system built on technologies such as containers, microservices, and DevOps. Migrating enterprise systems to the cloud has become a trend, and building cloud-based systems for banking has become an inevitable choice for banking development.

[0003] Currently, cloud-native infrastructure frameworks only provide atomic, basic service governance and monitoring capabilities, targeting fine-grained objects such as applications and APIs, and are highly technical. However, banking systems often involve more macro-level concepts, targeting application systems and units. Therefore, how to build a unified banking system in the cloud based on fine-grained objects has become a pressing issue. Summary of the Invention

[0004] This application provides a banking system, data processing method, storage medium, and program product. By establishing a mapping relationship between domain objects in the banking operation and maintenance domain model and fine-grained objects in the cloud-native infrastructure technology system, it solves the problem of the difficulty in establishing a banking system for enterprise and banking business in the cloud.

[0005] In a first aspect, this application provides a banking system built on the cloud based on a domain model, the banking system comprising: multiple business layers divided by an application architecture based on the banking business domain;

[0006] Each of the business layers includes at least one application system; each application system corresponds to an application group; the application group includes: N applications built based on a cloud-native domain model;

[0007] Each of the application systems includes: at least two internal modules deployed using a distributed microservice architecture, and the data required for the operation of each of the internal modules;

[0008] Each of the internal modules includes a microservice gateway and multiple microservice modules, each of the microservice modules being used to provide one application from the application group;

[0009] The cloud includes resources located in multiple regions;

[0010] The computing resources of each region include: multiple workspaces, each workspace including: at least one availability zone of a computer room, and the availability zones of the same workspace communicate with each other via a dedicated network;

[0011] Each availability zone includes: multiple units; each unit includes multiple deployment groups, and each unit is used to deploy application systems of a corresponding type;

[0012] The internal modules are deployed in units that match the type of application system they belong to, and different internal modules are deployed in different units.

[0013] Multiple instances of the microservice modules of the internal modules are deployed on at least one deployment group of the unit.

[0014] Optionally, the plurality of units include: a core business unit, a global business unit, a shared business unit, and a global technology unit;

[0015] The core business unit is used to deploy application systems that are split according to the user dimension;

[0016] The global business unit is used to deploy application systems containing applications that need to access the full amount of data.

[0017] The shared business unit is a read-only copy of the global business unit, used to deploy application systems that are frequently accessed by critical business processes.

[0018] The global technical unit is used to deploy technical components that are invoked by the application system of other units.

[0019] Optionally, the multiple business layers include: a channel integration layer, a user interaction layer, an integration layer, a business service layer, a data management layer, an intelligent analysis layer, and a technical support layer.

[0020] Secondly, this application provides a data processing method, which is applied to a banking system as described in any of the first aspects, the method comprising:

[0021] In response to a user-triggered resource monitoring request for the first dimension, resource monitoring is performed on the application system corresponding to the first dimension in the banking system; the first dimension includes at least one of the following: region, data center, unit, application group, application; the resources include: computing resources and / or traffic;

[0022] When the resources of any application system exceed the preset resource range corresponding to the first dimension, the resources of the application system are dynamically adjusted according to the resource usage of the banking system.

[0023] Optionally, the method further includes:

[0024] In response to a user-triggered request to aggregate and calculate the indicator data of the application system corresponding to the second dimension, the indicator data of the application system corresponding to the second dimension in the banking system is obtained; the second dimension includes at least one of the following: region, data center, unit, application group, and application;

[0025] Aggregate and calculate the indicator data corresponding to the second dimension;

[0026] Output the aggregated index data.

[0027] Optionally, the method further includes:

[0028] In response to a user-triggered canary release strategy configuration request for the application system corresponding to the third dimension, the canary release strategy of the application system corresponding to the third dimension is updated using the canary release strategy in the canary release strategy configuration request; the third dimension includes at least one of the following: region, data center, unit, application group, application.

[0029] The application system corresponding to the third dimension is subject to canary release control according to the updated canary release strategy.

[0030] Optionally, the method further includes:

[0031] In response to a user-triggered configuration request for an application system corresponding to the fourth dimension, the configuration information in the configuration request is used to configure the application system corresponding to the fourth dimension; the fourth dimension includes at least one of the following: region, data center, unit, application group, application; the configuration information includes: configuration information for system parameters and / or configuration information for access permissions;

[0032] Run the application system corresponding to the fourth dimension after configuration.

[0033] Optionally, the method further includes:

[0034] In response to a user-triggered disaster recovery switching request for the application system corresponding to the fifth dimension, disaster recovery switching is performed on the resources used by the application system corresponding to the fifth dimension; the fifth dimension includes at least one of the following: region, data center, unit, application group, and application.

[0035] Thirdly, this application provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, are used to implement the method as described in any of the second aspects.

[0036] Fourthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the second aspects.

[0037] The banking system, data processing method, storage medium, and program products provided in this application establish a mapping relationship between domain objects in the banking operation and maintenance domain model and fine-grained objects in the cloud-native basic technology system. For example, a mapping relationship is established between application systems and application groups, and a mapping relationship is established between microservice modules in the banking system and applications in the cloud, thereby realizing the construction of a domain model-based banking system in the cloud. Attached Figure Description

[0038] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0039] Figure 1 This application provides an architectural diagram of a banking system built on a domain model in the cloud.

[0040] Figure 2 This application provides a layered diagram of a bank application architecture.

[0041] Figure 3 A schematic diagram illustrating the mapping relationship between a banking system and a cloud domain model provided in this application;

[0042] Figure 4 A schematic diagram of a cloud architecture provided for this application;

[0043] Figure 5 A schematic diagram of a modular architecture provided in this application;

[0044] Figure 6 A flowchart illustrating a data processing method provided in this application;

[0045] Figure 7 A flowchart illustrating another data processing method provided in this application;

[0046] Figure 8 A flowchart illustrating another data processing method provided in this application;

[0047] Figure 9 A flowchart illustrating yet another data processing method provided in this application.

[0048] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0049] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0050] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0051] It should be noted that the banking system, data processing method, storage medium, and program product provided in this application can be used in the field of cloud computing, or in any field other than cloud computing. This application does not limit the application field of the banking system, data processing method, storage medium, and program product.

[0052] The following is an explanation of some of the terms used in this application:

[0053] Virtual Private Cloud (VPC): This is a private network in the cloud that you have all of your own. You have complete control over your private network, such as choosing IP address ranges, configuring routing tables and gateways, and you can use resources such as cloud servers, cloud databases, and load balancers within your self-defined private network.

[0054] Canary release, also known as gray-scale release, refers to a release method that allows for a smooth transition between black and white (unlocked and unreleased versions). It enables A / B testing, where some users continue using product feature A while others start using product feature B. If users have no objections to feature B, the release is gradually expanded until all users are migrated to feature B. Canary releases ensure overall system stability, allowing issues to be identified and addressed during the initial phase to minimize impact.

[0055] Domain model: A domain model is a visual representation of conceptual classes or real-world objects within a domain. It is also known as a conceptual model, domain object model, or analysis object model. Through a domain model, enterprises can focus on analyzing the problem domain itself, uncovering important business domain concepts, and establishing relationships between these concepts.

[0056] Pod: The smallest resource management component in Kubernetes, and also the smallest resource object for running containerized applications. A Pod represents a process running in the cluster.

[0057] Aggregate calculation: Aggregate operation is a data analysis operation that calculates a value from a set of values. For example, operations such as finding the maximum value, minimum value, sum, mean, variance, and median are all aggregate operations.

[0058] The IT operations and maintenance (O&M) systems of banks are quite complex, and their scale is often substantial. Furthermore, because bank systems are built upon years of usage experience, their architecture, functions, processes, and systems are relatively mature, possessing their own system architecture and domain model. In addition, the concepts associated with bank systems are often quite macroscopic, directly corresponding to entities within the O&M domain. For example, in actual O&M operations, maintenance personnel focus on concepts such as application architecture layering, application systems, and the relationships between application systems.

[0059] Currently, migrating enterprise systems to the cloud has become a trend, and building cloud-based banking systems has become an inevitable choice for the development of banking enterprises. However, the basic cloud-native technology frameworks only provide atomic, basic service governance, monitoring, and other operational capabilities, targeting fine-grained objects such as applications and application programming interfaces (APIs), and are inherently quite technical. Furthermore, different technology stacks offer varying concepts and capabilities. Existing domain models built on cloud-based technology concepts often fail to align with the banking domain model. Therefore, establishing a mapping relationship between macro-level domain objects (such as application systems and units) in the banking system's operational domain model and fine-grained objects (applications, APIs, etc.) in the cloud-native technology system, while shielding the differences in capabilities and implementations of different underlying technology stacks, and ultimately building an enterprise-level unified continuous release, operational governance, monitoring, and alerting banking system in the cloud, has become a pressing issue that needs to be addressed.

[0060] In view of this, this application provides a banking system built on the cloud based on a domain model. This domain model not only fits the system architecture characteristics of the banking system, but also corresponds to the fine-grained technology concepts of the cloud. It establishes a mapping relationship between macro-granular domain objects in the banking system operation and maintenance domain model and fine-grained objects in the cloud-native basic technology system, which can achieve a good fit between the banking system and the cloud technology system.

[0061] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0062] Figure 1 This application provides an architectural diagram of a banking system built in the cloud based on a domain model, as shown below. Figure 1 As shown, the banking system includes multiple business layers divided by the application architecture based on the banking business domain.

[0063] This application does not limit the specific form of the application architecture in the bank's business areas, nor does it limit the type or number of the aforementioned business layers. For example, Figure 2 This application provides a layered diagram of a bank application architecture, such as... Figure 2 As shown, multiple business layers may include one or more of the following: channel integration layer, user interaction layer, integration layer, business service layer, data management layer, intelligent analysis layer, and technical support layer. It should be understood that the above business layers are merely examples. In actual applications, the bank application architecture can be layered according to the above method, or other layering methods can be used, such as including other business layers besides those mentioned above. This application does not limit this.

[0064] Continue to refer to Figure 1 Each business layer includes at least one application system. The application system referred to here can be, for example, a business function within each business layer. For instance, the business service layer may include one or more of a payment and settlement application system, a funds transaction business system, and a credit management business system. It should be understood that the application systems in the above-described business service layer are merely examples; in actual application, the application systems included in each business layer can be determined according to the actual situation, and are not limited here.

[0065] Figure 3 This application provides a schematic diagram illustrating the mapping relationship between a banking system and a cloud domain model, such as... Figure 3 As shown, each of the above application systems corresponds to an application group. This application group includes N applications built based on a cloud-native domain model. This application does not limit the specific value of N; those skilled in the art can determine it according to the actual situation. The application group and application mentioned here refer to cloud-based concepts. An application refers to a set of code used to implement a specific function; this application does not limit the specific content of the code represented by each application.

[0066] Continue to refer to Figure 1Each application system includes: at least two internal modules deployed using a distributed microservice architecture, and the data required for the operation of each internal module. This application does not limit the specific content of the data required for the operation of each internal module; those skilled in the art can set it according to actual conditions. This application does not limit the specific implementation method of the above-mentioned distributed microservice architecture; specific implementations can be found in existing technologies, which will not be elaborated upon here.

[0067] Continuing with reference to 1, each of the above internal modules includes a microservice gateway and M microservice modules. Each microservice module provides a microservice for one application within the application group. The microservice gateway is used to enable interaction between internal modules and other internal modules or other application systems.

[0068] Each internal module can contain a maximum of N microservice modules, and these microservice modules can be the same or different. When the number of microservice modules in each internal module is different, differentiated services can be provided for the application system through these different internal modules.

[0069] For example, an internal module A includes N microservice modules, meaning it can provide microservices for N applications in total. Another internal module B includes M microservice modules, meaning it can provide microservices for M applications in total. In this implementation, internal module A can provide microservices for N applications in the application system for one type of user, while internal module B can provide microservices for M applications in the application system for another type of user, where M is less than N.

[0070] Optional, continue to refer to Figure 1 Since the application architecture is layered and the internal modules are all collections of service modules, and service modules correspond to application groups, the above application architecture layering and internal modules can all correspond to the concept of cloud application groups.

[0071] Figure 4 This application provides a schematic diagram of a cloud-based architecture, such as... Figure 4 As shown, the cloud includes resources located in multiple regions.

[0072] The aforementioned resources may include one or more of the following: computing resources, traffic, storage resources, and network transmission resources. It should be understood that this application does not limit the method of dividing the aforementioned regions; for example, the regions may be divided according to administrative divisions or based on the communication latency of resources within a region. For instance, the communication latency between resources within a region may not exceed a preset latency threshold. This application does not limit the specific value of this preset latency threshold; for example, it may be 2 milliseconds.

[0073] The computing resources for each region include multiple workspaces. This application does not limit the number or type of workspaces included in the computing resources for each region; the specific configuration can be based on the actual architecture of the bank's system. For example, multiple workspaces may include one or more of production workspaces and development workspaces.

[0074] Each workspace includes at least one availability zone in a data center. Availability zones within the same workspace communicate with each other using VPCs. VPCs define network boundaries, making it easier to customize network planning and management in the cloud. This allows for the creation of custom virtual router (vRouter) network segments and the configuration of routing table rules, as well as custom virtual switches (vSwitchers) and the configuration of subnets.

[0075] Each availability zone includes multiple units. These units can be, for example, logical units. This application does not limit the number or type of units included in each availability zone; the specific configuration can be based on the actual architecture of the bank's system. For example, an availability zone may include one or more of the following: a core business unit (Region Zone, RZone), a global business unit (Global Zone, GZone), a shared business unit (City Zone, CZone), and a global technology unit (Global Technique Zone, GTZone). This application does not limit the number of different units included in each availability zone.

[0076] RZone is used to deploy application systems split according to user dimensions. For example, each application system is split according to the smallest unit of functional implementation, and each smallest unit is further split according to the user dimension to obtain an RZone. For example, an RZone may include the full data of 10 users, corresponding to one internal module of the application system. The full data mentioned here refers to all data required to implement the business functions of the business system deployed in the RZone. It should be understood that this application does not limit the number of users included in each RZone; those skilled in the art can determine this based on actual circumstances. Optionally, the user data included in the RZone is hash-sharded according to the same business key value (e.g., customer identification), and each RZone is also sharded according to the same business key value. Since each RZone can perform business processing independently without accessing other units, i.e., convergence within each RZone unit, the business processing speed of the banking system can be improved in this way, while also improving system availability and disaster recovery performance. That is, when one RZone fails, it will not affect the normal processing of other units.

[0077] GZone is used to deploy application systems that require access to the full dataset. GZone deploys application systems that are not split by user dimension, which are relied upon by RZone to provide indivisible data and services, such as configuration-based services.

[0078] CZone is a read-only copy of GZone, used to deploy application systems that are frequently accessed by critical business operations, such as those deployed in RZone. Since there is a time lag between the creation (writing) and use (reading) of most data, and because the data in CZone is read-only, this method can solve the cross-domain communication latency problem.

[0079] GTZone is a technical component used for deployment and invocation by application systems of other units. This application does not limit the specific type of this technical component; for example, it could be a technical component used to implement clearing functions. It should be understood that GTZone does not store application system data; it only provides computational processing services.

[0080] It should be understood that the above is only an example. In actual applications, in addition to the above units, the banking system may also have other unit division methods, including other units.

[0081] Figure 5 A schematic diagram of a modular architecture provided in this application, such as Figure 5 As shown, each of the above units may include multiple deployment groups, and each unit is used to deploy the corresponding type of application system. The deployment group mentioned here is also called a deployment unit, which may be a group of virtual machines in a data center or a Deployment definition in Kubernetes (K8S) forming a deployment group. That is, the cloud uses virtual machines (VMs) and / or K8S to deploy units. This application does not limit the number of virtual machines or K8S deployed in the cloud. Depending on the data center layout, the capacity limitations of K8S or virtual machines, application characteristics, etc., virtual machines and K8S can be divided into multiple clusters. This application does not limit the number of corresponding type of application systems deployed in each unit; it can be one or multiple, and those skilled in the art can set it according to the actual situation.

[0082] Continue to refer to Figure 5 Each application system includes at least two internal modules, and each internal module is deployed in a unit that matches the type of the application system it belongs to. Different internal modules are deployed in different units. Multiple instances of the microservice modules of the internal modules are deployed on at least one deployment group of the unit they belong to.

[0083] This embodiment provides a cloud-based banking system built on a domain model. It establishes a mapping relationship between domain objects in the banking operations domain model and fine-grained objects in the cloud-native infrastructure. For example, it establishes a mapping relationship between application systems and application groups, and between microservice modules in the banking system and applications in the cloud. In this way, it achieves the construction of a banking system that aligns with both the actual business operations of the banking system and the cloud-based technological infrastructure, laying the foundation for the cloud deployment of banking systems.

[0084] Traditional cloud-based microservice frameworks (such as Spring Cloud and Dubbo) and service meshes (such as Istio) provide basic service governance and observability capabilities. However, the objects of operation and maintenance are relatively atomic, and the concepts are highly technical, such as microservice modules and API interfaces. In the overall operation and maintenance of a banking system, the objects that operation and maintenance personnel operate and observe may be both fine-grained objects such as microservice modules and API interfaces, and large-grained objects such as data centers, units, application systems, and internal modules.

[0085] The aforementioned cloud-based banking system built on a domain model allows operations personnel to transform their actions on objects within the operational domain into operations on fine-grained objects within the cloud-native infrastructure. Furthermore, this application achieves a macro-level understanding of building a cloud-based banking system, shielding the differences in capabilities and implementation across different underlying technology stacks. It allows for the aggregation of monitoring data from fine-grained objects within the cloud-native infrastructure into statistics on operational domain objects (such as the total transaction volume of the application system). This facilitates intelligent resource monitoring, indicator data statistical analysis, canary deployments, system parameter configuration management, disaster recovery switching, and access control for operations personnel. Ultimately, this improves the overall availability, stability, resource allocation rationality, and data security of the banking system.

[0086] The above content will be illustrated below with specific embodiments. For example, this application also provides a data processing method applied to the banking system in the above embodiments. The executing entity of this data processing method can be an application system, for example, a monitoring subsystem can be deployed in the application system to execute the data processing method; or the executing entity of this data processing method can be other systems or electronic devices (e.g., servers) independent of the banking system and having control over the banking system. This application does not limit this. The following describes the data processing method in detail using the monitoring subsystem of the banking system as an example. For example, based on this data processing method, the monitoring subsystem of the banking system can perform data processing in at least one or more of the following ways.

[0087] Method 1: Intelligent Resource Monitoring

[0088] Figure 6 A flowchart illustrating a data processing method provided in this application is shown below. Figure 6 As shown, the method may include the following steps:

[0089] S101. In response to a user-triggered resource monitoring request for the first dimension, perform resource monitoring on the application system corresponding to the first dimension in the banking system.

[0090] The first dimension mentioned above includes at least one of the following: region, data center, unit, application group, and application. The resources mentioned above include computing resources and / or traffic. The computing resources referred to here may be, for example, the number of hardware devices (e.g., servers) used to perform computations or the number of virtual machines. The traffic referred to here may be, for example, data traffic.

[0091] For example, the monitoring subsystem may be deployed with a display interface, through which it can obtain resource monitoring requests issued by users for the first dimension; or, the monitoring subsystem may obtain resource monitoring requests triggered by users for the first dimension through user terminals. Subsequently, the monitoring subsystem performs resource monitoring on the application system corresponding to the first dimension in the banking system based on the resource monitoring request for the first dimension.

[0092] This application does not limit the method by which the monitoring subsystem monitors resources. For example, the monitoring subsystem can obtain usage data from the banking system and determine resource usage based on this data. For instance, it can assess resource usage based on traffic volume and / or business data volume.

[0093] Each first dimension of the banking system has probe devices (e.g., processors with resource and / or traffic monitoring methods deployed within its corresponding device scope). This application does not limit the deployment method of the probe devices in different first dimensions. For example, the probe devices can be deployed on any hardware device included in or belonging to any first dimension. For instance, for the geographical dimension, the probe devices can be deployed on any hardware device where a virtual machine resides within the geographical region; for the data center dimension, the probe devices can be deployed on any hardware device within the data center.

[0094] For example, when the monitoring subsystem receives a resource monitoring request for the first dimension triggered by a user, the monitoring subsystem obtains the current resource usage of each first dimension from the probe devices deployed in each first dimension, so as to realize resource monitoring of the application system corresponding to the first dimension in the banking system.

[0095] S102. When the resources of any application system exceed the preset resource range corresponding to the first dimension, the resources of the application system shall be dynamically adjusted according to the resource usage of the bank system.

[0096] This application does not limit the specific value range of the preset resource interval; those skilled in the art can set it according to actual circumstances. For different resources, the specific value range of the preset resource interval can be the same or different.

[0097] It should be understood that the monitoring subsystem can adopt different dynamic resource adjustment methods for different resources. For example, regarding computing resources, if the monitoring subsystem detects that the computing resources of any application system are less than the minimum value of a preset computing resource range, it can increase the computing resources of that application system to bring its computing resources within the preset resource range corresponding to the first dimension. For example, the monitoring subsystem can, for instance, allocate computing resources from other application systems to the application system currently experiencing a computing resource shortage, provided that the computing resources of other application systems are within the preset computing resource range. This application does not limit the amount of computing resources allocated; for example, it could allocate the portion of computing resources exceeding the minimum value of the preset computing resource range from any application system with abundant computing resources to the application system currently experiencing a computing resource shortage for its use.

[0098] For example, regarding traffic, if the monitoring subsystem detects that the traffic of any application system exceeds the maximum value of the preset traffic resource range, the monitoring subsystem can, for example, evenly distribute the portion of the traffic exceeding the maximum value of the preset traffic resource range in that application system to other application systems to achieve a balanced distribution of traffic among different application systems.

[0099] Since the banking system provided in this application is built from multiple different domain object dimensions, and these multiple different domain object dimensions are all consistent with the actual operation of banking business and the cloud-based technical architecture, the above method can comprehensively and accurately monitor the resources of the application systems corresponding to each first dimension in the banking system. When abnormal resource usage occurs, the monitoring subsystem can take timely measures to allocate resources within the banking system, thereby improving the disaster recovery capability and availability of the banking system and facilitating service governance and other tasks for operations and maintenance personnel.

[0100] Method 2: Statistical Analysis of Indicator Data

[0101] Figure 7 A flowchart illustrating another data processing method provided in this application is shown below. Figure 7 As shown, the method may include the following steps:

[0102] S201. In response to the user-triggered request to aggregate and calculate the indicator data of the application system corresponding to the second dimension, obtain the indicator data of the application system corresponding to the second dimension in the banking system.

[0103] The aforementioned second dimension includes at least one of the following: region, data center, unit, application group, and application. This application does not limit the specific category of the indicator data. For example, the indicator data may be, for instance, business volume, traffic, etc. The indicators used for aggregation calculations across different second dimensions can be the same or different. For example, traffic indicator data can be aggregated and calculated separately from the dimensions of region, data center, unit, application group, and application; business volume can be aggregated and calculated from the application group dimension; and the number of resource indicators can be aggregated and calculated from the data center dimension.

[0104] One possible implementation is that after receiving a user-triggered aggregation calculation request for the indicator data of the application system corresponding to the second dimension, the monitoring subsystem sends indicator data reporting instructions to the hardware devices deployed with external access reception in different second dimensions according to the indicator data corresponding to different second dimensions in the monitoring request, so as to obtain the indicator data of the application system reported by different second dimensions.

[0105] Another possible implementation involves deploying a metric data monitoring probe in each second dimension, which reports the metric data to the monitoring subsystem in real time. After receiving a user-triggered aggregation calculation request for the metric data of the application system corresponding to the second dimension, the monitoring subsystem retrieves the metric data of the corresponding application system reported by different second dimensions at the current moment based on the request.

[0106] S202. Perform aggregate calculations on the indicator data corresponding to the second dimension.

[0107] In this step, the banking system aggregates and calculates the indicator data corresponding to the second dimension to achieve statistical analysis of the banking system's data from different dimensions. This application does not limit the method by which the banking system aggregates and calculates the indicator data corresponding to the second dimension; for example, it could be a summation operation or a median calculation, depending on the analysis requirements of the indicator data.

[0108] S203. Output the aggregated index data.

[0109] For example, a banking system may have a display interface where the monitoring subsystem outputs aggregated and calculated indicator data for users to view.

[0110] As stated above, the cloud-based banking system provided in this application, built on a domain model, aligns with the actual operational conditions of banking business and is compatible with the cloud's technical architecture. Furthermore, it offers multiple dimensions for monitoring and analyzing data metrics within the banking system. Therefore, based on this banking system, the aforementioned methods enable comprehensive and in-depth aggregation and statistical analysis of data from various dimensions of the banking system. This allows for timely and comprehensive understanding of the overall operation of the banking system, contributing to the steady development of banking operations.

[0111] Method 3: Canary Release

[0112] Figure 8 A flowchart illustrating another data processing method provided in this application is shown below. Figure 8 As shown, the method may include the following steps:

[0113] S301. In response to a user-triggered canary release strategy configuration request for the application system corresponding to the third dimension, update the canary release strategy of the application system corresponding to the third dimension using the canary release strategy configuration request.

[0114] The third dimension includes at least one of the following: region, data center, unit, application group, and application. The aforementioned canary release strategy is a specific release strategy designed based on the canary release method. This application does not limit the specific content of this canary release strategy; those skilled in the art can set it according to actual circumstances.

[0115] For example, the monitoring subsystem may be deployed with an interactive interface, which allows the monitoring subsystem to obtain user input requests for canary release strategy configurations for the application system corresponding to the third dimension. It should be understood that different canary release strategies can correspond to different third dimensions.

[0116] Subsequently, the monitoring subsystem, based on the canary release policy configuration request, sends the corresponding canary release policies to different dimensions to update the canary release policies of the application systems corresponding to the third dimension. For example, the canary release policy configuration request may include canary release policies for different regions and canary release policies for different units. The monitoring subsystem sends the canary release policy corresponding to each region to the corresponding region, and sends the canary release policy corresponding to each unit to different units, thereby achieving the updating of canary release policies that differentiate between different regions and units.

[0117] S302. Perform canary release control on the application system corresponding to the third dimension according to the updated canary release strategy.

[0118] Since the banking system provided in this application includes multiple different dimensions, based on this banking system and through the above implementation method, the monitoring subsystem can perform differentiated configuration of different types of canary release strategies for different dimensions of the banking system. That is, based on this banking system, differentiated canary release strategies can be deployed for domain objects in different dimensions. Furthermore, it can achieve the same canary release strategy configuration for domain object dimensions with the same release requirements, improving the overall configuration flexibility of the banking system and enhancing management efficiency.

[0119] Method 4: System parameter configuration management / access control

[0120] Figure 9 A flowchart illustrating another data processing method provided in this application is shown below. Figure 9 As shown, the method may include the following steps:

[0121] S401. In response to a user-triggered configuration request for the application system corresponding to the fourth dimension, configure the application system corresponding to the fourth dimension using the configuration information in the configuration request.

[0122] The fourth dimension includes at least one of the following: region, data center, unit, application group, and application. This application does not limit which one or more fourth dimensions the configuration request specifically targets. The configuration information includes: system parameter configuration information and / or access permission configuration information. The system parameters mentioned here are parameters related to variables such as the bank system status, functions, and behaviors. This application does not limit the specific system parameters that the system parameter configuration information targets. The access permissions mentioned above can be, for example, data access permissions, technical component access permissions, or system function access permissions. This application does not limit them.

[0123] For example, after receiving a configuration request from a user for the application system corresponding to the fourth dimension, the monitoring subsystem can send the configuration information for different fourth dimensions in the configuration request to the corresponding fourth-dimensional configuration interface. This updates the configuration for the fourth dimension. The monitoring subsystem can use different configuration methods for a single fourth dimension.

[0124] For example, the monitoring subsystem can be configured to have independent access permissions for each region, meaning that data cannot be shared between different regions. Alternatively, the monitoring subsystem can assign operational and maintenance permissions to different application systems, or to different data centers. Or, the monitoring subsystem can be configured to have different data access permissions for different regions.

[0125] S402, the application system corresponding to the fourth dimension after configuration.

[0126] The banking system provided in this application offers multiple implementation dimensions for parameter configuration. The monitoring subsystem can adopt different configuration methods for different dimensions, and can also adopt different configuration methods for the same dimension. It is flexible in operation and highly controllable, making the banking system highly available and able to meet the needs of more scenarios.

[0127] Method 5: Disaster Recovery Switching

[0128] For example, the monitoring subsystem can respond to a user-triggered disaster recovery switching request for the application system corresponding to the fifth dimension, and perform disaster recovery switching on the resources used by the application system corresponding to the fifth dimension.

[0129] The fifth dimension mentioned above includes at least one of the following: region, data center, unit, application group, application.

[0130] In this implementation, when an application system malfunctions, the monitoring subsystem can perform disaster recovery switching from different dimensions based on the scope of the malfunction. For example, if a data center of a bank's system malfunctions, the user can trigger a disaster recovery switching request for the application system corresponding to that data center. In response to this request, the bank's system can switch the resources used by the application system in the malfunctioning data center to another normal data center.

[0131] Alternatively, if an anomaly occurs in a certain unit, the monitoring subsystem can respond to the disaster recovery switch request triggered by the user for the application system corresponding to the fifth dimension, and switch the resources used by the application system of that unit to other units to ensure the high availability of the bank system.

[0132] Similarly, since the banking system provided in this application offers multiple different operation and maintenance management dimensions, if any module within any dimension experiences an anomaly, the monitoring subsystem can perform disaster recovery switching based on the module within that dimension. Through the above implementation method, the banking system can achieve disaster recovery switching for application systems corresponding to different dimensions from multiple different dimensions, enabling it to cope with various anomaly scenarios, improve the disaster recovery switching capability of the banking system, and enhance overall availability and data security.

[0133] It should be understood that the banking system provided in this application can perform data processing in more dimensions, which are related to business needs and will not be elaborated here.

[0134] This application also provides a computer-readable storage medium, which may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Specifically, the computer-readable storage medium stores computer program instructions, which are used in the data processing method described in the above embodiments.

[0135] This application also provides a computer program product including computer-executable instructions stored in a readable storage medium. At least one processor of an electronic device can read the execution instructions from the readable storage medium, and the execution of the execution instructions by the at least one processor causes the electronic device to implement the data processing methods provided in the various embodiments described above.

[0136] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0137] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A banking system built in the cloud based on a domain model, characterized in that, The banking system includes: multiple business layers divided based on the application architecture of the banking business domain; Each of the business layers includes at least one application system; each application system corresponds to an application group; the application group includes: N applications built based on a cloud-native domain model; Each of the application systems includes: at least two internal modules deployed using a distributed microservice architecture, and the data required for each of the internal modules to operate; Each of the internal modules includes a microservice gateway and multiple microservice modules, each of the microservice modules being used to provide a microservice for one of the applications in the application group; The cloud includes resources located in multiple regions; The computing resources of each region include: multiple workspaces, each workspace including: at least one availability zone of a computer room, and the availability zones of the same workspace communicate with each other via a dedicated network; Each availability zone includes: multiple units; each unit includes multiple deployment groups, and each unit is used to deploy application systems of a corresponding type; The internal modules are deployed in units that match the type of application system they belong to, and different internal modules are deployed in different units. Multiple instances of the microservice modules of the internal modules are deployed on at least one deployment group of the unit.

2. The system according to claim 1, characterized in that, The multiple units include: core business unit, global business unit, shared business unit, and global technology unit; The core business unit is used to deploy application systems that are split according to the user dimension; The global business unit is used to deploy application systems containing applications that need to access the full amount of data. The shared business unit is used as a read-only copy of the global business unit to deploy application systems that are frequently accessed by critical business processes. The global technical unit is used to deploy technical components that are invoked by the application system of other units.

3. The system according to claim 1 or 2, characterized in that, The multiple business layers include: channel integration layer, user interaction layer, integration layer, business service layer, data management layer, intelligent analysis layer, and technical support layer.

4. A data processing method, characterized in that, The method is applied to the banking system as described in any one of claims 1-3, and the method includes: In response to a user-triggered resource monitoring request for the first dimension, resource monitoring is performed on the application system corresponding to the first dimension in the banking system; the first dimension includes at least one of the following: region, data center, unit, application group, application; the resources include: computing resources and / or traffic; When the resources of any application system exceed the preset resource range corresponding to the first dimension, the resources of the application system are dynamically adjusted according to the resource usage of the banking system.

5. The method according to claim 4, characterized in that, The method further includes: In response to a user-triggered request to aggregate and calculate the indicator data of the application system corresponding to the second dimension, the indicator data of the application system corresponding to the second dimension in the banking system is obtained; the second dimension includes at least one of the following: region, data center, unit, application group, and application; Aggregate and calculate the indicator data corresponding to the second dimension; Output the aggregated index data.

6. The method according to claim 4, characterized in that, The method further includes: In response to a user-triggered canary release strategy configuration request for the application system corresponding to the third dimension, the canary release strategy of the application system corresponding to the third dimension is updated using the canary release strategy in the canary release strategy configuration request; the third dimension includes at least one of the following: region, data center, unit, application group, application. The application system corresponding to the third dimension is subject to canary release control according to the updated canary release strategy.

7. The method according to claim 4, characterized in that, The method further includes: In response to a user-triggered configuration request for an application system corresponding to the fourth dimension, the configuration information in the configuration request is used to configure the application system corresponding to the fourth dimension; the fourth dimension includes at least one of the following: region, data center, unit, application group, application; the configuration information includes: configuration information for system parameters and / or configuration information for access permissions; Run the application system corresponding to the fourth dimension after configuration.

8. The method according to claim 4, characterized in that, The method further includes: In response to a user-triggered disaster recovery switching request for the application system corresponding to the fifth dimension, disaster recovery switching is performed on the resources used by the application system corresponding to the fifth dimension; the fifth dimension includes at least one of the following: region, data center, unit, application group, and application.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 4 to 8.

10. A computer program product comprising a computer program that, when executed by a processor, implements the method as described in any one of claims 4 to 8.

Images