Dubbo概述

最近微服务很流行，大家一窝蜂的涌向spring_clould，很多不明所以然的朋友又是一顿各种配置，总算把spring_clould的一系列组件搭建好了。
不知那天，可能又会出来一个spring_sky，spring_rain，spring_wind之系列。然，大家就一直跟着屁股跑吧。
其实这里想跟大家说的是，技术框架是永远都学不完的。

如果大家不专注于底层原理，而是一味的追随，随着年龄的增长，同行的竞争力就会立马显现出来。
即使很多公司可能用不了多么高深的技术，但是相比之下，公司更理性和稳妥的做法是选择有深度的人，不是吗？


言归正传，如果想深入了解Dubbo，建议把spring原理、Netty、redis、zookeeper 给走一遍，帮助还是极大的。
特别是Netty，推荐给大家阅读《Netty 实战》。
Dubbo入门，官网有详细的讲解。

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

Dubbo |ˈdʌbəʊ| is ahigh-performance, java based RPC framework open-sourced by Alibaba.

 

主要核心部件：

Remoting: 网络通信框架，实现了sync-over-async 和request-response 消息机制.

RPC: 一个远程过程调用的抽象，支持负载均衡、容灾和集群功能

Registry: 服务目录框架用于服务的注册和服务事件发布和订阅

 

其核心部分包含:

1. 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。

2. 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

3. 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

 

Dubbo能做什么？

1.透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。

2.软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

3. 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

 

工作原理：

Provider 暴露服务方称之为“服务提供者”。

Container: 服务运行容器。 

Consumer 调用远程服务方称之为“服务消费者”。

Registry 服务注册与发现的中心目录服务称之为“服务注册中心”。

Monitor 统计服务的调用次数和调用时间的日志服务称之为“服务监控中心”。

 

(1) 连通性：

注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小

监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示

服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销

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

注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外

注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者

注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表

注册中心和监控中心都是可选的，服务消费者可以直连服务提供者

 

(2) 健壮性：

监控中心宕掉不影响使用，只是丢失部分采样数据

数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务

注册中心对等集群，任意一台宕掉后，将自动切换到另一台

注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯

服务提供者无状态，任意一台宕掉后，不影响使用

服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

 

(3) 伸缩性：

注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心

服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者