Shulou(Shulou.com)06/03 Report--

Author | Liu Jun (Land Turtle) Apache Dubbo PMC

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

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

Introduction: Apache Dubbo is an open source RPC framework, which provides easy-to-use, high-performance RPC capabilities, flexible and controllable expansion, powerful service governance, has been supported by Java, Go, JS, Python and other languages; and has quietly evolved into the Cloud Native infrastructure. All these achievements are inseparable from the construction of Dubbo community. In this paper, Apache Dubbo PMC Liu Jun will introduce the achievements of Dubbo community in the past year and the new development plan of Dubbo community in the future.

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 the evolution of the community and framework, and look forward to the future new planning of the Dubbo community and framework (roadmap).

Community building is a very important link in promoting the healthy and sustainable development of Dubbo. We need to maintain positive interaction with the community, active contributors, and positive and constructive discussions, and the whole Dubbo community has done a good job in this respect over the past year. In the evolution of the framework, we have mainly released six feature versions from 2.7.0 to 2.7.5, covering programming models, protocols, service governance, performance optimization and other aspects at the functional level. In addition to the features that have been released, we have also done in-depth exploration on the Dubbo 3.0 protocol, service introspection and cloud native, and the support for these directions will be an important direction for Dubbo's future work. I hope to synchronize more detailed thoughts and plans with you through this article.

Community review

Looking back at the development of the Dubbo community over the past year, one of the important nodes was graduating from Apache incubation in May 2019, becoming the second project donated by Alibaba to graduate from Apache. I had the honor to participate in the whole process from restarting source to entering Apache incubation to 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 and so on. On the one hand, these are the work required by the Apache community, but also play a positive role in promoting the development of Dubbo.

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

There are as many as 24 projects in the Dubbo community. Maintaining so many projects is not just a matter of a few active developers, but the result of the joint efforts of the whole community. I summarized all the Committer/PMC nominations over the past year, with a total of 27 nominations (23 committer, 4 PMC).

As can be seen from the pie chart below, less than 20% of the contributors are from Alibaba,80% and above are developers or enthusiasts from different 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 whole community and reflects the common aspirations of different organizations and different developers, and its development is not controlled or decided by a company, but 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 development, and look forward to becoming the next Committer.

In the past year, the Dubbo community organized more than 10 offline meetup activities, which basically covered all the cities where developers gathered in China, and maintained close communication with the vast number of Dubbo developers and users. Through these offline and online live events, we shared more than 100 topic speeches and explained in depth the latest developments, functional module development and short-term planning of the Dubbo community. In all the keynote speeches, the vast majority are practical topics that are collected by the community and finally shared by Dubbo's deep enterprises, including Ctrip, ICBC, koalas, credit calculus and so on.

From the perspective of Github, Dubbo has also received a very high level of attention in the past year. An important milestone is that the number of Star has exceeded 3w, an increase of nearly five times compared with the restart of open source. The number of contributors has increased from dozens at first to 282 now, of which 60 or 70 have been nominated as committer. Both the number of contributors and the proportion of committer have been greatly improved. The other data is the released version, a total of 64 versions have been released. If you want to know the specific information of each version, you can also click here to view it.

At present, there are three major versions of community maintenance, which are 2.5.x, 2.6.x and 2.7.x.

Among them, 2.7.x is our main development version, and a total of six versions (2.7.0-2.7.5) have been released in the past year, each with some noteworthy feature or functional upgrades, covering enhancements from programming models, service governance, performance to protocols.

Version 2.6.x is defined as the bugfix version, and three versions have been released in the past year, mainly to fix problems and security vulnerabilities, and no new feature has been added, so this series of versions are guaranteed in terms of stability.

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

There are no official statistics on the user distribution of versions 2.6 and 2.7, but according to our issue distribution and some deep user tracking, the usage distribution of these two versions is about 40-60%. At the same time, we also observe a trend, that is, a large number of 2.6 users have begun to investigate whether a framework can meet the business development requirements well or in the process of upgrading to version 2.7. An important factor is whether it continues to have functions to join and whether it can follow new technology trends. Version 2.6 has been very difficult to meet these requirements.

For many developers, the biggest concern for upgrading to version 2.7 is its stability. Because each version of 2.7 adds a lot of new content and iterates quickly, ensuring the stability of each release is also a challenge for the community. In order to make it easier for users to complete the upgrade assessment, we recently listed a separate issue on github to count the stability of current and future versions:

Version important feature upgrade recommendation 12.7.5 Service introspection HTTP/2 (gRPC) Protobuf TLS performance Optimization do not recommend large-scale production use 22.7.4.1bugfixes and enhancements of 2.7.3 recommended production use 32.7.3bigfixes of and enhancements of 2.7.2 recommended production use 42.7.2bigfixes of and enhancements of 2.7.1 do not recommend mass production use 52.7.1bigfixes of and enhancements of 2.7.0 Mass production is not recommended to use 62.7.0 asynchronous programming model-consumer / provider asynchronous service governance rules to enhance the simplified registration model configuration center, Metadata Center package refactoring beta version 2.6.x the first version after refactoring

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

