RPC framework DUBBO architecture principle and instructions - architecture, Dubbo, frame, instructions, principle, RPC

1. What is Dubbo

Official definition< /span>

DUBBO is a distributed service framework, dedicated to providing high-performance and transparent RPC remote service invocation scheme, which is Alibaba SOA The core framework of the service-based governance program provides support for 3,000,000,000+ visits per day for 2,000+ services, and is widely used in various member sites of the Alibaba Group.

For a detailed understanding, that’s

< p class="project-tagline" style="box-sizing: inherit; margin: 10px auto; padding: 0px; border-style: solid; border-width: 0px; background-repeat: no-repeat; font-family: Georgia, "Times New Roman", Times, sans-serif; white-space: normal; background-color: rgb(255, 255, 255);">Dubbo is a high-performance and excellent service framework open sourced by Alibaba. The application can realize the output and input functions of the service through high-performance RPC, and can be seamlessly integrated with the spring framework. It is a distributed service framework and SOA governance program. Its functions mainly include: high-performance NIO communication and multi-protocol integration, service dynamic addressing and routing, soft load balancing and fault tolerance, dependency analysis and degradation, etc.

Here are a few professional terms: 1.RPC , 2. Distributed, 3. SOA, if you don’t understand these terms, it may be a bit difficult to understand, you have to go back and do your homework.

Popular understanding means in a distributed system A kind of RPC technology, through Dubbo can realize the communication between systems or applications, realize the decoupling between applications (or loose coupling to the maximum extent), etc.

Second, the origin of Dubbo

1. Background

With the development of the Internet, the scale of website applications continues to expand. Conventional vertical application architecture can no longer cope with it. Distributed service architecture and mobile computing architecture are imperative. A governance system ensures the orderly evolution of the architecture.

Single application architecture

When the website The traffic is very small, only one application is needed, and all functions are deployed together to reduce deployment nodes and costs.
At this time, Data Access Framework (ORM) is the key.

Vertical Application Architecture

As the number of visits gradually increases, the acceleration caused by the addition of a single application to the machine becomes smaller and smaller, and the application is divided into several unrelated applications to improve efficiency.
At this time, Web framework (MVC) is the key.

Distributed Service Architecture

When there are more and more vertical applications, the interaction between applications is inevitable. The core business is extracted as an independent service, gradually forming a stable service center, so that front-end applications can be faster In response to changing market demands.
At this time, Distributed Service Framework (RPC) is the key.

Mobile Computing Architecture

When there are more and more services, capacity evaluation, waste of small service resources and other problems 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) is the key.

2. Requirements

Before large-scale servicing, applications may only pass RMI or Hes Tools such as sian simply expose and reference remote services, call them by configuring the URL address of the service, and perform load balancing through hardware such as F5.

(1) When there are more and more services, service URL configuration management becomes very difficult, F5 The single point of pressure on hardware load balancers is also increasing.

At this time, a service registration center is required for dynamic registration and discovery Service to make the location of the service transparent.

and obtain the service provider address list on the consumer side to achieve soft load balancing and Failover, reducing reliance on F5 hardware load balancer, can also reduce part of the cost.

(2) When further development, the dependencies between services become mistracked and complicated, or even separated It is clear which application should be started before which application, and the architect cannot fully describe the architectural relationship of the application.

At this time, you need to automatically draw a dependency graph between applications To help the architect clean up the relationship.

(3) Then, as the volume of service calls becomes larger and larger, the service capacity problem is exposed Come out, 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 serve now The daily call volume and response time are all counted as reference indicators for capacity planning.

Secondly, it is necessary to dynamically adjust the weight. On-line, the weight of a certain machine Keep increasing, and record the change in response time during the increasing process, until the response time reaches the threshold, record the number of visits at this time, and then multiply the number of visits by the number of machines to reverse the total capacity.

The above are the most basic requirements of Dubbo. For more service governance issues, see:

http://code.alibabatech.com/blog/experience_1402/service-governance -process.html

3. Architecture design drawing

Node role description:

Provider: Expose the service provider of the service.
Consumer: The service consumer that calls the remote service.
Registry: The registry for service registration and discovery.
Monitor: The monitoring center that counts the call times and call times of the service.
Container: Service running container.

Calling relationship description:

< p>0. The service container is responsible for starting, loading, and running the service provider.
1. When the service provider starts, it registers its services with the registration center.
2. When the service consumer starts, he subscribes to the registration center for the service he needs.
3. The registry returns a list of service provider addresses to consumers. If there are changes, the registry will push the changed data to consumers based on the persistent connection.
4. 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 one transfer.
5. 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.

4.Dubbo’s overall architecture

