×
Community Blog Apache Dubbo 3.0.0 Officially Released – Apply Cloud-Native in All Respects

Apache Dubbo 3.0.0 Officially Released – Apply Cloud-Native in All Respects

This article discusses Apache Dubbo 3.0 and its future.

1. Background

Since becoming open-source in 2011, Apache Dubbo has accumulated a lot of experience in the practice of a large number of large-scale Internet and IT companies. Besides, Dubbo has become one of the popular mainstream RPC frameworks in both China and abroad due to its Java user-friendliness, rich functionality, and strong governance capabilities, which have been very successful in the past.

However, with the development of the cloud-native era, Java microservice governance systems, such as Apache Dubbo and Spring Cloud, have faced many new requirements. These requirements include the faster startup time of applications, better protocol penetration for application communication, higher penetration of application communication protocols, and more user-friendly multilingual support. For example, Spring released its GraalVM-based Spring Native Beta solution this year. This solution features a millisecond-level startup capability and higher processing performance.

Such background puts forward two major requirements for the next-generation Apache Dubbo. One requirement is to retain the advantages accumulated in the context of the existing out-of-the-box and implementation practices, which are expected by many developers. Another requirement is to follow the cloud-native ideas as much as possible, reusing the underlying cloud-native infrastructure and fitting more into the cloud-native microservice architecture.

2. Apply Cloud-Native

Under the current background, Apache Dubbo 3 chose to apply cloud-native to upgrade the Dubbo architecture. It proposed various solutions for optimization, such as a brand new service discovery model, the next-generation RPC protocol, and cloud-native infrastructure adaption.

2.1 New Service Discovery Model (Application-Level Service Discovery)

1
Application-Level Registration Model

In the original Dubbo design, the data stored in the registry has duplicate content to a large extent, which wastes a lot of storage. When the cluster is large enough, the amount of data in the registry will be exploded as service registration discovery is based on service.

Currently, Spring Cloud and gRPC, which are also microservice governance tools, are based on application-level service discovery. If they still use interface-level registration, it will be hard for Dubbo to operate with them. However, if Dubbo can be registered at the service level like Spring Cloud, it can work easily under the heterogeneous system.

2
Deployment Solution under the Heterogeneous System

Application-level service discovery is a major mechanism forward for Apache Dubbo towards cloud-native. It bridges the gap between Dubbo and other microservice systems at the address discovery level and becomes the foundation for Dubbo to adapt to Kubernetes-native services and other infrastructures.

Based on application-level service discovery, the data in the registry will be reorganized, reducing the pressure on the registry significantly. Besides, the memory consumption of the application will be reduced because of the reduced address quantity.

3
Performance Improvements

Generally, the number of addresses stored in an application can be reduced by about half. For example, for large-scale deployment of upstream applications, 1,000 nodes are deployed, and 50 services are provided. The reduced number can even be more than 95%. This would improve the memory-intensive environment of core applications significantly.

2.2 Next-Generation RPC Protocol – Triple

In the cloud-native era, the Dubbo RPC protocol faces two major challenges:

  1. The ecosystem is not interoperable. The Dubbo protocol customizes core semantics that is strongly bound to RPC based on the binary stream, including protocol headers, flags, request IDs, and request/response data. For more cloud-native governance facilities, it is not easy for all of them to "read" and understand the binary "semantics" of Dubbo.
  2. Due to the protocol design, Dubbo's protocol header can no longer carry more metadata. If a gateway component, such as Mesh, needs to process data, it should parse a complete data packet to obtain the necessary metadata information, such as the RPC context. Meanwhile, there are several challenges in performance and usability for the component.

4
Dubbo Protocol Communication Solution

With the premise of supporting existing features and solving remaining problems, Apache Dubbo 3 proposes a next-generation RPC protocol, Triple.

Triple is expected to solve these problems below:

1.  Cross-Language Interconnection – The traditional multi-language mode with multi-SDK and mesh-based cross-language mode requires a more universal and extensible data transmission format.

2.  A more perfect request model is provided. Besides the Request and Response models, Streaming and Bidirectional models should be supported as well.

