From the perspective of programming development, Apache Dubbo (hereinafter referred to as Dubbo) is first of all an RPC service framework. Its biggest advantage lies in providing a service programming model oriented to interface proxy, which shields the remote communication details at the bottom for developers. Dubbo is also a service governance framework that provides service discovery, traffic scheduling and other service governance solutions for distributed microservices.

In this paper, we will take the above basic capabilities as the background to try to break through the Dubbo system itself and explore how to use Dubbo’s support for multi-protocol and multi-service discovery model to realize the interconnection between heterogeneous micro-service systems. In actual service scenarios, it can be used to solve communication problems when heterogeneous technology systems coexist, help companies realize smooth migration between heterogeneous technology systems, and solve problems such as address discovery and traffic scheduling in large-scale trans-regional and multi-cluster deployment scenarios.

Transparent service development framework for interface proxy

Let’s start with the familiar concept of Dubbo as a microservices development framework. Just as Spring is the basic framework for developing Java applications, Dubbo is often chosen as the basic framework for developing microservices. The greatest strength of the Dubbo framework I think lies in its interface oriented programming model, which makes developing remote service invocations almost like developing local services (take the Java language as an example) : 1. Service definition

public interface GreetingsService {
String sayHi(String name);
}
Copy the code

The consumer invokes the service

// Completely transparent, just like calling a local service. @Reference private GreetingService greetingService; public voiddoSayHello(String name) {
greetingService.sayHi("Hello world!");
}
Copy the code

The following diagram shows the basic working principle of Dubbo, where service providers and service consumers coordinate addresses through registries and exchange data through agreed protocols.

Problems faced by isomorphic/heterogeneous microservice system

Instead of focusing on the Dubbo protocol itself and the details of its service governance capabilities, we’ll take a higher level look at the challenges of building microservices within a company and what Dubbo can offer in terms of architecture selection and migration.

A company’s internal microservices may all be based on the same service framework, such as Dubbo, for such an architecture, we call it isomorphic microservices architecture; Some companies’ microservices may be constructed by using multiple different service frameworks, which is called heterogeneous microservice system. The co-existence of multiple microservice systems with different technology stacks is very common in large organizations. There may be many reasons for this situation. For example, it could be legacy systems, it could be a technology stack migration, or it could be a separate selection by different business units to meet their specific needs (which also means long-term coexistence of heterogeneous microservices).

1. Coexistence of heterogeneous microservice systems

One challenge we can easily imagine is how to achieve transparent address discovery and transparent RPC calls between different systems, which often use different RPC communication protocols and deploy separate registry clusters. If we do nothing, then each microservice system is only aware of its own service state and traffic is closed within its own system. In order to achieve smooth migration from system A to system B, or to maintain long-term coexistence of multiple systems within the company, it is very important to solve the interconnection between different systems and realize the transparent scheduling of traffic.

2. The problem of multi-protocol and multi-registry cluster within Dubbo system may also exist in homogeneous microservice system, especially when the size of microservice within an organization grows to a certain magnitude.

  • We may need to adopt different communication protocols between different services, because different services face different business scenarios, which further lead to different data transmission characteristics. We need to adopt protocols that are more suitable for different business characteristics. For example, we might use Dubbo protocol for common business services, HTTP protocol for services interacting with FrontEnd, and gRPC protocol for services requiring streaming data transmission, etc.
  • Another common problem within the Dubbo system is that in a large-scale distributed deployment scenario, the microservice system will be deployed across regions and registries. In this case, the problems of address synchronization and traffic scheduling between multiple clusters will occur.

To sum up, both homogeneous and heterogeneous systems face the problem of address discovery for multi-protocol communication and multi-registry cluster. Dubbo at present is to support the deal, the registry, can say is to solve the problem of Dubbo isomorphism of the above analysis we designed for the system within the scene, so we from homogeneous system under the agreement, the registry scenario, understand Dubbo agreement, first the basic support of the registry and how they work. The next chapter further explores how to extend this capability to support interconnection of heterogeneous microservices.

Multi – protocol, multi – registry mechanism in Dubbo system

We will use two examples to explain how Dubbo’s multi-protocol and multi-registry mechanism works.

multi-protocol

The above is a set of micro services developed by Dubbo, and different protocols are used for communication between services. According to our survey, it is very common to enable multiple protocols in the company, and we will not explain the specific scenarios here. Application B, as a service provider, published 5 services, among which:

  • DemoService1 DemoService2 Is published using the Dubbo protocol
  • DemoService3 DemoService4 Is published using the gRPC protocol
  • DemoService0 is released over dubbo and gRPC

As the consumer, application A uses dubbo to consume DemoService1 DemoService2 and gRPC to consume DemoService0.

As the consumer, application B uses gRPC to consume DemoService2 DemoService4 and Dubbo to consume DemoService0.

