Shulou(Shulou.com)06/02 Report--

From the perspective of programming development, Apache Dubbo (hereinafter referred to as Dubbo) is first of all a RPC service framework. Its biggest advantage is that it provides an interface agent-oriented service programming model, shielding the underlying remote communication details from developers. At the same time, Dubbo is also a service governance framework, which provides service discovery, traffic scheduling and other service governance solutions for distributed micro-services.

In this article, based on the above basic capabilities, we will try to break through the Dubbo system itself and explore how to make use of Dubbo's support for multi-protocol and multi-service discovery model to realize the interconnection between heterogeneous micro-service systems. In the actual business scenario, this can be used to solve the communication problems under the coexistence of heterogeneous technology systems, and help companies to achieve smooth migration between heterogeneous technology systems. solve the problems of address discovery and traffic scheduling in large-scale cross-region and multi-cluster deployment scenarios.

Transparent Service Development Framework for Interface Agent

Let's start with the familiar concept that Dubbo is a micro-service development framework. Just as Spring is the basic framework for developing Java applications, we often choose Dubbo as the basic framework for the development of micro-services. The biggest advantage of the Dubbo framework, I think, is its interface-oriented programming model, which makes developing remote service invocations just like developing local services (take the Java language as an example):

1. Service definition

Public interface GreetingsService {String sayHi (String name);}

2. Consumer invokes the service

/ / like invoking local services, it is completely transparent. @ Referenceprivate GreetingService greetingService;public void doSayHello (String name) {greetingService.sayHi ("Hello world!");}

The following figure is the basic working principle diagram of Dubbo. The service provider and the service consumer coordinate the address through the registry and exchange data through the agreed protocol.

Problems faced by isomorphic / heterogeneous micro-service system

The details of the Dubbo protocol itself and its service governance-related functions are not the focus of this article. Today, we will look at the challenges of building a micro-service system within the company from a higher level, and what solutions Dubbo can provide for architecture selection and migration.

Micro-services within a company may be developed based on the same service framework, such as Dubbo. For such an architecture, we call it an isomorphic micro-service system. However, the micro-services of some companies may be built using multiple different service frameworks, which we call heterogeneous micro-service systems. the co-existence of multiple different technology stack micro-service systems is still very common in large organizations. there may be many reasons for this. For example, it may be brought about by legacy systems, or it may be that the company is doing technology stack migration, or it may be the independent selection of different business units to meet their own special needs (which also means the long-term coexistence of heterogeneous micro-service systems).

1. Coexistence of heterogeneous micro-service systems

It is easy to think of a challenge: different systems usually use different RPC communication protocols and deploy independent registry clusters. In the face of this multi-protocol, multi-registry cluster scenario, how to achieve transparent address discovery and transparent RPC calls? If we do nothing, then each micro-service system can only perceive the service state in its own system, and the traffic is closed in its own system. In order to achieve the smooth migration from system A to system B, or to maintain the coexistence of multiple systems within the company for a long time, it is very important to solve the interconnection between different systems and realize the transparent scheduling of traffic.

2. Inside the Dubbo system

The problem of multi-protocol and multi-registry cluster may also exist in the isomorphic micro-service system, especially when the scale of micro-service within an organization grows to a certain order of magnitude.

We may have to use different communication protocols between different services, because different services face different business scenarios, which further leads to different characteristics of data transmission. we need to adopt protocols that are more suitable for various business characteristics. For example, in a typical scenario, we may use Dubbo protocol for ordinary business services, HTTP protocol for services that interact with FrontEnd, and gRPC protocol for services that need streaming data transmission. Another common problem within the Dubbo system is that in the scenario of large-scale distributed deployment, micro-service systems will be deployed across regions and across registries, which will lead to the problems of address synchronization and traffic scheduling between multiple clusters.

To sum up, both isomorphic and heterogeneous systems are faced with the problems of multi-protocol communication and multi-registry cluster address discovery. Dubbo currently supports multi-protocols and multi-registries, which can be said to be designed to solve the scenarios in the Dubbo homogeneous system we analyzed above. Therefore, let's start with the multi-protocols and multi-registries scenarios of the homogeneous system. Let's first understand the basic support of Dubbo multi-protocols and multi-registries and how they work. In the following chapter, we further explore how to expand this capability to support the interconnection of heterogeneous micro-service systems.

