table of Contents

Official address: https://dubbo.apache.org/zh/

Dubbo supports SpringXML configuration and client configuration. The registry supports Zookeeper and Redis. The default registry is Zookeeper. The latest version is 2.7 and 3.0 is under development.

background

This article describes the evolution of website applications

With the development of the Internet, the scale of website applications continues to expand, and conventional vertical application architectures can no longer cope with it. Distributed service architecture and mobile computing architecture are imperative, and a governance system is urgently needed to ensure an orderly evolution of the architecture.

Single application architecture

When the website traffic is very small, only one application is needed and all functions are deployed together to reduce deployment nodes and costs. At this time, the data access framework (ORM) used to simplify the workload of adding, deleting, modifying and checking is the key.

Vertical application architecture

When the number of visits gradually increases, the acceleration caused by the addition of a single application to the machine becomes smaller and smaller. One of the ways to improve efficiency is to split the application into several unrelated applications to improve efficiency. At this time, the web framework (MVC) used to accelerate the development of front-end pages is the key.

Distributed service architecture

When there are more and more vertical applications, interaction between applications is inevitable. The core business is extracted as an independent service, and a stable service center is gradually formed, so that front-end applications can respond more quickly to changing market demands. At this time, the Distributed Service Framework (RPC) for improving business reuse and integration is the key.

Mobile computing architecture

When there are more and more services, problems such as capacity evaluation and the waste of small service resources gradually appear. At this time, a dispatch center needs to be added to manage cluster capacity in real time based on access pressure to improve cluster utilization. At this time, the resource scheduling and governance center (SOA) used to improve machine utilization is the key.

demand

This article introduces the needs Dubbo wants to solve

Before large-scale servicing, applications may simply expose and reference remote services through tools such as RMI or Hessian, call through the URL address of the configuration service, and perform load balancing through hardware such as F5.

When there are more and more services, service URL configuration management becomes very difficult, and the single point pressure of F5 hardware load balancer is also increasing. At this time, a service registration center is needed to dynamically register and discover services to make the location of services transparent. And by obtaining a list of service provider addresses on the consumer side, it can achieve soft load balancing and Failover, reduce reliance on F5 hardware load balancers, and also reduce part of the cost.

When further development, the dependency between services becomes mistracked and complicated, and it is even unclear which application should be started before which application. Architects cannot completely describe the architectural relationship of the application. At this time, it is necessary to automatically draw a dependency graph between applications to help the architect clarify the relationship.

Then, the number of calls to the service becomes larger and larger, and the problem of service capacity is exposed. How much machine support does this service need? When should the machine be added? In order to solve these problems, the first step is to count the daily call volume and response time of the service as a reference indicator for capacity planning. Secondly, it is necessary to dynamically adjust the weight. Online, increase the weight of a certain machine, and record the change in response time during the increase process, until the response time reaches the threshold, record the amount of visits at this time, and then use this Multiply the number of visits by the number of machines to reverse the total capacity.

The above are the most basic requirements of Dubbo.

Architecture

Dubbo architecture

Node role description

node	Role description
`Provider`	Service provider that exposes the service
`Consumer`	Service consumer calling remote service
`Registry`	Registry for service registration and discovery
`Monitor`	Monitoring center that counts the number of service calls and call time
`Container`	Service running container

Call relationship description

The service container is responsible for starting, loading, and running the service provider.
When the service provider starts, it registers the service it provides with the registration center.
When a service consumer is started, he subscribes to the registry for the service he needs.
The registration center returns the list of service provider addresses to the consumer. If there is a change, the registration center will push the change data to the consumer based on the long connection.
Service consumers, from the provider address list, based on the soft load balancing algorithm, select one provider to call, and if the call fails, select another to call.
Service consumers and providers accumulate the number of calls and call time in the memory, and send statistical data to the monitoring center every minute.

The Dubbo architecture has the following characteristics, namely connectivity, robustness, scalability, and upgradeability to the future architecture.

Connectivity

The registration center is responsible for the registration and search of the service address, which is equivalent to a directory service. Service providers and consumers only interact with the registration center at startup, and the registration center does not forward requests, so the pressure is less
The monitoring center is responsible for counting the number of times each service is called, the calling time, etc. The statistics are first collected in the memory and sent to the monitoring center server every minute, and displayed in reports
The service provider registers the services it provides with the registration center and reports the call time to the monitoring center. This time does not include network overhead
The service consumer obtains the service provider address list from the registration center, and directly calls the provider according to the load algorithm, and at the same time reports the call time to the monitoring center. This time includes network overhead
The registration center, service provider, and service consumer are all long-lived connections, except for the monitoring center
The registration center perceives the existence of the service provider through the long connection, and the service provider is down, the registration center will immediately push the event to notify the consumer
The registration center and the monitoring center are all down, which does not affect the providers and consumers that are already running. The consumers cache the provider list locally
Both the registration center and the monitoring center are optional, and service consumers can directly connect to the service provider

Robustness

The downtime of the monitoring center will not affect the use, but some sampling data will be lost
After the database goes down, the registry can still provide service list queries through the cache, but cannot register new services
Registration center peer-to-peer cluster, after any one goes down, it will automatically switch to the other
After the registry is completely down, service providers and service consumers can still communicate through the local cache
The service provider is stateless, after any one is down, it will not affect the use
After the service providers are all down, the service consumer applications will be unavailable and will reconnect indefinitely and wait for the service provider to recover

Scalability

The registry is a peer-to-peer cluster, which can dynamically add machine deployment instances, and all clients will automatically discover the new registry
The service provider is stateless and can dynamically add machine deployment instances, and the registry will push new service provider information to consumers

Upgradeability

When the scale of service clusters is further expanded and IT governance structure is further upgraded, dynamic deployment and mobile computing are required. The existing distributed service architecture will not bring resistance. The following figure is a possible architecture in the future:

Node role description

node	Role description
`Deployer`	Local agent for automatic deployment services
`Repository`	Warehouse is used to store service application release packages
`Scheduler`	The dispatch center automatically increases or decreases service providers based on access pressure
`Admin`	Unified management console
`Registry`	Registry for service registration and discovery
`Monitor`	Monitoring center that counts the number of service calls and call time

usage

A simple and practical introduction to Dubbo

Local service Spring configuration

local.xml:

<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” />
<bean id=“xxxAction” class=“com.xxx.XxxAction”>
    <property name=“xxxService” ref=“xxxService” />
</bean>

Remote service Spring configuration

On the basis of the local service, only need to do a simple configuration to complete the remote:

local.xml Split the above configuration into two parts, place the service definition part on the service provider, remote-provider.xmland place the service reference part on the service consumer remote-consumer.xml.
And increase the exposed service configuration on the provider side <dubbo:service>, and increase the reference service configuration on the consumer side <dubbo:reference>.

remote-provider.xml:

<!-- 和本地服务一样实现远程服务 -->
<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” /> 
<!-- 增加暴露远程服务配置 -->
<dubbo:service interface=“com.xxx.XxxService” ref=“xxxService” />

remote-consumer.xml:

<!-- 增加引用远程服务配置 -->
<dubbo:reference id=“xxxService” interface=“com.xxx.XxxService” />
<!-- 和本地服务一样使用远程服务 -->
<bean id=“xxxAction” class=“com.xxx.XxxAction”> 
    <property name=“xxxService” ref=“xxxService” />
</bean>

Dubbo RPC service registration discovery governance framework