CN109271259B

CN109271259B - Enterprise service bus system, data processing method, terminal and storage medium

Info

Publication number: CN109271259B
Application number: CN201810928884.5A
Authority: CN
Inventors: 张学
Original assignee: OneConnect Financial Technology Co Ltd Shanghai
Current assignee: OneConnect Financial Technology Co Ltd Shanghai
Priority date: 2018-08-15
Filing date: 2018-08-15
Publication date: 2022-10-21
Anticipated expiration: 2038-08-15
Also published as: CN109271259A

Abstract

An enterprise service bus system for communicatively coupling an enterprise system to a third party system, comprising: ESB-API, KAFKA, ESB-CONSUMER, ESB-PROXY-IN, ESB-PROXY-OUT and ESB-FILE-PROXY-OUT subsystems, wherein KAFKA is IN communication connection with ESB-API and ESB-CONSUMER, ESB-API is IN communication connection with ESB-PROXY-IN, ESB-CONSUMER is IN communication connection with ESB-PROXY-OUT and ESB-FILE-PROXY-OUT subsystems. The invention also provides an enterprise service bus data processing method, a terminal and a storage medium. The invention can convert the data requests sent by different requesters into uniform messages and request protocols, realizes the function of a synchronous-to-asynchronous processing mechanism and improves the data processing speed.

Description

Enterprise service bus system, data processing method, terminal and storage medium

Technical Field

The invention relates to the technical field of computers, in particular to a remake-mode enterprise service bus system, a remake-mode enterprise service bus data processing method, a terminal and a storage medium.

Background

With the development of computer information systems, information systems are also increasingly large and complex. When there are many connection objects, the point-to-point connection method has high cost and low availability and maintainability, and therefore, the concept of bus is introduced into the architecture construction of information system. Following the concept of Service Oriented Architecture (SOA), the bus of an information system is often called the Service bus. The Bus at its strategic layer is called an Enterprise Service Bus (ESB). The enterprise service bus is an enterprise information system basic platform which is provided with a standard interface, realizes interconnection, communication and service routing and supports the realization of SOA.

In some enterprises selecting the heavy mode (self-operation mode), the control force is strong because of enough related intermediate links, but if each link is required to be done, the operation cost is very high, so that an enterprise service bus architecture is required to be established, and the operation cost and the management cost of the enterprises are reduced.

Disclosure of Invention

In view of the above, there is a need to provide a multimode enterprise service bus system, a multimode enterprise service bus data processing method, a terminal, and a storage medium, which can convert data requests sent by different requesters of the data requests into a unified message and a request protocol, and implement a function of converting a synchronous processing mechanism into an asynchronous processing mechanism.

A first aspect of the present invention provides an enterprise service bus system, the enterprise service bus system communicatively connecting a plurality of enterprise systems and a plurality of third party systems, the enterprise service bus system comprising: the KAFKA subsystem is respectively IN communication connection with the ESB-API subsystem and the ESB-CONSUMER subsystem, the ESB-API subsystem is IN communication connection with the ESB-PROXY-IN subsystem, and the ESB-FILE-PROXY-OUT subsystem is respectively IN communication connection with the ESB-PROXY-OUT subsystem and the ESB-FILE-PROXY-OUT subsystem, wherein,

the ESB-API subsystem is used for issuing a dubbo service protocol, and the ESB-PROXY-IN subsystem is used for issuing an http service protocol and an https service protocol;

said ESB-API subsystem is further configured to send said enterprise service bus system encapsulated message from a message producer in said ESB-API subsystem to said KAFKA subsystem;

the KAFKA subsystem is used for configuring a corresponding message queue according to the to-be-processed message and processing the to-be-processed message when receiving the to-be-processed message sent by the ESB-API subsystem;

the ESB-CONSUMER subsystem is used for pulling the message to be processed from the message queue of the KAFKA subsystem every other preset time period and creating a corresponding thread according to the message to be processed;

the ESB-CONSUMER subsystem is used for analyzing the message to be processed and sending the analyzed content to a server corresponding to the data request;

the ESB-CONSUMER subsystem is also used for acquiring a request result sent by a server of the data request and temporarily storing the request result into a message queue of the KAFKA subsystem;

the ESB-API subsystem is further configured to retrieve the request result from the KAFKA subsystem's message queue and send the request result to the requestor of the data request.

A second aspect of the present invention provides a method for processing enterprise service bus data by using the enterprise service bus system, where the method includes:

the issuing service is called by a requester, the issuing service protocol of the ESB-API subsystem is a dubbo protocol, and the issuing service protocol of the ESB-PROXY-IN subsystem is an http protocol and an https protocol;

detecting whether a data request of a requester is received;

when detecting that a data request of a requester is received, identifying whether the requester of the data request is legal or not;

when the requester of the data request is identified to be legal, the server of the data request is identified according to the data request;

encapsulating the data request into a corresponding message according to the service party of the request, and sending the encapsulated message to the KAFKA subsystem by a message producer in the ESB-API subsystem;

when the KAFKA subsystem receives the to-be-processed message sent by the ESB-API subsystem, configuring a corresponding message queue according to the to-be-processed message, and processing the to-be-processed message;

the ESB-CONSUMER subsystem pulls the messages to be processed from the message queue of the KAFKA subsystem every other preset time period, and corresponding threads are established according to the messages to be processed;

the ESB-CONSUMER subsystem analyzes the message to be processed and sends the analyzed content to a server corresponding to the data request;

the ESB-CONSUMER subsystem acquires a request result sent by a server of the data request and temporarily stores the request result into a message queue of the KAFKA subsystem;

the ESB-API subsystem obtains the request result from the message queue of the KAFKA subsystem and sends the request result to the requester of the data request.

Preferably, the data request of the requester is a data request obtained by encapsulating a data request by the requester according to a service protocol issued by an enterprise service system, and includes:

when the requesting party is the enterprise system, packaging the data request according to the dubbo protocol;

and when the requester is a third-party system, packaging the data request according to the http protocol or the https protocol.

Preferably, the identifying a service party of the data request according to the data request comprises:

identifying a server of the data request according to a data request server identifier carried in the data request;

when the data request service party identifier is identified as a first identifier, determining that the data request service party is an enterprise system;

and when the data request service party identifier is identified as a second identifier, determining that the data request service party is a third-party system.

Preferably, said encapsulating said data request into a corresponding message according to said requested service and sending the encapsulated message from a message producer in said ESB-API subsystem to said KAFKA subsystem comprises:

when the receiving system of the data request is the ESB-API subsystem, the data request is encapsulated into a message, and the encapsulated message is sent to the KAFKA subsystem by a message producer in the ESB-API subsystem;

when the receiving system of the data request is the ESB-PROXY-IN subsystem, the data request is packaged into a message and is forwarded to the ESB-API subsystem through the ESB-PROXY-IN subsystem, and then the message producer IN the ESB-API subsystem sends the message to the KAFKA subsystem.

