This article has been included github.com/lkxiaolou/l… Welcome to star. About the author: Didi middleware development engineer, wechat public account “bug catching master”, follow me, give you the purest technical dry goods.

background

A long time ago, web applications were single application architectures, with low traffic, all functions and codes deployed together and low cost. The DATABASE access framework ORM is key here.

Later, as traffic gradually increased, the single application was split into multiple unrelated applications, which was called vertical architecture. At this time, the Web framework MVC was the key to accelerate front-end page development.

Later, as vertical applications became larger and larger, interactions between applications became inevitable, and RPC, a distributed service framework, became the key.

dubbo

Remote Procedure Call (RPC) is a simple and convenient way to Call a local method. Common RPC frameworks include Dubbo, GRPC, thrift, etc.

Dubbo, | ˈ d ʌ b goes ʊ | is a high-performance, lightweight open source Java RPC framework, it provides three main core competencies: an interface of remote method invocation (rmi), intelligent fault tolerance and load balancing, and automatic registration and discovery of services. There are a lot of companies using Dubbo.

All men are mortal

The development of Dubbo can be summarized into three stages:

  • Born in Alibaba: Dubbo’s predecessor was born inside Alibaba in 2008, opened source in 2011, and stopped updating after the release of version 2.5.3 in 2012
  • Dangdang Continued life: In 2014, Dangdang released Dubbox, which is a dubbo version based on Alibaba’s dubbo 2.5.3, adding rest protocol
  • Restart Apache for Summit: In 2017, Ali restarted dubbo project, and entered Apache incubation in 2018, and became apache top project in 2019. Meanwhile, it also released dubo.js, Dubo-Go and other multi-language versions of Dubbo. In 2020, it released 3.0 strategic plan to develop cloud native project

Currently supported versions are 2.6.x and 2.7.x:

  • 2.6. X is mainly bugfix and a small amount of enhancements, thus fully guaranteeing stability
  • 2.7.x, as the major development version of the community, has been continuously updated with a large number of new features and optimizations, while also bringing some stability challenges

agreement

The dubbo native protocol is defined as follows:

  • 0-15: magic number, check whether it is dubbo protocol
  • 16: Determine whether to request or return
  • 17: Determine whether return is expected
  • 18: Checks whether it is an event message, such as a heartbeat event
  • 19-23: Serialization flag
  • 24-31: Flag response status (similar to HTTP status)
  • 32-63: request id
  • 64-95: Content length (bytes)
  • 96 -? : Serialized content (newline delimited)

Dubbo protocol has the advantages of compact design and consistent headers. The disadvantages are that resources cannot be located using headers. The header and body fields are redundant, and the protocol cannot be extended.

Of course, it also supports the extension of a variety of protocols, such as dangdang extended REST protocol, and the latest support for GRPC protocol

Speaking of extensions, which is probably the biggest highlight of Dubbo’s design, dubbo’s extensions are based on the Service Provide Interface (SPI) design and can achieve a lot of functionality without intrusive code.

The registry

The registry has the following features:

  • Dynamic membership, whereby service providers expose themselves dynamically to consumers through registries without requiring consumers to update their profiles individually.
  • Dynamically discover services. Consumers can dynamically discover new services without restart.
  • Unified configuration prevents service configuration inconsistency caused by local configuration.
  • Dynamic adjustment. The registry supports dynamic adjustment of parameters. New parameters are automatically updated to all relevant service nodes.
  • Unified management: Service nodes can be centrally managed and configured based on the registry data. The main registry for Dubbo is zooKeeper or NacOS, and there are many extensions.

The cluster

Clustering includes routing, load balancing, and cluster fault tolerance. Here is an example of the differences between these three aspects:

A Dubbo user service with 10 deployed in Beijing and 20 in Shanghai. A service consumer in Hangzhou makes a call and the following happens:

  1. According to the configured routing rules, if a call is initiated from Hangzhou, the call is routed to 20 providers in Shanghai.
  2. According to the configured random load balancing policy, one provider is randomly selected to be invoked
  3. Let’s say we get to the seventh provider at random. Calling the seventh provider failed. Retry other servers based on the configured failover cluster fault tolerance mode. The 13th provider was retried and the call succeeded.

Here, 1 corresponds to routing, 2 to load balancing, and 3 to cluster fault tolerance.

filter

