Dubbo 详解

一、分布式基础

  分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统。

  老式系统(单一应用架构)就是把一个系统，统一放到一个服务器当中然后每一个服务器上放一个系统，如果说要更新代码的话，每一个服务器上的系统都要重新去部署十分的麻烦。而分布式系统就是将一个完整的系统拆分成多个不同的服务，然后再将每一个服务单独的放到一个服务器当中。

发展演变

ORM

单一应用架构： 一个项目装到一个服务器当中，也可以运行多个服务器每一个服务器当中都装一个项目。

缺点：

• 如果要添加某一个功能的话就要把一个项目重新打包，在分别部署到每一个服务器当中去。
• 如果后期项目越来越大的话单台服务器跑一个项目压力会很大，不利于维护，开发和程序的性能。

MVC

垂直应用架构： 将应用切割成几个互不相干的小应用，在将每个小应用独立放到一个服务器上，如果哪一个应用的访问数量多就多加几台服务器。

RPC

分布式应用架构（远程过程调用）： 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。

SOA

流动计算架构： 在分布式应用架构的基础上增加了一个调度、治理中心基于访问压力实时管理集群容量、提高集群的利用率，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键 (不浪费计算机资源)

RPC 简介

• RPC [ Remote Procedure Call]是指远程过程调用，是一种进程间的通信方式，他是一种技术的思想，而不是规范。它允许程序调用另一个地址空间(通常是共享网络的另一台机器上)的过程或函数，而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同。
• 它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。也就是说两台服务器 A，B，一个应用部署在 A 服务器上，想要调用 B 服务器上应用提供的方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。

RPC 工作原理

1. Client 像调用本地服务似的调用远程服务；
2. Client stub 接收到调用后，将方法、参数序列化；
3. 客户端通过 sockets 将消息发送到服务端；
4. Server stub 收到消息后进行解码（将消息对象反序列化）；
5. Server stub 根据解码结果调用本地的服务；
6. 本地服务执行(对于服务端来说是本地执行)并将结果返回给 Server stub；
7. Server stub 将返回结果打包成消息（将结果消息对象序列化）；
8. 服务端通过 sockets 将消息发送到客户端；
9. Client stub 接收到结果消息，并进行解码（将结果消息发序列化）；
10. 客户端得到最终结果。

RPC 调用分以下两种：

• 同步调用： 客户方等待调用执行完成并返回结果。
• 异步调用： 客户方调用后不用等待执行结果返回，但依然可以通过回调通知等方式获取返回结果。若客户方不关心调用返回结果，则变成单向异步调用，单向调用不用返回结果。

二、Dubbo 简介

  Dubbo 是一款高性能、轻量级的开源 Java RPC 框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，服务自动注册和发现。

特性

（1）服务注册中心

• 相比 Hessian 类 RPC 框架，Dubbo 有自己的服务中心， 写好的服务可以注册到服务中心， 客户端从服务中心寻找服务，然后再到相应的服务提供者机器获取服务。通过服务中心可以实现集群、负载均衡、高可用(容错) 等重要功能。
• 服务中心一般使用 zookeeper 实现，也有 redis 和其他一些方式。以使用 zookeeper 作为服务中心为例，服务提供者启动后会在 zookeeper 的/dubbo 节点下创建提供的服务节点，包含服务提供者 ip、port 等信息。服务提供者关闭时会从 zookeeper 中移除对应的服务。
• 服务使用者会从注册中心 zookeeper 中寻找服务，同一个服务可能会有多个提供者，Dubbo 会帮我们找到合适的服务提供者，也就是针对服务提供者的负载均衡。

（2）负载均衡

• 当同一个服务有多个提供者在提供服务时，客户端如何正确的选择提供者实现负载均衡呢？dubbo 也给我们提供了几种方案：
  • random 随机 选择提供者，并可以给提供者设置权重
  • roundrobin 轮询 选择提供者
  • leastactive 最少活跃调用数，相同活跃数的随机，活跃数：指调用前后计数差。使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
  • consistenthash 一致性 hash，相同参数的请求发到同一台机器上。

（3）简化测试，允许直连提供者
  在开发阶段为了方便测试，通常系统客户端能指定调用某个服务提供者，那么可以在引用服务时加一个 url 参数去指定服务提供者。

（4）服务版本，服务分组
  在 Dubbo 配置文件中可以通过制定版本实现连接制定提供者，也就是通过服务版本可以控制服务的不兼容升级；当同一个服务有多种实现时，可以使用服务分组进行区分。

设计架构

服务提供者（Provider）： 暴露服务的服务提供方，服务提供者在启动时，向注册中心注册自己提供的服务。
服务消费者（Consumer）: 调用远程服务的服务消费方，服务消费者在启动时，向注册中心订阅自己所需的服务，服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
注册中心（Registry）： 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
监控中心（Monitor）： 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

配置原则

1. JVM 启动 -D 参数优先，这样可以使用户在部署和启动时进行参数重写，比如在启动时需改变协议的端口。
2. XML 次之，如果在 XML 中有配置，则 dubbo.properties 中的相应配置项无效。
3. Properties 最后，相当于缺省值，只有 XML 没有配置时，dubbo.properties 的相应配置项才会生效，通常用于共享公共配置，比如应用名。

dubbo 推荐在 Provider 上尽量多配置 Consumer 端属性

配置的覆盖原则

高可用

  通过设计，减少系统不能提供服务的时间
zookeeper 宕机与 dubbo 直连
现象：zookeeper 注册中心宕机，还可以消费 dubbo 暴露的服务。
原因：

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

服务降级

  当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。
  可以通过服务降级功能临时屏蔽某个出错的非关键服务，并定义降级后的返回策略。

集群容错

  在集群调用失败时，Dubbo 提供了多种容错方案：

Failover Cluster

  失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries=“2” 来设置重试次数(不含第一次)。

Failfast Cluster

  快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。

Failsafe Cluster

  失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。

Failback Cluster

  失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。

Forking Cluster

  并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks=“2” 来设置最大并行数。

Broadcast Cluster

  广播调用所有提供者，逐个调用，任意一台报错则报错 [2]。通常用于通知所有提供者更新缓存或日志等本地资源信息。