Alibaba Group's business-driven upgrade-the evolution of Dubbo 3.0

Introduction to Cloud proposed the "Trinity" concept at the end of 2020. The goal is to form a unified technology system for "self-researched technology," "open source projects," and "commercial products," so that the value of technology can be maximized. Dubbo 3.0, as the first proposal of the Trinity Architecture, has high hopes within the group. It perfectly integrates the characteristics of internal HSF, and naturally has high-performance and high-availability core capabilities. We expect to use it to solve internal landing problems and achieve a unified technology stack. This article will share the evolution of Dubbo 3.0 and how to help users enjoy the technical dividends brought by cloud native.

Author | Yuan Yun

Trinity

At the end of 2020, Alibaba Cloud put forward the concept of "three in one". The goal is to form a unified technology system for "self-researched technology", "open source projects", and "commercial products" so that the value of technology can be maximized.

The HSF framework within the Alibaba Group has undergone many years of testing at the traffic peaks of Double Eleven and has exercised its core competitiveness with high performance and high availability. As for Dubbo, as one of the most popular service governance frameworks at home and abroad, its open source affinity does not need to be said any more.

Dubbo 3.0, as the first proposal of the Trinity Architecture, has high expectations within the group. It perfectly integrates the characteristics of internal HSF, and naturally has high-performance and high-availability core capabilities. We expect to use it to solve internal landing problems and achieve a unified technology stack. At present, Koala has been implemented on a large scale, and will be implemented in many core scenarios in the future, and will carry complex business scenarios such as 618 and Double Eleven.

Benefits of Dubbo 3.0

Before explaining the details of the changes in Dubbo 3.0, let's talk about the benefits of upgrading to Dubbo 3.0 from two aspects.

First of all, Dubbo 3.0 will focus on improving the performance and stability of large-scale clusters in practice, reducing single-machine resource consumption by optimizing data storage methods, and based on this, ensuring the stability of the cluster under the condition of horizontal expansion of ultra-large-scale clusters. At the same time, Dubbo 3.0 puts forward the concept of flexible clusters, which can effectively ensure and improve the overall reliability and resource utilization of the entire link under a heterogeneous system.

The second point is that Dubbo 3.0 represents a milestone for Dubbo to fully embrace cloud native. Dubbo currently has a huge base of users at home and abroad, and with the advent of the cloud-native era, the demand for these users to go to the cloud is becoming stronger. Dubbo 3.0 will provide a complete set of solutions, migration paths and best practices to help enterprises achieve cloud-native transformation and enjoy the dividends brought by cloud-native.

1. Business income

So from the perspective of business applications, if you upgrade to Dubbo 3.0, what specific benefits can you get?

First of all, in terms of performance and resource utilization, Dubbo 3.0 can effectively reduce the additional resource consumption brought by the framework, thereby greatly improving resource utilization.

From a stand-alone perspective, Dubbo 3.0 can save about 50% of memory usage; from a cluster perspective, the scale of cluster instances supported by Dubbo 3.0 is in the millions, laying the foundation for future larger-scale business expansion; and Dubbo 3.0 The support of the Reactive Stream communication model can greatly increase the overall throughput in some business scenarios.

Secondly, Dubbo 3.0 brings more possibilities for business architecture upgrades. The most intuitive is the upgrade of the communication protocol, which brings more choices to the business architecture.

Dubbo's original agreement actually bound the microservice access method to a certain extent. For example, to access Dubbo's back-end services on mobile and front-end services, it needs to go through the gateway layer protocol conversion; for another example, Dubbo only supports the request-response mode of communication, which makes it necessary to stream or reverse the communication. The scene of communication to communication cannot be well supported.

Finally, Dubbo 3.0 brings an overall solution to the cloud native upgrade on the business side. Whether it is the passive change brought about by the upgrade of the underlying infrastructure or the active upgrade of the business to solve the pain point, when the business is upgraded to cloud native, Dubbo 3.0 can help business products quickly connect to cloud native by providing cloud native solutions.

Dubbo 3.0 overview

After clarifying the benefits of upgrading to Dubbo 3.0, let's take a look at the specific changes in Dubbo 3.0.

1. Support a new service discovery model. Dubbo 3.0 attempts to start with the application model, optimize its storage structure for its cloud-native mainstream design model, and avoid interoperability problems in the model. The new model is highly compressed in data organization, which can effectively improve performance and cluster scalability.

