Service bus-based service management method and device, and electronic device

By dividing the service bus into a core layer and a convergence layer, and using RDMA data connections for cross-region service calls, the problem of the existing technology being unable to perform hierarchical management of different businesses is solved, hierarchical management and fault impact isolation are achieved, and system security is improved.

CN119363554BActive Publication Date: 2025-10-21TRAVELSKY TECHNOLOGY LIMITED
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411495214.0
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-10-24
Publication Date
2025-10-21
Estimated Expiration
2044-10-24

AI Technical Summary

Technical Problem

The existing service bus is unable to implement hierarchical management of different businesses, resulting in hidden dangers at the system security level.

Method used

The service bus is divided into a core layer and a convergence layer. Cross-region service calls and management are achieved through RDMA data connections. The core layer parses service requests and performs hierarchical management based on health status information.

Benefits of technology

It realizes hierarchical management of different services, reduces the cross-impact during bus change and maintenance, and avoids low-level service failures affecting high-level services.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119363554B_ABST
    Figure CN119363554B_ABST
Patent Text Reader

Abstract

The application discloses a service management method and device based on a service bus, and electronic equipment, and relates to the technical field of distributed systems or other related fields, wherein the service bus comprises one core layer and N convergence layer partitions, N is a positive integer, and the method comprises the following steps: forwarding, by the convergence layer partitions, a service request related to cross-partition calling to the core layer through an RDMA data connection; analyzing the service request through the core layer to obtain a service name of a target service to be called and a target convergence layer partition where the target service is located; transmitting the service request to the target convergence layer partition based on health state information and the RDMA data connection, wherein the health state information is used for recording the health conditions of each target node in the target convergence layer partition; and calling the target service in the target convergence layer partition based on the service name in response to the service request. The application solves the technical problem that the service bus cannot implement hierarchical management of different services in the related art.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the technical field of distributed systems, and in particular to a service management method and device based on a service bus, and an electronic device. Background Art

[0002] With the development of information technology, more and more companies are taking digital transformation as their core strategy and applying it to many business areas. At the same time, driven by factors such as business scale and integrated innovation, business complexity is increasing, and more processes and businesses require the cooperation of multiple services to complete.

[0003] Existing technologies often employ a service-oriented architecture (SOA) for distributed management, addressing the diverse technical architectures and distribution of services across applications, systems, and even geographical locations within an enterprise. SOA introduces three key concepts: services, the service bus (ESB), and loose coupling. By encapsulating each business function as an independent service, leveraging loose coupling to reduce interdependencies and interactions between services, and using the enterprise service bus (ESB) to achieve efficient interconnection between heterogeneous services, SOA can better build flexible, reusable, and modular business systems that adapt to ever-changing market demands and technological environments.

[0004] Conventional service buses are usually single-layer architectures. For a specific business scenario, requests flow through specific functional plug-ins in sequence to complete the orchestration of business processes and realize the ultimate business functions. At the service bus level, all business scenarios are the same in terms of business processing priority and maintenance level. This unified and non-differentiated processing model can bring the benefits of simple structure and resource intensiveness. However, due to the inability to provide differentiated service guarantees based on business levels, it often brings hidden dangers at the system security level.

[0005] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0006] The embodiments of the present invention provide a service management method and device based on a service bus, and an electronic device, so as to at least solve the technical problem in related technologies that the service bus cannot implement hierarchical management of different services.

[0007] According to one aspect of an embodiment of the present invention, a service management method based on a service bus is provided, wherein the service bus includes a core layer and N aggregation layer partitions obtained after pre-layered partitioning processing, and the core layer and each aggregation layer partition establish an RDMA data connection in advance through a bridging component, where N is a positive integer. The service management method includes: when the aggregation layer partition receives a service request involving a cross-zone call, forwarding the service request to the core layer through the RDMA data connection; parsing the service request through the core layer to obtain the service name of the target service to be called and the target aggregation layer partition where the target service is located; transmitting the service request to the target aggregation layer partition based on health status information and the RDMA data connection, wherein the health status information is used to record the health status of each target node in the target aggregation layer partition; and in response to the service request, calling the target service in the target aggregation layer partition based on the service name.

[0008] Furthermore, the RDMA data connection is realized through the RDMA server and RDMA client in the bridging component, and the RDMA data connection includes: a first RDMA link and a second RDMA link, wherein the first RDMA link is a data link between the core layer server and the aggregation layer client, and the second RDMA link is a data link between the aggregation layer server and the core layer client.

[0009] Furthermore, the step of establishing the RDMA data connection includes: for the bridging component deployed in the aggregation layer partition, obtaining the first-class local IP and first-class service port information of all core nodes in the core layer from the registration center; starting the aggregation layer server and the aggregation layer client in each partition node of the aggregation layer partition; for each partition node, performing local registration in the registration center by the started aggregation layer server to obtain the second-class local IP and second-class service port information of the partition node; creating a first data connection request based on the first-class local IP and first-class service port information by the started aggregation layer client, wherein the first data connection request is used to request the core layer server to create the first RDMA link.

[0010] Furthermore, the step of establishing the RDMA data connection also includes: for the bridging component deployed in the core layer, obtaining the second-class local IP and second-class service port information of all partition nodes in each of the aggregation layer partitions from the registration center; starting the core layer server and the core layer client in each core node of the core layer; for each core node, performing local registration in the registration center by the started core layer server to obtain the first-class local IP and first-class service port information of the core node; creating a second data connection request based on the second-class local IP and second-class service port information by the started core layer client, wherein the second data connection request is used to request the second RDMA link from the aggregation layer server.