Dubbo frame design is divided into 10 layers, and the top Service layer is reserved for the actual use of Dubbo to develop distributed services Developers implement the interface layer of business logic. In the figure, the light blue background on the left is the interface used by the service consumer, the light green background on the right is the interface used by the service provider, and the interface on the central axis is the interface used by both parties.
Below, combined with Dubbo official documents, we will understand the design points of each level in the framework’s layered architecture:

Service interface layer (Service) : This layer is related to the actual business logic, and the corresponding interface and implementation are designed according to the business of the service provider and the service consumer. Configuration layer (Config): External configuration interface, centered on ServiceConfig and ReferenceConfig, you can directly new configuration class, or you can generate configuration class through spring analysis configuration. Service proxy layer (Proxy): transparent proxy of service interface, generating service client stub and server side Skeleton, centered on ServiceProxy, and extended interface as ProxyFactory. Service registration layer (Registry): encapsulates the registration and discovery of service addresses, centered on the service URL, and the extended interfaces are RegistryFactory, Registry, and RegistryService. There may not be a service registry, in which case the service provider directly exposes the service. Cluster layer (Cluster): encapsulates the routing and load balancing of multiple providers, and bridges the registry, with the Invoker as the center, and the expansion interfaces for Cluster, Directory, Router and LoadBalance. Combine multiple service providers into one service provider to achieve transparency to service consumers and only need to interact with one service provider. Monitoring layer (Monitor): RPC call times and call time monitoring, centered on Statistics, and extended interfaces are MonitorFactory, Monitor and MonitorService. Remote invocation layer (Protocol): Encapsulate RPC calls, centered on Invocation and Result, and extended interfaces as Protocol, Invoker and Exporter. Protocol is the service domain, it is the main function entrance exposed and referenced by Invoker, and it is responsible for the life cycle management of Invoker. Invoker is the entity domain. It is the core model of Dubbo. Other models rely on it or convert to it. It represents an executable and can initiate an invoke call to it. It may be a local implementation or it may be It is a remote implementation, or a cluster implementation. Information Exchange Layer (Exchange): Encapsulates the request response mode, synchronous to asynchronous, with Request and Response as the center, and the extension interfaces are Exchanger, ExchangeChannel, ExchangeClient and ExchangeServer. Network Transport Layer (Transport): Abstract mina and netty are unified interfaces, centered on Message, and extended interfaces are Channel, Transporter, Client, Server and Codec. Data serialization layer (Serialize): Some reusable tools, with extended interfaces such as Serialization, ObjectInput, ObjectOutput and ThreadPool.

As can be seen from the above figure, Dubbo provides each need to care for service providers and service consumers from the 10 layers of the framework. And extended interfaces to build the entire service ecosystem (service providers and service consumers themselves are service-centric).
According to the official provided, The description of the relationship between the above layers is as follows:

> In RPC, Protocol is the core layer, that is, as long as there is Protocol + Invoker + Exporter can complete non-transparent RPC calls, and then filter interception points on the main process of Invoker. > Consumer and Provider in the picture are abstract concepts. I just want to let viewers understand more intuitively which categories belong to the client and server. The reason for not using Client and Server is that Dubbo uses Provider, Consumer, and Registry in many scenarios. , Monitor divides logical topological nodes to maintain a unified concept. > Cluster is a peripheral concept, so the purpose of Cluster is to disguise multiple Invokers as one Invoker, so that others only need to pay attention to the Invoker at the Protocol layer. Adding Cluster or removing Cluster will not affect other layers because there is only one When providing providers, Cluster is not needed. > The Proxy layer encapsulates the transparent proxy of all interfaces, while the Invoker is the center at other layers. Only when it is exposed to users, will the Invoker be converted into an interface by the Proxy, or the interface implementation will be converted into an Invoker, that is, remove The RPC at the Proxy layer can be run, but it is not so transparent, and it does not look like a local service to call a remote service. > The Remoting implementation is the implementation of the Dubbo protocol. If you choose the RMI protocol, the entire Remoting will not be used. Remoting is then divided into the Transport transport layer and the Exchange information exchange layer. The Transport layer is only responsible for one-way message transmission. , Netty, Grizzly abstraction, it can also extend UDP transmission, and the Exchange layer encapsulates the Request-Response semantics on top of the transport layer. > Registry and Monitor are actually not considered as a layer, but an independent node, just for a global overview, drawn together in a layered manner.

5. Design advantages

(1) Connectivity:

The registration center is responsible for the registration and search of service addresses, which is equivalent to directory services, service providers and consumers The user only interacts with the registry at startup, the registry does not forward requests, and the pressure is less
The monitoring center is responsible for counting the number of service calls, calling time, etc., and the statistics are stored in the memory first After being aggregated, it is sent to the monitoring center server once every minute and displayed in a report.
The service provider registers the service provided by the registration center and reports the call time to the monitoring center. 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. Time includes network overhead
Registration center, service provider, and service consumer are all long-lived connections, except for monitoring center
Registration center perceives the existence of service provider through long connection, and the service provider is down, the registry will immediately push events to notify consumers
Registration center and monitoring center All downtime, does not affect the providers and consumers that are already running. Consumers cache the provider list locally
Registration center and monitoring center are optional, service Consumers can directly connect to the service provider