2. Proposed the next generation RPC protocol-Triple. This is an open new protocol designed based on HTTP/2 that is fully compatible with the gRPC protocol. Because it is designed based on HTTP/2, it is highly gateway-friendly and penetrating. It is fully compatible with the gRPC protocol, making it interoperable in multiple languages. Naturally, it has an advantage.

3. Proposed unified governance rules. This set of rules is geared towards cloud native traffic management and can cover a series of scenarios such as traditional SDK deployment, Service Mesh deployment, VM virtual machine deployment, and Container container deployment. One rule governing all scenarios can greatly reduce the cost of traffic governance, and unify the overall traffic governance under a heterogeneous system.

4. Provide solutions for accessing Service Mesh. For the Mesh scenario, Dubbo 3.0 proposes two access methods: One is the Thin SDK mode. The deployment model is exactly the same as the current mainstream deployment scenario of Service Mesh, while Dubbo will lose weight, shielding the same governance functions as Mesh, and only retains The core RPC capability; the second is the Proxyless mode. Dubbo will take over the duties of Sidecar and actively communicate with the control plane. Based on the unified governance rules of Dubbo 3.0, it will apply cloud native traffic governance functions.

Application-level service registration discovery

Application-level service discovery model

The prototype of the application-level service discovery model was actually first proposed in Dubbo 2.7.6. After a period of iteration, a relatively stable model in Dubbo 3.0 was finally formed.

In Dubbo 2.7 and previous versions, when applications register and discover services, they use interfaces as the granularity. Each interface corresponds to a piece of data in the registry. Different machines will be registered with metadata information belonging to the current machine or Interface-level configuration information, such as serialization, computer room, unit, timeout configuration, etc.

All servers that provide this service will independently change the interface granularity when restarting or publishing. For example, a gateway application relies on 30 interfaces of the upstream application. When the upstream application is released, there are 30 corresponding address lists that are going online and offline.

The method of using the interface as the first citizen of the registration discovery is the earliest SOA or microservice splitting method, which provides the independent and dynamic change capability of a single service and a single node. With the development of business, the number of services that a single application relies on is increasing, and the number of machines of each service provider is also increasing due to business or capacity reasons. From the perspective of the client as a whole, the total number of service addresses it depends on is increasing rapidly. According to this situation, we can consider optimizing the process design of registration discovery.

Note that there are two characteristics here:

• With the basic completion of the splitting of monolithic applications into multi-microservice applications, large-scale service splitting and reorganization are no longer a pain point. Most of the interfaces are provided by only one application or fixed by several applications.

• A large number of URLs used to mark address information are extremely redundant, such as timeouts, serialization, and so on. These configuration changes are extremely infrequent, but they appear in every URL.

Combining the above characteristics, the final application-level registration discovery is proposed, that is, the application is the basic dimension of registration discovery. The main difference from the interface level is that if an application provides 100 interfaces, it needs to register 100 nodes in the registry; if the application has 100 machines, every time it is released, it will be the same for its clients. Changes of 10,000 virtual nodes. However, application-level registration discovery only requires 1 node, and only 100 virtual nodes are changed for each release. For applications that rely on a large number of services and many machines, the scale will drop by tens to one percent, and the memory usage will also drop by at least half.

However, the design of the technical solution not only needs to consider the correct function, but also needs to consider the upgrade of the existing business. Therefore, the basis for upgrading to application-level registration discovery is the ability to align interface-level registration discovery in its functions. Regardless of whether the client is upgraded or application-level registration discovery is enabled, the premise is that the correct service call is not affected.

In order to provide this guarantee, we designed a new component, the metadata center, to manage two parts of data:

• Interface application mapping relationship: Reporting and querying the interface-to-application mapping can determine whether the client is enabled at the application level and avoid business code changes;

• Application-level metadata snapshot: When the configuration used between different interfaces of an application is different, data differentiation will occur. Therefore, in the application-level solution, the concept of metadata snapshot is proposed, that is, each application will be unified every time it is released Generate a metadata snapshot, which contains the metadata version of the current application and the configuration of all interfaces provided by the current application. This snapshot ID will be stored in the URL, which not only provides dynamic change capability, but also reduces the pressure on memory for data storage.

Finally, because this new service discovery is highly similar to the service discovery model under Spring Cloud, Service Mesh and other systems, Dubbo can realize mutual discovery with nodes under other systems from the registry level.

Dubbo 3.0-cloud native & endorsed by Ali, easy to use

Dubbo 3.0 is positioned to become the best microservice framework in the cloud-native era. Several trends that can be seen at present include K8s becoming the de facto standard for resource scheduling, Meshing becoming the mainstream, and rapid growth in scale. The existence of these trends puts forward higher requirements on Dubbo.