There has been a similar discussion in the community as to whether the next release version can be distinguished by identifying suffixes such as-beta, RC, etc., and we will depend on the future development.

Review of key functions

Next, it explains the new features released in version 2.7 from the perspectives of programming model, performance optimization, service governance, transport protocol, ecological development and so on.

Programming model

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

The server side of CompletableFuture asynchronous method signature asynchronously supports APIIDL cross-language service definition Reactive-style method signed service

First, let's take a look at the enhancements associated with asynchronization.

Typical service definitions for the Dubbo Java version are as follows:

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

If you want to implement asynchronous service invocation on the consumer side, you need to configure the asynchronous identity separately and use it in conjunction with RpcContext API:

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

After version 2.7, we can directly define the following method interfaces to implement consumer / provider asynchronism more intuitively:

Public interface HelloService {/ / Asynchronous style CompletableFuture sayHello (String name);} CompletableFuture future = helloService.sayHello ("world")

The above examples are all based on Java Interface to describe Dubbo services. If you want to intertune with multi-language heterogeneous micro-services, the services need to be redefined in the corresponding language, and cross-language service reuse cannot be achieved. In addition, cross-language serialization is also a problem to pay attention to.

For this purpose, version 2.7.5 introduces support for IDL + Protobuf to solve cross-language service definition issues, as shown in the example.

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

However, it should be noted that because the peripheral Reactive API needs to be supported by the underlying transport protocol, Reactive API can only be meaningful when using the gRPC protocol. For more information, please see 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 Dubbo business system, call link response speed, service governance link performance and so on.

1. System throughput

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

The key point of full asynchronization is the asynchronization of Filter links. In the past, Filter only had a synchronous invoke method. Now, in order to support asynchronous callback, a Listener callback listener is added to monitor and intercept the result of asynchronous calls.

With regard to the optimization of the consumer threading model, for gateway applications, applications that consume a large number of services will greatly improve system stability and performance. The overall working schematic diagram after optimization is shown below. For more information, please see the previously released article: "milestone Dubbo 2.7.5 release, performance improvement of 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, the performance of the call link has been improved by more than 30% through a series of optimizations. Overall, the goal of optimization is to reduce memory allocation and cpu calculation during calls, which are mainly modified in two aspects:

The service metadata is static, calculating and caching as much as possible in the startup phase, in order to reduce the calculation cost in the call process, speed up the response speed, and reduce the memory allocation caused by the URL operation in the call process. 3. Service governance link

There are mainly the following points to pay attention to on the service governance chain: address push, service governance rule push, service governance rule calculation, routing location, etc., especially in the scenario of large-scale service cluster, each of these points may become a performance or stability bottleneck. In version 2.7, the calculation path related to "address push" is optimized, which can be summarized as follows:

Address push events merge to avoid repeated calculation of full address push for a short time, avoid URL redistribution on URL merge links, introduce URL variable state, and avoid overhead service governance caused by URL copy

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

Optimizations and enhancements related to general routing rules support metadata and configuration centers for routing across regions and computer rooms

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

Among them, one of the most obvious changes is that the routing rules are rewritten in YAML, and all subsequent routing rules are planned to use YAML as the basic description language. Compared with the previous routing rules stored directly in the registry, with the addition of the configuration center in version 2.7, the new version of routing rules will be stored in an independent configuration center by default, and the configuration format push mechanism has been optimized. In addition, in version 2.7, routing rules with application granularity are added to facilitate the setting of traffic rules from the perspective of the whole application.

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

Currently, the supported registry cluster load balancing strategies are:

The same area priority re-polling specified priority is available arbitrarily

The metadata center stores the description of Dubbo service method definition, which is mainly used for service testing at present, and can also be used for service API management, gateway parameter mapping and so on in the future.

The new configuration center has two main uses: storage / push configuration rules and application configuration hosting. Next, we will focus on the related features of application configuration hosting to see its impact on the development and operation and maintenance configuration of Dubbo. Dubbo currently supports several configuration sources, such as JVM dynamic parameters, configuration center, API, and local configuration files, among which configuration overrides are implemented in the order from high priority to low priority, as shown in the following figure:

Configuration Center is equivalent to remote hosting of a shared version of dubbo.properties, where the key value has a specific naming convention:

# should apply level dubbo. {config-type} [. {config-id}]. {config-item} {config-item-value} # Service level dubbo.service. {interface-name} [. {method-name}]. {config-item} {config-item-value} dubbo.reference. {interface-name} [. {method-name}]. {config-item} {config-item-value} # multiple configuration item dubbo. {config-type} s. { Config-id}. {config-item} {config-item-value} Transport Protocol

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

One of the important reasons for supporting gRPC is that it is based on HTTP/2 protocol. As a HTTP standard protocol, HTTP/2 protocol is well supported in all levels of network equipment and gateway agents, so it has better penetration and versatility. By supporting the gRPC protocol, a transport protocol option is provided for Dubbo users who expect to use HTTP/2.