Preferably, the creating a corresponding thread according to the message to be processed includes: and creating a thread pool with corresponding size according to the request concurrency number corresponding to the server, wherein the request concurrency number is equal to the size of the thread pool.

Preferably, the sending the analyzed content to the service side corresponding to the data request includes: when the service party of the data request is the third-party system, the analyzed content is sent to the service party of the data request through the ESB-PROXY-OUT subsystem or the ESB-FILE-PROXY-OUT subsystem; and when the service party of the data request is the enterprise system, directly sending the analyzed content to the enterprise system.

Preferably, the sending the request result to the requester of the data request comprises: when the requester of the data request is the enterprise system, the ESB-API subsystem directly sends the request result to the enterprise system; and when the requester of the data request is the third-party system, the ESB-API subsystem sends the request result to the third-party system through the ESB-PROXY-OUT subsystem or the ESB-FILE-PROXY-OUT subsystem.

Preferably, the method further comprises:

judging whether the current request state meets the fusing condition or not;

when the current request state meets the fusing condition, configuring a first number of message queues, and returning preset information to a requester of the currently received data request;

when the current request state does not satisfy the fusing condition, a second number of message queues are configured.

Preferably, the fusing condition comprises a combination of one or more of:

the time consumed by the current data request exceeds the preset time consumed; or

The average value of the consumed time of all the data requests in the preset time period is greater than or equal to the interface exceeding time; or

The number of messages in the ESB-API subsystem message queue exceeds the preset number; or

The number of data requests of the requester receiving the same data request exceeds a preset number.

A third aspect of the present invention provides a terminal comprising a processor and a memory, wherein the processor is configured to implement the enterprise service bus data processing method when executing a computer program stored in the memory.

A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the enterprise service bus data processing method.

To sum up, the dual-mode enterprise service bus system, the data processing method, the terminal and the storage medium in the embodiments of the present invention adopt a synchronous processing mechanism of an open source framework dubbo, and combine with an asynchronous processing mechanism of an open source processing flow platform KAFKA to convert the synchronous processing mechanism into an asynchronous processing mechanism, so that the ESB not only has the feature of balanced load of dubbo, but also has the buffering function of a message queue of KAFKA, and can dynamically expand capacity and persist messages: messages are persisted to local disk and support data backup to prevent data loss. Secondly, a uniform message format is set, and data requests sent by different data request requesters are converted into uniform messages and request protocols, so that the bottom layer technical difference of a heterogeneous system can be shielded, and the development and management of the data request requesters are facilitated.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.

Fig. 1 is a diagram of an operating environment of a multimode enterprise service bus system according to an embodiment of the present invention.

Fig. 2 is a flowchart of a data processing method for a multimode enterprise service bus according to a second embodiment of the present invention.

Fig. 3 is a schematic diagram of a terminal according to a third embodiment of the present invention.

The following detailed description will further illustrate the invention in conjunction with the above-described figures.

Detailed Description

In order that the above objects, features and advantages of the present invention can be more clearly understood, a detailed description of the present invention will be given below in conjunction with the accompanying drawings and specific embodiments. It should be noted that the embodiments of the present invention and features of the embodiments may be combined with each other without conflict.

In the following description, numerous specific details are set forth to provide a thorough understanding of the present invention, and the described embodiments are merely a subset of the embodiments of the present invention, rather than a complete embodiment. All other embodiments, which can be obtained by a person skilled in the art without making any creative effort based on the embodiments in the present invention, belong to the protection scope of the present invention.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The terminology used in the description of the invention herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

Example one

In this embodiment, the Enterprise system 200 performs communication connection and data interaction with the third-party system 300 through the multimode Enterprise Service Bus system 100 (ESB, hereinafter abbreviated as ESB 100). The third party system 300 is in communication connection and data interaction with the enterprise system 200 through the ESB 100.

The enterprise system 200 may include a plurality of enterprise applications or enterprise file services, such as enterprise application 1, enterprise application 2, and enterprise application 3, and different enterprise applications or enterprise file services may be deployed on different servers.

The third-party system 300 may include a plurality of third-party applications or third-party file services, such as third-party application 1, third-party application 2, third-party application 3, and a third-party file service, and different third-party applications or third-party file services may be configured on different servers.

The ESB100 may include a plurality of subsystems, such as: an ESB-API subsystem (hereinafter abbreviated as ESB-API) 101, a KAFKA subsystem (hereinafter abbreviated as KAFKA) 102, an ESB-CONSUMER subsystem (hereinafter abbreviated as ESB-CONSUMER) 103, an ESB-PROXY-IN subsystem (hereinafter abbreviated as ESB-PROXY-IN) 104, an ESB-PROXY-OUT subsystem (hereinafter abbreviated as ESB-PROXY-OUT) 105, and an ESB-FILE-PROXY-OUT subsystem (hereinafter abbreviated as ESB-FILE-PROXY-OUT) 106. Wherein, KAFKA102 is respectively connected with ESB-API101 and ESB-CONSUMER103 IN communication, ESB-API101 is connected with ESB-PROXY-IN104 IN communication, ESB-CONSUMER103 is respectively connected with ESB-PROXY-OUT105 and ESB-FILE-PROXY-OUT106 IN communication. ESB-PROXY-IN104 may be referred to as an access PROXY. ESB-PROXY-OUT105 and ESB-FILE-PROXY-OUT106 may be referred to as take-off proxies.

In other embodiments, the ESB100 may further include a zokeeper subsystem 107 and a NAS subsystem 108.

IN this embodiment, each subsystem (e.g., ESB-API10, ESB-PROXY-IN104, ESB-PROXY-OUT105, ESB-FILE-PROXY-OUT 106) IN the ESB100 is used for publishing services. The publishing service is a publishing service agreement, which may include: dubbo protocol, http protocol, https protocol.

In this embodiment, the enterprise system 200, the ESB100, and the third party system 300 may be a requester or a server. ESB100 may establish a unique identifier and request concurrency number for different enterprise systems 200 and different third party systems 300, for example, establishing identifier "B10047" for a certain bank, and request concurrency number of 100.

IN this embodiment, the ESB-API101 issues a service protocol as a dubbo protocol, a service name format is "ESB-api.service.xxxxxx _ yyyyyyyy", where "XXXXXX" IN the interface name is an identifier of a service party (the enterprise system 200 or the third-party system 300), and "yyyyyyyyy" IN the interface name is a service name provided by the service party, and the ESB-API101 issues a service for the enterprise system 200 and the ESB-PROXY-IN104 to call.

IN this embodiment, the ESB-PROXY-IN104 issues the service protocol as an http protocol and an https protocol, the format of the service name is "ESB. Yyyyyyy", the "yyyyy" IN the interface name is the service name provided by the service party (the enterprise system 200 or the third-party system 300), and the ESB-PROXY-IN104 issues the service for the third-party system 300 to call. A service correspondence table is maintained when the ESB-PROXY-IN104 issues a service, and the service issued by the ESB-PROXY-IN104 corresponds to the service issued by the ESB-API101, for example, the ESB-client-queryrerst list service issued by the ESB-PROXY-IN101 corresponds to the ESB-API-service-file 004.Ff. Client.

