A. What Dubbo that? What do Dubbo?
With the development of the Internet, the market demand for rapid change, the business continued to grow rapidly, websites have evolved service architecture for distributed computing and mobile infrastructure from a single application architecture. In the context of a distributed architecture, the redeployment of resources within this non-process (remote) in the local becomes inevitable. Thus, the late emergence of a number of frameworks RPC (Remote Procedure Call), such as Apache Thrift, Hessian, gRPC and so on. However, with the promotion of RPC framework and the increasing use of in-depth, more and more services situation also spawned a new business requirements:
(1) How to manage too many service URL
(2) consumers want to use the service, you must know and understand the services provided directly address the service side. Background service address Once changed, they need a notice to consumers, this relationship very highly coupled use of maintenance.
(3) mass service will be extended a lot of mistakes, how to provide service management functions to these common failures.
In this context, Alibaba Group launched Dubbo distributed framework to address and mitigate these current demand and bottlenecks in the RPC framework. Specific measures are as follows:
(1) by introducing a service registry Registry to manage dependencies of service, and retrieve a list of addresses service providers, soft-load balancing and Failover, reduce dependence on F5 hardware load balancer in the consumer side.
(2) provided in the registry subscription release mechanism, so that consumers only need to care about the service itself, eliminating the need for hard-coded service provider address. Registry-based query interface name ip address of the service provider, the service provider will then address the dynamic back to the service consumer.
(3) a specialized independent service management center, unified cluster nodes do online service management, improve management efficiency.
Second Dubbo works (refer to the official document: https://github.com/apache/dubbo )
1) Node Description:
Provider: Service Provider exposed
Consumer: calling remote services service consumer
Registry: service registration and discovery registries
Monitor: Monitoring Center number of calls and call time statistical services
Container: container service running
2) the calling process and working principle:
0. service container Container startup, load, run service provider, initialize the Spring context by main function, each service release (as specified in the protocol depending on the service provider's XML configuration file protocol port number for each service has its own corresponding Protocol, Port ), thus completing the initialization of multiple services.
1. The service provider Provider at startup, according to a service address registry configuration Registry connection service registry, to publish service provider information to the registry (e.g. ZooKeeper), registration service itself (above) to the registry.
2. Services Consumer Consumer startup, consumer reference information service based on service consumers XML configuration file, connect to the registry, you need to subscribe to the service registry.
3. The service registry according to consumer service subscription relationship, return address list service providers to consumers, if there is a change, the registry will be based on a long connection to push new service address information to consumers (the listener process is another Dubbo NotifyListrener provided assistance to complete, concrete can see the next section of the presentation).
4. When the service consumer remote service call, according to the routing policy, choose from the list of addresses service providers in the local cache of a selected providers were, then establish the link protocol type, cross-process call the service provider, if the call fails , then select another call.
5. Service providers and consumers Consumer Provider, in memory of the cumulative number of calls and call time, time sent once per minute statistical data to the monitoring center Monitor.
Three .Dubbo underlying architecture interpretation (Reference document: http://dubbo.apache.org/zh-cn/docs/dev/design.html )
(1) came up from the figure of two layers, we can easily analyze the left of the blue part is the service consumer (ReferenceConfig), the right is the service provider (implement interfaces, ServiceConfig).
(2) which is an extension interface represents the left to the consumer to use a separate, interface represents the right is extended to the service used by the individual. And in the middle of the interface is both service providers and consumers can use.
(3) from top to bottom according to the working procedure dubbo, the total is divided into 10 layers. Described with reference to each portion ( http://crazyfzw.github.io/2018/06/10/dubbo-architecture/ )
-
Interface Layer Service (Service): This layer is associated with the actual business logic, according to a service provider and the service consumer interface design and implementation of services corresponding.
-
Layer configuration (Config): External configuration interface to ServiceConfig ReferenceConfig center and can be directly new configuration class, the configuration may be arranged to generate class by parsing spring.
-
Service proxy layer (Proxy): transparent proxy service interfaces, generating a service customer terminal and the server Skeleton Stub, in center ServiceProxy expansion interface ProxyFactory.
-
Service registration layer (Registry): registration and discovery package service address, to serve as the center URL, extended interface is RegistryFactory, Registry and RegistryService. It may not be registered service center, the Service Provider directly exposed services.
-
集群层（Cluster）：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为 Cluster、Directory、Router 和 LoadBalance。将多个服务提供方组合为一个服务提供方，实现对服务消费方来透明，只需要与一个服务提供方进行交互。
-
监控层（Monitor）：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory、Monitor 和 MonitorService。
-
远程调用层（Protocol）：封将 RPC 调用，以 Invocation 和 Result 为中心，扩展接口为 Protocol、Invoker 和 Exporter。Protocol 是服务域，它是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管理。Invoker 是实体域，它是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起 invoke 调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
-
信息交换层（Exchange）：封装请求响应模式，同步转异步，以 Request 和 Response 为中心，扩展接口为 Exchanger、ExchangeChannel、ExchangeClient 和 ExchangeServer。
-
网络传输层（Transport）：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel、Transporter、Client、Server 和 Codec。
-
数据序列化层（Serialize）：可复用的一些工具，扩展接口为 Serialization、 ObjectInput、ObjectOutput和ThreadPool。
大致的工作流程是：
1.读取配置文件，生成代理对象
2.代理对象负责将其注册到注册中心进行备份
3.下层monitor层对双方进行业务监控。
在 RPC 中，Protocol 是核心层，也就是只要有 Protocol + Invoker + Exporter 就可以完成非透明的 RPC 调用，然后在 Invoker 的主过程上 Filter 拦截点。
需要注意的是：为了底层可以使用NIO来传输数据，所有的公共api接口都应该实现Serializable.
四.Dubbo的缺点
因为是阿里出品，所以其目前只支持Java语言，对语言的支持性不是很好。