Multi-protocol and multi-registry mechanism in Dubbo system

We will use two scenario examples to specifically talk about the use and working principle of Dubbo's multi-protocol and multi-registry mechanism.

Multi-protocol

The above is a set of micro-services developed using Dubbo, and different protocols are used for communication between services. According to our research, it is a very common requirement to enable multi-protocols within the company. We will not explain the specific scenario here.

Application B, as a service provider, publishes five services, including:

DemoService1 DemoService2 publishes through dubbo protocol DemoService3 DemoService4 via gRPC protocol DemoService0 through dubbo and gRPC

Application A, as a consumer, uses dubbo protocol to consume DemoService1 DemoService2 and gRPC protocol to consume DemoService0.

Application B, as a consumer, uses gRPC protocol to consume DemoService2 DemoService4 and dubbo protocol to consume DemoService0.

The following is the specific code configuration:

1. Provider application B

2. Consumer application A

3. Consumer application C

Current status of Dubbo multi-protocol support

At present, the protocols supported by Dubbo include Dubbo, REST, Thrift, gRPC, JsonRPC, Hessian and so on, which basically cover most of the mainstream RPC communication protocols in the industry. It should be noted that the support of these protocols is in the form of directly integrating the official Release implementation. I think this is a good choice, which not only ensures the stability of protocol parsing itself, but also enables the Dubbo community to pay more attention to the improvement of Dubbo peripheral service governance capabilities. Imagine how much effort and time it would take for each protocol to achieve stable production availability if the Dubbo community provided its own implementation.

In addition to the above official support protocols, thanks to Dubbo's flexible extension mechanism, it is very easy to extend Dubbo protocols. Developers can add more protocol support to Dubbo at any time, including their own protocol extensions.

For support for the gRPC (HTTP/2) protocol, see "Dubbo's Exploration of Cross-language and Protocol Penetration: supporting HTTP/2 gRPC".

Problems that can be solved by multi-protocol

Seamlessly integrate the RPC framework into the service governance system of Dubbo. Through the protocol extension, the RPC protocol is incorporated into the Dubbo service development system, so as to reuse the programming model of Dubbo and the capabilities of service discovery and traffic control. For example, gRPC, whose service governance architecture is relatively weak and programming API is not friendly enough, is difficult to be directly used in micro-service development. Meet the call requirements of different scenarios.

Each service may be developed to meet different business needs, and the technology stacks of peripheral consumer applications may be varied. By enabling different communication protocols, the communication requirements of different scenarios can be optimized. Implement the migration between protocols.

By supporting a variety of protocols, with the help of the coordination of the registry, we can quickly meet the needs of intra-company protocol migration. For example, upgrade from self-owned protocol to Dubbo protocol, upgrade of Dubbo protocol itself, migration from Dubbo protocol to gRPC, migration from REST to Dubbo protocol, etc. Multiple registries

When the size of the service cluster is small, a centralized cluster deployment solution can well solve our business problems. However, with the growth of application scale and user traffic, we have to consider introducing a cross-regional and multi-cluster deployment solution for the business system. At this time, the registry cluster, which is closely related to the business system, is also faced with the selection of deployment scheme:

1. Continue to maintain globally shared registry clusters. The advantage of this architecture is that it is simple; the disadvantage is that the storage and push pressure of registry clusters will become great due to the storage of full address data, and the stability and performance of some registry products (such as Zookeeper, etc.) may face challenges in cross-cluster network deployment scenarios.

2. Each business cluster deploys an independent registry cluster. The advantage of multi-registry clusters is that it can not only solve the problem of cross-cluster network availability, but also reduce the storage and push pressure of registries; the disadvantage is that service frameworks (such as Dubbo, etc.) are required to have the ability to publish / monitor multiple registry clusters at the same time.