In this embodiment, the service protocol issued by the ESB-PROXY-OUT105 and the ESB-FILE-PROXY-OUT106 is a dubbo protocol, the format of the service name is "ESB-proxy.service.xxxxxx _ yyyyyyy", the "XXXXXX" in the interface name is an identifier of a service party (the enterprise system 200 or the third-party system 300), the "yyyyy" in the interface name is a service name provided by the service party, and the service issued by the ESB-PROXY-OUT105 and the ESB-FILE-PROXY-OUT106 is called by the ESB-API 101. The services issued by the ESB-PROXY-OUT105 and ESB-FILE-PROXY-OUT106 appear in pairs with the services issued by the ESB-API101, such as ESB-PROXY service.B10043. QueryGrating Interest issued by the ESB-PROXY-OUT105

The RateService service appears in pairs with the ESB-api.service.b10043.Query grad-ingInterestRateService service issued by the ESB-API 101.

It should be noted that, the ESB100 as a requester is mainly relative to subsystems inside the ESB100, because there is also a call relationship between subsystems inside the ESB 100.

For example: ESB-PROXY-IN104 of ESB100 calls other subsystems of ESB100, and ESB-PROXY-IN104 of ESB100 also calls ESB-API101 of ESB100, where ESB-PROXY-IN104 is the requestor with respect to ESB-API 101.

The ESB100 is also used to detect whether a data request from a requestor is received.

The data request of the requester is a data request encapsulated by the requester according to the service issued by ESB 100.

In this embodiment, the encapsulating, by the requestor, the data request according to the issued service may include:

1) When the requesting party is the enterprise system 200, the data request is encapsulated according to the dubbo protocol issued by each subsystem of the ESB 100.

2) When the requesting party is the third-party system 300, the data request is encapsulated according to the http protocol or the https protocol issued by each subsystem of the ESB 100.

The data request is encapsulated by the requester according to the service issued by each subsystem of the ESB100, and the requester just needs to encapsulate according to the uniform request message format of the ESB100, without paying attention to the problem that the request message formats of different service providers are different.

For example, the format of the unified request message provided in this embodiment is as follows:

the ESB100 is further configured to identify whether a requester of the data request is legal or not, when it is detected that the data request of the requester is received.

In this embodiment, when receiving a data request, ESB100 identifies whether a requester of the data request is legal according to the data request. The legality refers to whether the requesting party is the legal enterprise system 200 or the third-party system 300 which is acknowledged by the ESB100, and the enterprise system 200 and the third-party system 300 refer to systems which are interfaced by the ESB100 and for which unique identifiers are established.

In this embodiment, the data request may carry a data request source identifier, where the data request source identifier is used to indicate an identity of a requester of the data request. The source identification is the unique identification established by ESB100 for the system.

The ESB100 is also used to abort a request when the requestor of the data request is identified as being illegal.

The ESB100 is further configured to, upon identifying a requestor of the data request, identify a server of the data request based on the data request.

In this embodiment, when determining that the requester of the data request is a legitimate requester, the ESB identifies a service party of the data request according to the data request, where the service party may be the enterprise system 200 or the third-party system 300.

In this embodiment, the data request may carry an identifier of a data request service provider, where the identifier of the data request service provider is used to indicate an identity of a service provider of the data request. The data request service party identification comprises: the data request service party is used for requesting the data request service party to be the enterprise internal application or the enterprise internal file service, and the second identification is used for requesting the data request service party to be the third party application or the third party file service.

Identifying a service party of the data request according to the data request may include: identifying a server of the data request according to a data request server identifier carried in the data request; when the data request service party identifier is identified as a first identifier, determining that the data request service party is an enterprise system; and when the data request service party identifier is identified as the second identifier, determining that the data request service party is a third-party system.

For example, the data request service party identifier in this embodiment may be the "XXXXXX" part in the service name issued by the ESB-API101, ESB-PROXY-OUT105, and ESB-FILE-PROXY-OUT 106.

The ESB100 is further configured to encapsulate the data request into a corresponding message according to the service of the request, and send the encapsulated message to KAFKA102 by the message producer in ESB-API 101.

In this embodiment, the ESB-API101 is a predefined function of an Application Programming Interface (API), and is a service entry of the ESB100 and a producer of a message.

In this embodiment, encapsulating the data request into a corresponding message according to the service side of the request, and sending the encapsulated message to KAFKA102 by the message producer in ESB-API101 may include:

1) When the receiving system of the data request is the ESB-API101, the data request is encapsulated as a message and the encapsulated message is sent by the message producer in the ESB-API101 to KAFKA102.

2) When the receiving system of the data request is ESB-PROXY-IN104, the data request is encapsulated as a message and forwarded to ESB-API101 through the first PROXY server, and the message is sent by the message producer IN ESB-AP101I to KAFKA102.

After being encapsulated, the message is directly sent to a message queue of KAFKA102 by a message producer in ESB-API101, and the message carries an identification number which is used for indicating the position information of the stored message queue. For example, when the identification number is a, it indicates that the message is stored in the message queue 1, and when the identification number is B, it indicates that the message is stored in the message queue 2. The message queue may be a message queue of KAFKA102 or a message queue in memory.

The ESB-PROXY-IN104 may also include a load balancing function (e.g., F5 shown IN the figure) to perform load balancing control on data requests of the third party system 300. Prevent high concurrency from stressing enterprise systems (e.g., banking systems) and causing paralysis.

The KAFKA102 is configured to, when receiving a message to be processed sent by the ESB-API101, configure a corresponding message queue according to the message to be processed, and process the message to be processed.

In this embodiment, KAFKA102 is a high throughput distributed publish-subscribe messaging system, which provides a message queue for ESB100, and can process all action flow data in a consumer-scale website, and KAFKA102 has the characteristics of high throughput, supporting load balancing, asynchronous sending, and message persistence. When KAFKA102 detects a message sent by ESB-API101, the message to be processed is acquired, a corresponding message queue is configured, and the message to be processed is processed.

The processing the message to be processed may include: storing the message to be processed into a plurality of copies in a distributed manner; when the number of the messages to be processed exceeds a preset number threshold, slicing or dicing each message in the messages to be processed; and compressing the message to be processed. This ensures that pending messages are not lost and are not repeatedly consumed.

In this embodiment, the ESB100 uses KAFKA102 as a message queue, has a high throughput rate and a message persistence function, and can well improve the processing capability of the ESB100, so that the processing capability of the ESB100 is controllable, and when the service performance of the ESB100 is low, the message queue can be used to buffer information, thereby avoiding a crash.

The ESB-connector 103 is configured to pull the to-be-processed message from the message queue of KAFKA102 every preset time period, and create a corresponding thread according to the to-be-processed message.

