preface

This paper mainly introduces Dubbo from macro aspects such as introduction and architecture.

Application architecture evolution

Single application

In the early days, most applications were single applications. With the rapid development of the Internet, the rapid growth of data volume and the complexity of services, many enterprises split applications vertically, that is, separate unrelated systems to form independent external services. At this point, services are completely independent of each other and cannot be called remotely. Much of the basic code cannot be reused and needs to be copied. To solve these problems, distributed applications are derived.

Distributed application

SOA architecture

In order to solve the problem of single application, service-oriented architecture (SOA) emerged. SOA separates single process application into independent service providing components, and each component provides services through network protocol. The network protocol can be TCP, Http, etc. Through this protocol, services can interact with each other through interfaces. SOA has the following characteristics:

  • Explicit protocols. Services interact through specific protocols
  • Explicit interface, each service has explicit external interface, so that services can be reused
  • The change of cooperation mode, a more detailed division of labor and cooperation mode
  • Communication mode. The initial communication mode is usually XML, later replaced by Json

There are two ways to realize SOA: Web Service and ESB. However, the disadvantages of these two ways are obvious. The communication protocol of Web Service is cumbersome and the Service management setting is not perfect. The ESB itself is heavy, and changes to the system can in turn affect changes to the bus.

Micro service

In order to solve the problems that exist in the SOA, the architecture of service obtained the further evolution of recent years, the primary key to form the more granular services architecture, in micro service architecture, a service is split into separate, configurable, and can be run, maintainable service, great convenience to service reuse, and through the different ways of service choreography, Generate new business logic quickly.

Dubbo

Dubbo is one of the most important solutions to distributed communication problems in distributed scenarios. Writing highly concurrent, highly scalable systems in distributed scenarios requires a lot of skills, because it involves serialization/deserialization, networking, multithreading, design patterns, performance optimization, and so on. Dubbo does a good job of abstracting and encapsulating these at a higher level, providing a variety of out-of-the-box features for users to use foolproof.

architecture

The diagram above shows the architecture of Dubbo as follows:

  • The service Container is responsible for starting, loading, and running the Provider
  • The Provider registers its metadata (service Ip,Port, etc.) with the registry when it starts up.
  • Metadata that the Consumer subscribes to the registry service provider at startup
  • The registry gives a list of service provider addresses to consumers and pushes them to subscribing consumers if data changes occur
  • After retrieving the metadata, the Consumer can make an RPC call
  • Statistics (concurrency, calling interface, etc.) will be reported to the monitoring center before and after RPC call.

Problems Dubbo solves:

1, high-performance, transparent RPC calls

2. Automatic registration and discovery of services

  • Automatic load and fault tolerance
  • Dynamic traffic scheduling
  • Dependency analysis and call statistics

layered

Dubbo’s implementation is layered, with each layer responsible for different responsibilities, allowing users to do secondary development based on the Dubbo framework and extend its functionality. Dubbo is very scalable, which is why Dubbo is so popular.

Dubbo is generally divided into three layers: Biz layer, RPC layer and Remote layer. If each layer is subdivided, it can be divided into ten layers.

The layers in the Dubbo framework represent different logical implementations. They are the components that make up the entire Dubbo architecture. The following are the core components of Dubbo.

Overall call procedure

Service exposure process:

First, when the framework is started, the server (service provider) initializes the service instance, invokes the specific protocol through the Proxy component, encapsulates the interface to be exposed by the server as An Invoker (whose real type is AbstractProxyInvoker), and then switches to a friend. At this point, the framework will open the service port and record the service instance into memory, and finally register the service metadata to the Registry through Registry. This is how the entire interface is exposed on the server (service provider).

First, the invocation process also starts with a Proxy, which holds an Invoker object. The invoke call is then triggered. During an Invoke call, you need to use a Cluster, which is responsible for fault tolerance, such as retry of a failed call. The Cluster gets the Invoker list of all remote services that can be invoked from Directory before invoking it (an interface may have multiple nodes serving it). Because there are many remote services that can be called, if the user configures routing rules (for example, specifying that some methods can only call a node), the Invoker list will be filtered according to the routing rules.

Then, there may be many invokers that survive, which one to call? Load balancing continues with the LoadBalance method, and an Invoker is selected that can be called. The Invoker passes through a chain of filters before being called, which typically handles context, limiting, counting, and so on. Then, the Client will be used for data transmission, such as our common Netty Client. Some proprietary protocol construction must be done before transmission, in which case the Codec interface is used. Once constructed, the packets are serialized and transmitted to the service provider. When the service provider receives the packet, it will also use Codec to process the protocol header and some half-packets, sticky packets, etc. After the processing is complete, deserialize the complete data message.

The Request is then allocated to a ThreadPool for processing. Server handles these requests and looks up the corresponding Exporter(which has an Invoker internally) based on the Request. Invoker is layered with many filters in the decorator pattern, so it passes through a chain of filters on the service provider side before calling the final implementation class.

Finally, the actual implementation of the concrete interface is obtained and called, and the result is returned in the original way. At this point, a complete remote call process is complete.

summary

This article introduces the evolution of application architecture, including Dubbo architecture, layering, overall call process, etc. If you’re interested in Dubbo, stay tuned for this column.