Message bus vs Message Queuing

Some time ago to implement a RABBITMQ message bus, the implementation of the process itself is also constantly have to think, summarize and revise. You need to consider the various dimensions: efficiency, performance, network, throughput, and even the ability to envision the possible use of the API scenarios, patterns. But can have one thing, oneself willing to do, walk, eat, take a bus when all thinking how to improve it, and then in the process of practice, prompting to think and dig their knowledge of the blank, is also a happy thing.

Take this record of your own in the process of implementation, as well as some of the usual ideas.

This is the first one to talk about the difference between message bus and Message Queuing, and the need for enterprise-class applications to encapsulate Message Queuing as a message bus.

What is the difference between a message bus and a message queue? If someone asks you this question, what is your answer? If your message bus is based on a fairly mature message queue or message system, do two encapsulation. Why you need to use your client, instead of directly using the original (this is a time when everyone believes in authority, please note that this is a belief, not a superstition, that you really should believe in authority, at least more than you believe a novice, of course, I mean the authority, is the positive meaning).

So I'll talk about my thoughts on this issue from the following points:

Message Queuing Clientapi permissions are too large, CLIENTAPI trust level is too high
Message Queuing Clientapi technology-oriented, message bus CLIENTAPI technology + Business
Message Queuing cannot hide communication details
Message Queuing cannot implement live control
The advantages of the bus: Unified access to simplify interception costs
In order to understand the simple, you have to RABBITMQ as a message queue, in fact it is not just a message queue, some other JMS based Message Queuing to answer this question, also can be established.

(1) Message Queuing CLIENTAPI permission is too large, trust level is too highThis is not just a server-side component of the client driver implementation is the case, the vast majority of these are actually the case, their client is the service-side component (or, call it) protocol translation. Most of these servers carry CommandLine interface (which is almost standard). In fact, the CLI is indistinguishable from the client libraries of the various languages used in the program, and they are client--to server-implemented protocol translations or transformations that are calls to these packaged protocols. So they all have some kind of "management" interface: like Create,delete,remove a component or something like that. Yes, you see the implementations of all the client-led components that contain these APIs (this is not a question of right and wrong, and the client itself is not and should not assume your usage scenario). For example, if you look at Redis's client:jedis--, it even has the FLUSHALL,FLUSHDB function (emptying all redis data) and what it can't do except to shut down the server. In the case of RABBITMQ, its officialnative Java client can create/delete the core components of its communications: Exchange,queue. You can distribute these client directly to each business system without blocking it. You certainly need to do two packages to remove these high-risk managementapi.

(2) Message Queuing CLIENTAPI technology-oriented and message bus CLIENTAPI technology + businessMessage Queuing's clientapi are mostly protocol-oriented, communication-oriented, usability and high-performance, and if categorized as technology-oriented, it will not simulate business scenarios except for communication scenarios. The message bus needs to carry a business scenario to implement the mechanism that needs to be supported.
When you go to search for any message queue, there's one in the advantage: the producer and the consumer Decouple, as follows:

This is indeed the advantage of Message Queuing in terms of producer and consumer models. However, this advantage is also limited to some specific use scenarios, such as: single-service Message Queuing processing. So the common message queue scenario is more applicable to a single responsibility producer and consumer model; The message bus we expect is the communication of messages in every system in the enterprise, focusing on communication. Message Queuing simply provides an implementation mechanism for message traffic (message ordering, message caching, etc.), so the message bus encapsulates a business scenario that is appropriate for message interaction on the technical support provided by Message Queuing.

(3) Message Queuing cannot hide communication details
For system interactions within an enterprise, we want it to be as secure as possible. Data is usually in the queue, so ensuring the security of the data is naturally transformed into secure Message Queuing access: You should never allow unauthorized clients to access queues that should not have been accessed. Unfortunately, the official client of RABBITMQ is not up to this requirement, it wants to access a queue, needs to know the name of the real queue, needs to know its routing path. And in terms of connecting to a queue, we think it provides too much information, but that's no way to do it because its exchange and queue blending mechanisms are very flexible, so you have to provide a routing path called Routingkey. However, if you open this information to the caller to fill it out, it will almost certainly expose the routing mechanism and topology of your service-side exchange and queue. So what we need to do. We need to find a communication mechanism that only needs to know about a proxy node without having to focus on the name of the real queue, and then think of a way to hide its routingkey inside the message bus.

(4) Message Queuing cannot implement real-time controlIf you introduce a message bus between systems within an enterprise, it is clear that access control must be provided. For example, enforce a message size limit on a queue, activate/disable a queue, and so on.
Before we mentioned that Message Queuing is not business-oriented, it does not have to consider the security of data and the security control mechanism of access. And it's almost impossible to reinvent the server implementation of a message queue unless it's based on interceptor/plugin mode. Even if RABBITMQ is a plug-in, but for Erlang such an audience is not a particularly broad language, you go to write it to the plug-in inadvertently will go to the pit, and RABBITMQ official has stated that they do not recommend you to write Plug-ins. Considering the inconvenience, we can only do a fuss on the client. There is no doubt that our real-time control information must still be stored on the service side (it is only a separate server), but the native client obviously does not support this mechanism, so we need to encapsulate the logic code that subscribes to the real-time control information and enforces access controls outside the native Client.

(5) Advantages of the bus: Unified access to simplify interception costsWhether it is a message bus or a service bus, in fact, the so-called bus is the first to be folded and then divergent process. First, from the unified entrance, to complete the necessary unified processing logic, and then divergence, according to routing rules, routing to the various components to deal with. In fact, this is the role of agents: shielding internal details, the external unification of the entrance. On an agent-based basis, we can log all the messages on the message bus (because all messages must be represented by proxy), and if you want to implement a proxy on the route without cutting off the RABBITMQ itself channel, It's basically a tree-shaped topological structure.
written in the last

This article mainly discusses the difference between message bus and message queue. In fact, there are already some mature message queue can be used in the Open box, if you are for Message Queuing to encapsulate a message bus, someone will always think that there is a need. Without these open source message queues, you would have to implement a message bus that is similar to the one on the market (see Posa Volume 4), so Message Queuing is just the basis for implementing the message bus, or its message messagebroker , and the choice is based on some mature messagebroker to develop, can save a lot of work, but also enjoy the stability they provide and community contributions. If you want to see its implementation mechanism now, you can go to GitHub.