The ESB-connector 103 may listen every preset period of time (e.g., 200 milliseconds) for messages to be processed in KAFKA102, and when the ESB-connector 103 listens for messages to be processed in KAFKA102, pull the message from KAFKA102 and route it to the corresponding proxy server based on the message content.

ESB100 creates corresponding thread pools according to the message queues, wherein one message queue corresponds to one thread pool, each thread pool fixedly consumes the messages to be processed in the corresponding message queue, and different thread pools are not interfered with each other. For example, thread pool 1 is responsible for consuming messages pending in message queue 1 only, and thread pool 2 is responsible for consuming messages pending in message queue 2 only.

In this embodiment, the creating a corresponding thread according to the to-be-processed message may include: and creating a thread pool with a corresponding size according to the request concurrency number corresponding to the server. The number of request concurrencies is equal to the size of the thread pool.

Creating thread pools with different sizes according to the request concurrency number preconfigured by the service party, thereby implementing different concurrency control according to different data request amounts, for example, the data request amount of an enterprise system is generally small, and the request concurrency number preconfigured by the service party (the third-party system 300) is correspondingly low, so that the thread pools created by the ESB-constructor 103 are also small, for example, 20-50; for another example, the data request volume of the third-party system is generally larger, and the number of the request concurrences configured by the service party (the enterprise system 200) in advance is correspondingly higher, so that the thread pool created by the ESB-manager 103 is larger, for example, 100-150.

The ESB-constructor 103 parses the message to be processed, and sends the parsed content to the service side corresponding to the data request.

In this embodiment, the thread of the ESB-connector 103 may be configured with a configuration table corresponding to the to-be-processed message in advance. The configuration table includes: the system service name, the physical route of the system service, the condition code of the subsequent flow of the system service, the information of the subsequent service corresponding to the condition code and the like required by the completion of the data request. The analysis of the message to be processed is to determine the specific service content by retrieving the configuration table and explaining the content, and to determine the system service name, the system service physical route, the condition code of the subsequent flow, the subsequent service corresponding to the condition code, and the like.

In this embodiment, the service party refers to a service person who responds to the data request of the requesting party and provides a corresponding request result according to the data request, and the service party may include: enterprise system 200 or third party system 300. Of course, if the enterprise system 200 includes multiple enterprise subsystems, for example, enterprise subsystem 1, enterprise subsystem 2. The server may also be an enterprise subsystem of a plurality of enterprise subsystems. Similarly, if the third-party system 300 includes a plurality of third-party subsystems, for example, the third-party subsystem 1 and the third-party subsystem 2. The service party may also be one of a plurality of third party subsystems. That is, the requesting party and the serving party may be the enterprise system 200 at the same time, or may be the third-party system 300 at the same time, for example, when the enterprise subsystem 1 requests to invoke the enterprise subsystem 2, in this case, the enterprise subsystem 1 is the requesting party, and the enterprise subsystem 2 is the serving party.

For example, the server provided in this embodiment responds to the data request, that is, responds to the message format as follows:

in this embodiment, sending the analyzed content to the service side corresponding to the data request may include:

1) When the service party of the data request is the third-party system 300, the analyzed content is sent to the service party of the data request (the third-party system) through the outgoing proxy server.

When receiving the analyzed content sent by the thread of the ESB-connector 103, the take-off proxy server forwards the analyzed content to the third-party system 300. The ESB-PROXY-OUT105 is used for receiving the message of the ESB-CONSURER 103, requesting the third-party system to respond to the data request according to the message and a request mode preset by the third-party system, and returning a request result. The ESB-FILE-PROXY-OUT106 is configured to receive a message of the ESB-provider 103, request the third party system 300 according to the message in a request manner preset by the third party system 300, and upload or download a FILE corresponding to the data request.

2) When the service side of the data request is the enterprise system 200, the parsed content is directly sent to the enterprise system 200.

The ESB-connector 103 obtains the request result sent by the server of the data request and temporarily stores the request result in the message queue of KAFKA102.

In this embodiment, the request result sent by the server for obtaining the data request may include:

1) When the service side of the data request is the third-party system 300, the request result is obtained from the third-party system 300 through the take-off proxy server, and the request result is temporarily stored in a message queue of the KAFKA102.

2) When the server of the data request is the enterprise system 200, the request result is directly obtained from the enterprise system, and the request result is temporarily stored in a message queue of KAFKA102.

ESB-API101 retrieves the request result from the KAFKA102 message queue and sends the request result to the requestor of the data request.

In this embodiment, sending the request result to the requester of the data request may include:

1) When the requesting party of the data request is the enterprise system 200, the ESB-API101 directly sends the request result to the enterprise system 200.

2) When the requester of the data request is the third-party system 300, the ESB-API101 sends the request result to the third-party system 300 through the access proxy server.

It should be noted that either the enterprise system 200 or the third party system 300 may be a requester of a data request, or a server of a data request that responds to the data request and provides a request result. That is, the enterprise system 200 may respond to the data request as the data request server and provide the request result to the data request requester (the third-party system 300) while sending the data request to the data request server (the third-party system 300) as the data request requester. The third-party system, as a requester of the data request, may also respond to the data request as a server of the data request and provide a request result to the requester of the data request (the enterprise system 200) while sending the data request to the server of the data request (the enterprise system 200).

Further, when the ESB100 is further configured to receive a data request, determining whether a current request state meets a fusing condition; and when the current request state meets the fusing condition, configuring a first number of message queues, and returning preset information to a requester of the currently received data request. When the current request state does not satisfy the fusing condition, a second number of message queues are configured.

ESB100 may count the time consumed by each data request, where the time consumed by the data request is the time from the data request sent by the requester receiving the data request to the time when the request result corresponding to the data request is returned to the requester receiving the data request.

The current request state may include a combination of one or more of the following: the elapsed time of the current data request; averaging the time consumed by all data requests within a preset time period; the number of messages in the ESB-API message queue; the number of data requests of a requester that receives the same data request.

The fusing conditions may include a combination of one or more of the following: the time consumed by the current data request exceeds the preset time consumed; the average value of the consumed time of all the data requests in the preset time period is greater than or equal to the interface exceeding time; the number of messages in the ESB-API101 message queue exceeds a preset number; the number of data requests of the requester receiving the same data request exceeds a preset number.

The preset time is a predefined time value. The preset information may be "system traffic is busy, please try again later". The first quantity value is equal to the size value of the thread pool, and the second quantity value is equal to the size value of the thread pool multiplied by the ratio of the interface timeout time value to the average elapsed time value.

In this embodiment, by presetting a fusing condition, when it is detected that the fusing condition is satisfied, it is possible that an instantaneous high concurrency exceeds the processing capability of the ESB100, for example, when the number of messages in the message queue of the ESB-API101 exceeds a preset number, the KAFKA102 and the ESB-provider 103 are not in time to process the data request, or when a large number of messages in the message queue of the third-party system 300 are abnormal or the requests are overtime, it is possible to automatically perform fusing control on the current data request, increase the waiting time of the messages in the message queue, play a role in buffering the messages, reduce the pressure of the ESB100, and at the same time, it is also possible to timely return preset information to the requester of the current data request, achieve timely response, and improve the experience of the requester of the data request.

