In the above , I mainly introduced the concept of SOA, what is called a "service", and what characteristics the "service" should have. In this article, I will introduce a very common design practice of SOA-service bus-based design.
Design based on service bus
The design based on the bus draws on the design idea of the internal hardware composition of the computer (data transmission through the bus). In a distributed system, different subsystems need to communicate with each other and remotely call. The more direct way is the "point-to-point" communication method, but this will expose some obvious problems: tight coupling, configuration and Confusing references, intricate service call relationships, difficulty in unified management, and incompatibility between heterogeneous systems. The bus-based design is precisely to solve the above problems. The bus, as the central system, provides a unified service portal, and realizes functions such as unified service management, service routing, protocol conversion, and data format conversion. This can effectively connect different systems and greatly reduce the number of connections (each subsystem only needs to establish a connection with the bus) and the complexity of the connection topology between systems. as the picture shows:
The design based on the service bus often requires ESB (Enterprise Service Bus) products to act as the infrastructure. ESB adopts a model of "bus" to manage and simplify the integration topology between applications, and is based on widely accepted open standards to support dynamic interconnection between applications at the level of messages, events and services . ESB is a standard way of integration between loosely coupled services and applications.
In its internal design and implementation, some classic architecture patterns are usually applied, such as: Broker pattern, message bus pattern, pipeline filter pattern, publish and subscribe pattern, etc. Here, we will focus on these core architectural patterns.
Broker mode
Broker can be regarded as a part of the service bus, and is usually used in the scenario of synchronous calling (blocking after calling the service, waiting for the remote service response to complete before returning the result). Broker can be regarded as an agent and distribution, which means that the call to the service can be done directly through the Broker. In the software architecture design, adding a "third party" to the two existing (reference or call) relationships is a common decoupling method. Obviously, Broker is no exception. As shown below:
In order to further deepen readers' understanding of Broker mode, here is an example to illustrate:
In real life, we need to rent a house (can be regarded as a kind of service call), which can be done in several ways. First, we can first find out on the Internet, then go to the target community to inquire and inspect the house, and finally find the landlord to sign the contract, etc.; second, we can also directly contact the nearby real estate agent and tell us our requirements and budget, please The intermediary handled everything directly for us. Obviously, the first method requires you to have a sufficient understanding of the target and you have to go to the landlord to sign the contract in person (depending on the specifics, which can be regarded as a tight coupling), while the second method only needs to inform the intermediary of what is needed. Renting can be done without even knowing which community has a house, who the landlord is, etc. (rely on abstraction, and achieve decoupling through a third party). Of course, although it is easy to find an intermediary, it will also incur additional economic expenses. In the same way, calling the service through the Broker may also incur certain overhead.
Message bus mode
SOA system has three basic components: message bus, information conversion/processing engine, and storage library. Generally speaking, these components will be integrated into the ESB, and among these basic components, the message bus is the most important. The message bus is mainly used in asynchronous communication scenarios (returning the result immediately after delivering the message, without waiting for the remote system to return the execution success), which can greatly improve the response speed and system throughput. Of course, the message bus also supports synchronous communication mode. In the design based on the message bus mode, the message middleware shields the details of the underlying communication between systems, which is a typical (asynchronous) loosely coupled architecture.
In an enterprise, with the gradual development of business, the call interaction between major systems has become very frequent, and the relationship is complicated.
Imagine if there are dozens or hundreds of systems (common in insurance and financial fields), they will become difficult to maintain. By introducing message middleware, these problems can be effectively solved. Different systems only need to be connected to the message bus to ensure successful delivery/reception of messages. For the message sender (producer), there is no need to care about the recipients (consumers) of the message at all, nor do they need to care about what consumers should do after receiving the message. For the receiver (consumer), you only need to pay attention to the message related to yourself, and then make the corresponding processing after receiving the message. As shown below:
A typical application scenario: Zhang San entered the information of a customer's contracted order in the CRM system and passed the review, the CRM system will deliver a message to the message bus (the message contains necessary information, such as employee ID, order number, product number And transaction amount, etc., and the CRM system does not need to care which systems will receive the message). The employee performance bonus management system subscribes to the message topic, and starts processing after receiving the message notification (executing the bonus operation for Zhang San). At the same time, the invoicing system will update the quantity of the product inventory immediately after receiving the message notification. In this way, loosely coupled and asynchronous communication between heterogeneous systems is realized. Of course, the real scene may be more complicated than here, but the implementation ideas are similar.
After understanding the above examples, it is necessary to understand the widely used and implemented JMS (Java Message Service) in Java EE.
JMS is a specification for messages, and ActiveMQ, which is popular in the industry, is an open source message bus that implements the JMS specification.
JMS supports two modes: publish/subscribe mode and queue mode (point-to-point mode). Among them, the publish/subscribe model draws on real life publishers (publishing books) and readers (subscribing to books), message consumers (readers) only need to subscribe to the messages (books) they are interested in, and message producers ( After publishing (publishing) new news (new book) that consumers (readers) are interested in, they will notify consumers (readers) to accept the treatment. In the JMS publish/subscribe model, topics are usually used to identify messages, which is a one-to-many model, which means that the same topic can be subscribed and consumed by multiple consumers at the same time. In the JMS queue model, messages are usually identified by Queue name, which is a one-to-one model, which means that the same message can only be received and consumed by one consumer (and can only be consumed once). In an environment where both producers and consumers are clusters, it is usually necessary to combine these two modes. The situation is much more complicated, and complex issues such as fault tolerance, load balancing, message consistency, and message priority need to be considered.
The mainstream message bus (message middleware) products in the industry generally support message filtering, automatic retry, distributed transactions, persistence, message priority, message backtracking, (producer/consumer/middleware itself) clustering, and failover And other advanced features.
to sum up
The main advantages of bus-based architecture are:
l Scalability
Using the message architecture, applications can be added or removed without affecting existing applications.
l Low complexity
Each application only needs to communicate with the bus and has only one connection point, which reduces the complexity of application integration.
l Flexibility
For application communication groups that constitute complex processing, only the configuration and control routing parameters need to be changed to meet business logic or demand changes, without the need to change the service itself.
l Loosely coupled
The application program communicates directly with the message bus and does not depend on other applications, so it can be replaced and modified.
l Scalability
Multiple applications can be attached to the bus for concurrent processing to achieve load balancing.
The bus-based model can be oriented to homogeneous and heterogeneous systems (cross-platform). Currently, it is mainly used in the integration and system integration of traditional enterprise applications (for example: telecommunications, insurance, finance and other industries). Because the bus-based model is a centralized architecture, the bus itself easily forms a performance bottleneck, and the complexity and cost of achieving high availability and fault tolerance are relatively high. Therefore, this mode is not very suitable for high-concurrency, high-performance, and high-throughput Internet applications.
Note: There are many knowledge points about the message bus (message middleware), and there are many more in-depth and complex details in practical applications. Due to space issues, the author will not do too many detailed introductions and expansions. Interested readers can consult relevant materials or refer to open source products for in-depth study and research.
ESB products mainly include: open source Mule ESB , ServiceMix, JBoss ESB, commercial Oracle ESB, BEA AquaLogic ServiceBus, NService Bus, MassTransit in the .NET field, etc.
MQ products mainly include: ActiveMQ , RabbiteMQ, ZeroMQ, RocketMQ, Kafka, MSMQ, etc.