[0011] Furthermore, the step of forwarding the service request to the core layer through the RDMA data connection includes: obtaining health status information of all core nodes in the core layer; selecting a target core node from all the core nodes based on the health status information and the load balancing strategy; and forwarding the service request to the target core node through the first RDMA link in the RDMA data connection.

[0012] Furthermore, the step of transmitting the service request to the target convergence layer partition based on the health status information and the RDMA data connection includes: obtaining the health status information of all partition nodes in the target convergence layer partition; selecting a target partition node from all the partition nodes based on the health status information and the load balancing strategy; and forwarding the service request to the target partition node through a second RDMA link in the RDMA data connection.

[0013] Furthermore, the health status information is obtained through the following steps: creating a timed detection task and a health status shared memory, wherein the content of the timed detection task is set to: initiating M health checks on the target node at intervals of a specified duration within a specified period, the target node including: core nodes and / or partition nodes, M is a specified positive integer; updating the status indicators in the health status shared memory based on the timed detection task; after the timed detection task ends, generating the health status information based on the status indicators in the health status shared memory.

[0014] According to another aspect of an embodiment of the present invention, a service management device based on a service bus is also provided, wherein the service bus includes a core layer and N aggregation layer partitions obtained after pre-layered partitioning processing, and the core layer and each aggregation layer partition establish an RDMA data connection in advance through a bridging component, N is a positive integer, and the service management device includes: a forwarding unit, which is used to forward the service request to the core layer through the RDMA data connection when the aggregation layer partition receives a service request involving a cross-zone call; a parsing unit, which is used to parse the service request through the core layer to obtain the service name of the target service to be called and the target aggregation layer partition where the target service is located; a transmission unit, which is used to transmit the service request to the target aggregation layer partition based on health status information and the RDMA data connection, wherein the health status information is used to record the health status of each target node in the target aggregation layer partition; and a calling unit, which is used to respond to the service request and call the target service in the target aggregation layer partition based on the service name.

[0015] Furthermore, the RDMA data connection is realized through the RDMA server and RDMA client in the bridging component, and the RDMA data connection includes: a first RDMA link and a second RDMA link, wherein the first RDMA link is a data link between the core layer server and the aggregation layer client, and the second RDMA link is a data link between the aggregation layer server and the core layer client.

[0016] Furthermore, the service bus-based service management device includes: a first acquisition module, used to obtain the first-class local IP and first-class service port information of all core nodes in the core layer from the registration center for the bridging component deployed in the aggregation layer partition; a first startup module, used to start the aggregation layer server and the aggregation layer client in each partition node of the aggregation layer partition; a first registration module, used to obtain the second-class local IP and second-class service port information of each partition node by performing local registration in the registration center through the started aggregation layer server; a first creation module, used to create a first data connection request based on the first-class local IP and first-class service port information through the started aggregation layer client, wherein the first data connection request is used to request the core layer server to create the first RDMA link.

[0017] Furthermore, the service bus-based service management device also includes: a second acquisition module, used to obtain the second-class local IP and second-class service port information of all partition nodes in each of the aggregation layer partitions from the registration center for the bridging component deployed in the core layer; a second startup module, used to start the core layer server and the core layer client in each core node of the core layer; a second registration module, used to obtain the first-class local IP and first-class service port information of the core node by performing local registration at the registration center for each core node through the started core layer server; a second creation module, used to create a second data connection request based on the second-class local IP and second-class service port information through the started core layer client, wherein the second data connection request is used to request the aggregation layer server to create the second RDMA link.

[0018] Furthermore, the forwarding unit includes: a third acquisition module, used to obtain the health status information of all core nodes in the core layer; a first selection module, used to select a target core node from all the core nodes based on the health status information and the load balancing strategy; and a first forwarding module, used to forward the service request to the target core node through the first RDMA link in the RDMA data connection.

[0019] Furthermore, the transmission unit includes: a fourth acquisition module, used to obtain the health status information of all partition nodes in the target aggregation layer partition; a second selection module, used to select the target partition node from all the partition nodes based on the health status information and load balancing strategy; and a second forwarding module, used to forward the service request to the target partition node through the second RDMA link in the RDMA data connection.

[0020] Furthermore, the service management device based on the service bus also includes: a third creation module, used to create a scheduled detection task and a health status shared memory, wherein the content of the scheduled detection task is set to: initiate M health checks on the target node at intervals of a specified time within a specified period, and the target node includes: a core node and / or a partition node, and M is a specified positive integer; an update module, used to update the status indicators in the health status shared memory based on the scheduled detection task; and a generation module, used to generate the health status information based on the status indicators in the health status shared memory after the scheduled detection task ends.

[0021] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is further provided, wherein the computer-readable storage medium includes a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute any of the above-mentioned service bus-based service management methods.

[0022] According to another aspect of an embodiment of the present invention, an electronic device is also provided, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any one of the above-mentioned service bus-based service management methods.

[0023] In the present invention, a service management method based on a service bus is proposed. When a convergence layer partition receives a service request involving a cross-zone call, the service request is first forwarded to the core layer through an RDMA data connection, and then the service request is parsed by the core layer to obtain the service name of the target service to be called and the target convergence layer partition where the target service is located. Then, based on the health status information and the RDMA data connection, the service request is transmitted to the target convergence layer partition, wherein the health status information is used to record the health status of each target node in the target convergence layer partition. Finally, the service request is responded to and the target service in the target convergence layer partition is called based on the service name.

