dubbo_初识DUBBO

1、why（为什么选择使用dubbo）

目前自己参与的一个项目有这么几个情况：

（1）由于项目逻辑较复杂，需要有多个服务同时为此项目提供服务，如果通过URL配置进行管理可能会相当复杂；

（2）由于复杂，各个服务之间的依赖关系也很多很乱，就各个服务的启动顺序都是一个让人头痛的问题；

（3）根据现在的需要分析来看，上线之后的用户量也相当大，服务的扩展也是一个重要问题。

由于以上问题的存在，领导最终选择了使用开源框架DUBBO。

2、what（什么是dubbo）------ 以下部分内容摘自于官网

（1）Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 SPRING框架无缝集成。

（2）dubbo架构

角色说明：

provider：暴露服务的服务提供方；

consumer：调用远程服务的服务消费方；

registry：注册与发现服务的注册中心；

monitor：服务的统计计数的监控中心；

container：服务运行容器；

过程说明：

<0> 服务容器负责启动，加载，运行服务提供者。

<1>服务提供者在启动时，向注册中心注册自己提供的服务。

<2>服务消费者在启动时，向注册中心订阅自己所需的服务。

<3> 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

<4>服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

<5> 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

特点说明：

(1) 连通性：
•注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小
•监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示
•服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销
•服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销
•注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
•注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
•注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
•注册中心和监控中心都是可选的，服务消费者可以直连服务提供者

(2) 健状性：
•监控中心宕掉不影响使用，只是丢失部分采样数据
•数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
•注册中心对等集群，任意一台宕掉后，将自动切换到另一台
•注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
•服务提供者无状态，任意一台宕掉后，不影响使用
•服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

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

(4) 升级性：
•当服务集群规模进一步扩大，带动IT治理结构进一步升级，需要实现动态部署，进行流动计算，现有分布式服务架构不会带来阻力：

（3）模块分包

模块说明：

• dubbo-common 公共逻辑模块，包括Util类和通用模型。
• dubbo-remoting 远程通讯模块，相当于Dubbo协议的实现，如果RPC用RMI协议则不需要使用此包。
• dubbo-rpc 远程调用模块，抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。
• dubbo-cluster 集群模块，将多个服务提供方伪装为一个提供方，包括：负载均衡, 容错，路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。
• dubbo-registry 注册中心模块，基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。
• dubbo-monitor 监控模块，统计服务调用次数，调用时间的，调用链跟踪的服务。
• dubbo-config 配置模块，是Dubbo对外的API，用户通过Config使用Dubbo，隐藏Dubbo所有细节。
• dubbo-container 容器模块，是一个Standlone的容器，以简单的Main加载Spring启动，因为服务通常不需要Tomcat/JBoss等Web容器的特性，没必要用Web容器去加载服务。

整体上按照分层结构进行分包，与分层的不同点在于：

• container为服务容器，用于部署运行服务，没有在层中画出。
• protocol层和proxy层都放在rpc模块中，这两层是rpc的核心，在不需要集群时(只有一个提供者)，可以只使用这两层完成rpc调用。
• transport层和exchange层都放在remoting模块中，为rpc调用的通讯基础。
• serialize层放在common模块中，以便更大程度复用。

以上内容是自己从网上其它地方查的我自己想了解的一些信息，自己综合在一起做为自己的一个笔记，接下来我想对dubbo进行一下深入了解，也想学习一下源码，这虽然对于我一个从来没看过开源代码的人来说有点难，但我想挑战一下自己，万事开头难，我想只要坚持努力，会有效果的。加油。