Further, the ESB100 may also be used to configure visualization management tools for storing messages and responding to data requests. The visualization management tool may include: mongo dB, mongo boost, admin Mongo.

Further, the ESB100 may also be used to provide distributed application coordination services for providing a registry for KAFKA and dubbo. The distributed application coordination service may be a ZooKeeper component.

In summary, the enterprise service bus system in the dual mode described in the embodiment of the present invention adopts the synchronous processing mechanism of the open source frame dubbo, and combines the asynchronous processing mechanism of the open source processing flow platform KAFKA to convert the synchronous processing mechanism into the asynchronous processing mechanism, so that the ESB not only has the feature of balanced load of dubbo, but also has the buffering function of the message queue of KAFKA, and can dynamically expand capacity and persist messages: messages are persisted to local disk and support data backup to prevent data loss. Secondly, a uniform message format is set, and data requests sent by different data request requesters are converted into uniform messages and request protocols, so that the bottom layer technical difference of a heterogeneous system can be shielded, and the development and management of the data request requesters are facilitated. In addition, a corresponding thread is created according to the messages to be processed in the message queue, and the size of the thread pool is configured, so that the data request server system is effectively prevented from being paralyzed due to pressure caused by the data request server in high concurrency. And the producer and the consumer are deployed independently, and one producer can configure a plurality of consumers to consume the messages to be processed. Finally, a fusing condition is set, when instantaneous high concurrency exceeds ESB processing capacity or when a large number of abnormal requests or requests of a third-party system exceed time, fusing control can be automatically carried out on the current data request, waiting time of the messages in the message queue is prolonged, the message buffering effect is achieved, pressure of the ESB is reduced, meanwhile, preset information can be timely returned to the requester of the current data request, timely response is achieved, and experience degree of the requester of the data request is improved.

Example two

Fig. 2 is a flowchart of a data processing method of an enterprise service bus according to a second embodiment of the present invention. The execution sequence in the flowchart may be changed and some steps may be omitted according to different requirements.

The data processing method of the enterprise service bus provided by the embodiment of the invention can be applied to one or more terminals. The data processing method of the enterprise service bus can also be applied to a hardware environment formed by a terminal and a server connected with the terminal through a network. Networks include, but are not limited to: a wide area network, a metropolitan area network, or a local area network. The data processing method of the enterprise service bus of the embodiment of the invention can be executed by a server or a terminal; or may be performed by both the server and the terminal.

The terminal which needs to perform the data processing method of the enterprise service bus can directly integrate the data processing function of the enterprise service bus provided by the method of the invention on the terminal, or install a client for realizing the method of the invention. For another example, the method provided by the present invention may also be run on a device such as a server in the form of a Software Development Kit (SDK), and an interface of an enterprise service bus architecture function is provided in the form of an SDK, and a terminal or other devices may implement data processing on an enterprise service bus through the provided interface.

And S11, issuing service for the calling of the request party.

In this embodiment, each subsystem in the ESB may issue a service, and each subsystem in the ESB includes: the service issuing protocol comprises an ESB-API, an ESB-PROXY-IN, an ESB-PROXY-OUT and an ESB-FILE-PROXY-OUT, and the issuing service is an issuing service protocol which can comprise: dubbo protocol, http protocol, https protocol.

In this embodiment, the requesting party may be an enterprise system, an ESB, or a third-party system. The enterprise system may include multiple intra-enterprise applications or intra-enterprise file services, and different intra-enterprise applications or intra-enterprise file services may be deployed on different servers. The ESB may be each subsystem in the ESB in the present solution. The third-party system may include a plurality of third-party applications or third-party file services, and different third-party applications or third-party file services may be configured on different servers. The ESB may establish a unique identifier and request concurrency number for different enterprise systems and different third-party systems, for example, establish an identifier "B10047" for a certain bank, and the request concurrency number is 100.

IN this embodiment, the ESB-API publishing service protocol is a dubbo protocol, the format of the service name is "ESB-api.service.xxxxxx _ yyyyyyy", the "XXXXXX" IN the interface name is an identifier of a service party (the enterprise system or the third party system), the "yyyyyyy" IN the interface name is a service name provided by the service party, and the ESB-API publishing service is called by the enterprise system and the ESB-PROXY-IN.

IN this embodiment, the ESB-PROXY-IN publishing service protocol is an http protocol and an https protocol, the format of the service name is "ESB. YYYYYY", the "YYYYYY" IN the interface name is a service name provided by the service party (the enterprise system or the third-party system), and the ESB-PROXY-IN publishing service is called by the third-party system. A service correspondence table is maintained when the ESB-PROXY-IN issues a service, and the service issued by the ESB-PROXY-IN corresponds to the service issued by the ESB-API, for example, the ESB. Customer. Queryrerblist service issued by the ESB-PROXY-IN corresponds to the ESB-API. Service. File 004.Ff. Customer. Queryrerblist service issued by the ESB-API.

In this embodiment, the ESB-PROXY-OUT and ESB-FILE-PROXY-OUT publishing service protocol is a dubbo protocol, the format of the service name is "ESB-proxy.service.xxxxxx _ yyyyyyy", the "XXXXXX" in the interface name is an identifier of a service party (the enterprise system or the third party system), the "YYYYYY" in the interface name is a service name provided by the service party, and the ESB-PROXY-OUT and ESB-FILE-PROXY-OUT publishing service is called by the ESB-API. The service issued by the ESB-PROXY-OUT and the ESB-FILE-PROXY-OUT and the service issued by the ESB-API appear in pairs, for example, ESB-proxy.service.b10043.Query granted interest server service issued by the ESB-PROXY-OUT and ESB-api.service.b10043.Query granted interest server service issued by the ESB-API appear in pairs.

It should be noted that the ESB as the requestor is mainly relative to the subsystems inside the ESB, because there is also a call relationship between the subsystems inside the ESB.

For example: the ESB-PROXY-IN subsystem of the ESB calls other subsystems of the ESB, and the ESB-PROXY-IN subsystem of the ESB calls the ESB-API subsystem of the ESB, wherein the ESB-PROXY-IN subsystem is a requester relative to the ESB-API subsystem.

S12, detecting whether a data request of a requester is received.

The data request of the requester is a data request obtained by encapsulating the data request according to the service issued by the ESB.

In this embodiment, the encapsulating, by the requester, the data request according to the issued service may include:

1) And when the requesting party is an enterprise system, encapsulating the data request according to the dubbo protocol issued by each subsystem of the ESB.

2) And when the requester is a third-party system, encapsulating the data request according to an http protocol or an https protocol issued by each subsystem of the ESB.

