dubbo之二
-
为什么要使用dubbo
传统的ORM、MVC不能实现大量数据的访问需求，不利于项目模块的扩展。使用dubbo基于RPC（远程过程调用）可以实现模块与模块之间的分离，从而使得模块之间的耦合性降低，实现多模块的开发和维护，学习dubbo要学会它的思想。
-
RPC原理
-
1.1 什么是RPC
RPC(Remote Procedure Call Protocol)——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP/IP或UDP，为通信程序之间携带信息数据。RPC将原来的本地调用转变为调用远端的服务器上的方法，给系统的处理能力和吞吐量带来了近似于无限制提升的可能。在OSI网络通信模型中，RPC跨域了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
1.2 RPC架构
一个完整的RPC架构里面包含了四个核心的组件，分别是Client，Client Stub，Server以及Server Stub，这个Stub可以理解为存根。
- 客户端(Client)，服务的调用方。
- 客户端存根(Client Stub)，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。
- 服务端(Server)，真正的服务提供者。
- 服务端存根(Server Stub)，接收客户端发送过来的消息，将消息解包，并调用本地的方法。
-
1.3 RPC调用过程
(1) 客户端（client）以本地调用方式（即以接口的方式）调用服务；
(2) 客户端存根（client stub）接收到调用后，负责将方法、参数等组装成能够进行网络传输的消息体（将消息体对象序列化为二进制）；
(3) 客户端通过sockets将消息发送到服务端；
(4) 服务端存根( server stub）收到消息后进行解码（将消息对象反序列化）；
(5) 服务端存根( server stub）根据解码结果调用本地的服务；
(6) 本地服务执行并将结果返回给服务端存根( server stub）；
(7) 服务端存根( server stub）将返回结果打包成消息（将结果消息对象序列化）；
(8) 服务端（server）通过sockets将消息发送到客户端；
(9) 客户端存根（client stub）接收到结果消息，并进行解码（将结果消息发序列化）；
(10) 客户端（client）得到最终结果。
RPC的目标是要把2、3、4、7、8、9这些步骤都封装起来。
注意：无论是何种类型的数据，最终都需要转换成二进制流在网络上进行传输，数据的发送方需要将对象转换为二进制流，而数据的接收方则需要把二进制流再恢复为对象
-
-
原文：https://www.cnblogs.com/swordfall/p/8683905.html
dubbo特性
1、面向代理的高性能RPC调用
2、智能负载均衡
3、服务自动注册与发现
4、可扩展
5、运行流量调度
6、可视化维护
配置覆盖
在dubbo的配置中，有三种配置形式，分别为xml、properties、-D
优先级为-D>xml>properties
-
不同粒度配置的覆盖关系
- 方法级优先，接口级次之，全局配置再次之。
- 如果级别一样，则消费方优先，提供方次之。
实例
1、启动检查
在dubbo中，默认情况下是启动检查的"check=true"，也就是说如果不先开启提供者，那么消费者就会报错。如果把“check=false"，那么据可以直接启动消费者，消费者只有在调用提供者时才会去检查是否有提供者。这样就避免了大规模启动的时候，各个服务器因启动时长不同导致报错的情况。
可以在
2、超时配置
为了避免网络延迟出现调用方法时间过长，导致大量线程堵塞。指定超时属性可以避免上述情况，其单位是毫秒级。timeout="3000" 这是3秒。默认超时时间是1秒。
同样可以统一配置在
3、重试次数
当某个服务方法求情超时导致远程调用失败，我们可以使用重试次数来多次重新访问。次数是整数，不包含第一次调用。
retries="3" 额外重新访问3次，一共4次。重试会调用相同模块中的不同计算机上的服务。
4、多版本
当某个接口或者功能出现了升级，可以先做出一部分的的功能换成新的，一部分保留老的。
在服务方
Zookeeper宕机也能继续使用dubbo ，前提是消费方已经访问过服务方。
负载均衡机制
1、RandomLoadBalance 权重访问
2、
设计架构
总架构
Dubbo框架设计一共划分了10个层，而最上面的Service层是留给实际想要使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口， 位于中轴线上的为双方都用到的接口。
Dubbo框架设计一共划分了10个层：
服务接口层（Service）：该层是与实际业务逻辑相关的，根据服务提供方和服务消费方的业务设计对应的接口和实现。
配置层（Config）：对外配置接口，以ServiceConfig和ReferenceConfig为中心，可以直接new配置类，也可以通过spring解析配置生成配置类。
服务代理层（Proxy）：服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。
服务注册层（Registry）：封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory、Registry和RegistryService。可能没有服务注册中心，此时服务提供方直接暴露服务。
集群层（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。
原文：https://baijiahao.baidu.com/s?id=1612574809664801766&wfr=spider&for=pc