[0024] In the present invention, the service bus is divided into a convergence layer and a core layer at the architectural level, and the convergence layer is divided into N business partitions. Each partition has the full set of functions of a traditional service bus, and an RDMA data connection is established in advance with the core layer through a bridging component, so as to facilitate cross-region service calls and management between the convergence layer partitions through the core layer. In addition, the core layer implements the service control function, and after receiving the cross-region call service request forwarded by the convergence layer partition, it parses to obtain the target service and the partition where the service is located, and forwards the cross-region service call request based on the health status of each target node in the partition where the service is located, and calls the target service, thereby realizing hierarchical partition management of different call requests, thereby realizing hierarchical management of different businesses, and thus solving the technical problem in the related art that the service bus cannot realize hierarchical management of different businesses. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0026] Figure 1 is a logical structure diagram of an optional hierarchical and partitioned service bus according to an embodiment of the present invention;

[0027] Figure 2 is a flow chart of an optional service bus-based service management method according to an embodiment of the present invention;

[0028] Figure 3 It is a schematic diagram of a processing flow of an optional convergence layer bridge component RDMA client and RDMA server according to an embodiment of the present invention;

[0029] Figure 4 It is a schematic diagram of a processing flow of an optional core layer bridge component RDMA client and RDMA server according to an embodiment of the present invention;

[0030] Figure 5 is a schematic diagram of an optional service bus-based service management device according to an embodiment of the present invention;

[0031] Figure 6 The figure is a hardware structure block diagram of an electronic device (or mobile device) for a service management method based on a service bus according to an embodiment of the present invention. DETAILED DESCRIPTION

[0032] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0033] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0034] The following embodiments of the present invention can be applied to various systems / applications / devices that require hierarchical management of a service bus, enabling cross-region service call functionality based on hierarchical and partitioned management of the service bus. At the architectural level, the present invention divides the service bus into a convergence layer and a core layer, and also divides the convergence layer into N business partitions. Each partition has the full set of traditional service bus functions and pre-establishes an RDMA data connection with the core layer via a bridging component, facilitating cross-region service calls and management between convergence layer partitions through the core layer.

[0035] The core layer of the present invention also implements the service control function. After receiving the cross-region service call request forwarded by the aggregation layer partition, it parses the target service and the partition where the service is located, and then forwards the cross-region service call request based on the health status of each target node in the partition where the service is located, and calls the target service.

[0036] The present invention will be described in detail below with reference to various embodiments.

[0037] Example 1

[0038] According to an embodiment of the present invention, an embodiment of a service management method based on a service bus is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0039] The embodiment of the present invention provides a pre-layered and partitioned service bus, which implements hierarchical management through a layered and partitioned architectural design, facilitates independent business orchestration and service management based on the business levels and maintenance levels specified by different user needs, reduces the cross-impact during bus change and maintenance, and prevents low-level service failures from affecting high-level services.