1. How users can deploy and call Dubbo services more conveniently on K8s is a problem that must be solved. To solve this problem, a unified protocol and data exchange format is a prerequisite. 2. The popularity of Mesh has brought diversified problems, that is, how do native Dubbo and Mesh Dubbo coexist, and how to support multi-language scenes. 3. The growth of scale will bring greater challenges to the entire Dubbo architecture. Whether it is components such as the registry or the client, there will be more data and more calls.

How to provide more efficient services while maintaining stability is the top priority of Dubbo's evolution.

These challenges brought by the cloud-native era have contributed to the development of Dubbo to the next generation: new protocols, K8s infrastructure support, multi-language support, and scale.

1. The next generation of RPC protocol

The most basic ability of the RPC framework is to complete service calls across business processes, form a chain and form a network, and the core carrier of this is the RPC protocol.

At the same time, due to the tight coupling with business data, the design and implementation of the RPC protocol also directly determines the business architecture in some aspects, such as the interaction from the terminal device to the backend, the adoption of multiple languages in the microservice architecture, and the data transmission between services Model etc.

Dubbo 2 provides the core semantics of RPC, including protocol headers, flag bits, request ID, and request/response data. However, in the cloud-native era, the Dubbo 2 protocol faces two main challenges: one is that the ecosystem is not interoperable, and it is difficult for users to directly understand the binary protocol; the other is that it is not friendly to gateway-type components such as Mesh and requires a complete analysis protocol to obtain all the information. The required call metadata, such as some RPC contexts, face challenges from performance to ease of use.

As a service framework, Dubbo's most important thing is to provide remote communication capabilities. The design and implementation of the Dubbo 2 RPC protocol has been proven in practice to limit the development of business architecture in some aspects, such as the interaction from terminal devices to back-end services, and the use of multiple languages in the microservice architecture Data transfer model between applications, services, etc.

On the premise of supporting existing functions and solving existing problems, the next-generation protocol needs to have the following characteristics:

• The agreement needs to solve the problem of cross-language intercommunication. Both the traditional multi-language and multi-SDK mode and the Mesh-based cross-language mode require a more versatile and extensible data transmission format.

• The protocol should provide a more complete request model. In addition to the Request/Response model, it should also support Streaming and Bidirectional.

• In terms of performance, the request Id mechanism is retained to avoid performance loss caused by head-of-line blocking.

• Easy to expand, including but not limited to Tracing/ Monitoring and other support, should also be recognized by devices at all levels, reducing the difficulty of user understanding.

Based on these requirements, the combination of HTTP2/protobuf is the most suitable. When it comes to the combination of these two, it may be easy to think of the gRPC protocol. The relationship between the new generation protocol and gRPC is as follows:

1. The new Dubbo protocol is an extended protocol based on GRPC, which also ensures that the new protocol and GRPC can communicate and share in the ecosystem.

2. On the basis of the first point, the new Dubbo protocol will more natively support Dubbo's service governance and provide greater flexibility.

3. In terms of serialization, since most applications have not yet used Protobuf, the new protocol will provide sufficient support for serialization, smoothly adapt to existing serialization, and facilitate migration to Protobuf.

4. In the request model, the new protocol will natively support Reactive, which is also not available in the gRPC protocol.

2、Service Mesh

In order to make Dubbo fall in the Service Mesh system, after referring to many solutions, the two forms of Mesh solutions that are most suitable for Dubbo 3.0 are finally determined. One is the classic Sidecar-based Service Mesh, and the other is the Proxyless Mesh without Sidecar.

For the Sidecar Mesh solution, its deployment method is the same as the current mainstream Service Mesh deployment solution. The focus of Dubbo 3.0 is to provide a completely transparent upgrade experience for business applications as much as possible. It is not only a non-sense upgrade from a programming perspective, but also through Dubbo 3.0 lightweight, Triple protocol, etc., so that the loss and operation and maintenance costs on the entire call link are also Reduce to a minimum. This solution is also known as the Thin SDK solution, and Thin is that it removes all unnecessary components.

The Proxyless Mesh deployment plan is another Mesh form planned by Dubbo 3.0. The goal is to directly interact with the control plane without starting the Sidecar.

Imagine that Proxyless Mesh deployment schemes are often applicable to the following scenarios:

• The business side expects to upgrade the Mesh solution, but cannot accept the performance loss caused by Sidecar's traffic hijacking. This situation is common in core business scenarios

• Expect to reduce Sidecar operation and maintenance costs and reduce system complexity

