Dubbo是一个SOA基于TCP传输和Hession序列化的一个轻量级的开源RPC框架，10层模型，可以大概分为三层。

SOA架构

即面向服务架构。
面向服务的体系结构，是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。
接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
image.pngimage.png

业务逻辑层

我们自己来提供一些接口和实现，还有一些接口信息。

RPC层

（Remote Procedure Call）远程过程调用，

网络层

网络传输协议和数据的一个封装

六大核心能力

面向接口代理的高性能RPC调用

智能容错和负载均衡

服务的自动注册和发现

高度可扩展能力

运行期流量调度

可视化的服务治理和运维

配置

  1. <!-- 整合Dubbo -->
  2. <!-- 第一步：Dubbo起名称    计算用此名称来区分   -->
  3. <dubbo:application name="babasport-console"/>
  4. <!-- 第二步：中介  注册中心    zookeeper  redis ... -->
  5. <!--<dubbo:registry address="192.168.200.128:2181,192.168.200.129:2181,192.168.200.130:2181" protocol="zookeeper"/> -->
  6. <dubbo:registry address="192.168.200.128:2181" protocol="zookeeper"/>
  7. <!-- 第三步：调用服务提供方 提供的接口 -->
  8. <dubbo:reference interface="cn.itcast.core.service.TestTbService" id="testTbService"/>

与Zookeeper的关系

image.png

Dubbo建议使用Zookeeper作为服务的注册中心。

Zookeeper的作用：

zookeeper用来注册服务和进行负载均衡，哪一个服务由哪一个机器来提供必需让调用者知道，简单来说就是ip地址和服务名称的对应关系。当然也可以 通过硬编码的方式把这种对应关系在调用方业务代码中实现，但是如果提供服务的机器挂掉调用者无法知晓，如果不更改代码会继续请求挂掉的机器提供服务。 zookeeper通过心跳机制可以检测挂掉的机器并将挂掉机器的ip和服务对应关系从列表中删除。至于支持高并发，简单来说就是横向扩展，在不更改代码 的情况通过添加机器来提高运算能力。通过添加新的机器向zookeeper注册服务，服务的提供者多了能服务的客户就多了。

dubbo：

是管理中间层的工具，在业务层到数据仓库间有非常多服务的接入和服务提供者需要调度，dubbo提供一个框架解决这个问题。
注意这里的dubbo只是一个框架，至于你架子上放什么是完全取决于你的，就像一个汽车骨架，你需要配你的轮子引擎。这个框架中要完成调度必须要有一个分布式的注册中心，储存所有服务的元数据，你可以用zk，也可以用别的，只是大家都用zk。

zookeeper和dubbo的关系：

Dubbo的将注册中心进行抽象，是得它可以外接不同的存储媒介给注册中心提供服务，有ZooKeeper，Memcached，Redis等。
引入了ZooKeeper作为存储媒介，也就把ZooKeeper的特性引进来。首先是负载均衡，单注册中心的承载能力是有限的，在流量达到一定程度的时 候就需要分流，负载均衡就是为了分流而存在的，一个ZooKeeper群配合相应的Web应用就可以很容易达到负载均衡；资源同步，单单有负载均衡还不 够，节点之间的数据和资源需要同步，ZooKeeper集群就天然具备有这样的功能；命名服务，将树状结构用于维护全局的服务地址列表，服务提供者在启动 的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址，这个操作就完成了服务的发布。 其他特性还有Mast选举，分布式锁等。

负载均衡

Dubbo内置了4种负载均衡策略:

  1. RandomLoadBalance:随机负载均衡。随机的选择一个。是Dubbo的默认负载均衡策略，也是按权重来选择的，不是完全随机，性能好可以设置权重大，调用概率高
  2. RoundRobinLoadBalance:轮询负载均衡。轮询选择一个，性能好可以设置权重大，轮询负载均衡算法可以让RPC调用严格按照我们设置的比例来分配，性能好分的多，存在慢的 Provider 累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上，导致整个系统变慢。
  3. LeastActiveLoadBalance:最少活跃调用数，相同活跃数的随机。活跃数指调用前后计数差。使慢的 Provider 收到更少请求，因为越慢的 Provider 的调用前后计数差会越大，就是来一个请求活跃调用数加1，请求结束减1，处理快的服务器，累积下来肯定请求结束的早，积累的少，可以拿到更多请求。
  4. ConsistentHashLoadBalance:一致性哈希负载均衡。相同参数的请求总是落在同一台机器上，这个 Provider 上可以把用户数据在内存中进行缓存，减少访问数据库或分布式缓存的次数。如果业务上允许这部分数据有一段时间的不一致，可以考虑这种做法。（适合一致性要求不高的场景）