Architect Growth Series | From 2019 to 2020, Apache Dubbo Annual Review and Summary

Author | Liu Jun (Lu Turtle) Apache Dubbo PMC

This article is compiled from the live course of the architect growth series on February 18.

Follow the "Alibaba Cloud Native" official account and reply  "218" to get the corresponding live playback link and PPT download link.

Introduction : Apache Dubbo is an open source RPC framework that provides easy-to-use, high-performance RPC capabilities, flexible and controllable extensions, and powerful service governance. Currently, there are multiple languages ​​such as Java, Go, JS, and Python. Support; and has quietly evolved into the Cloud Native infrastructure. All these achievements are inseparable from the construction of the Dubbo community. This article will introduce the achievements of the Dubbo community in the past year and the new development plans of the Dubbo community in the future by Apache Dubbo PMC Liu Jun.

Thank you very much for your interest in the Dubbo community, through this article we will:

• Summarize the achievements of the Dubbo community in the past year, including two aspects of community and framework evolution;
• Looking ahead to the new roadmap of the Dubbo community and framework.

Community building is a very important link to promote the healthy and sustainable development of Dubbo. We need to maintain positive interactions with the community, have active contributors, and have active and constructive discussions, and the entire Dubbo community has Well done; in terms of framework evolution, we mainly released 6 feature versions from 2.7.0 to 2.7.5, which cover programming models, protocols, service governance, performance optimization and other aspects at the functional level; in addition to the functions that have been released , we have also made in-depth explorations in the direction of Dubbo 3.0 protocol, service introspection and cloud native. Support for these directions will be an important work direction of Dubbo in the future. I hope that through this article, more detailed thinking and Plan to sync to everyone.

community review

Looking back on the development of the Dubbo community in the past year, one of the important nodes is that it graduated from Apache incubation in May 2019, becoming the second project to graduate from Apache after being donated by Alibaba. the entire process of graduation. The community has done a lot of work in this process, including mailing list construction, code specification inspection, document and code internationalization, issue/pr processing, etc. These are on the one hand the work required by the Apache community, and also promote the development of Dubbo. to a positive effect.

After graduating from Apache, Dubbo-related projects have also been migrated to the github.com/apache organization.

There are as many as 24 projects in the Dubbo community. The maintenance of so many projects is not achieved by a few active developers, but by the joint efforts of the entire community. I rounded up all the Committers/PMCs nominated over the past year, and a total of 27 were nominated (23 committers, 4 PMCs).

As can be seen from the pie chart below, less than 20% of the contributors are from Alibaba, and more than 80% are developers or enthusiasts from various organizations. Such Committer distribution is one of the most important changes brought to the Dubbo community by joining Apache: the Dubbo project belongs to the entire community, reflecting the common demands of different developers from different organizations, and its development is not controlled by a company or It is decided by the community after discussion. If you are interested in participating in the Dubbo community, you can participate in the discussion, decision-making and coding of Dubbo's development, and I look forward to seeing you all become the next Committer.

In the past year, the Dubbo community has organized more than 10 offline meetup events , basically covering all the cities where developers gather in China, and maintaining close communication with the majority of Dubbo developers and users. Through these offline and online live events, more than 100 topic speeches were shared, and the latest developments of the Dubbo community, functional module development and recent plans were explained in depth. In all the keynote speeches, most of them were collected by the community and finally shared by Dubbo's in-depth enterprises. Typical representatives include Ctrip, Industrial and Commercial Bank of China, Koala, and Credit Computing.

Judging from Github, Dubbo has also received a lot of attention in the past year. An important milestone is that the number of Stars exceeded 3w, an increase of nearly 5 times compared with the restart of open source; the number of contributors has increased from the initial dozens to Now there are 282, of which 60 or 70 have been nominated as committers, both the number of contributors and the ratio of committers have been greatly improved; the other data is the released version, a total of 64 versions have been released, everyone If you want to know the specific information of each version, you can also click here to view it.

