dubbo 框架解读_dubbo类似框架_dubbo框架

Dubbo 是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。主要核心部件：

Remoting: 网络通信框架，实现了 sync-over-async 和 request-response 消息机制. RPC:一个远程过程调用的抽象，支持负载均衡、容灾和集群功能 Registry: 服务目录框架用于服务的注册和服务事件发布和订阅

连通性说明

注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小；监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示。

服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销；服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销。

注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外；注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者；注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表；注册中心和监控中心都是可选的，服务消费者可以直连服务提供者。

健状性说明

监控中心宕掉不影响使用，只是丢失部分采样数据；宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务。

注册中心对等集群，任意一台宕掉后，将自动切换到另一台；注册中心全部宕掉后，服务提供者和服务消费者仍能通

过本地缓存通讯。服务提供者无状态，任意一台宕掉后，不影响使用；服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复。

伸缩性说明

注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心；服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者。

以上内容是Dubbo主页提供的一些简单介绍，对于Dubbo的详细架构分析和介绍网上也有专门的文章说明，在此不再详细描述，只是对Dubbo本身的一些架构思路和使用场景再做些简单总结。dubbo 框架解读

对于Dubbo分布式服务框架可以看到，对于实现系统内的完全组件化独立开发相当有好处，在这个之前我们往往使用的方法是利用OSGI软总线方式来实现内部的组件化开发和独立部署。而Dubbo框架可以更加容易的实现这点，即将逻辑层的方法很容易暴露为远程可以调用的各种类型的服务。即组件完全独立部署，而组件之间的交互只能够通过服务代理层暴露出来的服务进行交互，而这些服务都在服务注册中心进行注册。

对于注册中心和监控中心，这里有一个高可靠性设计，即即使两者都宕机无法访问，也不会影响到服务的正常消费和调用，这个设计相当重要，直接降低了本身服务框架和业务系统组件之间的强耦合性。当然注册中心本身也有内置的基于zookeeper的分布式协调机制和机器本身的动态心跳检测。

Dubbo分布式服务框架同传统的ESB一个重点区别就是对于实际的消息流不会走在Dubbo上面，即前面我有文章谈到过的对于服务的调用基本上是两次调用模式。即第一次调用首先从注册中心获取到动态的服务调用地址，第二次调用即服务的提供端和消费端直接握手，以解决消息流不需要在dubbo上传递的问题。这样做的好处就是dubbo本身不会有太大的消息传输和性能压力，但是缺点就是dubbo无法对消息传输日志进行详细的审计，这个只有留个各个业务系统自己去完成。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/shumachanpin/article-44658-1.html