GRPC constructs the RPC semantics of Stream on HTTP/2, and 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 its own Dubbo protocol or extended other three-party protocols such as Thrift, Hessian, gRPC, etc., thanks to this design, we can extend any new protocol support. For information on how to extend the RPC protocol and its application scenarios, see the previously published article "connecting heterogeneous micro-service architectures using Dubbo".

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 micro-service development and operation and maintenance; at the protocol level, we will begin to develop the next generation of RPC protocol, which will provide richer built-in semantics such as Stream and Flow Control, and will have better scalability and gateway friendliness. Based on the service discovery mechanism of application granularity, cloud natively brings about changes in the underlying infrastructure, and derives micro-service solutions such as ServiceMesh. We need to continue to explore Dubbo; micro-service functions.

The microservice functions currently under development or planning include service authentication, circuit breaker, routing rule enhancement and so on, which are expected to be released in the next version 2.7.6. In the future, other micro-service functions will be added according to the demands of the community.

Take the service authentication feature currently under development as an example, which is a requirement encountered by many Dubbo users in the community: although Dubbo services mainly operate internally, some services are still expected to be open only to some scenarios or users, such as those involving sensitive data manipulation, which requires authentication support.

In this issue, there is a detailed discussion about the authentication function that Dubbo is currently developing. Generally speaking, the authentication function provided by Dubbo restricts the basic flow of Dubbo side authentication, which is a set of general authentication scheme, which is designed to be extensible in token calculation, verification and other aspects, so it can be easily connected to various authentication and authority management systems.

Thank you very much to the active developer of the community, who now works in iqiyi's https://github.com/CodingSinger, which is the initiator and major contributor to the authentication module.

Protocol-3.0

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

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

Lack of extensibility RPC protocol layer coupled with payload binary private protocol built on TCP lacks support for Stream semantics

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

Reactive Stream

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

Protocol upgrade

The protocol should be built into a layer protocol negotiation mechanism, including 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 micro-service Yunyuan scenario, the communication protocol based on HTTP/2 has good versatility and penetration.

Scalable

The protocol is extensible to distinguish the parameters of the protocol header Metadata and the RPC method.

Multilingual support

For example, it provides better support for cross-language service definition and serialization transfer by supporting Protobuf.

Mesh

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

Flow control

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

Protocol generality

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

Service introspection-Service Registration with Application granularity

One of the biggest advantages of Dubbo is its ease of use and interface-oriented programming model (RPC method). At the same time, interface-oriented governance also brings some problems:

The number of addresses is growing exponentially, which puts a lot of pressure on address push and does not match the mainstream micro-service system models, such as SpringCloud, Kubernetes and so on.

To this end, we plan to introduce an application-granularity service registration mechanism with the following key points:

The registry is organized according to "application-instance IP". It no longer cares about RPC interface synchronization and introduces independent metadata services to complete RPC interface synchronization.

The following is the basic working principle of application granularity service registration (service introspection). Please continue to follow the specific analysis and development progress of this section.

Cloud origin

Cloud native has brought about all-round changes in the underlying infrastructure, application development, deployment, operation and maintenance, and so on.

The change of infrastructure scheduling mechanism brings about changes in operation and maintenance (life cycle) and service governance; service discovery capability sinks, and Kubernetes abstracts Native Service Discovery. Service Mesh-cloud native micro service solution Mesh provides a solution for cross-language and sdk upgrade. Dubbo sdk needs to cooperate with Mesh to achieve convenient adaptation of features, protocols, service governance, and so on. Mesh has not 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 SDK still exist, and the mixed migration scenario may exist for a long time.

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

Do not use Kubernetes Native Service,Kubernetes only as a container orchestration and scheduling facility, continue to use the service registration and discovery mechanism built by Dubbo; reuse Kubernetes Native Service,Dubbo no longer care about service registration, Dubbo Client is responsible for service discovery and traffic distribution; Dubbo sdk to Mesh migration, on the one hand, to adapt to the Mesh architecture, become the RPC programming and communication scheme under the Mesh system. On the other hand, it is necessary to achieve the long-term coexistence of Dubbo and Mesh architecture, to communicate with each other through the service discovery and governance system, and to support the smooth migration of mixed deployment on and under the cloud, including the unification of service discovery and the opening of network communication solutions.

In terms of Dubbo function division, support for cloud native infrastructure will be focused on the following aspects:

Lifecycle: Dubbo is bound with Kubernetes scheduling mechanism to maintain automatic alignment of service lifecycle and Pod container lifecycle; governance rules: service governance rules optimize the rule body and rule format, such as describing the rule body in YAML, canceling the direct dependence of filtering rules on IP, defining rule-specific CRD resources, etc. Service discovery: support K8S Native Service service discovery, including DNS, API-Server, support xDS service discovery; Mesh architecture cooperation: build the next generation HTTP/2-based communication protocol, support xDS standardized data distribution.

"Alibaba Cloud Native focus on micro-services, Serverless, containers, Service Mesh and other technology areas, focus on cloud native popular technology trends, cloud native large-scale landing practice, to be the best understanding of cloud native developers of the technology circle."

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.