There are currently three major versions maintained by the community, namely 2.5.x, 2.6.x and 2.7.x.

• Among them, 2.7.x is our main development version. In the past year, a total of 6 versions (2.7.0 - 2.7.5) have been released, and each version has brought some interesting features or functional upgrades, covering from Enhancements to programming models, service governance, performance, and protocols;

• The 2.6.x version is positioned as a bugfix version. A total of 3 versions have been released in the past year, mainly to fix problems and security vulnerabilities, and no new features have been added. Therefore, the stability of this series of versions is guaranteed. ;

• The 2.5.x version has announced EOF since the beginning of last year and only made security fixes; in the second half of the year, maintenance has been completely stopped. Users still using this version are advised to upgrade to version 2.6 or 2.7 as soon as possible.

Regarding the user distribution of versions 2.6 and 2.7, there is currently no official statistics, but according to our issue distribution and tracking of some in-depth users, the usage distribution of these two versions is about 40% - 60% of the state . At the same time, we also observed a trend, that is, a large part of 2.6 users have begun to investigate and upgrade to 2.7 version or in the process of upgrading, after all, whether a framework can well meet business development demands, an important factor is whether it There are constantly adding functions and whether new technology trends can be followed. Version 2.6 has been difficult to meet these demands.

For many developers, the current biggest concern when upgrading to version 2.7 is its stability. Because each version of 2.7 will add a lot of new content and the iteration speed is fast, it is also a challenge for the community to ensure the stability of each release version. In order to facilitate users to better complete the upgrade evaluation, we recently listed a separate issue on github to count the stability of the current version including the future version:

	Version	Important features	Upgrade suggestion
1	2.7.5	Service introspection HTTP/2 (gRPC) Protobuf TLS performance optimization	Not recommended for mass production use
2	2.7.4.1	bugfixes and enhancements of 2.7.3	Recommended for production use
3	2.7.3	bigfixes of and enhancements of 2.7.2	Recommended for production use
4	2.7.2	bigfixes of and enhancements of 2.7.1	Not recommended for mass production use
5	2.7.1	bigfixes of and enhancements of 2.7.0	Not recommended for mass production use
6	2.7.0	Asynchronous programming model - consumer/provider asynchronous service governance rules enhancement, simplified registration model configuration center, metadata center package refactoring	beta version, the first version after 2.6.x refactoring

Among them, version 2.7.5 is expected to gradually reach a stable state after the next 1-2 versions.

The community has also had similar discussions on whether the next version will use the identifying suffixes such as -beta, RC, etc. to distinguish the release version at different stages, and we will follow up on the future development.

Review of key features

Next, for the new functions released in version 2.7, we will give specific explanations from the perspectives of programming model, performance optimization, service governance, transmission protocol, and ecological development.

programming model

The changes related to the programming model in Dubbo are mainly as follows:

• CompletableFuture service for asynchronous method signatures
• Server-side asynchronous support API
• IDL Cross-Language Service Definition
• Services with Reactive-style method signatures

First, let's take a look at the enhancements related to asynchrony.

A typical service definition for the Java version of Dubbo is as follows:

public interface HelloService {
  // Synchronous style
  String sayHello(String name); 
}

If you want to implement asynchronous service calls on the consumer side, you need to configure the asynchronous identity separately and use it through the RpcContext API:

String result = helloService.sayHello("world"); // result is always null
Future future = RpcContext.getContext().getFuture();

After version 2.7, we can directly define the following method interface to achieve consumer/provider asynchrony more intuitively:

public interface HelloService {
  // Asynchronous style
  CompletableFuture<String> sayHello(String name); 
}

CompletableFuture<String> future = helloService.sayHello("world");

The above examples are based on the Java Interface to describe the Dubbo service. If you want to achieve intermodulation with multi-language heterogeneous microservices, the service needs to be redefined in the corresponding language, and cross-language service reuse cannot be achieved; Serialization across languages ​​is also an issue to be aware of.

For this reason, the 2.7.5 version introduces support for IDL + Protobuf to solve the problem of cross-language service definition. For details, please refer to the example .