Let's take a look at the solution provided by Dubbo for the multi-registry clustering scenario.

There are two business clusters in the figure above, deployed in Beijing and Shanghai respectively. Each business cluster has its own independent registry cluster to solve the problem of transparent RPC communication of services between the two business clusters.

1. Service provider, issued by double registries

2. Service consumers make single / double registry subscriptions according to consumer demand.

Dubbo's support for heterogeneous registry clusters

Although we will do multi-registry cluster deployment, usually we deploy the same registry products, such as Zookeeper and Nacos;. For registry migration scenarios, Dubbo is required to provide support for more registry products or, most importantly, good scalability. The registry implementations officially supported by Dubbo are as follows:

It is worth mentioning here that the current Dubbo service registration / discovery model is based on interface granularity, and since version 2.7.5, Dubbo has introduced a new application-granularity service registration / discovery model. On the one hand, it helps to optimize Dubbo's current service discovery mechanism and improve service capacity, on the other hand, it is also very important for China Unicom's micro-service system represented by SpringCloud (which will be further mentioned in the next chapter). For more information on "Application granularity Service Discovery: service introspection", we will supplement it in the following articles or documents. Please stay tuned.

Traffic scheduling problem caused by multiple subscriptions

After the introduction of multi-registry clusters, Dubbo has one more layer of load balancing among registry clusters when selecting traffic locations:

At the Cluster Invoker level, we support the following location policies (version 2.7.5 +. For more information, please see the documentation):

1. Specify priority

2. Same as zone priority

3. Weight rotation

4. By default, stick to is available at will

Priority scheduling of traffic in the same region in scenarios applicable to multiple registries

In order to meet the needs of disaster recovery or service scalability, services / applications often need to be deployed in multiple independent computer rooms / regions. In the scenario where there is an independent registry cluster in each region, the priority scheduling of traffic in the same region can well solve the problems of delay and availability. Registry migration

A company's services may always be stored in a registry, such as Zookeeper, but at a certain point in time, for a variety of reasons, when we want to migrate to another registry, the multi-registry model ensures a smooth migration. Heterogeneous system interworking

The services developed by different micro-service systems are closed in their respective service discovery systems, and through a unified multi-registry model, services in different systems can discover each other. With the help of Dubbo Unicom heterogeneous micro service system

We mentioned above that there are various reasonable possibilities of heterogeneous micro-service architecture in an organization. Now let's take a specific look at the actual scenario of heterogeneous micro-service system and the solution of using Dubbo to achieve interconnection. First of all, let's take a look at what the heterogeneous micro-service system of Unicom looks like through a picture.

As shown in the figure above, some of our micro services can be built based on SpringCloud, gRPC, K8S or self-built systems, and they are isolated from each other and cannot be connected by default. When we build a set of micro-service system based on Dubbo, we can interconnect with each other by using Dubbo's multi-protocol and multi-service discovery model. Furthermore, as shown by the orange arrow in the figure, relying on the Dubbo system as the bridging layer, we can also achieve the connection between the two heterogeneous micro-service systems.

For the following example scenarios, since there is no unified standard at the address discovery level, let's assume that there are no obstacles to the construction of different systems at the address discovery level. We will focus on the basic process of migration and communication protocols. (with regard to address discovery, we will discuss it in depth after "Service introspection: service Discovery based on Application granularity".)

Protocol Migration (coexistence) in Dubbo system

Most developers have such an inherent understanding of Dubbo: to develop micro-service systems using Dubbo, the best solution is to use Dubbo protocol as the communication protocol between services. In fact, there is no need for us to be tied to the Dubbo RPC protocol at all. Dubbo as a micro-service development framework and Dubbo as a RPC protocol are two concepts, in fact, we can look at it separately. For example, we use Dubbo framework to develop business systems, there is no problem in choosing rest and gRPC communication (participate in the list of protocols supported by Dubbo), specific protocols according to business characteristics and technology planning is the most suitable.