< span style="box-sizing: inherit; margin: 0px; padding: 0px; border-style: solid; border-width: 0px; background-repeat: no-repeat; font-weight: bolder;">(2) 健Characteristics:

The downtime of the monitoring center will not affect the use, but some sampling data will be lost
After the database is down, the registry can still provide service list query through the cache , But cannot register new services
Registration center 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 local cache
The service provider is stateless, and any one of them is down. , Does not affect the use
After all the service providers are down, the service consumer applications will be unavailable, and will be reconnected indefinitely and wait for the service provider to recover

li>

(3) Scalability:

The registry is a peer-to-peer cluster, and machine deployment instances can be dynamically added, and all clients will automatically discover the new registry

li>
Service providers are stateless, and machine deployment instances can be dynamically added, and the registry will push new service provider information to consumers

(4) 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:

Three, how to use Dubb o

由于Dubbo无缝的集成了spring，所以我们使用起来还是很方便的，

本地服务：(Spring配置)

local.xml

远程服务：(Spring配置)

在本地服务的基础上，只需做简单配置，即可完成远程化：

将上面的local.xml配置拆分成两份，将服务定义部分放在服务提供方remote-provider.xml，将服务引用部分放在服务消费方remote-consumer.xml。
并在提供方增加暴露服务配置，在消费方增加引用服务配置。

如下：

服务提供者：remote-provider.xml

服务消费者：remote-consumer.xml

Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

1.示例

服务提供者

定义服务接口: (该接口需单独打包，在服务提供方和消费方共享)

package com.alibaba.dubbo.demo;  public interface DemoService {      String sayHello(String name);  }

在服务提供方实现接口：(对服务消费方隐藏实现)

package com.alibaba.dubbo.demo.provider;  import com.alibaba.dubbo.demo.DemoService;  public class DemoServiceImpl implements DemoService {      public String sayHello(String name) {        return "Hello " + name;    }  }

用Spring配置声明暴露服务：provider.xml

加载Spring配置：

