Community Blog Dubbo-Go 1.5 – A Key Step Toward Cloud Native

Dubbo-Go 1.5 – A Key Step Toward Cloud Native

Dubbo-Go 1.5, released in 2020, is an application communication framework designed to scale out the capabilities of Dubbo and written in Go.


By Yu Yu, He Xinming, et al.


It is generally said that computer technology goes through a revolution about every 10 years, and related knowledge systems are innovated at least every 5 years and lose about half their value every 2 years. This is also true in the field of application service communication frameworks. A communication framework with a long lifecycle takes about five years to develop and another five years to stabilize and mature. Every application communication framework is developed to meet existing needs. The cross-language, cross-platform, and low-performance gRPC framework would not have been adopted in the 2G era 20 years ago.

The value of a communication framework is estimated by different people in different ways. For example, beginners need simplicity and ease of use, performance evaluators focus on performance, application architects consider maintenance costs, and enterprise users consider overall costs. Compared with performance, stability and evolution are more important for application communication frameworks. A well-maintained framework has a lower overall cost over a long period of time, including lower learning costs, maintenance costs, upgrade costs, and replacement costs.

Dubbo-Go is the Go implementation for Apache Dubbo and fully compatible with Dubbo. Dubbo-Go is also an application communication framework designed to scale out the capabilities of Dubbo and written in Go, which is the primary programming language in the cloud-native field.

Backed by Alibaba and the community, Apache Dubbo has been constantly evolving since it emerged in 2008. Dubbo-Go was released in 2016 and Dubbo-Go 1.5, fully compatible with Dubbo 2.7.x, was released in 2020. The latest release, Dubbo-Go 1.5.5 was released on Jan 5, 2021.

Dubbo-Go provides the following capabilities:

  • Interoperability: Dubbo-Go enables interoperation between the gRPC framework and Spring Cloud ecosystem.
  • Observability: Based on OpenTracing and Prometheus, Dubbo-Go provides strong logging, tracing, and metrics display capabilities.
  • Cloud native: Dubbo-Go provides communication capabilities to registries based on the Kubernetes API server, which minimizes upgrade costs.

Dubbo-Go is still evolving and will soon incorporate the following capabilities:

  • Ease of use: Many people interested in Dubbo-Go constantly complain about the difficulty in learning how to use it. As Dubbo-Go is more widely applied within Alibaba, it will be further packaged by the Alibaba middleware team and will be made open source in the community after it is tested in production environments.
  • Cloud native: Dubbo-Go is a Kubernetes-based solution. From the perspective of a layered technical architecture, the Kubernetes API server is an O&M component and cannot be exposed to the application layer. Otherwise, the Kubernetes API server can be overloaded with communication traffic, producing high system risks. The Kubernetes API server may fail due to improper use of the application layer or a traffic bug of the framework. This will make backend service capabilities unavailable. To avoid these risks, the application layer must be able to perceive the operators provided by Kubernetes. With constant evolution, Dubbo-Go plans to provide its own operators in the 1.6 version.

As difficult as this might be, we will proceed with our initial mission.

Application-level Registration Model

After a period of hard work, we built a model for application-level service registration and discovery. This model has the following two advantages over the interface-level registration model:

  • It is consistent with mainstream registration models, such as Spring Cloud, which registers services based on applications. The application-level registration model provides fundamental support for cloud native.
  • It significantly mitigates the registry workload. From the perspective of registries, the cluster size is proportional to the number of services, rather than the number of instances.

We considered migration costs when we designed the model. To migrate your data to the new registration model, you only need to replace your existing registry with a new service discovery registry.

A service discovery registry can be implemented through the following methods:

  • Nacos
  • etcd
  • ZooKeeper

We recommend that you use Nacos or etcd for newly launched businesses because they are more reliable and stable.

Metadata Report Center