The data request is encapsulated by the requester according to the service issued by each subsystem of the ESB, and the requester only needs to encapsulate according to the uniform request message format of the ESB without paying attention to the problem that the request message formats of different service providers are different.

when detecting that the data request of the requester is received, executing step S13; otherwise, it can continue to detect whether the data request of the requesting party is received.

And S13, identifying whether the requester of the data request is legal or not.

In this embodiment, when receiving a data request, the ESB identifies whether a requester of the data request is legal according to the data request. The legality refers to a legal enterprise system or a third-party system which is approved by the ESB or not by the requester, and the enterprise system and the third-party system are systems which are docked by the ESB and establish a unique identifier for the ESB. If the requester does not abort the request properly, the requester performs the subsequent process S14 if the requester is legal.

In this embodiment, the data request may carry a data request source identifier, where the data request source identifier is used to indicate an identity of a requester of the data request. The source identification, namely the unique identification established by the ESB for the system.

And S14, identifying a server of the data request according to the data request.

In this embodiment, when determining that the requester of the data request is a legal requester, the ESB identifies a service provider of the data request according to the data request, where the service provider may be an enterprise system or a third-party system. The enterprise system may include multiple intra-enterprise applications or intra-enterprise file services, and different intra-enterprise applications or intra-enterprise file services may be deployed on different servers. The third-party system may include a plurality of third-party applications or third-party file services, and different third-party applications or third-party file services may be configured on different servers.

In this embodiment, the data request may carry a data request service provider identifier, where the data request service provider identifier is used to indicate an identity of a service provider of the data request. The data request service party identification comprises: the data request service part comprises a first identifier and a second identifier, wherein the first identifier is used for indicating that the data request service part is an enterprise internal application or an enterprise internal file service, and the second identifier is used for indicating that the data request service part is a third party application or a third party file service.

For example, the data request service party identifier in this embodiment may be the "XXXXXX" part in the service name issued by the ESB-API, ESB-PROXY-OUT, ESB-FILE-PROXY-OUT.

S15, encapsulating the data request into corresponding information according to the service party of the request, and sending the encapsulated information to KAFKA by the information producer in ESB-API.

In this embodiment, an Application Programming Interface (API) is a predefined function, and is a service entry of the ESB and a producer of the message.

In this embodiment, encapsulating the data request into a corresponding message according to the service side of the request, and sending the encapsulated message to KAFKA by the message producer in the ESB-API may include:

1) When the receiving system of the data request is the ESB-API, the data request is encapsulated as a message, and the encapsulated message is sent by a message producer in the ESB-API to KAFKA.

2) When the receiving system of the data request is the first proxy server, the data request is packaged into a message and is forwarded to the ESB-API through the first proxy server, and then the message producer in the ESB-API sends the message to KAFKA.

And directly sending the encapsulated message to a KAFKA message queue by a message producer in the ESB-API, wherein the message carries an identification number for indicating the position information of the stored message queue. For example, when the identification number is a, it indicates that the message is stored in the message queue 1, and when the identification number is B, it indicates that the message is stored in the message queue 2. The message queue may be a KAFKA message queue or an in-memory message queue.

The first PROXY server may be an access PROXY server (ESB-PROXY-IN).

The first proxy server may further include a load balancing function (e.g., F5 shown in the figure) for performing load balancing control on the data request of the third-party system. Prevent high concurrency from stressing enterprise systems (e.g., banking systems) and causing paralysis.

S16, when the KAFKA receives the message to be processed sent by the ESB-API, configuring a corresponding message queue according to the message to be processed, and processing the message to be processed.

In this embodiment, KAFKA is a high throughput distributed publish-subscribe messaging system, provides a message queue for the ESB, can process all action flow data in a consumer-scale website, and has the characteristics of high throughput, supporting load balancing, asynchronous sending, and message persistence. When KAFKA detects a message sent by ESB-API, the message to be processed is obtained, a corresponding message queue is configured, and the message to be processed is processed.

The processing the message to be processed may include: storing the message to be processed into a plurality of copies in a distributed manner; when the number of the messages to be processed exceeds a preset number threshold, slicing or dicing each message in the messages to be processed; and compressing the message to be processed. This ensures that pending messages are not lost and are not consumed repeatedly.

In this embodiment, the ESB uses KAFKA as the message queue, has high throughput and message persistence functions, and can well improve the processing capability of the ESB, so that the processing capability of the ESB is controllable, and when the service performance of the ESB is low, the message queue can be used to buffer the information, thereby avoiding the crash.

S17, pulling the message to be processed from the message queue of KAFKA every other preset time period ESB-CONSUMER, and creating a corresponding thread according to the message to be processed.

The ESB-connector may listen every preset period of time (e.g., 200 milliseconds) for messages to be processed in KAFKA, and when the ESB-connector listens for messages to be processed in KAFKA, pull the messages from KAFKA and route to the corresponding proxy server based on the message content.

The ESB establishes corresponding thread pools according to the message queues, one message queue corresponds to one thread pool, each thread pool fixedly consumes the messages to be processed in the corresponding message queue, and different thread pools are not interfered with each other. For example, thread pool 1 is responsible for consuming messages pending in message queue 1 only, and thread pool 2 is responsible for consuming messages pending in message queue 2 only.

Creating thread pools with different sizes according to the request concurrency number preset by the service party, so as to implement different concurrency control according to different data request amounts, for example, the data request amount of an enterprise system is generally small, the request concurrency number preset by the service party (a third-party system) is correspondingly low, and thus the thread pools created by the ESB-connector are also small, for example, 20-50; for another example, the data request volume of the third-party system is generally larger, and the number of the request concurrences configured by the service party (enterprise system) in advance is correspondingly higher, so that the thread pool created by the ESB-manager is larger, for example, 100-150.

And S18, the ESB-CONSUMER analyzes the message to be processed and sends the analyzed content to a service party corresponding to the data request.

In this embodiment, the thread of the ESB-connector may be configured with a configuration table corresponding to the to-be-processed message in advance. The configuration table includes: the system service name, the physical route of the system service, the condition code of the subsequent flow of the system service, the information of the subsequent service corresponding to the condition code and the like required by the completion of the data request. The analysis of the message to be processed is to explain the content in the message by searching the configuration table so as to determine the specific service content and determine the system service name, the system service physical route, the condition code of the subsequent flow, the subsequent service corresponding to the condition code and the like.

In this embodiment, the service party refers to a service person who responds to the data request of the requesting party and provides a corresponding request result according to the data request, and the service party may include: an enterprise system or a third party system. Of course, if the enterprise system includes multiple enterprise subsystems, for example, enterprise subsystem 1, enterprise subsystem 2. The service party may also be one of a plurality of enterprise subsystems. Similarly, if the third-party system includes a plurality of third-party subsystems, for example, the third-party subsystem 1 and the third-party subsystem 2. The service party may also be one of a plurality of third party subsystems. That is, the requesting party and the service party may be enterprise systems at the same time, or may be third-party systems at the same time, for example, when the enterprise subsystem 1 requests to invoke the enterprise subsystem 2, at this time, the enterprise subsystem 1 is the requesting party, and the enterprise subsystem 2 is the service party.

