Dubbo Mesh: from service framework to unified service control platform

Apache Dubbo is an RPC service development framework, which is used to solve the service governance and communication problems under the microservice architecture. It officially provides Java, Golang and other multilingual SDK implementations. Microservices developed by Dubbo have the ability of remote address discovery and communication with each other natively. With the rich service governance features provided by Dubbo, service governance demands such as service discovery, load balancing and traffic scheduling can be realized. Dubbo is designed to be highly scalable, and users can easily implement various customized logics for traffic interception and location.

What is Dubbo 3？

Dubbo 3 maintains the classic architecture of Dubbo 2, takes solving the inter process communication of micro services as its main responsibility, and better controls the micro service cluster through rich service governance capabilities (such as address discovery, traffic management, etc.); Dubbo3's upgrade of the original framework is comprehensive, which is reflected in almost every link of the core Dubbo features. Through the upgrade, stability, performance, scalability and ease of use are comprehensively improved.

General communication protocol. The new RPC protocol should abandon the private protocol stack, and use the more general HTTP/2 protocol as the transport layer carrier. With the standardized characteristics of HTTP protocol, it can solve the problems of traffic universality and penetration, so that the protocol can better deal with the scenarios such as front-end and back-end connection, gateway proxy, etc; Support the Stream communication mode, which can meet the demands of different business communication models and bring greater throughput to the cluster.

For millions of cluster instances, the cluster is highly scalable. With the promotion of microservice practice, the scale of microservice cluster instances is constantly expanding, which benefits from the lightweight and easy horizontal expansion of microservices. At the same time, it also brings burden to the entire cluster capacity, especially some centralized service governance components; Dubbo 3 needs to solve various resource bottlenecks caused by instance scale expansion to achieve truly unlimited horizontal expansion.

Embrace cloud native. In the cloud native era, the changes in the underlying infrastructure are profoundly affecting the deployment, operation and maintenance, and even the development process of applications, as well as the selection and deployment mode of Dubbo 3 microservice technology solutions. Dubbo 3 fully aligns the model of cloud native infrastructure on the service discovery model, and can align the design of address, life cycle, etc. with container scheduling platforms such as Kubernetes.

What problems the future Dubbo needs to solve

At the moment when the functions of Dubbo 3 are basically complete, we begin to rethink the current overall architecture of Dubbo and summarize the following problems:

The business code is directly coupled with each microservice component, making upgrading difficult

In the current deployment mode, if you need to integrate a component, you need to adapt the component in the business code environment. Take a simple example. If you need to access a user-defined data format conversion component, you need to weave the corresponding adaptation implementation into the business code based on Dubbo SPI. This deployment mode causes high intrusion to business deployment. If the transformation component needs to be upgraded, all business parties that have deployed the component need to be promoted to upgrade. It is extremely difficult in a production environment.

High complexity of multi language implementation

At present, all the computing processing logic of Dubbo is integrated into the business code in the form of SDK, which inevitably leads to the problem of high implementation complexity when cross language calls are required. For Dubbo, in addition to Java and Golang's SDK implementations, other languages still lack corresponding perfect implementations. In addition, for an interceptor function, the implementation under the Java SDK cannot be directly reused on the Golang SDK due to differences in language and interface design, which also brings difficulties and instability to middleware development to a certain extent.

Governance capability sinks on the data side, and middleware governance capability is fragmented

In the current Dubbo deployment mode, when it is necessary to access a middleware governance capability, it needs to be integrated through direct access to the business code on the data side. This way will lead to the independent work of each governance component. From the global perspective, the access to the data side is very chaotic, and unified governance cannot be carried out from a unified perspective. At the same time, because these components are accessed independently, the work between components cannot be well combined in some scenarios.

Dubbo Mesh

Dubbo Mesh is clearly divided into control plane and data plane in terms of architecture and deployment form.

As the core of service governance, the control plane has an abstract and unified model, which is responsible for the connection with the underlying infrastructure and provides a unified governance portal from startup configuration, service discovery, traffic management to authentication and authentication.

The data side focuses on the business programming model and communication capability. It is based on the access service governance capability of multiple deployment forms (SDK, Sidecar, Agent) and decoupled from the business code based on the dynamic deployment capability.

In general, the data plane is lighter and more focused, and the control plane is more cohesive and powerful. Only one set of control planes needs to be deployed to use the production level service governance capabilities.

The responsibilities and capabilities under Dubbo Mesh are described in the following two parts: control surface and data surface:

Dubbo control surface

The control surface is the core of service governance. It has an abstract and unified model, is responsible for the connection with the underlying infrastructure, and provides a unified governance portal from startup configuration, service discovery, traffic management to authentication and authentication.

1. Abstract service governance model: Dubbo control surface inherits the high extensibility of Dubbo, and divides various fields and extension points for each component. Customized components can be added. You can quickly deploy, pull up, and hot update components in the Dubbo Mesh as long as they are extended in a standard format.

2. Shielding infrastructure and components: Dubbo control plane integrates the access of infrastructure, such as Kubernetes, into the interior through the mode of components, shields the differences from each infrastructure facing the data plane, and supports native Kubernetes deployment, VM deployment, hybrid deployment and other scenarios.

3. Unified service governance rules: Dubbo control plane supports the docking of unified service governance rules and the governance of multiple frameworks through a set of rules.

4. Cross language support: Dubbo control plane distributes control data through a common data format, and solves cross language governance problems with multiple deployment methods of the data plane.

Dubbo data surface

Dubbo data plane will focus on business programming model and communication capability, provide multiple access methods, interface with component management and control from Dubbo control plane, and support dynamic pull of governance rule identification and execution capability issued by control plane through component hot update.

1. Focus on programming and communication: Dubbo data will focus more on supporting business developers with programming models. Users only need to rely on simple call APIs to complete the corresponding RPC remote calls, and no longer need to care about the access of the governance capabilities behind.

2. Multiple access methods: Dubbo data plane will support SDK based proxless mode access, agent based imperceptible access and Sidecar based cross language access in the future, covering more usage scenarios as much as possible, and improving the ease of use of the overall function.

3. Component hot update: The Dubbo data plane will support dynamic loading and updating of the corresponding governance component capabilities issued from the Dubbo control plane, and the management of governance capabilities will be closed in the Dubbo control plane for unified management to improve the operation and maintenance process.

4. Identification and implementation of governance rules: Dubbo data plane is mainly responsible for the identification and implementation of the corresponding governance rules, loading the corresponding governance capabilities through dynamic loading capabilities, and realizing the governance capability of data plane traffic.