5
Request Model Diagram

3.  Easy expansion and high penetration should be supported, including (but not limited to) tracing or monitoring. It should also be able to be recognized by devices at all layers. Besides, gateway facilities can recognize data messages, which are user-friendly for deploying Service Mesh, thus easing the comprehension of users.

4.  Upgrade without awareness for Java users is supported. Instead of defining cumbersome IDL files, users can easily upgrade to Triple by simply changing the protocol name.

Based on these expectations, it is reasonable to use a combination of HTTP/2 as the underlying communication protocol and protobuf as the serialization protocol, which is also the one used by the gRPC protocol. Triple can be evolved based on the gRPC protocol to meet the features of Apache Dubbo. Moreover, this ensures that the new protocol and gRPC can be interconnected and shared in the ecosystem.

6
Triple Protocol Communication Solution

2.3 Integrate with Cloud-Native Facilities

For Kubernetes scenarios, Apache Dubbo 3 is integrated with two aspects:

First, it supports alignment natively with the lifecycle of Kubernetes Pod. Based on the Dubbo QoS, Kubernetes can perceive the current status of Dubbo applications running in Pod containers. In addition, thanks to the Dubbo SPI, users can customize the dimension of probe detection. By doing so, the implementation framework and the lifecycle of the business can be unified.

Second, Dubbo also supports connections to the Kubernetes Native Service system. It supports service discovery systems natively based on the Kubernetes API Server and DNS, enabling the alignment of service concepts under the deployment architecture with those in Dubbo.

7
Deployment Solution in the Kubernetes Architecture

For the Service Mesh system, if the application with Apache Dubbo 2 wants to deploy as a Mesh, it needs to use Sidecar to intercept the Dubbo traffic. However, since Dubbo has certain governance capabilities, it causes a significant additional burden for applications and a call disruption for clusters.

Based on this condition, Apache Dubbo 3 proposes two deployment modes. One is the Thin SDK mode deployed with Sidecar, and the other is the Proxyless Mesh mode directly connected to the control plane.

8
Deploy Dubbo 3 Deployment Architecture in Mesh Scenarios

In addition to the access of the deployment architecture, Apache Dubbo 3 defines the cloud-native traffic governance that supports unified governance rules for traditional SDK and Mesh scenarios.

Apache Dubbo 3 is expected to use this set of rules to implement a wide range of routing semantics, such as Canary release and A/B testing. Only one set of rules needs to be configured and written to a unified control plane to control all clusters in a unified manner. By doing so, whether it is a direct deployment with Kubernetes, a hybrid deployment with Thin SDK or Proxyless in a Mesh scenario, or a direct manual deployment of the cluster by the user, all can be controlled with the same set of rules, achieving the goal of defining once and using everywhere.

3. Future Prospects

Apache Dubbo 3.0.0 is a milestone donated to Apache, representing an important node for Apache Dubbo to fully apply cloud-native.

In November 2021, Apache Dubbo 3.1 will be released, which will bring the implementation and practices of Apache Dubbo deployment in Mesh scenarios.

In March 2022, Apache Dubbo 3.2 will be released, which will bring a new intelligent traffic scheduling mechanism for large-scale application deployment, improving system stability and resource utilization.

Currently, Apache Dubbo 3 has been integrated with the internal RPC framework of Alibaba Group and is expected to be used to solve internal implementation challenges and achieve a unified technology stack. In the future, it will be implemented on a large scale in Alibaba Group to support complex business scenarios, such as the 618 and Double 11 shopping festivals.

The community sincerely welcomes everyone to submit issues and project reviews. The community will review and respond as soon as possible. In addition, the community will try its best to ensure a short release cycle and fix existing problems in a timely manner.

From Apache Dubbo 3, the community will also adopt a more open attitude towards customization requirements in the production environment. We welcome everyone to contribute your customization implementations to the open-source community, and dubbo-spi-extensions warehouse will support these customizations in the future.

0 0 0
Share on

Aliware

47 posts | 4 followers

You may also like

Comments