Here is the code configuration:

1. Provider application B

<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService1" protocol="dubbo"/>
<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService2" protocol="dubbo"/>

<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService3" protocol="grpc"/>
<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService4" protocol="grpc"/>

<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService0" protocol="dubbo, grpc"/>
Copy the code

2. Consumer application A

<dubbo:reference protocol="dubbo" interface="org.apache.dubbo.samples.basic.api.DemoService1"/>
<dubbo:reference protocol="dubbo" interface="org.apache.dubbo.samples.basic.api.DemoService2"/>

<dubbo:reference protocol="grpc" interface="org.apache.dubbo.samples.basic.api.DemoService0"/>
Copy the code

3. Consumer application C

<dubbo:reference protocol="grpc" interface="org.apache.dubbo.samples.basic.api.DemoService3"/>
<dubbo:reference protocol="grpc" interface="org.apache.dubbo.samples.basic.api.DemoService4"/>

<dubbo:reference protocol="dubbo" interface="org.apache.dubbo.samples.basic.api.DemoService0"/>
Copy the code

Dubbo multi-protocol support status quo

Dubbo currently supports protocols such as Dubbo, REST, Thrift, gRPC, JsonRPC, and Hessian, which basically covers most of the mainstream RPC communication protocols in the industry. It is important to note that these protocols are supported in the form of direct integration with the official Release implementation, which I think is a good choice to ensure the stability of the protocol resolution itself and enable the Dubbo community to focus more on improving the governance capabilities of Dubbo’s peripheral services. Imagine if the Dubbo community provided the implementation for each protocol itself, how much effort and time it would take to get each protocol to stable production availability.

In addition to the above officially supported protocols, Dubbo’s flexible extension mechanism makes it easy to extend protocols for Dubbo, and developers can always add more protocol support to Dubbo, including their own protocol extensions.

For support for the gRPC (HTTP/2) protocol, see Dubbo’s Exploration of Cross-language and protocol penetration: Support for HTTP/2 gRPC.

Problems that multiple protocols can solve

  • Seamlessly integrate the RPC framework into Dubbo’s service governance architecture. Through protocol extension, RPC protocol is incorporated into Dubbo service development system, so that Dubbo programming model, service discovery, traffic control and other capabilities can be reused. For example, gRPC, whose service governance system is relatively weak and programming API is not friendly enough, is difficult to be directly used for microservice development.
  • Meet the call requirements of different scenarios. Each service may be developed to meet different business requirements, and the technology stack applied by the peripheral consumer end may be diverse. By enabling different communication protocols, the communication requirements of different scenarios can be optimized.
  • Implement migration between protocols. By supporting multiple protocols and coordinating registries, the need for intra-company protocol migration can be quickly met. For example, the Dubbo protocol is upgraded from its own protocol to Dubbo, Dubbo itself is upgraded, Dubbo is migrated from Dubbo to gRPC, and REST is migrated to Dubbo.

Multi-registry

When the service cluster scale is small, a centralized cluster deployment solution can solve our business problems well. However, with the growth of the application scale and the increase of user traffic, we have to consider the introduction of trans-regional and multi-cluster deployment scheme for the business system, while registry clusters closely related to the business system are also facing the selection of deployment scheme:

1. Continue to maintain the globally shared registry cluster. The advantage of this architectural approach is simplicity; The disadvantages are that the registry cluster needs to store the full amount of address data, so the storage and push pressure will be great. In addition, some registry products (such as Zookeeper) may face stability and performance challenges in the scenario of cross-cluster network deployment.

2. Deploy an independent registry cluster for each service cluster. The advantage of a multi-registry cluster is that it can solve the problem of network availability across the cluster and reduce the storage and push pressure of the registry. The disadvantage is that the service framework (such as Dubbo, etc.) is required to be able to publish/listen to multiple registry clusters simultaneously.

Let’s take a closer look at Dubbo’s solution for a multi-registry cluster scenario.

The figure above shows two business clusters deployed in Beijing and Shanghai respectively. Each business cluster has its own independent registry cluster to solve the problem of transparent RPC communication between the services of the two business clusters. 1. Service provider side, dual registry publishing

<dubbo:registry id="beijingRegistry" address="zookeeper://${zookeeper.address1}" default="false"/>
<dubbo:registry id="shanghaiRegistry" address="zookeeper://${zookeeper.address2}" />

<dubbo:service interface="org.apache.dubbo.samples.multi.registry.api.HelloService" ref="helloService" registry="shanghaiRegistry,beijingRegistry"/>
<dubbo:service interface="org.apache.dubbo.samples.multi.registry.api.DemoService" ref="demoService" registry="shanghaiRegistry,beijingRegistry"/>
Copy the code

2, service consumer, according to the consumer demand to do single/double registry subscription

<dubbo:registry id="beijingRegistry" address="zookeeper://${zookeeper.address1}" default="false" preferred="true" weight="100"/>
<dubbo:registry id="shanghaiRegistry" address="zookeeper://${zookeeper.address2}" default="true" weight="20"/>

<dubbo:reference interface="org.apache.dubbo.samples.multi.registry.api.DemoService"/>

<dubbo:reference  interface="org.apache.dubbo.samples.multi.registry.api.DemoService" registry="beijingRegistry, shanghaiRegistry"/>

<dubbo:reference interface="org.apache.dubbo.samples.multi.registry.api.HelloService" registry="beijingRegistry"/>

<dubbo:reference interface="org.apache.dubbo.samples.multi.registry.api.HelloService" registry="shanghaiRegistry,shanghaiRegistry"/>
Copy the code

Dubbo support for heterogeneous registry clusters

Although we do cluster multi-registry deployments, we usually deploy the same registry products, such as Zookeeper, Nacos; For registry migration scenarios, Dubbo is required to provide support for more registry products or, most importantly, to be able to scale well. Dubbo currently supports the following registry implementations:

One important point to note here is that Dubbo’s service registration/discovery model is currently interface-grained, while starting with version 2.7.5, Dubbo has introduced an application-grained service registration/discovery model. On the one hand, this helps to optimize Dubbo’s current service discovery mechanism and increase service capacity; on the other hand, it is also very important for China Unicom’s micro-service system represented by SpringCloud (more on this in the next chapter). Stay tuned for more information on Application Granularity Service Discovery: Service Introspection, which we will supplement in upcoming articles and documents.

Traffic scheduling problems caused by multiple subscriptions

With the introduction of multi-registry clustering, Dubbo added a layer of load balancing between registries in traffic location:

At the level of Cluster Invoker, we support the following location selection strategies (version 2.7.5+, please refer to the document for specific use) :

1. Specify a priority

<! - from preferred ="true"Registry address will be selected first, only if the registry has no available address will Fallback to other registries --> <dubbo:registry address="zookeeper://${zookeeper.address1}" preferred="true" />
Copy the code

2. The same zone is preferred

<! --> <dubbo:registry address="zookeeper://${zookeeper.address1}" zone="beijing" />
Copy the code

3, weight round selection

<! -- Addresses from Beijing and Shanghai clusters will be allocated traffic in a 10:1 ratio --> <dubbo:registry id="beijing" address="zookeeper://${zookeeper.address1}"Weight = "100" / > < dubbo: registry id ="shanghai" address="zookeeper://${zookeeper.address2}"Weight = "10" / >Copy the code

4, default, stick to any available

Multiple registries

  • Traffic scheduling in the same region For DISASTER recovery (Dr) or service scalability requirements, services and applications must be deployed in multiple independent equipment rooms or regions. If each region has an independent registry cluster, traffic scheduling in the same region can effectively solve latency and availability problems.
  • Registry migration A company’s services may always be stored in one registry, such as Zookeeper, but at some point in time, for various reasons, when we move to another registry, the multi-registry model ensures a smooth migration.
  • Interworking between heterogeneous systems The services developed by different microservice systems are closed in their own service discovery systems. However, through a unified multi-registry model, services of different systems can be discovered each other.

With the help of Dubbo Unicom’s heterogeneous micro-service system

As mentioned above, there are various reasonable possibilities for heterogeneous microservices in the organization. Now let’s take a look at the actual scenario of heterogeneous microservices and the solution of interconnection using Dubbo. First of all, let’s see what kind of scene unicom’s heterogeneous micro-service system is through a picture.

As shown in the figure above, some of our microservices can be built based on SpringCloud, gRPC, K8S or self-built systems, which are isolated from each other by default and cannot be connected. When we build a set of micro-service system based on Dubbo, we can make use of Dubbo’s multi-protocol and multi-service discovery model to achieve the interconnection between each micro-service system. Further, as shown by the orange arrow in the figure, relying on the Dubbo system as the bridge layer, we can also realize the connection between two heterogeneous microservice systems.

For the following sample scenarios, since there is no unified standard on the address discovery level, we will assume that there are no obstacles for different systems to be built at the address discovery level. We will focus on the basic process of migration and communication protocol. (For the address discovery part, we will explore this further in the follow-up service Introspection: Service Discovery based on Application Granularity.)

Protocol migration (Coexistence) in Dubbo architecture

Most developers have a built-in understanding of Dubbo that when developing microservices using Dubbo, it is best to use the Dubbo protocol as the communication protocol between services. In fact, we don’t need to be tied to the Dubbo RPC protocol at all. Dubbo as a micro-service development framework and Dubbo as RPC protocol are two concepts that can be completely separated. For example, for the business system developed with Dubbo framework, there is no problem in choosing REST and gRPC communication (join the list of protocols supported by Dubbo). Specific protocols are most appropriate for business characteristics and technology planning.