import org.springframework.context.support.ClassPathXmlApplicationContext;     public class Provider {         public static void main(String[] args) throws Exception {          ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[] {"http://10.20.160.198/wiki/display/dubbo/provider.xml"});          context.start();             System.in.read(); // 按任意键退出     }   }

服务消费者

通过Spring配置引用远程服务：consumer.xml

加载Spring配置，并调用远程服务：(也可以使用IoC注入)

import org.springframework.context.support.ClassPathXmlApplicationContext;  import com.alibaba.dubbo.demo.DemoService;     public class Consumer {         public static void main(String[] args) throws Exception {          ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[] {"http://10.20.160.198/wiki/display/dubbo/consumer.xml"});          context.start();            DemoService demoService = (DemoService)context.getBean("demoService"); // 获取远程服务代理         String hello = demoService.sayHello("world"); // 执行远程方法           System.out.println( hello ); // 显示调用结果     }   }

2.其他广播方式

示例中使用的是multicast广播暴露和发现服务的，当然还有其他的方式，现在使用最多的是ZooKeeper

如果使用ZooKeeper则配置修改为：

 替换为  或者

服务提供者和服务消费者做相同的修改

3.说明

以上是Dubbo的XML配置，Dubbo还支持属性配置，注解配置，API配置，下面介绍下API配置，另外两种配置方式，感兴趣的朋友可以去Dubbo官网去看下：Dubbo

如果不想使用Spring配置，而希望通过API的方式进行调用（官方不推荐）则

(1) 服务提供者：

import com.alibaba.dubbo.rpc.config.ApplicationConfig;  import com.alibaba.dubbo.rpc.config.RegistryConfig;  import com.alibaba.dubbo.rpc.config.ProviderConfig;  import com.alibaba.dubbo.rpc.config.ServiceConfig ;  import com.xxx.XxxService;  import com.xxx.XxxServiceImpl;     // 服务实现  XxxService xxxService = new XxxServiceImpl();   // 当前应用配置 ApplicationConfig application = new ApplicationConfig(); application.setName("xxx");   // 连接注册中心配置 RegistryConfig registry = new RegistryConfig(); registry.setAddress("10.20.130.230:9090"); registry.setUsername("aaa"); registry.setPassword("bbb");   // 服务提供者协议配置 ProtocolConfig protocol = new ProtocolConfig(); protocol.setName("dubbo"); protocol.setPort(); protocol.setThreads();   // 注意：ServiceConfig为重对象，内部封装了与注册中心的连接，以及开启服务端口   // 服务提供者暴露服务配置 ServiceConfig service = new ServiceConfig(); // 此实例很重，封装了与注册中心的连接，请自行缓存，否则可能造成内存和连接泄漏 service.setApplication(application); service.setRegistry(registry); // 多个注册中心可以用setRegistries() service.setProtocol(protocol); // 多个协议可以用setProtocols() service.setInterface(XxxService.class); service.setRef(xxxService); service.setVersion("1.0.0");   // 暴露及注册服务 service.export();

(2) 服务消费者：

  import com.alibaba.dubbo.rpc.config.ApplicationConfig;  import com.alibaba.dubbo.rpc.config.RegistryConfig;  import com.alibaba.dubbo.rpc.config.ConsumerConfig;  import com.alibaba.dubbo.rpc.config.ReferenceConfig;  import com.xxx.XxxService;     // 当前应用配置  ApplicationConfig application = new ApplicationConfig();  application.setName("yyy");   // 连接注册中心配置 RegistryConfig registry = new RegistryConfig(); registry.setAddress("10.20.130.230:9090"); registry.setUsername("aaa"); registry.setPassword("bbb");   // 注意：ReferenceConfig为重对象，内部封装了与注册中心的连接，以及与服务提供方的连接   // 引用远程服务 ReferenceConfig reference = new ReferenceConfig(); // 此实例很重，封装了与注册中心的连接以及与提供者的连接，请自行缓存，否则可能造成内存和连接泄漏 reference.setApplication(application); reference.setRegistry(registry); // 多个注册中心可以用setRegistries() reference.setInterface(XxxService.class); reference.setVersion("1.0.0");   // 和本地bean一样使用xxxService XxxService xxxService = reference.get(); // 注意：此代理对象内部封装了所有通讯细节，对象较重，请缓存复用

四、Dubbo的一些相关疑问

1.Dubbo适用于哪些场景？

当网站变大后，不可避免的需要拆分应用进行服务化，以提高开发效率，调优性能，节省关键竞争资源等。

当服务越来越多时，服务的URL地址信息就会爆炸式增长，配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。

当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。

接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？等等……

在遇到这些问题时，都可以用Dubbo来解决。

可参见：Dubbo的背景及需求

2.Dubbo的需求和依赖情况？

Dubbo运行JDK1.5之上，缺省依赖javassist、netty、spring等包，但不是必须依赖，通过配置Dubbo可不依赖任何三方库运行。

可参见：用户指南 – 依赖

3.Dubbo的性能如何？

Dubbo通过长连接减少握手，通过NIO及线程池在单连接上并发拼包处理消息，通过二进制流压缩数据，比常规HTTP等短连接协议更快。在阿里巴巴内部，每天支撑2000多个服务，30多亿访问量，最大单机支撑每天近1亿访问量。

可参见：Dubbo性能测试报告

4.和淘宝HSF相比，Dubbo的特点是什么？

Dubbo比HSF的部署方式更轻量，HSF要求使用指定的JBoss等容器，还需要在JBoss等容器中加入sar包扩展，对用户运行环境的侵入性大，如果你要运行在Weblogic或Websphere等其它容器上，需要自行扩展容器以兼容HSF的ClassLoader加载，而Dubbo没有任何要求，可运行在任何Java环境中。

Dubbo比HSF的扩展性更好，很方便二次开发，一个框架不可能覆盖所有需求，Dubbo始终保持平等对待第三方理念，即所有功能，都可以在不修改Dubbo原生代码的情况下，在外围扩展，包括Dubbo自己内置的功能，也和第三方一样，是通过扩展的方式实现的，而HSF如果你要加功能或替换某部分实现是很困难的，比如支付宝和淘宝用的就是不同的HSF分支，因为加功能时改了核心代码，不得不拷一个分支单独发展，HSF现阶段就算开源出来，也很难复用，除非对架构重写。

HSF依赖比较多内部系统，比如配置中心，通知中心，监控中心，单点登录等等，如果要开源还需要做很多剥离工作，而Dubbo为每个系统的集成都留出了扩展点，并已梳理干清所有依赖，同时为开源社区提供了替代方案，用户可以直接使用。

Dubbo比HSF的功能更多，除了ClassLoader隔离，Dubbo基本上是HSF的超集，Dubbo也支持更多协议，更多注册中心的集成，以适应更多的网站架构。

5.Dubbo在安全机制方面是如何解决的？

Dubbo主要针对内部服务，对外的服务，阿里有开放平台来处理安全和流控，所以Dubbo在安全方面实现的功能较少，基本上只防君子不防小人，只防止误调用。

Dubbo通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。 Dubbo还提供服务黑白名单，来控制服务所允许的调用方。

可参见：Dubbo的令牌验证

原文链接：http://www.cnblogs.com/study-everyday/p/6742350.html