At present, under the background of cloud native and Mesh, HTTP1/2 and gRPC protocols begin to receive more and more attention, on the one hand, because they do better in standardization, get more support from network equipment and infrastructure, and have better versatility and penetration. For many enterprises that are willing to migrate natively to the cloud, migrating to such protocols will undoubtedly be more helpful for future architecture upgrades.

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

The leftmost represents the old applications that have not yet been migrated, which still consume and provide Dubbo services during the migration process. The middle representatives are applications in transition, and some of them may be service providers, providing both Dubbo services for the old system on the left and gRPC services for the new system on the right; so they are all dual-protocol exposure services. On the far right are newly developed or migrated applications that can communicate fully using the gRPC protocol. After finally passing the intermediate state, we expect all applications to reach the leftmost application state and achieve complete gRPC protocol communication. Migration from Spring Cloud system to Dubbo system (coexistence)

As mentioned earlier, due to the problem of the service discovery model between SpringCloud and Dubbo, the address interworking between the two systems needs to be adapted by the Dubbo side. This part will be released in the "Service introspection" section of version 2.7.5, and we think it has been done for the time being.

Some applications in the Dubbo system are the key nodes of the transparent Unicom two systems, some service provider applications are issued with dual protocols, and some consumer applications are required to consume with selected protocols. Since the old Spring Cloud system is not allowed to make any changes, the key to the two systems of China Unicom is the REST protocol, for the application of the Dubbo side:

Some applications may consume SpringCloud services with REST protocol; some applications may expose REST protocol and share SpringCloud consumption; and Dubbo's own system will communicate through its own selected protocol. Here, it is more flexible and can be any one of Dubbo, REST, gRPC, etc. If the REST protocol is selected, it will become more natural for the interconnection with the SpringCloud system, because the protocols at both ends are unified.

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

For applications that provide services for consumption on the Spring Cloud side, specify that the service is exposed as rest protocol, or dual-protocol exposure (because if the service is to be invoked by applications in the new system):

As maintainers of Dubbo, although we have a clear bias here, we are talking about how to migrate from the SpringCloud system to the Dubbo system. But on the other hand, if you have chosen or are about to choose Dubbo to develop micro services, the future migration from Dubbo to SpringCloud is the same idea. Dubbo's multi-protocol and multi-registration model provides the same flexibility for two-way migration.

Transfer from self-built system to Dubbo system (coexistence)

This scenario is similar to the SpringCloud migration mentioned in the previous section. The biggest difference is that the rest protocol is officially supported by Dubbo by default. For private communication protocols in the existing micro-service system, you need to extend Dubbo Protocol to provide protocol-level support. For more information on how to expand Protocol, please see the following official documents:

Http://dubbo.apache.org/zh-cn/docs/dev/impls/protocol.html

Summary and prospect

In order to realize the coexistence or migration between heterogeneous micro-service systems, the key point is to open up the protocols and service discovery between heterogeneous systems. Thanks to the support of Dubbo to multi-protocol and multi-registration model, we can easily make Dubbo become the middle layer of bridging heterogeneous micro-service systems. Students who are familiar with the details of Dubbo multi-protocol implementation may worry that in a scenario with a large number of services, multi-protocol registration will double the number of addresses and affect address push performance.

In addition, in the section of "connecting heterogeneous micro-service systems with Dubbo", we do not explain in detail how to realize transparent service discovery between heterogeneous systems. With regard to this part of service discovery, we will elaborate on it in the next article to see how the introduction of a new service discovery mechanism in Dubbo version 2.7.5 solves this problem. Stay tuned for follow-up articles and Dubbo official documentation.

Author information:

Liu Jun, GitHub account Chickenlj,Apache Dubbo PMC, the core maintainer of the project, witnessed the whole process of Dubbo from restarting open source to graduating from Apache. Now he works as the native application platform team of Ali Yunyun, and participates in the work related to service framework and micro-services. At present, he is mainly promoting the open source cloud biochemistry of Dubbo.

"Alibaba Cloud Native focus on micro-services, Serverless, containers, Service Mesh and other technology areas, focus on cloud native popular technology trends, cloud native large-scale landing practice, to be the best understanding of cloud native developers of the technology circle."

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.