At present, in the context of cloud native and Mesh, HTTP1/2 and gRPC protocols begin to receive more and more attention. On the one hand, it is natural that they do better in standardization, get more network equipment and infrastructure support, and have better versatility and penetration. For many enterprises that are willing to move to cloud native, moving to such protocols will undoubtedly help with future architecture upgrades.

The following figure illustrates an intermediate state of migration from the Dubbo protocol to the gRPC protocol in a Dubbo architecture.

  • The leftmost represents older applications that have not yet been migrated and that still consume and provide Dubbo protocol services during the migration process.
  • In the middle are applications that are being migrated. Some of them may be service providers that provide Dubbo protocol services to the older systems on the left. To provide gRPC service for the new system on the right; So they are both dual-protocol exposure services.
  • On the far right are newly developed or migrated applications that can communicate fully with the gRPC protocol.
  • Finally, after passing the intermediate state, we expect all applications to reach the state of the leftmost application to achieve complete gRPC protocol communication.

Spring Cloud architecture migrating to Dubbo Architecture (Coexistence)

As mentioned above, due to the problems of the service discovery model between SpringCloud and Dubbo, the address communication between the two systems needs to be appropriate on the Dubbo side. As for this part, it will be released in the next version of “Service Introspection” in 2.7.5, so we temporarily think it has been solved.

Some applications in the Dubbo system are the key nodes of the transparent connection between the two systems. Some service provider applications should be issued by dual protocols, and some consumer applications should be consumed by selected protocols. Since the old Spring Cloud architecture does not allow any changes, the key to connecting the two systems is the REST protocol. For Dubbo side applications:

  • Some applications may consume SpringCloud’s services using REST protocols;
  • Some applications may expose REST protocols for SpringCloud consumption;
  • Dubbo’s own system through their own protocol communication, here is more flexible, can be Dubbo, REST, gRPC, and so on any of them. If the REST protocol is selected, the connection to the SpringCloud architecture becomes more natural because the protocols are unified at both ends.

For applications that consume Spring Cloud services, configure the service:

<dubbo:reference interface ="xxx.SpringService" protocol="rest"/>
Copy the code

For applications that provide services for consumption on the Spring Cloud side, specify that the service is exposed to REST or dual-protocol exposure (because if the service is also called by applications within the new architecture) :

<dubbo:service interface="xxx.NewService" protocol="rest,dubbo"/>
Copy the code

As maintainers of Dubbo, although we have an obvious bias here, we talk about how to migrate from SpringCloud to Dubbo. But on the flip side, if you have or will choose Dubbo to develop microservices, it is the same idea to migrate from Dubbo to SpringCloud in the future. Dubbo’s multi-protocol, multi-registry model provides the same flexibility for both migrations.

Migrating a self-built system to a Dubbo system (Coexistence)

This scenario is somewhat similar to the SpringCloud migration described in the previous section, with the major difference being that the REST protocol is officially supported by Dubbo by default, while for existing proprietary communication protocols within the microservices architecture, You need to extend the Dubbo Protocol to provide support at the Protocol level. For details on how to extend the Protocol, see the following official documents: dubbo.apache.org/zh-cn/docs/…

Summary and Prospect

In order to realize the coexistence or migration between heterogeneous microservice systems, the key point lies in the discovery of protocols and services between heterogeneous systems. Thanks to Dubbo’s support of multi-protocol and multi-registration model, we can easily make Dubbo become the middle layer of bridging heterogeneous microservice system. Students familiar with the details of Dubbo multi-protocol implementation may worry that multi-protocol registration will double the number of addresses in a scenario with a large number of services, thus affecting the performance of address push. In addition, in the section of “Using Dubbo to connect heterogeneous microservice System”, we did not give a detailed explanation on how to realize the transparent service discovery among heterogeneous systems. This part of service discovery will be covered in an upcoming article to see how the new service discovery mechanism introduced in Dubbo version 2.7.5 addresses this issue. Stay tuned for subsequent articles and the official Dubbo documentation.

Author information: Liu Jun, GitHub account Chickenlj, Apache Dubbo PMC, the project core maintenance, witnessed the whole process of Dubbo from the restart of open source to Apache graduation. Currently, I am working in aliyun cloud native application Platform team, participating in service framework and micro-service related work, and mainly promoting Dubbo open source cloud biogenics.

“Alibaba Cloud originators pay close attention to technical fields such as microservice, Serverless, container and Service Mesh, focus on cloud native popular technology trends and large-scale implementation of cloud native, and become the technical circle that knows most about cloud native developers.”