CN112114977A - Cross-platform service system docking method and device - Google Patents
Cross-platform service system docking method and device Download PDFInfo
- Publication number
- CN112114977A CN112114977A CN202010771990.4A CN202010771990A CN112114977A CN 112114977 A CN112114977 A CN 112114977A CN 202010771990 A CN202010771990 A CN 202010771990A CN 112114977 A CN112114977 A CN 112114977A
- Authority
- CN
- China
- Prior art keywords
- rabbitmq
- service system
- information
- request information
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 39
- 238000003032 molecular docking Methods 0.000 title claims abstract description 18
- 238000012545 processing Methods 0.000 claims abstract description 15
- 238000012546 transfer Methods 0.000 claims abstract description 15
- 230000008569 process Effects 0.000 claims abstract description 11
- 238000006243 chemical reaction Methods 0.000 claims description 8
- 230000005540 biological transmission Effects 0.000 abstract description 5
- 239000003814 drug Substances 0.000 description 30
- 229940079593 drug Drugs 0.000 description 26
- 238000005516 engineering process Methods 0.000 description 4
- 230000003993 interaction Effects 0.000 description 4
- 230000000694 effects Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 238000004590 computer program Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 238000004891 communication Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000008570 general process Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000002688 persistence Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/547—Messaging middleware
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Telephonic Communication Services (AREA)
Abstract
The invention provides a cross-platform service system docking method and a device, wherein the method comprises the following steps: the first service system transmits the request information to the second service system for processing through a first RabbitMQ transmitter, an A-B message queue and a second RabbitMQ receiver of the self system in sequence; and the second service system receives the request information, processes the request information and then transfers the processed information to the first service system through a second RabbitMQ transmitter, a B-A message queue and a first RabbitMQ receiver of the self system in sequence, thereby completing the message intercommunication between the first service system and the second service system. The invention uses the message middleware as the message transmission medium between different service systems to realize the information transmission between different service systems.
Description
Technical Field
The invention relates to the technical field of computers, in particular to a cross-platform business system docking method and device.
Background
Under the large environment of the global Internet, various industries in various fields are connected with the Internet, and a large number of Internet products are bred. Under the rapid development of the internet, the technology is continuously and rapidly updated, and the internet products are also continuously and rapidly iterated. Internet products in the industry are more and more, and the difficulty of message interaction between products is greatly increased due to the fact that the used technology and the applied system are different among the products.
A large number of service systems may be applied in a user organization, but the interaction of messages between the service systems cannot be realized through a simple programming language due to the difference of the programming language or the deployment system. Taking the outpatient system and the medicine system of a hospital institution as an example, the detailed information of the hospital system is as follows:
| name of service system | Programming language | Deployment system | Deployment time |
| Outpatient service system | C# | Windows | 2.1/month/2003 |
| Medicine system | Java | Linux | 4 month and 1 day of 2018 |
As can be seen from the above table, the outpatient system is a business system written in 2003 using the C # programming language and is deployed on the Windows operating system. The medicine system is a business system written in 2018 by using Java programming language and is deployed on a Linux operating system. Both business systems are due to time. Resulting in inconsistencies in both the programming languages used and the deployment environments of the two business systems. However, the two service systems need to communicate messages with each other, such as: a doctor needs to select medicines in a medicine system from an outpatient service system as a patient medical order; the patient needs to take the medication in the drug system with a medication order from the doctor. However, it is difficult to solve this problem directly at the level of the programming language.
Therefore, the invention provides a solution for solving the problem of cross-system and cross-platform, so that the service systems of different systems or platforms can realize message intercommunication.
Disclosure of Invention
The technical problem to be solved by the present invention is to provide a cross-platform service system docking method and apparatus, which uses a message middleware as a message transmission medium between different service systems to implement information transfer between different service systems.
In a first aspect, the present invention provides a cross-platform service system docking method, which is applied to a first service system and a second service system belonging to different platforms, and includes the following steps:
s1, the first service system transmits the request information to a first RabbitMQ transmitter of the system;
s2, the first RabbitMQ sender sends the request information to an A-B message queue;
s3, the A-B message queue receives the request message and sends the request message to a second RabbitMQ receiver of a second service system according to the configuration information of the exchanger;
s4, the second RabbitMQ receiver receives the request information and transfers the request information to a second service system for processing;
s5, the second service system receives the request information, processes the request information and sends the processed information to a second RabbitMQ sender of the system;
s6, the second RabbitMQ sender sends the processed information to a B-A message queue;
s7, the B-A message queue receives the processed information and sends the processed information to a first RabbitMQ receiver of a first service system according to the configuration information of the exchanger;
and S8, after receiving the processed information, the first RabbitMQ receiver transfers the processed information to the first service system.
In a second aspect, the present invention provides a cross-platform service system docking apparatus, which is characterized in that: the system is applied to a first service system and a second service system which belong to different platforms, and comprises the following modules:
the first RabbitMQ transmitter is subordinate to the first service system and used for transmitting request information of the first service system to an A-B message queue;
the A-B message queue is used for receiving the request information forwarded by the first RabbitMQ transmitter and transmitting the request information to a second RabbitMQ receiver according to the configuration information of the switch;
the second RabbitMQ receiver is subordinate to the second service system and used for receiving the request information forwarded by the A-B message queue and transferring the request information to the second service system for processing;
the second RabbitMQ transmitter receives the processed information of the second service system and forwards the processed information to the B-A message queue;
and the B-A message queue is used for receiving the processed information forwarded by the second RabbitMQ sender and transferring the processed information to the first service system through the first RabbitMQ receiver according to the configuration information of the exchanger.
One or more technical solutions provided in the embodiments of the present invention have at least the following technical effects or advantages: according to the principle of a message middleware RabbitMQ, a RabbitMQ transmitter and a RabbitMQ receiver are arranged on different service systems, a transfer server is deployed to operate message queues interacted between the two systems, the service system of a requester forwards messages to the corresponding message queues through the RabbitMQ transmitter of the requester, and the message queues forward the messages to the RabbitMQ receiver of the service system of a receiver according to the configuration of a switch, so that message intercommunication between the different service systems is completed. And the RabbitMQ message middleware supports all mainstream operating systems and all mainstream programming languages at present. It is very convenient to add a transmitter and a receiver for the old and new systems.
The foregoing description is only an overview of the technical solutions of the present invention, and the embodiments of the present invention are described below in order to make the technical means of the present invention more clearly understood and to make the above and other objects, features, and advantages of the present invention more clearly understandable.
Drawings
The invention will be further described with reference to the following examples with reference to the accompanying drawings.
FIG. 1 is a schematic block diagram of the system of the present invention;
FIG. 2 is a flow chart of a method according to one embodiment of the present invention;
FIG. 3 is a flow chart of a method applied to a hospital outpatient system and a drug system according to an embodiment of the present invention;
fig. 4 is a flowchart after the method implements the cluster policy in the second embodiment of the present invention;
fig. 5 is a flowchart after the method of the third embodiment of the present invention broadcasts a message;
fig. 6 is a flowchart illustrating a method according to a fourth embodiment of the present invention when a message format conversion function is used;
FIG. 7 is a flowchart illustrating a method according to a fifth embodiment of the present invention when queue intelligence is preferred;
fig. 8 is a block diagram of a device according to a sixth embodiment of the present invention.
Detailed Description
The embodiment of the application provides a cross-platform service system docking method and device, and realizes information transfer between different service systems by using a message middleware as a message transmission medium between the different service systems.
The technical scheme in the embodiment of the application has the following general idea: according to the principle of a message middleware RabbitMQ, a RabbitMQ transmitter and a RabbitMQ receiver are arranged on different service systems, a transfer server is deployed to operate message queues interacted between the two systems, the service system of a requester forwards messages to the corresponding message queues through the RabbitMQ transmitter of the requester, and the message queues forward the messages to the RabbitMQ receiver of the service system of a receiver according to the configuration of a switch, so that message intercommunication between the different service systems is completed.
The message middleware RabbitMQ is an open-source message transmission middleware which implements the AMQP protocol. Written using the Erlang language. Erlang is a concurrency oriented language. Therefore, under a large concurrent environment, the RabbtiMQ can freely respond. The RabbitMQ consists of a switch, a message queue and a message, the message is distributed to the appointed message queue through the switch, and the message queue transmits the message to the service system. RabbitMQ supports all mainstream systems today, as follows:
RabbitMQ supports all current mainstream programming languages, as follows:
| Python | Java | Ruby | PHP | C# | JavaScript | GO | Elixir | Objective-C | Swoft |
the message middleware RabbitMQ is a stand-alone application that can be deployed into any system. It is irrelevant to the programming language and deployment system of the drug system and the outpatient system. The message middleware RabbitMQ is only responsible for sending received messages to the destination and does not care what system the messages are sent from and what the form of the messages are. This feature fully meets the current requirements for information transfer between the outpatient system and the pharmaceutical system.
In addition, before describing the specific embodiment, a system framework corresponding to the method of the embodiment of the present application is described, as shown in fig. 1, the system is roughly divided into several parts:
the first server is used for deploying a first service system, and the first service system comprises a first RabbitMQ transmitter and a first RabbitMQ receiver and is used for transmitting information to an external system and receiving information from the external system;
the second server is used for deploying a second service system, and the second service system is an external system of the first service system; and includes a second RabbitMQ transmitter and a second RabbitMQ receiver for transmitting information to and receiving information from the external system;
the relay server is used for deploying the exchanger, an A-B message queue and a B-A message queue, the A-B message queue is used for forwarding the message of the first RabbitMQ sender to the second RabbitMQ receiver, the B-A message queue is used for forwarding the message of the second RabbitMQ sender to the first RabbitMQ receiver, A refers to the first service system, and B refers to the second service system.
Example one
As shown in fig. 2, this embodiment provides a cross-platform service system docking method, which is applied to a first service system and a second service system that belong to different platforms, and includes the following steps:
s1, the first service system transmits the request information to a first RabbitMQ transmitter of the system;
s2, the first RabbitMQ sender sends the request information to an A-B message queue;
s3, the A-B message queue receives the request message and sends the request message to a second RabbitMQ receiver of a second service system according to the configuration information of the exchanger;
s4, the second RabbitMQ receiver receives the request information and transfers the request information to a second service system for processing;
s5, the second service system receives the request information, processes the request information and sends the processed information to a second RabbitMQ sender of the system;
s6, the second RabbitMQ sender sends the processed information to a B-A message queue;
s7, the B-A message queue receives the processed information and sends the processed information to a first RabbitMQ receiver of a first service system according to the configuration information of the exchanger;
and S8, after receiving the processed information, the first RabbitMQ receiver transfers the processed information to the first service system.
As shown in fig. 3, when the embodiment is applied to the interaction between the outpatient system and the drug system in a hospital, a doctor selects the drugs in the drug system in the outpatient system as a patient order, and the patient needs to take the drugs in the drug system by using the drug order, the outpatient system is equivalent to a first system, and the drug system is equivalent to a second system. The configuration information of the switch establishes a communication link between the outpatient system and the drug system.
Example two
As shown in fig. 4, the second embodiment is a better implementation of the second embodiment: namely, the second service system implements a cluster strategy and has a plurality of sub-service systems which are respectively deployed on a plurality of servers, so as to reduce the pressure of a single service system. However, in the example of the hospital, if the drug system implements a clustering strategy and is deployed on multiple servers, the drug information request sent by the outpatient service system is acquired by the receivers of multiple drug systems, so that multiple drug information is returned. This loses the meaning of cluster deployment. Thus, we can identify the business system of the cluster by the message queue support route key (routeKey) of the RabbitMQ.
The specific method comprises the following steps: the message queues of the second service system are bound to the same switch through the same routing key, and the first RabbitMQ sender and the first RabbitMQ receiver automatically classify the message queues of the same routing key into the same service system, and invoke the sub-service systems of the second service system according to the polling rule, so that steps S2 to S6 in the first embodiment may be replaced with steps S2 to S6:
s2, the RabbitMQ transmitter of the first service system transmits the request information carrying route key information (routeKey) to an A-B message queue;
s3, the A-B message queue receives the request information and the routing key information, polls according to the routing key information and a polling rule, and sends the request information to a RabbitMQ receiver of a corresponding sub-service system;
s4, the RabbitMQ receiver of the sub-service system receives the request information and transfers the request information to the corresponding sub-service system for processing;
s5, the sub-service system receives the request information, processes the request information and sends the processed information to a RabbitMQ sender of the sub-service system;
and S6, the RabbitMQ sender of the sub-service system sends the processed information to a B-A message queue.
The polling rule can be defined by itself according to actual conditions, and the polling rule in fig. 4 is an average rule to ensure that the chances of information interaction of each sub-service system are equal, so as to avoid that the pressure of a single service system is too high due to repeated calling of only a single service system.
EXAMPLE III
Except for point-to-point service system messaging. There may also be a single business system that needs to send messages to multiple business systems. For example, when a hospital outpatient system issues a drug order, the outpatient system notifies the order system to generate a consumption detailed order in addition to notifying the drug system. RabbitMQ message middleware supports message broadcasting to multiple message queues. The switch may be set to fanout (broadcast mode) upon binding the queue of messages to be broadcast to the switch. I.e. adding the drug system and the order system to the same fanout mode switch. The outpatient system sends messages to the switch drug system and the order system receives messages.
As shown in fig. 5, the third embodiment is a more preferred implementation of the first embodiment: that is, when the first service system needs to send a message to a plurality of second service systems, the switch is configured to be in the broadcast mode, the message queue needing to be broadcast is bound to the switch, and the plurality of second service systems are added to the switch at the same time, then steps S2 to S3 in the first embodiment are replaced with:
s2, the RabbitMQ sender of the first service system sends the request information to a plurality of A-B message queues bound to the switch;
and S3, after receiving the request information, the A-B message queues send the request information to the corresponding RabbitMQ receiver of the second service system according to the configuration information of the exchanger.
Example four
Any one business system or application cannot guarantee that no problem will occur in the production environment. The same R message middleware abbit mq cannot avoid the application terminating service caused in some situations such as network outage and the like. The message middleware RabbitMQ acts as a message queue, wherein the most important is the task messages of different service systems in the message queue. The message middleware RabbitMQ supports persistence of messages and message queues. The message and the contents of the message queue are written to disk. Messages and message queues may be configured to be set to persistent mode. Once the message middleware RabbitMQ is disconnected from the network and the power is cut off, and the like. And after restarting the message middleware RabbitMQ, recovering the persistent messages and the message queues in the disk.
The fourth embodiment is a more preferable implementation manner of the first to third embodiments:
in step S3, the a-B message queue receives the request information, writes the request information and the queue content into a disk of a local server, and reads the request information and the queue content from the disk to continue sending when the network is recovered due to an unexpected interruption;
in step S7, the B-a message queue receives the processed information, writes the processed information and the queue content into a disk of a local server, and reads the request information and the queue content from the disk to continue sending when the network is recovered due to an unexpected interruption.
EXAMPLE five
There are many kinds of data formats transmitted, such as JSON, XML, etc., and there are differences in data formats received by services in different business systems. When the interactive data formats between the service systems are inconsistent, it is very troublesome to modify the service codes of the service systems. We can modify the format conversion type of the transmitter or receiver to handle this problem. As shown in fig. 6, taking the outpatient system and the drug system of the hospital as an example:
the data format of the outpatient system for sending and receiving is XML, and the data format of the medicine system for sending and receiving is JSON. The format conversion type of the transmitter of the outpatient system can be modified to be XML- > JSON, and the transmitter can automatically convert the data format of the XML into the JSON format and transmit the JSON format to a specified receiver. Neither the transmitter nor the receiver of the drug system is modified. The outpatient system receiver receives the data in JSON format. The format conversion type of the outpatient system receiver is modified to JSON- > XML. The receiver will process the data format as XML. The service codes in the outpatient system can be executed seamlessly without modification.
The same effect can be achieved by modifying only the receiver and transmitter of the drug system without modifying the receiver and transmitter of the outpatient system. When the service system has special data format requirement, the conversion logic of data format can be written according to the interface specification of the transmitter or receiver to realize self-defining the transmitter or receiver.
The general process is as follows:
when the data formats of the information interacted between the first service system and the second service system are inconsistent, the first RabbitMQ transmitter or the first RabbitMQ receiver or the second RabbitMQ receiver of the two interacting parties convert the data formats of the interacted information and then continuously transmit the interacted information.
EXAMPLE six
There are many business services in the business system, and a complex business requires hundreds of business services to provide support. These services may not be deployed in the same business system due to time or technology. Then the service request needs to be passed through the message queue to process the service data. When business services like robbery of purchases, ticket robbery and the like need to process a large number of requests. Multiple queues may be set up for the business service. Then there are multiple queues to choose from when the switch receives the requested data. This time the queue intelligence preferred feature is enabled.
Intelligence is preferably determined primarily by 3 factors:
the number of successful tasks in the historical queue, the number of tasks successfully consumed in the queue;
the number of tasks currently queued in the queue, and the number of tasks to be consumed in the queue;
average processing speed of the queue task, and the average time spent by one task successfully consumes in the queue.
Therefore, as shown in fig. 7, when the first business system has a plurality of business services, each business service corresponds to one a-B message queue, when the switch receives the request information of the first business system, the queue intelligent preference function is enabled to select the a-B message queue, and the priority is arranged from high to low: the queue task processing speed is high.
Based on the same inventive concept, the application also provides a device corresponding to the method in the first embodiment, which is detailed in the seventh embodiment.
EXAMPLE seven
As shown in fig. 8, in this embodiment, a cross-platform service system docking apparatus is provided, which is applied to a first service system and a second service system belonging to different platforms, and includes the following modules:
the first RabbitMQ transmitter is subordinate to the first service system and used for transmitting request information of the first service system to an A-B message queue;
the A-B message queue is used for receiving the request information forwarded by the first RabbitMQ transmitter and transmitting the request information to a second RabbitMQ receiver according to the configuration information of the switch;
the second RabbitMQ receiver is subordinate to the second service system and used for receiving the request information forwarded by the A-B message queue and transferring the request information to the second service system for processing;
the second RabbitMQ transmitter receives the processed information of the second service system and forwards the processed information to the B-A message queue;
and the B-A message queue is used for receiving the processed information forwarded by the second RabbitMQ sender and transferring the processed information to the first service system through the first RabbitMQ receiver according to the configuration information of the exchanger.
Similarly, as one or more preferred implementations of the seventh embodiment, the apparatus of the sixth embodiment may be further optimized, specifically see the eighth to twelfth embodiments:
example eight
If the second service system implements a cluster policy and has a plurality of sub-service systems, which are respectively deployed on a plurality of servers, the message queues of the second service system are bound on the same switch through the same routing key, and the first RabbitMQ transmitter, the second RabbitMQ transmitter, the first RabbitMQ receiver and the second RabbitMQ receiver automatically classify the message queues of the same routing key into the same service system, and call the sub-service systems of the second service system according to a polling rule, then:
the first RabbitMQ transmitter simultaneously carries routing key information when forwarding the request information; and the A-B message queue polls according to the routing key information and a polling rule, so that the request information is sent to a second RabbitMQ receiver of the corresponding sub-service system.
Example nine
If the first service system needs to send the message to a plurality of second service systems, configuring the switch into a broadcast mode, binding a message queue needing to be broadcast to the switch, and adding the plurality of second service systems to the switch at the same time, then:
the first RabbitMQ sender sends the request message to a plurality of A-B message queues bound to the switch;
and after receiving the request information, the A-B message queues send the request information to corresponding second RabbitMQ receivers according to the configuration information of the exchanger.
Example ten
The A-B message queue receives the request information, writes the request information and queue content into a disk of a local server, and reads the request information and the queue content from the disk to continue sending when the network is recovered due to unexpected interruption;
and the B-A message queue receives the processed information, writes the processed information and the queue content into a disk of a local server, and reads the request information and the queue content from the disk to continue sending when the network is recovered due to unexpected interruption.
EXAMPLE eleven
When the data formats of the information interacted between the first service system and the second service system are inconsistent, the RabbitMQ transmitter or the RabbitMQ receiver of the two interacting parties carries out data format conversion on the interacted information and then continues to forward the information.
Example twelve
There are many business services in the business system, and a complex business requires hundreds of business services to provide support. These services may not be deployed in the same business system due to time or technology. Then the service request needs to be passed through the message queue to process the service data. When business services like robbery of purchases, ticket robbery and the like need to process a large number of requests. Multiple queues may be set up for the business service. Then there are multiple queues to choose from when the switch receives the requested data. This time the queue intelligence preferred feature is enabled.
Intelligence is preferably determined primarily by 3 factors:
the number of successful tasks in the historical queue, the number of tasks successfully consumed in the queue;
the number of tasks currently queued in the queue, and the number of tasks to be consumed in the queue;
average processing speed of the queue task, and the average time spent by one task successfully consumes in the queue.
When the first business system has a plurality of business services, each business service corresponds to one A-B message queue, when the switch receives request information of the first business system, the intelligent priority function of the queue is enabled to select the A-B message queue, and the priority is arranged from high to low: the queue task processing speed is high.
Since the apparatuses described in the seventh to twelfth embodiments of the present invention are apparatuses used for implementing the methods in the first to sixth embodiments of the present invention, those skilled in the art can understand the specific structure and modifications of the apparatuses based on the method described in the first embodiment of the present invention, and thus the details are not described herein again. All the devices adopted in the method of the first embodiment of the present invention belong to the protection scope of the present invention.
The technical scheme provided in the embodiment of the application at least has the following technical effects or advantages: according to the principle of a message middleware RabbitMQ, a RabbitMQ transmitter and a RabbitMQ receiver are arranged on different service systems, a transfer server is deployed to operate message queues interacted between the two systems, the service system of a requester forwards messages to the corresponding message queues through the RabbitMQ transmitter of the requester, and the message queues forward the messages to the RabbitMQ receiver of the service system of a receiver according to the configuration of a switch, so that message intercommunication between the different service systems is completed. And the RabbitMQ message middleware supports all mainstream operating systems and all mainstream programming languages at present. It is very convenient to add a transmitter and a receiver for the old and new systems.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, apparatus or system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
Although specific embodiments of the invention have been described above, it will be understood by those skilled in the art that the specific embodiments described are illustrative only and are not limiting upon the scope of the invention, and that equivalent modifications and variations can be made by those skilled in the art without departing from the spirit of the invention, which is to be limited only by the appended claims.
Claims (10)
1. A cross-platform service system docking method is characterized in that: the method is applied to a first service system and a second service system which belong to different platforms, and comprises the following steps:
s1, the first service system transmits the request information to a first RabbitMQ transmitter of the system;
s2, the first RabbitMQ sender sends the request information to an A-B message queue;
s3, the A-B message queue receives the request message and sends the request message to a second RabbitMQ receiver of a second service system according to the configuration information of the exchanger;
s4, the second RabbitMQ receiver receives the request information and transfers the request information to a second service system for processing;
s5, the second service system receives the request information, processes the request information and sends the processed information to a second RabbitMQ sender of the system;
s6, the second RabbitMQ sender sends the processed information to a B-A message queue;
s7, the B-A message queue receives the processed information and sends the processed information to a first RabbitMQ receiver of a first service system according to the configuration information of the exchanger;
and S8, after receiving the processed information, the first RabbitMQ receiver transfers the processed information to the first service system.
2. The cross-platform business system docking method according to claim 1, wherein: if the second service system implements a cluster policy and has a plurality of sub-service systems, which are respectively deployed on a plurality of servers, the message queues of the second service system are bound on the same switch through the same routing key, and the first RabbitMQ transmitter, the second RabbitMQ transmitter, the first RabbitMQ receiver, and the second RabbitMQ receiver automatically classify the message queues of the same routing key into the same service system, and invoke the sub-service systems of the second service system according to a polling rule, then steps S2 to S6 are replaced with steps S6:
s2, the RabbitMQ sender of the first service system sends the request information carrying the routing key information to an A-B message queue;
s3, the A-B message queue receives the request information and the routing key information, polls according to the routing key information and a polling rule, and sends the request information to a RabbitMQ receiver of a corresponding sub-service system;
s4, the RabbitMQ receiver of the sub-service system receives the request information and transfers the request information to the corresponding sub-service system for processing;
s5, the sub-service system receives the request information, processes the request information and sends the processed information to a RabbitMQ sender of the sub-service system;
and S6, the RabbitMQ sender of the sub-service system sends the processed information to a B-A message queue.
3. The cross-platform business system docking method according to claim 1, wherein:
if the first service system needs to send the message to a plurality of second service systems, configuring the switch in a broadcast mode, binding the message queue needing to be broadcast to the switch, and adding a plurality of second service systems to the switch, then the steps S2 to S3 are replaced by:
s2, the RabbitMQ sender of the first service system sends the request information to a plurality of A-B message queues bound to the switch;
and S3, after receiving the request information, the A-B message queues send the request information to the corresponding RabbitMQ receiver of the second service system according to the configuration information of the exchanger.
4. A cross-platform business system interfacing method according to any one of claims 1 to 3, wherein:
in step S3, the a-B message queue receives the request information, writes the request information and the queue content into a disk of a local server, and reads the request information and the queue content from the disk to continue sending when the network is recovered due to an unexpected interruption;
in step S7, the B-a message queue receives the processed information, writes the processed information and the queue content into a disk of a local server, and reads the request information and the queue content from the disk to continue sending when the network is recovered due to an unexpected interruption.
5. A cross-platform business system interfacing method according to any one of claims 1 to 3, wherein:
when the data formats of the information interacted between the first service system and the second service system are inconsistent, the first RabbitMQ transmitter or the first RabbitMQ receiver or the second RabbitMQ receiver of the two interacting parties carry out data format conversion on the interacted information and then continue to forward the information;
when the first business system has a plurality of business services, each business service corresponds to one A-B message queue, when the switch receives request information of the first business system, the intelligent priority function of the queue is enabled to select the A-B message queue, and the priority is arranged from high to low: the queue task processing speed is high.
6. A cross-platform service system docking device is characterized in that: the system is applied to a first service system and a second service system which belong to different platforms, and comprises the following modules:
the first RabbitMQ transmitter is subordinate to the first service system and used for transmitting request information of the first service system to an A-B message queue;
the A-B message queue is used for receiving the request information forwarded by the first RabbitMQ transmitter and transmitting the request information to a second RabbitMQ receiver according to the configuration information of the switch;
the second RabbitMQ receiver is subordinate to the second service system and used for receiving the request information forwarded by the A-B message queue and transferring the request information to the second service system for processing;
the second RabbitMQ transmitter receives the processed information of the second service system and forwards the processed information to the B-A message queue;
and the B-A message queue is used for receiving the processed information forwarded by the second RabbitMQ sender and transferring the processed information to the first service system through the first RabbitMQ receiver according to the configuration information of the exchanger.
7. The cross-platform business system docking device of claim 6, wherein: if the second service system implements a cluster policy and has a plurality of sub-service systems, which are respectively deployed on a plurality of servers, the message queues of the second service system are bound on the same switch through the same routing key, and the first RabbitMQ transmitter, the second RabbitMQ transmitter, the first RabbitMQ receiver and the second RabbitMQ receiver automatically classify the message queues of the same routing key into the same service system, and call the sub-service systems of the second service system according to a polling rule, then:
the first RabbitMQ transmitter simultaneously carries routing key information when forwarding the request information; and the A-B message queue polls according to the routing key information and a polling rule, so that the request information is sent to a second RabbitMQ receiver of the corresponding sub-service system.
8. The cross-platform business system docking device of claim 6, wherein:
if the first service system needs to send the message to a plurality of second service systems, configuring the switch into a broadcast mode, binding a message queue needing to be broadcast to the switch, and adding the plurality of second service systems to the switch at the same time, then:
the first RabbitMQ sender sends the request message to a plurality of A-B message queues bound to the switch;
and after receiving the request information, the A-B message queues send the request information to corresponding second RabbitMQ receivers according to the configuration information of the exchanger.
9. The cross-platform business system docking device according to any one of claims 6 to 8, wherein:
the A-B message queue receives the request information, writes the request information and queue content into a disk of a local server, and reads the request information and the queue content from the disk to continue sending when the network is recovered due to unexpected interruption;
and the B-A message queue receives the processed information, writes the processed information and the queue content into a disk of a local server, and reads the request information and the queue content from the disk to continue sending when the network is recovered due to unexpected interruption.
10. The cross-platform business system docking device according to any one of claims 6 to 8, wherein:
when the data formats of the information interacted between the first service system and the second service system are inconsistent, the RabbitMQ transmitter or the RabbitMQ receiver of the two interacting parties carries out data format conversion on the interacted information and then continues to forward the information;
when the first business system has a plurality of business services, each business service corresponds to one A-B message queue, when the switch receives request information of the first business system, the intelligent priority function of the queue is enabled to select the A-B message queue, and the priority is arranged from high to low: the queue task processing speed is high.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010771990.4A CN112114977A (en) | 2020-08-04 | 2020-08-04 | Cross-platform service system docking method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010771990.4A CN112114977A (en) | 2020-08-04 | 2020-08-04 | Cross-platform service system docking method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112114977A true CN112114977A (en) | 2020-12-22 |
Family
ID=73799128
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010771990.4A Pending CN112114977A (en) | 2020-08-04 | 2020-08-04 | Cross-platform service system docking method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112114977A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115086419A (en) * | 2022-07-24 | 2022-09-20 | 浙江大学 | Message mechanism-based cross-three-party system message transmission center system |
| CN117411845A (en) * | 2023-12-14 | 2024-01-16 | 四川桃子健康科技股份有限公司 | Online diagnosis and treatment chat message processing method and medical aggregation system |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107066265A (en) * | 2017-03-15 | 2017-08-18 | 杭州华澜微电子股份有限公司 | The interconnecting method and system of different programming languages |
| CN107302476A (en) * | 2017-08-04 | 2017-10-27 | 上海爱数信息技术股份有限公司 | A kind of automated testing method and system for testing asynchronous interactive system |
| CN109471710A (en) * | 2018-10-25 | 2019-03-15 | 网易（杭州）网络有限公司 | Processing method, device, processor, terminal and the server of task requests |
| CN110086888A (en) * | 2019-05-15 | 2019-08-02 | 上海淇毓信息科技有限公司 | More cluster dynamic load methods, device, electronic equipment based on RabbitMQ |
| CN111198923A (en) * | 2020-01-08 | 2020-05-26 | 北京仿真中心 | Data synchronization method and system based on message queue |
-
2020
- 2020-08-04 CN CN202010771990.4A patent/CN112114977A/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107066265A (en) * | 2017-03-15 | 2017-08-18 | 杭州华澜微电子股份有限公司 | The interconnecting method and system of different programming languages |
| CN107302476A (en) * | 2017-08-04 | 2017-10-27 | 上海爱数信息技术股份有限公司 | A kind of automated testing method and system for testing asynchronous interactive system |
| CN109471710A (en) * | 2018-10-25 | 2019-03-15 | 网易（杭州）网络有限公司 | Processing method, device, processor, terminal and the server of task requests |
| CN110086888A (en) * | 2019-05-15 | 2019-08-02 | 上海淇毓信息科技有限公司 | More cluster dynamic load methods, device, electronic equipment based on RabbitMQ |
| CN111198923A (en) * | 2020-01-08 | 2020-05-26 | 北京仿真中心 | Data synchronization method and system based on message queue |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115086419A (en) * | 2022-07-24 | 2022-09-20 | 浙江大学 | Message mechanism-based cross-three-party system message transmission center system |
| CN117411845A (en) * | 2023-12-14 | 2024-01-16 | 四川桃子健康科技股份有限公司 | Online diagnosis and treatment chat message processing method and medical aggregation system |
| CN117411845B (en) * | 2023-12-14 | 2024-03-29 | 四川桃子健康科技股份有限公司 | Medical treatment polymerization system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7383355B1 (en) | Systems and methods for providing centralized management of heterogeneous distributed enterprise application integration objects | |
| JP2020533892A (en) | Internet of Things Resources Subscription Methods, Devices, and Systems | |
| CN112069265B (en) | Synchronization method of configuration data, business data system, computer system and medium | |
| US20100082748A1 (en) | System and Method for Improving Scalability and Throughput of a Publish/Subscribe Network | |
| CN101917394B (en) | Middleware system for sharing data in mobile phone equipment and working method | |
| CN112114977A (en) | Cross-platform service system docking method and device | |
| US10938868B2 (en) | Application service integration | |
| US20120117186A1 (en) | Dds structure with scalability and adaptability and node constituting the same | |
| CN104579905A (en) | Message passing method and system, MOM (message oriented middleware) server and receiving terminal | |
| CN112217847A (en) | Micro service platform, implementation method thereof, electronic device and storage medium | |
| CN105528254A (en) | Business processing method and apparatus | |
| US7325060B2 (en) | Management system for hardware network devices | |
| EP1332430A2 (en) | Sytems and methods for providing centralized management of heterogeneous distributed enterprise application integration objects | |
| CN114217921A (en) | Distributed parallel computing method, computing device and storage medium | |
| US6370590B1 (en) | Method and apparatus for providing inter-application program communication using a common view | |
| US20170048081A1 (en) | Multi-ring reliable messaging system | |
| CN102054213A (en) | Information integration method, device and system | |
| US8316083B2 (en) | System and method for client interoperability | |
| CN201854301U (en) | Middleware system for sharing data on mobile phones | |
| CN107193663A (en) | A kind of service message processing method and device | |
| US20100250684A1 (en) | High availability method and apparatus for shared resources | |
| CN107395765B (en) | Distributed file system, network communication method, platform and creation method thereof | |
| CN101795237A (en) | Workflow integration method and device based on data exchange | |
| CN107306290B (en) | Session sharing method and application server | |
| CN113301088B (en) | Message processing method, device and system, electronic equipment and readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |