[Dubbo3.0 technology topic] general technical system introduction and technical guide (preface)

This is the 14th day of my participation in the August More Text Challenge

Background on Dubbo

Apache Dubbo is a microservices development framework (a high-performance, lightweight, open source Java services framework) that provides two key capabilities: RPC communication and microservices governance. This means that the microservices developed by Dubbo will have the ability of remote discovery and communication between each other, and the rich service governance capabilities provided by Dubbo can realize service governance demands such as service discovery, load balancing, and traffic scheduling. Dubbo is also highly extensible, allowing users to customize their implementation at almost any function point to change the framework’s default behavior to suit their business needs.

Dubbo features

1. High-performance RPC calls for interface proxy;

2. Automatic service registration and discovery;

3. Intelligent load balancing strategy;

4. Highly scalable capability;

5. Run-time flow scheduling;

6. Visual service governance and operation and maintenance;

Dubbo’s frame structure

The history of Dubbo

• 2011/10/27: Alibaba announces Dubbo open source.

• 2012/10/23: Release the last version 2.5.3 and stop maintenance updates.

• 2017/07/31: Back from the dead, officially announced to open the re-update, and will receive key maintenance, reference: Dubbo announced to restart maintenance.

• 2017/09/07: Release the first version of resurrection: Dubo-2.5.4.

• 2018/01/08:

  1. Dubbo 3.0 is coming. Dubbo 3.0 is coming.

  2. Dubbo-2.6.0 was released, which mainly incorporated dubbox project branch from Dangdang open source. PS: Dubbo maintenance period, Dangdang open source dubBox based on Dubbo.

• Dubbo Spring Boot release: Dubbo – Spring-boot-Starter V1.0.0 public beta.

• 2018/02/09: Dubbo has been voted into the Apache Foundation incubator and the Apache domain name has been updated and is no longer limited to Java.

• 2019/05/20: Apache Software Foundation announces Dubbo’s graduation as Apache’s Top project.

Dubbo3.0 is back

Based on The evolution of Dubbo2, Dubbo3 has been upgraded in terms of ease of use, ultra-large scale micro-service practice and cloud native infrastructure adaptation while maintaining its original core functions and features. The following documents will be expanded based on Dubbo3.

The Dubbo3.0 extension extends

Functionally, Dubbo3. Completed functionality will cover the full link from the API layer, where developers are directly exposed, to the underlying transport.

• The API layer will include a complete data exchange format based on IDL, which will bring two benefits:

  • First, the unified IDL model can generate unified client stub and server stub, which can directly make non-reflective calls and greatly improve performance.

  • Second, the native support for asynchronous and streaming gives users more options to choose more convenient usage according to different business scenarios.

• The second layer is an extension to the registry, metadata center, and configuration center.

  • The registry and configuration center basically support all the mainstream implementations in the industry, and the metadata center is a new abstraction from Dubbo 2.7 that is responsible for accessing metadata. The metadata here includes the invocation configuration of the service, such as timeout, serialization method, protocol, and so on, as well as the abstraction of the signature of the service method to facilitate Dubbo’s cross-framework and cross-language invocation.

• The cluster layer is a major highlight of Dubbo. In addition to supporting various retry strategies, Dubbo also provides load balancers for various scenarios, such as randomness and weights. Notably, Dubbo3.0 will bring pull-based adaptive load balancing that will significantly improve the performance and efficiency of distributed clusters.

• The next layer is the protocol layer, which is the kernel part of RPC framework and is generally divided into application layer protocol and transport layer protocol. Application layer protocol Dubo3.0 supports mainstream protocols such as GRPC, Redis, and REST as well as Dubbo native Dubo2.0.

• The transport layer supports HTTP/HTTP2 and some custom protocols such as RSOCKET. On the serialization side, Dubbo supports Protobuf in addition to Hessian and Java, which has huge performance and cross-language implications.

Maven rely on

<dependency>
    <groupId>org.apache.dubbo</groupId>
    <artifactId>dubbo</artifactId>
    <version>3.0.0</version>
</dependency>
Copy the code

• Dubbo3 was born in the background of cloud native. The microservices constructed with Dubbo follow the idea of cloud native, and can better reuse the underlying cloud native infrastructure and fit into the cloud native microservice architecture.

• Dubbo 3.0.0 is compatible with almost all 2.7.x behaviors. Dubbo3 is based on Dubbo2. While maintaining the original core functions and features, Dubbo3 has been comprehensively upgraded in terms of ease of use, ultra-large scale micro-service practice, and cloud native infrastructure adaptation.

Dubbo3 official document

• Dubbo3.0 official document

• Dubbo3.0 technical documentation

Dubbo3 core functions

1. Application-level service discovery mechanism;

