In today's Internet of Things field, the MQTT protocol has become an indispensable key element, providing core technical support for efficient and real-time data transmission. However, the current projects that provide MQTT capabilities in the market are mainly focused on the traditional and existing "out-of-the-box" IoT device management platforms, resulting in a lack of sufficient attention and exploration on the implementation of the lower-level MQTT protocol. However, we firmly believe that the characteristics of the MQTT protocol have broader application prospects, not only limited to the field of Internet of Things. It is precisely because of this belief that after years of practice and technology accumulation, we launched the open source project BifroMQ, which focuses on the efficient processing of the MQTT protocol, especially in the face of large-scale load.
▌MQTT protocol middleware with both neutrality and scalability
Compared with the traditional IoT device management platform, BifroMQ adheres to a different concept in design. We have boldly abandoned the traditional paradigm of "one package solution" and focused our attention on the need for a high-performance MQTT protocol. We firmly believe that the protocol characteristics of MQTT have a wider application paradigm, so BifroMQ is committed to giving full play to the potential of the MQTT protocol, especially its excellent performance when handling large-scale loads.
Compared with the integration logic (such as Kafka) built into the MQTT implementation, BifroMQ is more inclined to "dock" with the downstream system in a way that conforms to the MQTT standard. For example, through the shared subscription (Shared Subscription) mechanism, the integration logic is externalized to achieve more decoupled bridging and the ability to forward messages to heterogeneous systems while maintaining high message throughput. This design concept makes BifroMQ a highly customizable middleware that can easily adapt to various downstream systems and meet the needs of different business scenarios.
▌Constructing large-scale multi-tenant serverless cloud services
The mission of BifroMQ is to build an MQTT message system suitable for large-scale multi-tenancy to support the business characteristics of serverless cloud services. This mission is driven by a deep understanding of the characteristics of the MQTT protocol and confidence in its wider application. Different from traditional enterprise-level architectures, serverless cloud services emphasize on-demand resource allocation, elastic expansion, and highly flexible service construction. For this reason, BifroMQ, through its multi-tenant architecture and resource sharing mechanism, provides the characteristics of "shared resources and exclusive experience" for Serverless business.
▌Enterprise-level deployment: both flexibility and robustness
Although the goal of BifroMQ is to build multi-tenant Serverless cloud services, multi-tenant + shared resources are essentially an abstraction of single-tenant exclusive resources. Consistent with our philosophy, through the free combination and configuration of core components, BifroMQ easily supports common "Shared Nothing" enterprise-level cluster deployments. In fact, this is also the default deployment mode of the BifroMQ open source version. This flexibility enables BifroMQ to adapt to system architectures of various sizes and needs.
▌Structure Analysis of BifroMQ
The architectural design of BifroMQ is based on "first principles", analyzing the technologies required to achieve design goals from a technical perspective and how to "organically" combine these technologies to achieve the overall optimization effect. Therefore, it is difficult to fully understand its connotation only from the project structure and code logic. The following will give a high-level description of the overall architecture of BifroMQ from three main perspectives.
▌Modular architecture based on decentralized cluster management
First of all, regardless of the implementation logic of the MQTT protocol itself, each functional service module of BifroMQ is built on a set of decentralized underlying cluster construction capabilities (base-cluster), as shown in the following figure:
▲ Modular Architecture of BifroMQ Decentralized Cluster
The cluster built by base-cluster is logically divided into two layers: Underlay Cluster and Overlay Cluster. Underlay Cluster is called "Host" Cluster, and each Host in BifroMQ corresponds to a service process (Process) running on the operating system. The Host Cluster implements the Host membership service (Membership) by using the Gossip class protocol (SWIM Protocol), and provides the abstraction of the Host address for the Overlay Cluster. Overlay Cluster is called "Agent" Cluster, which provides Agent-level address abstraction (Agent Address) based on the Host address. In BifroMQ, Agent corresponds to a logical service (Service) that implements specific functions. These logical services (implemented uniformly through the base-rpc framework) include modules with two roles, client and server, and use the capabilities of Agent Cluster to realize service registration and discovery.
The benefits of this architecture include:
1. The logical service is decoupled from the process where the service resides, enabling more flexible encapsulation and combination according to deployment scenarios.
2. The "service discovery" of logical services does not rely on the traditional registration center or name service, thereby eliminating the operation and maintenance risk of a single point of failure and enabling the cluster scale to scale freely.
▌Modular load isolation and collaboration
Next, we describe the structure of BifroMQ from the perspective of protocol implementation. When designing the architecture from the perspective of building serverless cloud services, it is necessary to consider the rationality of function realization from the perspective of load isolation and management, that is, the multi-tenancy of load. We split the workload of the MQTT protocol so that each load can exist in the form of an independent sub-cluster, and these sub-clusters build a complete MQTT capability through cooperation. The following are the modules related to MQTT load in BifroMQ:
● bifromq-mqtt: responsible for handling the long connection load of the MQTT protocol
● bifromq-dist: responsible for maintaining MQTT subscription status for highly reliable access and large-scale message routing
● bifromq-inbox: Responsible for highly reliable access to subscriber session messages in CleanSession=false mode
● bifromq-retain: Responsible for highly reliable access to Retain messages
The collaborative relationship between these modules is shown in the following figure:
▲ BifroMQ module collaboration relationship 1
▲ BifroMQ module collaboration relationship 2
It is worth mentioning that the bifromq-dist, bifromq-inbox and bifromq-retain modules all make full use of the capabilities of base-kv to achieve distributed strong consistency persistence for key loads. In the operation and maintenance scenario of serverless cloud services, this is especially important to ensure SLA.
▌Neutrality : standard-oriented and scalable integration
As mentioned earlier, BifroMQ is positioned as a middleware that implements the MQTT standard, with more emphasis on neutrality and integration. Not on the same level as other "package IoT platform" projects that include MQTT capabilities. Therefore, the criterion for judging "Does BifroMQ have a certain function or will it support a certain function in the future?" is very simple: all the capabilities defined by the MQTT protocol belong to the category that the bifromq project needs to support, and all functions beyond the MQTT protocol definition, we It is more inclined to exist as an independent component or service, and integrates with BifroMQ in a way that conforms to the MQTT standard. This approach helps to build larger-scale cloud services and promotes the maturity of related technologies. Of course, the integration of BifroMQ is also reflected in the integration of the middleware itself with various business systems, mainly including three mechanisms: Plugin, API and Metrics:
▲ Typical scene integration architecture
- Plugin mechanism is the main way to realize business logic integration. bifromq currently defines the following plugin interface modules:
- bifromq-plugin-auth-provider: Implement client authentication and Pub/Sub authentication logic based on message topics
- bifromq-plugin-event-collector: implement business logic triggered by various MQTT related events
- bifromq-plugin-setting-provider: implements tenant-level runtime setting change management logic
- Reference implementations of these interfaces can be found in the BifroMQ-Inside project.
- The API mechanism (coming soon) provides BifroMQ's runtime HTTP management interface to implement basic management operations such as server-side subscription management and disconnection.
- The Metrics mechanism realizes the definition and sampling of indicators by using the micrometer library, but does not limit the type of collection end, so that the business integrator can customize it (refer to the build-plugin-demo module in the project).
▌Summary _
In summary, this is an overall introduction to the BifroMQ technical architecture. Please look forward to our upcoming series of feature articles that will delve into the various components and design principles of BifroMQ.
Finally, in order to help you better understand the technical architecture of BifroMQ, we will hold a BifroMQ online live broadcast public class on September 21 (Thursday) . You are welcome to pay attention to the information in the above-mentioned BifroMQ developer exchange group and lock the live broadcast in advance Address, exchange and learn with the majority of peers!