[0040] Figure 1 is a logical structure diagram of an optional hierarchical partitioned service bus according to an embodiment of the present invention, such as Figure 1 As shown, the service bus is logically divided into a convergence layer and a core layer, where the convergence layer can be divided into N partitions, where N is a positive integer. Figure 1 In the example of N=3, the core layer service bus is connected to each aggregation layer partition service bus through the bridge component ( Figure 1 (not shown) pre-establish data connections, each convergence layer partition docking several business / services, for example, Figure 1 As shown in the figure: partition 01 is connected to service A, service B...service G, partition 02 is connected to service H, service I...service N, and partition 03 is connected to service O, service P...service T.

[0041] It should be noted that the aggregation layer is used to group and aggregate services according to service levels and the affinity between services. Each aggregation layer partition is used to implement routing forwarding, data conversion, data transmission, protocol adaptation, service management and monitoring, service integration and other functions of the business traffic in this partition.

[0042] The aggregation layer can prevent problems in one partition from spreading to other partitions and the core layer by dividing them into zones. To meet the needs of cross-zone access scenarios, the aggregation layer and the core layer use a unified bridging application for high-speed data transmission, without having to consider the complex protocol types of the outer layer. The structure is simple but the operation is reliable.

[0043] Another thing that needs to be explained is that the core layer is used to control high-speed data transmission between the partitions of the aggregation layer, and to transmit cross-zone requests to the target node in the specified aggregation layer partition, to achieve optimized transmission, addressing routing and load balancing between the aggregation layer node network.

[0044] Compared with the traditional service bus, the hierarchical and partitioned service bus adds the following functional modules in each partition of the aggregation layer and the core layer: bridging components and node detection components.

[0045] Among them, the bridging component is used to realize data transmission between the aggregation layer and the core layer. RDMA technology can be used during the data transmission process to improve data transmission efficiency and performance; the node detection component is used to realize node detection between the nodes of the aggregation layer partition and the core layer nodes, implement active and passive node health check mechanisms, isolate faulty nodes in time, incorporate healthy nodes in time, and return the interface address of the target node according to the load balancing strategy.

[0046] Figure 2 This is a flowchart of an optional service bus-based service management method according to an embodiment of the present invention. The method is applied to the service bus after the above-mentioned hierarchical partition optimization, including a core layer and N aggregation layer partitions obtained after pre-hierarchical partition processing. The core layer and each aggregation layer partition pre-establish RDMA data connection through a bridge component, where N is a positive integer. Figure 2 As shown, the method includes the following steps:

[0047] Step S201: When a convergence layer partition receives a service request involving a cross-zone call, the convergence layer partition forwards the service request to the core layer through an RDMA data connection.

[0048] Optionally, the RDMA data connection is implemented through the RDMA server and RDMA client in the bridging component, and the RDMA data connection includes: a first RDMA link and a second RDMA link, wherein the first RDMA link is a data link between the core layer server and the aggregation layer client, and the second RDMA link is a data link between the aggregation layer server and the core layer client.

[0049] It should be noted that the bridging component is divided into different modes of RDMA server and RDMA client according to whether it is deployed in the aggregation layer or the core layer.

[0050] For the bridging components deployed in each partition of the aggregation layer, they first obtain the IP information and RDMA service port information of each core node in the core layer from the registration center under the SOA architecture, and then start the RDMA server and RDMA client respectively on the aggregation node where the bridging component is located. After startup, the RDMA server requests the registration center under the SOA architecture to register the local IP and RDMA service port, and waits for the establishment of RDMA connection with the core node in the core layer. The RDMA server also listens for connection requests from the core node, maintains the data connection with the core node after confirming the connection and verification, and receives business requests forwarded by the core node (such as cross-zone call requests), routes them to the target node and calls the target service.

[0051] The aggregation node RDMA client is used to create connection requests with all core node RDMA servers. After the connection request is accepted and the connection is confirmed, the connection is maintained using heartbeat messages. In cross-region access scenarios, the aggregation node RDMA client is also used to forward service requests to the core node for subsequent processing.

[0052] Optionally, the step of establishing the first RDMA link in the RDMA data connection includes: for a bridging component deployed in a convergence layer partition, obtaining the first-class local IP and first-class service port information of all core nodes in the core layer from a registration center; starting the convergence layer server and convergence layer client in each partition node of the convergence layer partition; for each partition node, performing local registration in the registration center by the started convergence layer server to obtain the second-class local IP and second-class service port information of the partition node; creating a first data connection request based on the first-class local IP and first-class service port information by the started convergence layer client, wherein the first data connection request is used to request the core layer server to create a first RDMA link.

[0053] For the bridging components deployed in the core layer, it is also necessary to start the RDMA server and RDMA client separately and perform connection-level maintenance and management. The core node RDMA server is used to receive cross-region service requests issued by the aggregation node. After addressing and load balancing the aggregation layer partition to which the target service belongs, it determines the target node and forwards the request data through the RDMA connection between the target node and the server.

[0054] Optionally, the step of establishing a second RDMA link for the RDMA data connection includes: for the bridging component deployed in the core layer, obtaining the second-class local IP and second-class service port information of all partition nodes in each aggregation layer partition from the registration center; starting the core layer server and the core layer client in each core node of the core layer; for each core node, performing local registration in the registration center by the started core layer server to obtain the first-class local IP and first-class service port information of the core node; creating a second data connection request based on the second-class local IP and second-class service port information by the started core layer client, wherein the second data connection request is used to request a second RDMA link from the aggregation layer server.

[0055] It should also be noted that the embodiment of the present invention also uses a node liveness detection component to implement both active and passive health checks to obtain health status information of target nodes at each layer.

[0056] Under the active check mechanism, the health status information of the target node is updated by periodically detecting the target node IP and service port. For example, if the detection succeeds / fails for three consecutive times, the status of the target node is considered healthy / unhealthy.

[0057] Under the passive checking mechanism, the health status information of the target node is updated with the help of the RDMA connection result between the target node and the target node. When sending or receiving data successfully or failing, the health / unhealthy status count value of the target node is updated. If the count value reaches a certain threshold, the status of the target node is considered healthy / unhealthy.

[0058] Optionally, the step of forwarding the service request to the core layer through the RDMA data connection includes: obtaining health status information of all core nodes in the core layer; selecting a target core node from all core nodes based on the health status information and the load balancing strategy; and forwarding the service request to the target core node through the first RDMA link in the RDMA data connection.

[0059] It should be noted that the load balancing strategy is a technology that optimizes resource utilization and improves system service reliability. By evenly distributing the load (in the embodiment of the present invention, it refers to service requests or service call tasks) among multiple servers or resource nodes, it ensures that each node is neither overloaded nor idle for a long time, thereby maintaining efficient and stable operation of the system.

[0060] The present invention provides several commonly used load balancing strategies: round-robin, weighted round-robin, and the least-connected principle. Round-robin assigns requests to each core node sequentially; weighted round-robin assigns weights to each core node in advance, distributing service requests based on the weights. Core nodes with higher weights receive more service requests; and the least-connected principle assigns service requests to the core node with the lowest current load. The least-connected principle is the most preferred, as it is suitable for scenarios with uneven request processing times and effectively prevents overloading of a single node.

[0061] Step S202: The core layer parses the service request to obtain the service name of the target service to be called and the target convergence layer partition where the target service is located.

[0062] It should be noted that in the cross-region access scenario, the RDMA server in the core layer bridging component receives the request data forwarded by the aggregation layer partition node, uses the registration center information to address the aggregation layer partition where the target service is located, selects the aggregation layer partition node where the target service is located through load balancing decision, and forwards the request data through the second RDMA link between the core node RDMA client and the RDMA server of the aggregation node.

[0063] Step S203: transmitting the service request to the target convergence layer partition based on the health status information and the RDMA data connection, wherein the health status information is used to record the health status of each target node in the target convergence layer partition.

[0064] Optionally, step S203 includes: obtaining health status information of all partition nodes in the target aggregation layer partition; selecting a target partition node from all partition nodes based on the health status information and load balancing strategy; and forwarding the service request to the target partition node through the second RDMA link in the RDMA data connection.

[0065] Optionally, the health status information is obtained through the following steps: creating a scheduled detection task and a health status shared memory, wherein the content of the scheduled detection task is set to: initiating M health checks on the target node at specified intervals within a specified period, the target node includes: core nodes and / or partition nodes, and M is a specified positive integer; updating the status indicators in the health status shared memory based on the scheduled detection task; and generating health status information based on the status indicators in the health status shared memory after the scheduled detection task ends.

[0066] Step S204: respond to the service request and call the target service in the target convergence layer partition based on the service name.

[0067] Through the above steps S201 to S204, when the convergence layer partition receives a service request involving a cross-zone call, the service request can be first forwarded to the core layer through the RDMA data connection, and then the service request is parsed by the core layer to obtain the service name of the target service to be called and the target convergence layer partition where the target service is located. Then, based on the health status information and the RDMA data connection, the service request is transmitted to the target convergence layer partition, wherein the health status information is used to record the health status of each target node in the target convergence layer partition. Finally, the service request is responded to and the target service in the target convergence layer partition is called based on the service name.

[0068] In an embodiment of the present invention, the service bus is divided into a convergence layer and a core layer at the architectural level, and the convergence layer is divided into N business partitions. Each partition has the full set of functions of a traditional service bus, and an RDMA data connection is established in advance with the core layer through a bridging component, so as to facilitate cross-region service calls and management between the convergence layer partitions through the core layer. In addition, the core layer implements a service control function. After receiving the cross-region call service request forwarded by the convergence layer partition, it parses to obtain the target service and the partition where the service is located, and forwards the cross-region service call request based on the health status of each target node in the partition where the service is located, and calls the target service, thereby realizing hierarchical partition management of different call requests, thereby realizing hierarchical management of different businesses, and thus solving the technical problem in related technologies that the service bus cannot realize hierarchical management of different businesses.

[0069] The present invention will be described below in conjunction with another specific embodiment.

[0070] Under the traditional SOA architecture, the service bus is usually deployed in a centralized manner, including functions such as message routing, data conversion, data transmission, protocol conversion and adaptation, security management, service management and monitoring, service integration and functional auditing. The above functions are usually implemented through plug-ins, and plug-ins are selected and processes are orchestrated according to different service call requirements. However, there is no difference in business processing priority, node maintenance level, etc., and it is impossible to provide differentiated service guarantees according to business levels, which often brings hidden dangers to the system operation security level.

[0071] To address this problem, the present invention proposes a hierarchical and partitioned service bus implementation method. By dividing the service bus into a convergence layer and a core layer, hierarchical bus-level management and fault impact isolation are implemented during service invocations. To achieve high-speed data transmission between convergence and core layer nodes and an effective health check mechanism between nodes, the present invention designs bridge components that utilize RDMA technology to achieve high-speed data transmission between nodes. These components can be specifically divided into two categories based on their deployment location: convergence layer bridge components and core layer bridge components.

[0072] In the cross-zone access scenario, the RDMA client in the aggregation layer bridge component receives the request data forwarded by the message routing component, and uses the RDMA link between the core layer node to forward the request data to the core layer node for subsequent processing; the RDMA server in the aggregation layer bridge component receives the cross-zone request forwarded from the core layer node and adds it to the subsequent processing link of the message routing (such as data conversion or data transmission).

[0073] Figure 3 Schematic diagram of the processing flow of an optional convergence layer bridge component RDMA client and RDMA server according to an embodiment of the present invention, such as Figure 3 The left figure shows the RDMA client processing flow of the convergence layer bridge component, and the right figure shows the RDMA server processing flow of the convergence layer bridge component. The following describes them one by one.

[0074] like Figure 3 As shown in the middle left figure, the implementation steps of the RDMA client of the aggregation layer bridge component are detailed as follows:

[0075] Step 1: Listen to the registration center under the SOA architecture to obtain and update the core layer node information in a timely manner.

[0076] Step 2: Create RDMA context information as a preparation resource for establishing an RDMA connection with the core layer node.

[0077] Step 3: Create and maintain RDMA connections with core nodes.

[0078] Step 4: Listen for pipeline messages. If an exit signal is received, execute step 7; otherwise, execute step 5.

[0079] Step 5: Select the specific core node to be sent based on the core node information obtained in step 1 and the node's health status and load balancing strategy.

[0080] Step 6: Use the RDMA connection between the selected core layer node to realize data transmission. After the transmission is completed, jump back to step 4.

[0081] Step 7: Clean up resources and exit the process.

[0082] like Figure 3 As shown in the middle right figure, the implementation steps of the RDMA server of the convergence layer bridge component are detailed as follows:

[0083] Step 1: Listen to the registration center under the SOA architecture to obtain and update the core layer node information in a timely manner.

[0084] Step 2: Create RDMA context information as a preparation resource for establishing an RDMA connection with the core layer node.

[0085] Step 3: Start listening.

[0086] Step 4: Receive the connection request and check whether the connection IP belongs to the core layer node obtained in step 1. If not, reject the connection; if so, accept the connection and perform connection management and maintenance.

[0087] Step 5: Listen for pipeline messages. If an exit signal is received, execute step 8; otherwise, execute step 6.

[0088] Step 6: Receive a message from the RDMA link.

[0089] Step 7: Put the message into the listening pipeline of the subsequent processing plug-in and jump back to step 5.

[0090] Step 8: Clean up resources and exit the process.

[0091] In the cross-region access scenario, the RDMA server in the core layer bridging component receives the request data forwarded by the aggregation layer partition node, uses the registration center information to address the aggregation layer partition where the target service is located, selects the aggregation layer node through load balancing decision, and forwards the request data through the RDMA client between the node.

[0092] Figure 4 FIG. 1 is a schematic diagram of a processing flow of an optional core layer bridge component RDMA client and RDMA server according to an embodiment of the present invention, such as Figure 4 The left figure shows the RDMA server processing flow of the core layer bridge component, and the right figure shows the RDMA client processing flow of the core layer bridge component. The following describes them one by one.

[0093] like Figure 4 As shown in the middle left figure, the implementation steps of the core layer bridge component RDMA server are detailed as follows:

[0094] Step 1: Listen to the registration center under the SOA architecture to obtain and timely update the node information of each partition of the aggregation layer and the correspondence between each service and the aggregation layer partition.

[0095] Step 2: Create RDMA context information as a preparation resource for subsequently establishing an RDMA connection with the aggregation layer node.

[0096] Step 3: Create and maintain RDMA connections with core nodes.

[0097] Step 4: Start listening.

[0098] Step 5: Receive the connection request and check whether the connection IP belongs to the aggregation layer node obtained in step 1. If not, reject the connection; if so, accept the connection and perform connection management and maintenance.

[0099] Step 6: Listen for pipeline messages. If an exit signal is received, execute step 13; otherwise, execute step 7.

[0100] Step 7: Receive the cross-zone request message forwarded by the aggregation layer node from the RDMA link.

[0101] Step 8: Parse the header and obtain the target service name in the request message. If successful, proceed to step 9; otherwise, proceed to step 12.

[0102] Step 9: Obtain the target convergence layer partition to be forwarded according to the parsed target service name and the correspondence between the service and convergence layer partition obtained in step 1.

[0103] Step 10: Select a specific forwarding node based on the health check status and load balancing strategy of each node in the target aggregation layer partition.

[0104] Step 11: Put the message into the message receiving pipe of the RDMA client corresponding to the target node in the core layer node, and then jump to step 6.

[0105] Step 12: Record the error, discard the message, and jump to step 6.

[0106] Step 13: Clean up resources and exit the process.

[0107] like Figure 4 As shown in the middle right figure, the implementation steps of the RDMA client of the core layer bridge component are detailed as follows:

[0108] Step 1: Listen to the registration center under the SOA architecture to obtain and update the aggregation layer node information in a timely manner.

[0109] Step 2: Create RDMA context information as a preparation resource for subsequently establishing an RDMA connection with the core layer node.

[0110] Step 3: Establish an RDMA connection with a convergence layer node and perform connection management and maintenance.

[0111] Step 4: Listen for pipeline messages. If an exit signal is received, execute step 7; otherwise, execute step 5.

[0112] Step 5: Read the message to be forwarded from the pipeline.

[0113] Step 6: Use the RDMA connection between the aggregation layer nodes to realize data transmission. After the transmission is completed, jump back to step 4.

[0114] Step 7: Clean up resources and exit the process.

[0115] When selecting the target node to send, the aggregation layer partition nodes and core layer nodes all use the node health check function, which is completed by the node liveness detection component. The node liveness detection component uses active node liveness detection and passive health status updates based on business requests to implement health status updates for each node.

[0116] The specific implementation steps of the node liveness detection component include:

[0117] S1, create a node health status shared memory for use by the node detection component and the bridge component.

[0118] S2, obtain the node information that needs to be followed from the registration center and put it into the list of nodes to be followed.

[0119] The aggregation layer nodes pay attention to the information of the core layer nodes, and the core layer nodes pay attention to the information of all the partition nodes of the aggregation layer.

[0120] S3, for each node in the list, starts a scheduled task to actively detect the service port of each node.

[0121] If the detection is successful, the health status value of the corresponding node in the shared memory is increased by 1, and the unhealth value is set to 0; if it is unsuccessful, the unhealth status value of the corresponding node in the shared memory is increased by 1, and the health value is set to 0; if the health value or unhealth value reaches the set threshold, indicating that the corresponding node has the same detection status for multiple consecutive times, the status of the corresponding node in the shared memory is set to available or unavailable according to the status.

[0122] S4, while actively probing for activity, uses the results of sending and receiving messages in the RDMA link to update the health status value and unhealth status value. If the sending or receiving is successful, the health status value is increased by 1 and the unhealth value is set to 0. Otherwise, if it fails, the unhealth status value is increased by 1 and the health value is set to 0. The request in the RDMA link is used to achieve a rapid update of the health status.

[0123] In the embodiment of the present invention, the active detection and passive inspection mechanism of the node detection component is used to realize efficient health checks between nodes. At the same time, by dividing the service bus into the aggregation layer and the core layer, and realizing multi-partition deployment in the aggregation layer, hierarchical management and fault impact isolation are realized at the bus level during the service call process.

[0124] The embodiments of the present invention also facilitate users to independently arrange services and manage services according to different service levels and maintenance levels, reduce cross-influences during bus change and maintenance, and prevent low-level service failures from affecting high-level services.

[0125] The present invention is described below in conjunction with another optional embodiment.

[0126] Example 2

[0127] The service management device based on a service bus provided in this embodiment includes multiple implementation units, each implementation unit corresponding to each implementation step in the above-mentioned embodiment 1.

[0128] Figure 5 FIG. 1 is a schematic diagram of an optional service management device based on a service bus according to an embodiment of the present invention. Figure 5 As shown, the device may include: a forwarding unit 51, a parsing unit 52, a transmission unit 53, and a calling unit 54.

[0129] The forwarding unit 51 is configured to forward the service request to the core layer via the RDMA data connection when the convergence layer partition receives a service request involving a cross-zone call.

[0130] The parsing unit 52 is configured to parse the service request through the core layer to obtain the service name of the target service to be called and the target convergence layer partition where the target service is located.

[0131] The transmission unit 53 is configured to transmit the service request to the target convergence layer partition based on the health status information and the RDMA data connection, wherein the health status information is used to record the health status of each target node in the target convergence layer partition.

[0132] The calling unit 54 is configured to respond to the service request and call the target service in the target convergence layer partition based on the service name.

[0133] The above-mentioned service management device based on the service bus can, when the convergence layer partition receives a service request involving a cross-zone call, first forward the service request to the core layer through the forwarding unit 51 using the RDMA data connection, and then control the core layer to parse the service request through the parsing unit 52 to obtain the service name of the target service to be called and the target convergence layer partition where the target service is located, and then transmit the service request to the target convergence layer partition based on the health status information and the RDMA data connection through the transmission unit 53, wherein the health status information is used to record the health status of each target node in the target convergence layer partition, and finally respond to the service request through the calling unit 54, and call the target service in the target convergence layer partition based on the service name.

[0134] In an embodiment of the present invention, the service bus is divided into a convergence layer and a core layer at the architectural level, and the convergence layer is divided into N business partitions. Each partition has the full set of functions of a traditional service bus, and an RDMA data connection is established in advance with the core layer through a bridging component, so as to facilitate cross-region service calls and management between the convergence layer partitions through the core layer. In addition, the core layer implements a service control function. After receiving the cross-region call service request forwarded by the convergence layer partition, it parses the target service and the partition where the service is located, and forwards the cross-region service call request based on the health status of each target node in the partition where the service is located, and calls the target service, thereby realizing hierarchical partition management of different call requests, thereby realizing hierarchical management of different businesses, and thus solving the technical problem in related technologies that the service bus cannot realize hierarchical management of different businesses.

[0135] Optionally, the RDMA data connection is implemented through the RDMA server and RDMA client in the bridging component, and the RDMA data connection includes: a first RDMA link and a second RDMA link, wherein the first RDMA link is a data link between the core layer server and the aggregation layer client, and the second RDMA link is a data link between the aggregation layer server and the core layer client.

[0136] Optionally, the service management device based on the service bus includes: a first acquisition module, used to obtain the first-class local IP and first-class service port information of all core nodes in the core layer from the registration center for the bridging component deployed in the aggregation layer partition; a first startup module, used to start the aggregation layer server and aggregation layer client in each partition node of the aggregation layer partition; a first registration module, used to perform local registration in the registration center for each partition node through the started aggregation layer server to obtain the second-class local IP and second-class service port information of the partition node; a first creation module, used to create a first data connection request based on the first-class local IP and first-class service port information through the started aggregation layer client, wherein the first data connection request is used to request the core layer server to create a first RDMA link.

[0137] Optionally, the service management device based on the service bus also includes: a second acquisition module, which is used to obtain the second-class local IP and second-class service port information of all partition nodes in each aggregation layer partition from the registration center for the bridging component deployed in the core layer; a second startup module, which is used to start the core layer server and core layer client in each core node of the core layer; a second registration module, which is used to register locally with the registration center for each core node through the started core layer server to obtain the first-class local IP and first-class service port information of the core node; a second creation module, which is used to create a second data connection request based on the second-class local IP and second-class service port information through the started core layer client, wherein the second data connection request is used to request the aggregation layer server to create a second RDMA link.

[0138] Optionally, the forwarding unit includes: a third acquisition module, used to obtain the health status information of all core nodes in the core layer; a first selection module, used to select the target core node from all core nodes based on the health status information and load balancing strategy; and a first forwarding module, used to forward the service request to the target core node through the first RDMA link in the RDMA data connection.

[0139] Optionally, the transmission unit includes: a fourth acquisition module, used to obtain the health status information of all partition nodes in the target aggregation layer partition; a second selection module, used to select the target partition node from all partition nodes based on the health status information and load balancing strategy; and a second forwarding module, used to forward the service request to the target partition node through the second RDMA link in the RDMA data connection.

[0140] Optionally, the service management device based on the service bus also includes: a third creation module, used to create a scheduled detection task and a health status shared memory, wherein the content of the scheduled detection task is set to: initiate M health checks on the target node at intervals of a specified time within a specified period, and the target node includes: a core node and / or a partition node, and M is a specified positive integer; an update module, used to update the status indicators in the health status shared memory based on the scheduled detection task; and a generation module, used to generate health status information based on the status indicators in the health status shared memory after the scheduled detection task ends.

[0141] The above-mentioned service management device based on the service bus can also include a processor and a memory. The above-mentioned forwarding unit 51, parsing unit 52, transmission unit 53, calling unit 54, etc. are all stored in the memory as program units, and the processor executes the above-mentioned program units stored in the memory to realize the corresponding functions.

[0142] The processor includes a kernel that retrieves the corresponding program unit from the memory. One or more kernels can be configured to transmit service requests to the target aggregation layer partition based on health status information and RDMA data connections by adjusting kernel parameters. The health status information is used to record the health status of each target node in the target aggregation layer partition, and, in response to the service request, invoke the target service in the target aggregation layer partition based on the service name.

[0143] The above-mentioned memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0144] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing a program that initializes the following method steps: when a convergence layer partition receives a service request involving a cross-zone call, forwarding the service request to the core layer through an RDMA data connection; parsing the service request through the core layer to obtain the service name of the target service to be called and the target convergence layer partition where the target service is located; transmitting the service request to the target convergence layer partition based on health status information and the RDMA data connection, wherein the health status information is used to record the health status of each target node in the target convergence layer partition; and responding to the service request, calling the target service in the target convergence layer partition based on the service name.