The filter is an important concept in the overall design of Dubbo, and most of the functionality of Dubbo itself is implemented based on this extension point, where interceptions of the Filter are performed on each call. Filter is a chain of responsibility design pattern:

Common filters include monitoring, logging, traffic limiting degradation, and authentication.

The three center

The three centers are the registry, metadata center, and configuration center. Why do we need three centers? Check out the data from dubbo’s registry:

Dubbo/org. Apache. Dubbo. Demo. DemoService/will/dubbo % % 2 f % 2 f172. 3 a 23.234.48%3 a20880%2 forg. Apache dubbo. Demo. DemoServi Ce % 3 fanyhost % 3 dtrue % 26 application % 3 ddubbo - demo - API - the provider % 26 default % 3 dtrue % 26 deprecated % 3 dfalse % 26 dubbo % 3 d2. The 0.2% 26 dyna mic%3Dtrue%26generic%3Dfalse%26interface%3Dorg.apache.dubbo.demo.DemoService%26metadata-type%3Dremote%26methods%3DsayHel lo%2CsayHelloAsync%26pid%3D21563%26release%3D%26side%3Dprovider%26timestamp%3D1600336623852Copy the code

You can see that there is a lot of data, and this is interface level data, and as the number of interfaces increases, the pressure on the registry increases, and changes push more and more data.

So, we need metadata centers and configuration centers to take the pressure off registries. Infrequently changing data can be placed in the metadata center.

Dubbo/org. Apache. Dubbo. Demo. DemoService/will/dubbo % % 2 f % 2 f172. 3 a 23.234.48%3 a20880%2 forg. Apache dubbo. Demo. DemoServi Ce % 3 fapplication % 3 ddubbo - demo - API - the provider % 26 deprecated % 3 dfalse % 26 dubbo % 3 d2. The 26 timestamp % 3 d1600336144382 0.2%Copy the code

The same is true for the configuration center. If there is no configuration center to push the changed URL in full, the configuration center only needs to push the changed configuration.

Generalization call

A common way to call dubbo is to import the interface JAR package defined by the provider, but if you don’t have that JAR, can you make the call? Of course it can, and there are such scenarios, such as service test platform, Dubbo service gateway, etc. As long as you know the interface name, parameters and other information can initiate the call.

The future development

Dubbo’s vision for the future was a curve, not a step to the current cloud native direction. The direction we want to go in 2019 is responsive programming (or reactive programming). In IO intensive applications, thread pool is usually one of the important factors limiting throughput. Assume that the consumer thread pool is 100, the response time of the provider interface is 500ms, and the QPS limit of the consumer is (1000/500) x 100 = 200. Responsive programming solves this problem.

Reactive programming is a programming paradigm declarative based on data stream and propagation of change. RSocket is an open source network communication protocol that supports reaction-Stream semantics. It encapsulates the complex logic of Reactive semantics so that the upper layer can implement network programs easily. Dubbo in version 3.0.0-Snapshot provides support for responsive programming based on RSocket, allowing users to use Mono and Flux type objects in request parameters and return values.

But by 2020, as cloud native concepts rise and big companies land, could Dubbo move in that direction?

Cloud native is based on container and grid service, service, immutable infrastructure and declarative elastic extension of application of the API to build, build based on automation technology has high fault tolerance, easy management and convenient for observation of loosely coupled systems, build a unified ecological, open source cloud services provided by the decoupling and cloud companies.

Dubbo’s service-level registry discovery is contrary to the application-level service discovery orchestrated by K8S containers, and Dubbo is “re-SDK”, which is contrary to easy administration.

So application-level service discovery is supported in the latest version, originally with an interface like this:

Dubbo/org. Apache. Dubbo. Demo. DemoService/will/dubbo % % 2 f % 2 f172. 3 a 23.234.48%3 a20880%2 forg. Apache dubbo. Demo. DemoServi Ce % 3 fapplication % 3 ddubbo - demo - API - the provider % 26 deprecated % 3 dfalse % 26 dubbo % 3 d2. The 26 timestamp % 3 d1600336144382 0.2%Copy the code

This is true for using application level services to discover registrations to the registry

/ services/dubbo - demo - API - the provider / 172.23.234.48:20880Copy the code

The SDK may be improved by Mesh in the future. It is said that Ali already has a dubbo Mesh line of business.