Support for Reactive-style API is similar to CompletableFuture above, allowing users to define service interfaces of RxJava and Reactor API.

However, it should be noted that since the peripheral Reactive API needs to be supported by the underlying transport protocol, it is meaningful. Therefore, the current Reactive API is only meaningful when using the gRPC protocol. For details, please refer to the example and the following.

performance optimization

Version 2.7 has also done a lot of work in performance optimization, which has significantly improved the throughput of the Dubbo business system, the response speed of the call link, and the performance of the service management link.

1. System throughput

The enhancements related to improving the system throughput mainly include the fully asynchronous transformation of the framework, the optimization of the consumer thread model, and the introduction of the Stream semantic protocol.

The key point of the fully asynchronous transformation is the asynchronousization of the Filter link. The previous Filter only had a synchronous invoke method. Now, in order to support asynchronous callbacks, a Listener callback listener has been added, so that the monitoring and control of the asynchronous call results can be realized. intercept.

Regarding the optimization of the consumer thread model, for gateway applications that need to consume a large number of services, the system stability and performance will be greatly improved. The overall working principle after optimization is shown below. For detailed analysis, please refer to Previously published articles: "Milestone Dubbo 2.7.5 version released, performance improved by 30%, support for HTTP/2, TLS, Protobuf and other features" .

How the old threading model works:

How the new threading model works:

2. RPC call link

From 2.7.0 to 2.7.5, according to our test data, through a series of optimizations, the performance of the call link is improved by more than 30%. In general, the goal of optimization is to reduce memory allocation and cpu calculation in the calling process. There are mainly two aspects of transformation:

• The service metadata is static, and as much as possible is calculated and cached in the startup phase to reduce the calculation cost during the calling process and speed up the response speed;
• Reduce memory allocations from URL operations during invocation.

3. Service Governance Link

The following points are worthy of attention on the service governance link: address push, service governance rule push, service governance rule calculation, route selection, etc. Especially in the scenario of large-scale service clusters, each of the above points may become a performance factor. or stability bottleneck. In version 2.7, it focuses on optimizing the calculation path related to "address push", which can be briefly summarized as follows:

• Address push events are merged to avoid repeated calculation in a short period of time
• Avoid URL reassignment when full address push
• In the URL merge link, the URL variable state is introduced to avoid the overhead caused by URL copying

Service Governance

Service governance is also a module that has been enhanced in version 2.7. In general, it can be divided into three parts:

• Optimizations and enhancements related to common routing rules
• Enhanced routing support for cross-region and cross-machine room deployment
• Metadata Center, Configuration Center

We will explain these three parts step by step. Below are a few examples of routing rules for version 2.7.

Among them, the most obvious change is that the routing rules are all rewritten in YAML, and all subsequent routing rules are planned to use YAML as the basic description language; compared with the previous routing rules directly stored in the registry, it was added in version 2.7. After the configuration center is installed, the routing rules of the new version will be stored in the independent configuration center by default, and the configuration format push mechanism has been optimized; in addition, the 2.7 version also adds application-level routing rules, which is convenient to set from the perspective of the entire application traffic rules.

The newly added cross-registry routing mechanism can achieve load balancing of call traffic among multiple registration centers, which is useful for scenarios that require remote disaster recovery, priority in the same computer room, or registration center migration.

Currently supported registry cluster load balancing strategies are:

• Same area priority
• Weight polling
• assign priority
• any available

The metadata center stores the descriptions of Dubbo service method definitions. Currently, it is mainly used for service testing, and can also be used for service API management, gateway parameter mapping, etc. in the future.

The newly added configuration center has two main purposes: storage/push configuration rules, and application configuration hosting. Next, we will focus on the application configuration hosting related functions and see how they affect Dubbo's development and operation and maintenance configuration. Dubbo currently supports several configuration sources, such as JVM dynamic parameters, configuration center, API, and local configuration files. They implement configuration coverage in descending order of priority, as shown in the following figure:

