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

Abstract: introduction: recently, at the Apache Dubbo developer Salon Hangzhou Station, Cao Shengli, an expert in middleware technology from Alibaba, shared the planning of the Dubbo2.7 version with the developers. This article will explore the thinking and implementation behind Dubbo 2.7s.

Cdn.com/1533ca3c248d38eee9102c7d3bdfb4cec92642b9.png ">

Introduction:

Recently, at the Apache Dubbo developer Salon Hangzhou Station, Cao Shengli, a middleware expert from Alibaba, shared the Dubbo2.7 version plan with the developers.

This article will explore the thinking and implementation behind Dubbo 2.7s.

Author: (sorted by last name Pinyin, ranking first and last)

Cao Shengli (photo): Apache Dubbo Committer.

Liu Jun (tortoise): Apache Dubbo Committer.

Dubbo 2.7 will focus on asynchronous support optimization, metadata transformation, introduce the features of JDK8, Netty4.0 and MetricsAPI to improve the efficiency of service invocation and service governance, as well as scalability, and fix a number of issues raised by the community.

It is reported that 2.7.x will be the graduation version of Dubbo in the Apache community, and Dubbo will have the opportunity to become another Apache top-level project (TLP) from Alibaba after RocketMQ.

Optimize support for async

The realization of full asynchronous programming based on Dubbo is a new function introduced after the enhancement of the existing asynchronous mode in version 2.7.0. The previous version is not very friendly to asynchronous support, and there are some problems. Version 2.7 will make some targeted enhancements based on CompletableFuture in JDK8 and add @ Dubboasync annotation, which can generate asynchronization-related code.

»Asynchronous mode prior to version 2.6.x

Versions 2.6.x and earlier provide some asynchronous programming capabilities, including asynchronous calls on the Consumer side, parameter callbacks, event notifications, and so on. However, the current asynchronous approach has the following problems:

The way to get Future is not direct enough.

Future interface cannot implement automatic callback. Although custom ResponseFuture supports callback, it supports limited asynchronous scenarios, such as mutual coordination or combination between Future, etc.

Provider side async is not supported

Take the asynchronous usage of Consumer as an example:

1. Define a common synchronous interface and declare that it supports asynchronous invocation

Public interface FooService {String findFoo (String name);}

2. Obtain Future through RpcContext

/ / this call will immediately return nullfooService.findFoo (fooId); / / get the Future reference of the call, and when the result is returned, it will be notified and set to this FutureFuture fooFuture = RpcContext.getContext () .getFuture (); fooFuture.get ()

Or

/ / this call will immediately return nullfooService.findFoo (fooId); / / get the ResponseFuture built into Dubbo and set the callback ResponseFuture future = ((FutureAdapter) RpcContext.getContext (). GetFuture ()). GetFuture (); future.setCallback (new ResponseCallback () {@ Overridepublic void done (Object response) {System.out.print (response);} @ Overridepublic void caught (Throwable exception) {exception.printStackTrace ();}}))

From this simple example, we can experience some inconveniences in use:

The synchronous interface of findFoo cannot directly return the Future representing the asynchronous result, which can be further obtained through RpcContext.

Future only supports blocking get () interface to get results.

Callbacks can be set by getting the built-in ResponseFuture interface. However, the API for obtaining ResponseFuture is inconvenient to use, and only callback is supported. Other asynchronous scenarios are not supported, such as scenarios in which multiple Future work together.

»2.7.0 CompletableFuture-based enhancements

Students who understand the evolution history of Future in Java should know that Future used in Dubbo 2.6.x and earlier was introduced in Java 5, so there are some of the above functional design problems, while the introduction of CompletableFuture in Java 8 further enriches the Future interface and solves these problems.

Dubbo has upgraded its support for Java 8 in version 2.7.0 and enhanced the current asynchronous functionality based on CompletableFuture.

1. You can directly define the service interface that returns CompletableFuture. Through this type of interface, we can more naturally implement asynchronous programming on the Consumer and provider side.

Public interface AsyncService {CompletableFuture sayHello (String name);}

2. If you do not want to define the return value of the interface as Future type, or if there is a defined synchronous type interface, you can define an additional asynchronous interface and provide a method of Future type.

Public interface GreetingsService {String sayHi (String name);} @ AsyncFor (GreetingsService.class) public interface GrettingServiceAsync extends GreetingsService {CompletableFuture sayHiAsync (String name);}

In this way, Provider can only implement the sayHi method; while Consumer can get a Future instance by calling sayHiAsync directly, and the Dubbo framework is automatically converted to a call to the sayHi method on the provider side. Providing an asynchronous method definition for each synchronous method is cumbersome, and further, using the AnnotationProcessor implementation in the Dubbo ecology can help us automatically generate asynchronous method definitions.

3. Similarly, if your original interface definition is not a return value of type Future, provider-side async also provides a programming interface similar to Async Servlet in Servlet3.0: RpcContext.startAsync ().

Public interface AsyncService {String sayHello (String name);} public class AsyncServiceImpl implements AsyncService {public String sayHello (String name) {final AsyncContext asyncContext = RpcContext.startAsync (); new Thread (()-> {asyncContext.write ("Hello" + name + ", response from provider.");}) .start (); return null;}}

At the beginning of the method body, RpcContext.startAsync () starts the async, starts the new thread to execute the business logic asynchronously, and writes the result back through asyncContext.write after the time-consuming operation is completed.