• • At the same time, Dubbo 3.0.0 has changed the interface level service registration to application level service registration. For example, prior to version 3.0.0, all services were registered with metadata in the form of interfaces:

    Dubbo: / / 192.168.101.8:20880 / com. Example. The demo. Async. API. BookFacade? Anyhost = true&application = demo - provider&deprecated = fals E&dubbo = 2.0.2 & dynamic = true&generic = false&interface = com. Example. Demo. Async. API. BookFacade&metadata -type = remote&methods = qu EryByName, queryAll&pid = 53639 & release 3.0.0 & side of = = provider&timestamp = 1624889509797Copy the code

• • As you can see, if we register services at the interface level, there will be a lot of duplicate data, which will result in the registry data being proportional to the number of interfaces. The more interfaces there are, the more metadata will be registered. What if we register as an application-level service? The following is shared metadata for application level service registration:

    {" name ":" demo - provider ", "id" : "192.168.101.8:20880", "address" : "192.168.101.8", "port" : 20880, "sslPort" : null, "payload": { "@class": "org.apache.dubbo.registry.zookeeper.ZookeeperInstance", "id": null, "name": "demo-provider", "metadata": { "anyhost": "true", "application": "demo-provider", "deprecated": "false", "dubbo": "2.0.2," "dubbo. Endpoints" : "[{\ port \" ": 20880, \" protocol \ ": \" dubbo \} "] ", "dubbo. Metadata - service. Url - params" : "{\" version \ ": \" 1.0.0 \ "and \" dubbo \ ": \" 2.0.2 \ ", \ "release \" : \ "3.0.0 \", \ "the port \" : \ "20880 \", \ "protocol \" : \ "dubbo \"} ", "dubbo.metadata.revision": "525892dddd25ea459ee539d0734b2f1a", "dubbo.metadata.storage-type": "remote", "dynamic": "True", "generic" : "false", "interface" : ". Com. Example demo. Async. API. BookFacade ", / / multiple service interface only to save a "metadata - type" : "Remote ", "methods": "queryByName,queryAll"," PID ": "63941", "release": "3.0.0", "side": "provider", "timestamp": "1624891074206" } }, "registrationTimeUTC": 1624891075236, "serviceType": "DYNAMIC", "uriSpec": null }Copy the code

• • From these shared metadata, it can be seen that application-level registration reduces a large number of duplicate metadata, which can reduce the storage and push pressure of the registry to the greatest extent, and then reduce the address calculation pressure of the Dubbo consumer. Cluster size also began to become predictable and measurable (independent of the number of RPC interfaces, only of instance deployment size).

    • Prior to Dubbo3 registration discovery was at the interface level. That is, multiple services published by the same application register multiple copies of data in the registry. These data are independent of each other, facilitating service transformation and interface migration. Why propose application-level registration discovery?

    • There are two main reasons:

      • First, the interoperability of the existing ecosystem, including Spring Cloud and K8s, is based on instances, that is, registration at the application level. In order for Dubbo to become the best RPC framework for connecting heterogeneous systems, it needs to support instance granularity.

      • Second, in terms of scale, larger growth leads to a rapid expansion of metadata, which leads to a larger footprint for the registry and clients. Based on current data analysis, upgrading to application-level registry discovery will reduce memory footprint and registry data by 60% if an application publishes an average of 50 services, for example. For platform-based applications that publish more than 10K interfaces, for example, these numbers can be reduced by 90%.

• How to ensure smooth migration and how user interface-based configurations are mapped to applications.

• Metadata centers are abstracted to manage interface – to – application mapping and application-level metadata.

  • In deployment mode, the Dubbo framework automatically reports this relationship to the metadata center.
  • Configuration and service governance on the running user side remaps the application granularity to the interface granularity through this mapping. Involves the most core part — site selection is also divided into two parts, application level site selection and interface level site selection exist at the same time, convenient service governance. The optimization brought about by application-level registration discovery is significant.

2. Next generation RPC protocol: Triple: Triple is the main protocol of Dubbo3. It is fully compatible with gRPC over HTTP/2 and extends load balancing and traffic control mechanisms at the protocol level.

3. New routing rules;

4. Significantly improved performance;

5. Kubernetes service Integration:

   • Dubbo3 has made new enhancements mainly in cloud service capabilities. Why do you say that? The service registry capability was awkward when the author integrated Kubernetes in his work, because Kubernetes itself provides service registration and discovery capabilities, but it was not perfectly integrated with Dubbo.

   • Before Dubbo3 we probably deployed a Cluster of ZooKeeper services in Kubernetes for service registration and discovery. However, this approach is not suitable for cloud service applications, and the service registration and discovery capabilities are more appropriate to be implemented by the underlying service components.

• First, the K8s lifecycle needs to be aligned so that Dubbo services can be registered and discovered natively in the K8s system.
• Second, support for Mesh. The new protocol eliminates the need for the gateway to resolve the full protocol by using HTTP2 for header/payload separation. Another issue is service registry discovery and governance, which requires Dubbo to be able to navigate through the Mesh’s xDS architecture as a data plane. Governance requires the gradual migration of existing rules to YAML based rules that remove IP dependencies. The end result will be a native Dubbo service that interacts perfectly with thin SDK-BASED Dubbo + Mesh and governance.