• The legacy system upgrades slowly, the migration process is long, and multiple deployment architectures coexist for a long time

• Multiple deployment environments. The multiple deployment environments here include multiple deployment methods such as VM virtual machines, Container containers, etc., as well as mixed deployment of multiple types of applications, such as the mixed deployment of Thin SDK and Proxyless solutions, and the deployment of performance-sensitive applications In the Proxyless mode, the Thin SDK deployment scheme is adopted for peripheral applications, and multiple data planes are jointly scheduled by a unified control plane.

Looking at these two forms as a whole, under different business scenarios, different migration stages, and different infrastructure guarantees, Dubbo will have Mesh schemes to choose from, and any further steps can be achieved through unified Controlling the governance.

Future deployment

1. Deploy on K8s

The picture above is the expected deployment plan of Dubbo 3.0 on Kubernetes in the future. Dubbo 3.0 will use its Kubernetes native service on the service discovery model to support mutual invocation without the need to deploy an independent registry.

2. Deploy on Istio

The picture above is the expected deployment plan of Dubbo 3.0 on Istio in the future. Here is a mixed deployment mode of Thin SDK and Proxyless, as shown in Pod 1 and Pod 3, data traffic is sent directly by Dubbo Service, while Pod 2 is deployed in Thin SDK mode, and the traffic is intercepted by Sidecar and then flows out.

Flexible enhancement planning

Cloud native has brought about a major change in technology standardization. How to make applications easier to create and run on the cloud, and have the ability to elastically expand, is the core goal of all cloud-native basic components. With the elasticity brought by cloud native technology, applications can expand a large number of machines in a very short time to support business needs.

For example, in order to deal with zero-point spike scenarios or emergencies, the application itself often requires thousands or even tens of thousands of machines to improve performance to meet the needs of users, but the expansion also brings about node abnormalities such as the extremely large number of cluster nodes. A series of problems such as frequent occurrence and service capacity being affected by a variety of objective factors, resulting in unequal node service capabilities, are all problems encountered when clusters are deployed on a large scale in a cloud-native scenario.

Dubbo expects to solve these problems based on a flexible cluster scheduling mechanism. This mechanism mainly solves two problems. One is that in the case of abnormal nodes, distributed services can remain stable without problems such as avalanches; the other is that for large-scale applications, it can run in the best state and provide Higher throughput and performance.

• From a single service perspective, Dubbo's desired goal is to provide an unbreakable service to the outside world, that is, when the number of requests is particularly high, it can selectively reject some requests to ensure the correctness and timeliness of the overall business sex.

• From a distributed perspective, it is necessary to minimize the overall performance degradation due to complex topologies and different node performance. The flexible scheduling mechanism can dynamically allocate traffic in an optimal way, so that heterogeneous systems can accurately serve according to runtime Reasonable allocation of capacity requests to achieve optimal performance.

Dubbo 3.0 roadmap

Apache Dubbo 3.0.0 was officially released in June this year as a milestone version donated to Apache, which represents a node where Apache Dubbo fully embraces cloud native.

In November 2021, we will release version 3.1 of Apache Dubbo. At that time, we will bring the implementation and practice of Apache Dubbo deployment in Mesh scenarios.

In March 2022, we will release Apache Dubbo version 3.2. In this version, we will bring a new intelligent traffic scheduling mechanism under large-scale application deployment to improve system stability and resource utilization.

Finally, Apache Dubbo 3.0 has been integrated with the internal RPC framework of Alibaba Group. It is expected to use it to solve internal landing problems and achieve a unified technology stack. In the future, Apache Dubbo 3.0 will land on Alibaba Group on a large scale, carrying complex business scenarios such as 618 and Double Eleven.

The community will try its best to ensure a short release cycle and repair existing problems in a timely manner. The community sincerely hopes that everyone is welcome to submit issues and PRs to the community, and students in the community will review and reply as soon as possible. thanks for your support!

﹀

﹀

﹀

If you want to discuss more Dubbo related content, you can search for group number: 21976540 Join

Copyright Statement: content of this article is contributed spontaneously by Alibaba Cloud real-name registered users, and the copyright belongs to the original author. The Alibaba Cloud Developer Community does not own its copyright and does not assume corresponding legal responsibilities. For specific rules, please refer to the "Alibaba Cloud Developer Community User Service Agreement" and the "Alibaba Cloud Developer Community Intellectual Property Protection Guidelines". If you find suspected plagiarism in this community, fill in the infringement complaint form to report it. Once verified, the community will immediately delete the suspected infringing content.