4. RpcContext returns CompletableFuture directly

CompletableFuture f = RpcContext.getContext () .getCompletableFuture ()

All the above enhancements are based on compatibility with existing asynchronous programming, so asynchronous programs based on version 2.6.x can run smoothly without any modification.

Metadata transformation

The transformation of metadata is mainly carried out from the point of view of adapting the micro-service registry, configuring the separation model of the center, reducing the pressure on the registry, and improving the ability and efficiency of service governance. The current version of Dubbo has dozens of key/value key-value pairs in the registry's URL, which contains all the metadata for a service. On the basis of large-scale practice, we gradually find that there are some problems with the metadata organized in this way:

URL stored in the registry is too long:

This leads to a sharp increase in storage pressure and a significant decline in the push efficiency of change events; at the same time, it brings additional computing pressure to subscribers, especially in large-scale scenarios.

The registry assumes the function of too much service governance configuration:

Responsible for the synchronization of the initial configuration, as well as storing various runtime configuration rules. On the one hand, this aggravates the pressure on the registry, on the other hand, the flexibility of configuration rules is also limited, and it is also unable to take advantage of the powerful functions brought by some more professional micro-service configuration centers.

The functional positioning of the property is not clear:

Methods, pid and owner all seem to be registered for service query services, but when we actually develop or operate the service management system, we find that such crude information is difficult to meet the query governance requirements. We have more properties and need richer registration data. Take methods as an example, although the content of the method list is already very long, when we want to test / mock functions in the OPS development service, we find that the required data such as method signatures still cannot be obtained.

To sum up the above problems, we divide the metadata in URL into three parts:

Metadata information

The complete definition of the interface: contains the interface name, the method contained in the interface, and the input and exit parameter information contained in the method. It is very important for service testing and service mock.

Execute data on the link

Parameters need to be passed from the provider side to the consumer side for the consumer side to perceive. Such as token,timeout, etc.

Service self-owning configuration & Ops requirements

Only those that need to be used on the provider side or the consumer side, such as executes, document, etc.

Support configuration center

Configuration Center is a dynamic version of dubbo.properties, supporting granularity including global, application-level, and service-level dimensions. Through the above metadata transformation, configuration center support, and the original registry, it will exist in the Dubbo system:

Registry:

Ideally, the registry will only be used for the synchronization of critical service information (core links), further reducing the storage pressure on the registry, improving the efficiency of address synchronization, and alleviating the current Consumer memory computing pressure caused by URL redundancy during large-scale push.

Configuration Center:

To solve the problem of coupling current configuration and address information, by abstracting the dynamic configuration layer, developers can interface with more commonly used and professional configuration centers in micro-service scenarios, such as Nacos, Apollo, Consul, Etcd, etc., and provide more flexible and rich configuration rules, including services and applications with different granularity configurations, richer routing rules, centralized management dynamic parameter rules, and so on.

Service query governance center (including metadata)

For pure service query related data, including Consumer service subscription data, are often immutable after registration and do not need synchronization between nodes, such as methods, owner and other key that can be seen by current URL, as well as all Consumer-side URL.

Therefore, we introduced the storage module in 2.7.0 to store this part of data, which will be closely integrated with the new version of Dubbo-ops as the data basis for rich service query, testing and other functions, so this part of the data will be further enriched. Generally speaking, whether or not to enable this feature will be optional for users, and the implementation will also be extensible, such as we plan to support Redis, Zookeeper and so on.

Routing rules

Dubbo provides some scalable routing rules, among which conditional routing and script routing are representative. 2.6.x and the following:

Routing rules are stored in the registry

Only service-granularity routing is supported, and routing rules cannot be defined at the application level.

Support for routing caching, but basically not scalable

A service or application allows multiple routing rules to be defined, and service governance cannot be controlled

In implementation, each rule generates a Router instance and loads it dynamically.

Starting from the problem, we redesigned the original routing configuration from the registry to the configuration center. The boundaries of configuration and service discovery are clearly defined. Added RouterChain to restructure routing rule logic, add application-level routing, Tag route optimization, etc. For service-level routing, it is accurate to a single service, avoiding the problem that routing rules cannot be clarified.

Let's briefly summarize the various types of collaborative relationships.

RegistryDirectory, which contains a complete list of addresses, connects directly to the registry, and dynamically receives registry address changes.

RouterChain, a list assembled by Router, is the entrance to the routing action, receives the incoming address list and returns the filtered address list to the caller, while the specific filtering action is delegated to Router to perform

Router receives and parses the routing rules, receives the address list, completes the filtering action according to the routing rules, and returns the filtered address list. It is also a ConfigurationListener that receives routing rule updates at any time.

ConfigurationListener, callback API for dynamic configuration changes

DynamicConfiguration, dynamic configuration of SPI, supported extension implementations including Zookeeper, Apollo, Nacos, etc.

Dubbo will officially release version 2.7.0 in the near future, which coincides with the one-year anniversary of Dubbo's announcement of restart. This year, Dubbo released 13 versions, a total of 24 PPMC/Committer,144-bit Contributor in the community, and held 5 developer salons in Beijing, Shanghai, Shenzhen, Chengdu and Hangzhou, but there is no end to the road to open source technology. We welcome more developers to participate and share in Dubbo meetup to build Dubbo ecology.

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.