[0145] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is further provided, which includes a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute the service bus-based service management method of any one of the above-mentioned embodiments.

[0146] According to another aspect of an embodiment of the present invention, an electronic device is also provided, including one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by one or more processors, the one or more processors implement the service bus-based service management method of any one of the above-mentioned embodiments.

[0147] Figure 6 FIG is a hardware structure diagram of an electronic device (or mobile device) for a service management method based on a service bus according to an embodiment of the present invention. Figure 6 As shown, the electronic device may include one or more ( Figure 6(The processor 602a, processor 602b, ..., processor 602n are used to illustrate) a processor 602 (the processor 602 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), and a memory 604 for storing data. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a keyboard, a power supply, and / or a camera. It will be understood by those skilled in the art that Figure 6 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 6 More or fewer components than shown, or with Figure 6 Different configurations shown.

[0148] The serial numbers of the above embodiments of the present invention are for description only and do not represent the advantages or disadvantages of the embodiments.

[0149] In the above embodiments of the present invention, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0150] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only exemplary. For example, the division of the units can be a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0151] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0152] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0153] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk, etc. Various media that can store program codes.

[0154] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A service management method based on a service bus, characterized in that: The service bus includes a core layer and N aggregation layer partitions obtained after pre-layered partitioning processing, the core layer and each aggregation layer partition pre-establish an RDMA data connection through a bridge component, N is a positive integer, and the service management method includes: When the convergence layer partition receives a service request involving a cross-zone call, forwarding the service request to the core layer through the RDMA data connection; Parsing the service request through the core layer to obtain the service name of the target service to be called and the target convergence layer partition where the target service is located; Transmitting the service request to the target convergence layer partition based on health status information and the RDMA data connection, wherein the health status information is used to record the health status of each target node in the target convergence layer partition; In response to the service request, the target service in the target convergence layer partition is called based on the service name.