1) And when the service party of the data request is a third-party system, sending the analyzed content to the service party (the third-party system) of the data request through a second proxy server.

The second PROXY server may be an outbound PROXY server (service adapter ESB-PROXY-OUT or service FILE adapter ESB-FILE-PROXY-OUT), and when receiving the analyzed content sent by the thread of the ESB-provider, the second PROXY server forwards the analyzed content to a third-party system. And the ESB-PROXY-OUT is used for receiving the message of the ESB-CONSURER, requesting the third-party system to respond to the data request according to the message in a request mode preset by the third-party system and returning a request result. And the ESB-File-PROXY-OUT is used for receiving an ESB-CONSUMER message, requesting a third-party system according to the message in a request mode preset by the third-party system, and uploading or downloading a FILE corresponding to the data request.

2) And when the service party of the data request is an enterprise system, directly sending the analyzed content to the enterprise system.

And S19, the ESB-CONSUMER acquires a request result sent by a server of the data request and temporarily stores the request result into a message queue of KAFKA.

1) And when the service party of the data request is a third-party system, obtaining the request result from the third-party system through the second proxy server, and temporarily storing the request result into a KAFKA message queue.

2) And when the service side of the data request is an enterprise system, directly obtaining the request result from the enterprise system, and temporarily storing the request result into a KAFKA message queue.

S20, ESB-API obtains the request result from the KAFKA message queue and sends the request result to the requester of the data request.

1) When the requester of the data request is an enterprise system, the ESB-API directly sends the request result to the enterprise system.

2) And when the requester of the data request is a third-party system, the ESB-API sends the request result to the third-party system through the first proxy server.

It should be noted that, whether the enterprise system or the third-party system, the data request may be made from a requester or a server responding to the data request and providing a data request requesting the result. That is, while the enterprise system as a requester of the data request sends the data request to a server (third-party system) of the data request, the enterprise system may also serve as a server of the data request to respond to the data request and provide the request result to the requester (third-party system) of the data request. The third-party system, as a requester of the data request, may respond to the data request as a server of the data request and provide a request result to the requester of the data request (the enterprise system) while sending the data request to the server of the data request (the enterprise system).

Further, when a data request is received, the method may further include: judging whether the current request state meets the fusing condition or not; and when the current request state meets the fusing condition, configuring a first number of message queues, and returning preset information to a requester of the currently received data request. And when the current request state does not meet the fusing condition, configuring a second number of message queues.

The ESB may count the time consumed by each data request, where the time consumed by the data request is the time from the data request sent by the requester receiving the data request to the time when the request result corresponding to the data request is returned to the requester receiving the data request.

The current request state may include a combination of one or more of the following: the time consumed by the current data request; averaging the time consumed by all data requests within a preset time period; the number of messages in the ESB-API message queue; the number of data requests of a requester that receives the same data request.

The fusing conditions may include a combination of one or more of the following: the time consumed by the current data request exceeds the preset time consumed; the average value of the consumed time of all the data requests in the preset time period is greater than or equal to the interface exceeding time; the number of messages in the ESB-API message queue exceeds a preset number; the number of data requests of the requester receiving the same data request exceeds a preset number.

The preset time is a predefined time value. The preset information may be "system traffic is busy, please try again later". The first numerical value is equal to the size value of the thread pool, and the second numerical value is equal to the size value of the thread pool multiplied by the ratio of the interface timeout time value to the average time-consuming time value.

In this embodiment, by presetting the fusing condition, when it is detected that the fusing condition is met, it is possible that an instantaneous high concurrency exceeds the ESB processing capability, for example, when the number of messages in an ESB-API message queue exceeds a preset number, KAFKA and ESB-provider are not in time to process a data request, or when a third-party system is largely abnormal or a request is overtime, fusing control can be automatically performed on a current data request, the waiting time of the messages in the message queue is increased, a message buffering effect is achieved, the pressure of the ESB is reduced, and meanwhile, preset information can be timely returned to a requester of the current data request, so that timely response is achieved, and the experience of the requester of the data request is improved.

Further, the method may further include: and configuring a visual management tool for storing messages and responding to data requests. The visualization management tool may include: mongo dB, mongo boost, admin Mongo.

Further, the method may further include: a distributed application coordination service is provided for providing a registry for KAFKA and dubbo. The distributed application coordination service may be a ZooKeeper component.

In summary, the data processing method for the dual-mode enterprise service bus according to the embodiment of the present invention adopts the synchronous processing mechanism of the open-source framework dubbo, and combines the asynchronous processing mechanism of the open-source processing flow platform KAFKA to convert the synchronous processing mechanism into the asynchronous processing mechanism, so that the ESB not only has the feature of balanced load of dubbo, but also has the buffering function of the message queue of KAFKA, and can dynamically expand capacity and persist messages: messages are persisted to local disk and support data backup to prevent data loss. Secondly, a uniform message format is set, and data requests sent by different data request requesters are converted into uniform messages and request protocols, so that the bottom layer technical difference of a heterogeneous system can be shielded, and the development and management of the data request requesters are facilitated. In addition, a corresponding thread is created according to the messages to be processed in the message queue, and the size of the thread pool is configured, so that the data request server system is effectively prevented from being paralyzed due to pressure caused by a data request server during high concurrency. And the producer and the consumer are independently deployed, and one producer can configure a plurality of consumers to consume the messages to be processed. Finally, a fusing condition is set, when instantaneous high concurrency exceeds ESB processing capacity or when a large number of abnormal requests or requests of a third-party system exceed time, fusing control can be automatically carried out on the current data request, waiting time of the messages in the message queue is prolonged, the message buffering effect is achieved, pressure of the ESB is reduced, meanwhile, preset information can be timely returned to the requester of the current data request, timely response is achieved, and experience degree of the requester of the data request is improved.

The above description is only a specific embodiment of the present invention, but the scope of the present invention is not limited thereto, and it will be apparent to those skilled in the art that modifications may be made without departing from the inventive concept of the present invention, and these modifications are within the scope of the present invention.

EXAMPLE III

Fig. 3 is a schematic diagram of a terminal according to a fifth embodiment of the present invention.

The terminal 3 includes: a memory 31, at least one processor 32, a computer program 33 stored in said memory 31 and executable on said at least one processor 32, and at least one communication bus 34.

The at least one processor 32, when executing the computer program 33, implements the steps in the enterprise service bus data processing method embodiments described above.

Illustratively, the computer program 33 may be partitioned into one or more modules/units, which are stored in the memory 31 and executed by the at least one processor 32 to implement the present invention. The one or more modules/units may be a series of computer program instruction segments capable of performing certain functions, which are used to describe the execution of the computer program 33 in the terminal 3.

