Dubbo:RPC架构、SOA架构

Dubbo缺省协义采用了单一化的长连接和NIO异步通信，适用小信息量大高并发的服务项目通话和服务项目顾客机械设备数远高于服务供应商机械设备数的状况。

做为RPC:适用dubbo、hession、json、fastjson等各种各样传输协议，底端由mina、netty长连接传送!非常典型的provider和cusomer模式!

做为SOA:具备管理与服务作用，出示服务项目申请注册和发觉!用zookeeper完成认证中心!启动，服务项目方将在认证中心申请注册全部插口，并订购configurators、服务项目消費方订购provide、configurators、routers、订购变动时，zk消息推送providers、configuators、routers、启动申请注册长连接、通讯proveider和provider运行后，在后台管理运行计时器，将数据统计发送至monitor(监控管理中心)!出示各种各样不正确体制和负载平衡发展战略!

Consumer服务项目顾客，Provider服务供应商。Container服务项目器皿。消費自然是invoke服务提供者，invoke这条实线是图上的表明同歩的含意，在具体启用全过程中，Provider的部位对Consumer而言是全透明的，之前启用服务项目的部位(IP地址)和下一次启用服务项目的部位是不确定性的。这个地方完成了软负载。

服务供应商先运行start，随后申请注册register服务项目。

消費预定subscribe服务项目，要是没有预定自身要想的服务项目，就持续试着预定。新的服务项目在认证中心申请注册后，认证中心将这种服务项目根据notify向顾客出示。

Monitor它是一种监控，图上的斜线表明Consumer和Provider根据多线程向Monitor发送短信，Consumer和Provider将信息内容储存在本地硬盘中，均值1min发送短信。Monitor在全部架构中是可选择的(图上的斜线并不是可选择的含意)，Monitor作用必须独立配备，不配备或配备后，Monitor挂掉不容易危害服务项目的启用。

什么叫netty?

netty是根据nio的顾客、网络服务器终端设备程序编写架构，netty出示多线程、量化策略的网络技术应用架构和专用工具，能够快速开发设计能用的顾客终端设备和网络服务器。

netty是根据nio包裝jdknio，使方式更为灵便。

dubbo的基本原理?

复位全过程的关键点:

图中的第一步是将服务项目装车到器皿中，提前准备申请注册服务项目。类似Spring中的运行全过程，当spring启动，将bean装车到器皿里时，先要剖析bean。因而，dubbo也要先阅读文章文档剖析服务项目。

剖析服务项目:剖析服务项目:

1.根据dubbo.jar内的Meta-inf/spring.handlers配备，spring在碰到dubbo名字室内空间时，招回dubonamespandler类。

2.全部dubo标识，统一用dubobeandefinitionParser剖析，根据一对一特性投射，将XML标识剖析为bean目标。

在ServiceConfig.export或ReferenceConfig.get复位时，将Bean目标变换为url文件格式，将Bean特性变换为url参数。

随后将URL传送给Protocol拓展点，依据拓展点的Adaptive体制，依据URL的协义头开展不一样协义的服务项目曝出和引入。

a.只曝露服务项目端口号。

在沒有应用认证中心的状况下，这类状况一般适用开发工具，服务项目的启用和出示同样的IP，只需打开服务的端口号就可以。

ServiceConfig剖析的URL格式以下

Dubo://service-host/com.xxx.Txxserviceversion=1.0.0。

根据拓展点的Adaptiver体制根据URL的dubo://协义头鉴别，立即启用DuboProtocolexport()方式，打开服务端口号。

b.向认证中心公布服务项目:

与以前的差别:必须将服务项目的IP和端口号一起曝露在认证中心。

ServiceConfig剖析的url文件格式以下

registry://registry-host/com.alibaba.dubo.registry.registryserviceexport=URL.encode(dubo://service-host/com.xxx.txxserviceversion=1.0.0)

根据拓展点的Adaptive体制，根据URL的registry://协义头顶部鉴别，启用RegistryProtocol的export方式，将export主要参数中的服务提供者URL申请注册为认证中心，再度传送给Protocol拓展点version=1.0.0。

服务项目曝出和消費的详尽步骤。

1.服务供应商表明服务项目的详尽全过程。

服务供应商曝露服务项目的关键全过程:

ServiceConfig类得到对外开放服务项目的具体类ref(比如HelloWorldImpl)，根据ProxyFactory类getInvoker方法应用ref转化成AbstractProxyInvoker的事例。

到这个流程，实际的服务项目就完成了Invoker的变换。下面是Invoker变换到Exporter的全过程。

Dubo解决服务项目曝露的关键是Invoker变换到Exporter的全过程(如圖的鲜红色一部分)，以Dubbo和RMI二种非常典型协义的完成开展表明。

Dubbo的完成:

Dubbo协义的Invoker变化为Exporter产生在Dubboprotocol类的export方式，主要是开启socket监听服务项目，接纳顾客的各种各样要求，通讯关键点由Dubo自身完成。

RMI的完成:

RMI协义的Invoker变成了RmiProtocol类export方式

根据Spring或Dubbo或JDK完成RMI服务项目，通讯关键点由JDK基本完成，节约了许多劳动量。

2.服务项目顾客消費服务项目的详尽全过程。

dubbo原理和机制：应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。

服务项目消費的关键全过程:

ReferenceConfig类的init方式启用Protocol的refer方式转化成Invoker案例(如圖中的鲜红色一部分)是服务项目消費的重要。