2. The service management method according to claim 1, wherein: The RDMA data connection is realized through the RDMA server and RDMA client in the bridging component, and the RDMA data connection includes: a first RDMA link and a second RDMA link, wherein the first RDMA link is a data link between the core layer server and the aggregation layer client, and the second RDMA link is a data link between the aggregation layer server and the core layer client.

3. The service management method according to claim 2, wherein: The steps of establishing the RDMA data connection include: For the bridge component deployed in the aggregation layer partition, obtain the first-class local IP and first-class service port information of all core nodes in the core layer from the registration center; Start the convergence layer server and the convergence layer client in each partition node of the convergence layer partition; For each partition node, register the local node at the registration center through the aggregation layer server after startup to obtain the second type local IP and second type service port information of the partition node; The started convergence layer client creates a first data connection request based on the first type of local IP and the first type of service port information, wherein the first data connection request is used to request the core layer server to create the first RDMA link.

4. The service management method according to claim 2, wherein: The step of establishing the RDMA data connection further includes: For the bridge component deployed in the core layer, obtain the second-class local IP and second-class service port information of all partition nodes in each of the aggregation layer partitions from a registration center; Starting the core layer server and the core layer client in each core node of the core layer; For each core node, register the core layer server at the registration center after startup to obtain the first-class local IP and first-class service port information of the core node; The started core layer client creates a second data connection request based on the second type of local IP and the second type of service port information, wherein the second data connection request is used to request the aggregation layer server to create the second RDMA link.