The terminal 3 may be a desktop computer, a notebook, a palm computer, a cloud server, or other computing devices. It will be appreciated by those skilled in the art that the schematic diagram 3 is merely an example of the terminal 3 and does not constitute a limitation of the terminal 3, and may include more or less components than those shown, or some components may be combined, or different components, for example, the terminal 3 may further include an input output device, a network access device, a bus, etc.

The at least one Processor 32 may be a Central Processing Unit (CPU), other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components, etc. The processor 32 may be a microprocessor or the processor 32 may be any conventional processor or the like, said processor 32 being the control center of said terminal 3, the various parts of the whole terminal 3 being connected by means of various interfaces and lines.

The memory 31 may be used to store the computer program 33 and/or the modules/units, and the processor 32 may implement various functions of the terminal 3 by running or executing the computer program and/or the modules/units stored in the memory 31 and calling data stored in the memory 31. The memory 31 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application program required by at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may store data (such as audio data, a phonebook, etc.) created according to the use of the terminal 3, and the like. In addition, the memory 31 may include a high speed random access memory, and may also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), at least one magnetic disk storage device, a Flash memory device, or other volatile solid state storage device.

The integrated modules/units of the terminal 3, if implemented in the form of software functional units and sold or used as separate products, may be stored in a computer readable storage medium. Based on such understanding, all or part of the flow of the method according to the embodiments of the present invention may also be implemented by a computer program, which may be stored in a computer-readable storage medium, and when the computer program is executed by a processor, the steps of the method embodiments may be implemented. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U.S. disk, removable hard disk, magnetic diskette, optical disk, computer Memory, read-Only Memory (ROM), random Access Memory (RAM), electrical carrier wave signal, telecommunications signal, and software distribution medium, etc. It should be noted that the computer-readable medium may contain suitable additions or subtractions depending on the requirements of legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer-readable media may not include electrical carrier signals or telecommunication signals in accordance with legislation and patent practice.

In the several embodiments provided in the present invention, it should be understood that the disclosed terminal and method may be implemented in other manners. For example, the above-described terminal embodiments are merely illustrative, and for example, the division of the unit is only one logical function division, and there may be another division manner in actual implementation.

In addition, functional units in the embodiments of the present invention may be integrated into the same processing unit, or each unit may exist alone physically, or two or more units are integrated into the same unit. The integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional module.

It will be evident to those skilled in the art that the invention is not limited to the details of the foregoing illustrative embodiments, and that the present invention may be embodied in other specific forms without departing from the spirit or essential attributes thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Any reference sign in a claim should not be construed as limiting the claim concerned. Furthermore, it is obvious that the word "comprising" does not exclude other elements or that the singular does not exclude the plural. A plurality of units or means recited in the system claims may also be implemented by one unit or means in software or hardware. The terms first, second, etc. are used to denote names, but not to denote any particular order.

Finally, it should be noted that the above embodiments are only intended to illustrate the technical solutions of the present invention and not to limit the same, and although the present invention is described in detail with reference to the preferred embodiments, it should be understood by those skilled in the art that modifications or equivalent substitutions may be made to the technical solutions of the present invention without departing from the spirit of the technical solutions of the present invention.

Claims

1. An enterprise service bus system communicatively coupling a plurality of enterprise systems and a plurality of third party systems, the enterprise service bus system comprising: the KAFKA subsystem is respectively IN communication connection with the ESB-API subsystem and the ESB-CONSUMER subsystem, the ESB-API subsystem is IN communication connection with the ESB-PROXY-IN subsystem, and the ESB-FILE-PROXY-OUT subsystem is respectively IN communication connection with the ESB-PROXY-OUT subsystem and the ESB-FILE-PROXY-OUT subsystem, wherein,

said ESB-API subsystem is further adapted to send said enterprise service bus system encapsulated message from a message producer to said KAFKA subsystem;

the KAFKA subsystem is configured to, when receiving a to-be-processed message sent by the ESB-API subsystem, configure a corresponding message queue according to the to-be-processed message, and process the to-be-processed message, and includes: storing the message to be processed into a plurality of copies in a distributed manner; when the number of the messages to be processed exceeds a preset number threshold, slicing or dicing each message in the messages to be processed; compressing the message to be processed;

the ESB-CONSUMER subsystem is used for pulling the messages to be processed from the message queue of the KAFKA subsystem at intervals of a preset time period, and creating corresponding threads according to the messages to be processed, and comprises the following steps: creating a thread pool with corresponding size according to a request concurrency number corresponding to a server, wherein the request concurrency number is equal to the size of the thread pool;

2. A method for enterprise service bus data processing using the enterprise service bus system of claim 1, the method comprising:

detecting whether a data request of a requester is received;

the ESB-CONSUMER subsystem pulls the message to be processed from the message queue of the KAFKA subsystem every other preset time period, and creates a corresponding thread according to the message to be processed;

and the ESB-API subsystem acquires the request result from the message queue of the KAFKA subsystem and sends the request result to the requester of the data request.

3. The method of claim 2, wherein the requesting data request is a data request encapsulated by the requesting party according to a service agreement published by the enterprise service system, and comprises:

4. The method of claim 2, wherein the identifying a server of the data request from the data request comprises:

and when the data request service party identifier is identified as the second identifier, determining that the data request service party is a third-party system.

5. The method of claim 2, wherein said encapsulating the data request into a corresponding message according to the server of the request and sending the encapsulated message to the KAFKA subsystem by a message producer in the ESB-API subsystem comprises:

when the receiving system of the data request is the ESB-API subsystem, the data request is packaged into a message, and the packaged message is sent to the KAFKA subsystem by a message producer in the ESB-API subsystem;

6. The method of claim 2,

the creating of the corresponding thread according to the message to be processed includes: creating a thread pool with a corresponding size according to the request concurrency number corresponding to the server, wherein the request concurrency number is equal to the size of the thread pool;

the sending the analyzed content to the server corresponding to the data request comprises: when the service party of the data request is the third-party system, the analyzed content is sent to the service party of the data request through the ESB-PROXY-OUT subsystem or the ESB-FILE-PROXY-OUT subsystem; when the service party of the data request is the enterprise system, directly sending the analyzed content to the enterprise system;

the sending the request result to the requester of the data request comprises: when the requester of the data request is the enterprise system, the ESB-API subsystem directly sends the request result to the enterprise system; and when the requester of the data request is the third-party system, the ESB-API subsystem sends the request result to the third-party system through the ESB-PROXY-OUT subsystem or the ESB-FILE-PROXY-OUT subsystem.

7. The method of any of claims 2 to 6, further comprising:

judging whether the current request state meets the fusing condition;

8. The method of claim 7, wherein the fusing condition comprises a combination of one or more of:

The number of messages in the ESB-API subsystem message queue exceeds the preset number; or alternatively

9. A terminal, characterized in that the terminal comprises a processor and a memory, the processor being configured to implement the enterprise service bus data processing method according to any one of claims 2 to 8 when executing a computer program stored in the memory.

10. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the enterprise service bus data processing method according to any one of claims 2 to 8.