The application-level registration model of Dubbo-Go 1.5 must be able to support the storage of interface-level metadata. The difference between the service-level registration model and application-level registration model lies in the type of data registered to the registry. In the application-level registration model, interface-level data is no longer registered to the registry. However, in the remote procedure call (RPC) framework, a consumer must acquire available service information from the provider when the consumer wants to find the service address to be called. In Dubbo-Go 1.5, the interface-level data is stored in a metadata center, which can be viewed as an interface definition or a general storage area. This metadata center stores interface-level metadata and supports read and write operations on the stored data. Providers can store data in the metadata center, and consumers can read and write data from and to the metadata center. Data in the metadata center must be accurate and up-to-date.

The metadata center provides two parent class implementations: local implementation and remote implementation. In the Go programming language, a child class can inherit from a combination of parent classes. In local implementation, the memory of a provider is used as a virtual metadata center. In remote implementation, a registry, such as ZooKeeper, etcd, and Nacos, is used as a metadata center. Remote implementation supports the child classes of ZooKeeper, Nacos, etcd, and Consul. This allows you to store and distribute metadata by using the preceding third-party registries.

Attribute Support by the Invocation Interface

The invocation structure provides attribute support to store intra-process attributes. Unlike attachments, attributes are not transmitted from consumers to providers.

Kubernetes Registry

In Dubbo-Go versions earlier than 1.5, the Kubernetes registry is directly implemented through the List and Watch operations of the pod objects on the Kubernetes client. The Kubernetes informer is introduced in the version 1.5 iteration for two reasons. First, the Kubernetes registry of Dubbo-Go is a Kubernetes controller and the informer is more Kubernetes-native. Second, the informer is an exploration in the future evolution toward the combination of CustomResourceDefinition (CRD) and operators planned by the community. The 1.5 version iteration also supports cross-namespace service discovery. To reduce the List and Watch operations on the Kubernetes API server, Dubbo-Go 1.5 differentiates between the provider and consumer behaviors. Providers no longer watch the Kubernetes API server and only perform read and write operations on it.

Optimized Router Model

In Dubbo-Go versions earlier than 1.5, the router model includes the Priority and Router attributes, and the router chain only includes the Router attribute. The router chain can be viewed as a special type of router. In Dubbo-Go 1.5, the Router attribute is abstracted into the PriorityRouter and Chain attributes, which are inherited from the Router attribute. This makes the router chain a special type of router and clarifies the attribute inheritance relationship. See the following figure.


Review and Prospects

Dubbo-Go is a relatively stable and mature solution. Dubbo-Go 1.5 was developed in line with the evolution toward cloud native and its first new feature is the application service-level registration model, which is totally different from any existing model. Dubbo-Go 1.5 represents a new step toward cloud native. It also includes the optimizations discussed above.

Dubbo-Go 1.5.1, launched August 2020, is compatible with Dubbo 2.7.x and provides enhanced distributed capabilities.

Dubbo-Go 1.5.1 provides the Seata extension for distributed transactions. It also adds filters to enable server-end reception of extended identifiers (XIDs) and combines this feature with Seata-Golang to support distributed transactions. This will allow you to process distributed transactions in the Dubbo-Go framework by using more personalized methods.

Dubbo-Go 1.5.1 provides an important transmission link security feature based on Transport Layer Security (TLS). This feature will provide a unified entry for introducing more related features to suit different scenarios.

Dubbo-Go 1.5.1 also provides a registry model that supports inter-cluster load balancing among multiple registries. Figure 1 shows a business deployment model with two registries, in which all providers select registries at the same time. Figure 2 shows another business deployment model that implements inter-cluster load balancing during the registry selection process.

Figure 1

Figure 2

The RPC of the Getty framework was reused as the RPC layer of Dubbo-Go, making it impossible to separate protocols from application communication addresses. Zhantu, a member of the Alibaba middleware team, refactored the RPC layer of Dubbo-Go for connection reuse, which enables multi-protocol communication over the same consumer-provider TCP connection. The relevant PRs have been merged and released in Dubbo-Go 1.5.1.

Dubbo-Go 1.5.5 was released in January 2021, and features several enhancements, new features, and bug fixes. You can learn more about these updates by visiting the official GitHub page for Dubbo-Go 1.5.5

0 0 0
Share on

Alibaba Developer

162 posts | 30 followers

You may also like