The configuration center is equivalent to dubbo.propertiesthe , where the key value has a specific naming convention:

# 应⽤用级别
dubbo.{config-type}[.{config-id}].{config-item} {config-item-value}
# 服务级别
dubbo.service.{interface-name}[.{method-name}].{config-item} {config-item-value}
dubbo.reference.{interface-name}[.{method-name}].{config-item} {config-item-value}
# 多配置项
dubbo.{config-type}s.{config-id}.{config-item} {config-item-value}

Transfer Protocol

Version 2.7 extends the RPC protocol layer and serialization layer. The RPC protocol layer adds support for the gRPC protocol, and the serialization layer adds support for the Protobuf protocol.

An important reason for supporting gRPC is that it is built on the HTTP/2 protocol. As the HTTP standard protocol, the HTTP/2 protocol is well supported on all levels of network devices and gateway agents, so it has better penetration. and versatility. By supporting the gRPC protocol, Dubbo users who wish to use HTTP/2 are provided with a choice of transport protocol.

gRPC builds the RPC semantics of Stream on HTTP/2, supports Request-Response, Stream-Response, Request-Stream, Bi-Stream and other semantics, which can meet different business call scenarios.

In the design of Dubbo, all RPC protocols are in an equal position, whether it is the own Dubbo protocol, or other extended three-party protocols such as Thrift, Hessian, gRPC, etc. Thanks to this design, we can extend any New protocol support. For how to extend the RPC protocol and its application scenarios, please refer to the previously published article "Using Dubbo to Connect Heterogeneous Microservices" .

Protobuf serialization protocol support is more about cross-language, security, and performance.

Roadmap

In the future, the community will continue to promote the development of Dubbo, focusing on the following directions:

• Continue to enhance service governance related capabilities to better meet the needs of microservice development and operation and maintenance;
• At the protocol level, start to develop the next-generation RPC protocol. The new protocol will provide richer built-in semantics such as Stream and Flow Control, as well as better scalability and gateway friendliness;
• Service discovery mechanism based on application granularity,
• Cloud native brings changes in the underlying infrastructure, and on this basis, microservice solutions such as ServiceMesh are derived. We need to continue to explore Dubbo;

Microservice functionality

The microservice functions currently under development or planning include service authentication, circuit breaker, routing rule enhancement, etc. It is expected to be released in the next 2.7.6 and other versions. In the future, support for other microservice functions will be gradually added according to the demands of the community.

Taking the service authentication function currently under development as an example, this is the demand encountered by many Dubbo users in the community in actual use: although the Dubbo service is mainly operated internally, some services are still expected to be only open to some scenarios or users. , such as some services involving sensitive data operations, which require the support of authentication capabilities.

In this issue , there is a detailed discussion on the authentication function currently under development by Dubbo. Generally speaking, the authentication function provided by Dubbo constrains the basic process of authentication on the Dubbo side. This is a general authentication scheme. , verification and other links are designed to be extensible, so it can be easily connected to various authentication and authority management systems.

I am very grateful to the active developers in the community. I am currently working at https://github.com/CodingSinger in iQIYI , which is the initiator and main development contributor of the authentication module.

Protocol - 3.0

The following is the Dubbo 2.0 protocol, which we have explained in detail on several occasions before.

The Dubbo 2.0 protocol exposes some problems in cloud native, mesh and other scenarios, such as:

• The protocol lacks extensibility
• The RPC protocol layer is coupled with the payload
• A binary private protocol built on TCP
• Lack of support for Stream semantics

Therefore, in response to the above problems, the new generation of Dubbo protocol will highlight the following characteristics:

• Reactive Stream

Reactive Stream introduces RPC, which brings richer communication semantics and API programming model support, such as Request-Stream, Bi-Stream, etc.

• Protocol upgrade

The protocol has a built-in application layer protocol negotiation mechanism, including a self-built protocol upgrade mechanism, ALPN, etc., to facilitate future protocol upgrades or migration compatible with older versions of the protocol.