Dubbo3.0 native microservices

Following the K8s integration, Dubbo3.0 – the next generation of cloud native microservices.

The emergence of a new architecture or technology is bound to be accompanied by certain trends.

Several trends we can see are K8s becoming the de facto standard for resource scheduling, meshing going mainstream, and rapid growth in size. The existence of these trends puts higher demands on Dubbo:

• First of all, how to deploy and call Dubbo service on K8s more conveniently is a problem that must be solved. To solve this problem, unified protocol and data exchange format is a prerequisite.
• Secondly, the popularity of Mesh has brought about the problem of diversification, that is, how native Dubbo and Mesh Dubbo can coexist, how to support multi-language scenes;
• Third, the increase in size will bring greater challenges to the overall Dubbo architecture, with more data and call volumes for both components such as registries and clients. How to provide more efficient services while maintaining stability is the top priority in Dubbo’s evolution.
• The challenges of these cloud-native eras have led to the next generation of Dubbo definitions. The new protocol, K8s infrastructure support, multilingual support, and scale support comprise Dubbo3.0. Let’s dive into Dubbo3.0 to see what’s new.

Dubbo3 extension separation

The Dubbo core no longer provides third-party SDK extensions, which need to be supported through the Dubbo-spI-Extensions project.

Dubbo3 diversity registration

1. Zookeeper serves as a registry, metadata report, and configuration center.

2. Nacos as a registry, metadata reporting, configuration center;

3. Kubernetes as the registry;

4. Redis as metadata reporting;

5. Apollo as the configuration center;

6. Hessian2 and JDK as default serializers;

7. The Triple protocol supports Protobuf;

Dubbo3 upgrade alert

1. The spring-based configuration list is subject to change. Please leave a message in the official upgrade document.

2. Early versions of Dubbo 3 enable multiple registration and multiple subscription by default for high compatibility.

Dubbo3.0 flexibility enhancement

There are two problems to be solved in flexible enhancement:

• First, in the case of abnormal nodes, the distributed service can remain stable, without avalanche and other problems;
• Second, for large-scale applications, it can run in the best state and provide higher throughput and performance.

In terms of methodology, the flexible enhancement of Dubbo3.0 will be based on the concept of failure-oriented design, providing support for precise capacity assessment, adaptive flow limiting, and adaptive load balancing, and building large-scale and reliable applications in a step-by-step, bottom-up manner. From the perspective of a single service, service is unbreakable and stable.

From the perspective of distribution, complex topology does not degrade performance. Distributed load balancing can dynamically allocate traffic in an optimal way to ensure that heterogeneous systems can reasonably allocate requests based on the accurate service capacity at runtime, thus achieving optimal performance.

Dubbo3 represents the next generation RPC protocol

Dubbo2.x protocol header

As you can see, this is the protocol for Dubo2.0. Functionally, Dubo2.0 provides the core semantics of RPC, including protocol headers, flag bits, request ids, and request/response data. In the cloud native era, 2.0 protocols face two main challenges:

• First, it is difficult for users to understand binary protocols directly because of ecological incompatibility.

• Secondly, it is not friendly to gateway components such as Mesh, and requires complete parsing protocols to obtain the required call metadata, such as some RPC contexts, which will face challenges in terms of performance and ease of use.

Dubbo3 protocol header

• Firstly, the protocol needs to solve the problem of cross-language communication. Both the traditional multi-language multi-SDK mode and the Mesh cross-language mode need a more general and easily extensible data transmission format.

• Secondly, the protocol should provide a more complete Request model. Besides Request/Response model, it should also support Streaming and Bidirectional.

• Thirdly, in terms of performance, the new protocol should retain the request Id mechanism to avoid performance loss brought by HOL.

• Finally, the new protocol should be easy to extend, including but not limited to Tracing/ Monitoring and other support, and should be recognized by all layers of devices to reduce the difficulty of users to understand.

---

• Based on these requirements, the HTTP2/ Protobuf combination is the best fit. Mention these two and you may easily think of the GRPC protocol. What is the relationship between this new generation of protocols and GRPC?

• First of all, the new Dubbo protocol is based on the extended GRPC protocol, which also ensures that the new protocol and GRPC can communicate and share in the ecosystem.

• Second, on this basis, the new Dubbo protocol will more native support Dubbo service governance, providing greater flexibility;

• On the serialization side, since most applications currently do not use Protobuf, the new protocol will provide enough support for serialization to smoothly adapt existing serializations to facilitate migration to Protobuf.

• On the request model, the new protocol will support Reactive natively, which the GRPC protocol does not.

Dubbo3 development route