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:
Dubbo-Go is still evolving and will soon incorporate the following capabilities:
As difficult as this might be, we will proceed with our initial mission.
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:
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:
We recommend that you use Nacos or etcd for newly launched businesses because they are more reliable and stable.
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.
The invocation structure provides attribute support to store intra-process attributes. Unlike attachments, attributes are not transmitted from consumers to providers.
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.
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.
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
Guidelines for Transforming from a Monolithic Architecture to a Serverless Architecture
508 posts | 48 followers
FollowAlibaba Developer - May 20, 2021
Alibaba Cloud Native Community - July 2, 2021
Alibaba Cloud Native Community - December 30, 2021
Aliware - April 13, 2020
Alibaba Cloud Native Community - March 6, 2023
Alibaba Cloud Native Community - April 23, 2023
508 posts | 48 followers
FollowAccelerate and secure the development, deployment, and management of containerized applications cost-effectively.
Learn MoreAlibaba Cloud Container Service for Kubernetes is a fully managed cloud container management service that supports native Kubernetes and integrates with other Alibaba Cloud products.
Learn MoreProvides a control plane to allow users to manage Kubernetes clusters that run based on different infrastructure resources
Learn MoreA secure image hosting platform providing containerized image lifecycle management
Learn MoreMore Posts by Alibaba Cloud Native Community