• HTTP/2

In the native scenario of microservice cloud, the communication protocol based on HTTP/2 has better versatility and penetration.

• Scalable

The protocol is extensible, distinguishing between the protocol header Metadata and the parameters of the RPC method.

• Multilingual Support

For example, it provides more complete support for cross-language service definition and serialization transmission by supporting Protobuf.

• Mesh

The protocol is more friendly to Mesh and facilitates cooperation with Mesh, including flow control mechanism, application layer configuration negotiation, etc.

• flow control

The protocol has a built-in flow control mechanism and supports a Request (n) flow control mechanism similar to Reqctive Stream.

• Protocol commonality

Taking into account the versatility and performance, the support protocol can run on a variety of devices.

Service Introspection - Application Granular Service Registration

One of Dubbo's greatest strengths is its ease of use and interface-oriented (RPC approach) programming model. At the same time, interface-oriented governance also brings some problems:

• The number of addresses has increased exponentially, bringing great pressure to address push
• It does not match the mainstream microservice system model, such as SpringCloud, Kubernetes, etc.

To this end, we plan to introduce an application-granular service registration mechanism, which mainly focuses on the following points:

• The registry is organized by "application-instance IP" and no longer cares about RPC interface synchronization
• Introduce independent metadata service to complete RPC interface synchronization

The following is the basic working principle of application granular service registration (service introspection), please continue to pay attention to the specific analysis and development progress of this part.

cloud native

Cloud native brings a full range of changes to the underlying infrastructure, application development, deployment, and operation and maintenance.

infrastructure

• Changes in infrastructure scheduling mechanisms bring changes in operation and maintenance (life cycle), service governance, etc.;
• The service discovery capability sinks, and Kubernetes abstracts Native Service Discovery.

Service Mesh - Cloud Native Microservice Solution

• Mesh provides solutions for cross-language, sdk upgrade, etc. Dubbo sdk needs to cooperate with Mesh to achieve convenient adaptation of functions, protocols, service governance, etc.;
• Mesh has not yet been rolled out on a large scale, and it is more suitable for applications that pay more attention to traffic control. The performance advantages of traditional SDKs still exist, and the co-location migration scenario of the two may exist for a long time.

In terms of application scenarios, possible deployment environments for Dubbo include:

1. Instead of using Kubernetes Native Service, Kubernetes is only used as a container orchestration and scheduling facility, and continues to use Dubbo's self-built service registration and discovery mechanism;
2. Reusing Kubernetes Native Service, Dubbo no longer cares about service registration, and Dubbo Client is responsible for service discovery and traffic distribution;
3. To migrate Dubbo sdk to Mesh, on the one hand, it needs to adapt to the Mesh architecture and become an RPC programming and communication solution under the Mesh system; on the other hand, it needs to achieve long-term coexistence of Dubbo and Mesh architectures and open up service discovery and governance systems to each other;
4. Smooth migration support for hybrid deployments on Kubernetes and off-cloud, including the unification of service discovery and the integration of network communication solutions.

From the function division of Dubbo, it will focus on providing support for cloud native infrastructure from the following aspects:

• Life cycle : Dubbo is bound to the Kubernetes scheduling mechanism to maintain the automatic alignment of the service life cycle with the life cycle of the Pod container;
• Governance rules : Service governance rules are optimized in terms of rule body and rule format. For example, the rule body is described in YAML, the direct dependence of filtering rules on IP is canceled, and the CRD resources specific to the rules are defined, etc.;
• Service discovery : Support service discovery of K8S Native Service, including DNS, API-Server, and service discovery of xDS;
• Mesh architecture collaboration : Build a next-generation HTTP/2-based communication protocol to support the standardized data distribution of xDS.

" Alibaba Cloud Native focuses on micro-services, serverless, containers, Service Mesh and other technical fields, focuses on popular cloud-native technology trends, and implements large-scale implementation of cloud-native, and is the technology circle that understands cloud-native developers best."

{{o.name}}

{{m.name}}