5. The service management method according to claim 2, wherein: The step of forwarding the service request to the core layer through the RDMA data connection comprises: Obtaining health status information of all core nodes in the core layer; Selecting a target core node from all the core nodes based on the health status information and the load balancing strategy; The service request is forwarded to the target core node via a first RDMA link in the RDMA data connection.

6. The service management method according to claim 2, wherein: The step of transmitting the service request to the target aggregation layer partition based on the health status information and the RDMA data connection comprises: Obtain the health status information of all partition nodes in the target convergence layer partition; Selecting a target partition node from all the partition nodes based on the health status information and the load balancing strategy; The service request is forwarded to the target partition node via a second RDMA link in the RDMA data connection.

7. The service management method according to claim 5 or 6, characterized in that: The health status information is obtained by the following steps: Create a scheduled detection task and health status shared memory, where the content of the scheduled detection task is set to: initiate M health checks on the target node at specified intervals within a specified period, and the target node includes: core nodes and / or partition nodes, and M is a specified positive integer; Update the status indicator in the health status shared memory based on the timed detection task; After the scheduled detection task is completed, the health status information is generated based on the status indicator in the health status shared memory.

8. A service management device based on a service bus, characterized in that: The service bus includes a core layer and N aggregation layer partitions obtained after pre-layered partitioning processing, and the core layer and each aggregation layer partition establish an RDMA data connection in advance through a bridge component, where N is a positive integer. The service management device includes: A forwarding unit, configured to forward the service request to the core layer through the RDMA data connection when the convergence layer partition receives a service request involving a cross-zone call; A parsing unit, configured to parse the service request through the core layer to obtain a service name of a target service to be called and a target convergence layer partition where the target service is located; a transmission unit, configured to transmit the service request to the target convergence layer partition based on health status information and the RDMA data connection, wherein the health status information is used to record the health status of each target node in the target convergence layer partition; A calling unit is used to respond to the service request and call the target service in the target convergence layer partition based on the service name.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a stored computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located is controlled to execute the service bus-based service management method according to any one of claims 1 to 7.

10. An electronic device, characterized in that: It includes one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the service bus-based service management method described in any one of claims 1 to 7.

Citation Information

Patent Citations

  • System and method for supporting message pre-processing in a distributed data grid cluster

    CN104620558A

  • Interconnect partition binding API, allocation and management of application-specific partitions

    US20140358972A1