分布式系统Dubbo学习(一)

基础知识

分布式系统

定义

若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统。分布式系统（distributed system）是建立在网络之上的软件系统。

演变过程

1. 单一应用架构

   当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。

   ![].\image\dubbo\SingleApplicationArchitecture.png)

   适用于小型网站，小型管理系统，将所有功能都部署到一个功能里，简单易用。

   缺点： 性能扩展比较难，协同开发问题，不利于升级维护

2. 垂直应用架构

   当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。
   
   通过切分业务来实现各个模块独立部署，降低了维护和部署的难度，团队各司其职更易管理，性能扩展也更方便，更有针对性。

   缺点： 公用模块无法重复利用，开发性的浪费

3. 分布式服务架构

   当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。

4. 流动计算架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)[
Service Oriented Architecture]是关键。

RPC简介

定义

RPC【Remote Procedure Call】是指远程过程调用，是一种进程间通信方式，他是一种技术的思想，而不是规范。它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同。

Dubbo概念

简介

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

官网：http://dubbo.apache.org/zh-cn/

基本概念

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

调用关系说明

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

特性

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

  提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。

• 只能负载均衡

  内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量。

• 服务自动注册与发现

  支持多种注册中心服务，服务实例上下线实时感知。

  

• 高度可扩展能力

  遵循微内核+插件的设计原则，所有核心能力如Protocol、Transport、Serialization被设计为扩展点，平等对待内置实现和第三方实现。

• 运行期流量调度

  内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布，同机房优先等功能。

• 可视化的服务治理与运维

  提供丰富服务治理、运维工具：随时查询服务元数据、服务健康状态及调用统计，实时下发路由策略、调整配置参数。

环境搭建

注册中心 官方推荐使用Zookeeper注册中心

1. 下载zookeeper

   网址 https://archive.apache.org/dist/zookeeper/zookeeper-3.4.13/

2. 解压zookeeper

   解压运行zkServer.cmd ，初次运行会报错，没有zoo.cfg配置文件

3. 修改zoo.cfg配置文件

   将conf下的zoo_sample.cfg复制一份改名为zoo.cfg即可。

   注意几个重要位置：

   dataDir=./ 临时数据存储的目录（可写相对路径）

   clientPort=2181 zookeeper的端口号

   修改完成后再次启动zookeeper

4. 使用zkCli.cmd测试

   ls /：列出zookeeper根下保存的所有节点

   create –e /hwl 123：创建一个hwl节点，值为123

   get /hwl：获取/hwl节点的值

监控中心

dubbo本身并不是一个服务软件。它其实就是一个jar包能够帮你的java程序连接到zookeeper，并利用zookeeper消费、提供服务。为了让用户更好的管理监控众多的dubbo服务，官方提供了一个可视化的监控程序，不过这个监控即使不装也不影响使用。

1. 下载dubbo-admin

   https://github.com/apache/incubator-dubbo-ops

2. 进入目录，修改dubbo-admin配置

   修改 src\main\resources\application.properties 指定zookeeper地址

3. 打包dubbo-admin

   mvn clean package -Dmaven.test.skip=true

4. 运行dubbo-admin

   java -jar dubbo-admin-0.0.1-SNAPSHOT.jar

   访问地址127.0.0.1:7001 默认使用root/root 登陆

Dobbo HelloWord

服务提供者配置

provider.xml

<!-- 1.指定当前服务/应用的名字（同样的服务名字相同，不要和别的服务重名） -->
<dubbo:application name="demo-provider"/>
<!-- 2.指定注册中心的位置 -->
<dubbo:registry address="zookeeper://127.0.0.1:2181"/>
<!-- 3.指定通信规则（通信协议？通信规则） -->
<dubbo:protocol name="dubbo" port="20890"/>
<!-- 4.暴露服务 ref：指向服务的真正的实现对象 -->
<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService" ref="demoService"/>
<!-- 5.服务的实现 -->
<bean id="demoService" class="org.apache.dubbo.samples.basic.impl.DemoServiceImpl"/>
<!-- 6.监控中心 -->
<dubbo:monitor protocal="registry"></dubbo:monitor>

服务消费者配置

consumer.xml

<!-- 1.指定当前服务/应用的名字（同样的服务名字相同，不要和别的服务重名） -->
<dubbo:application name="demo-consumer"/>
<!-- 2.指定注册中心的位置 -->
<dubbo:registry group="aaa" address="zookeeper://127.0.0.1:2181"/>
<!-- 3.声明需要调用的远程服务的接口，生成远程服务代理 -->
<dubbo:reference id="demoService" check="false" interface="org.apache.dubbo.samples.basic.api.DemoService"/>
<!--监控中心协议，如果为protocol="registry"，表示从注册中心发现监控中心地址，否则直连监控中心-->
<dubbo:monitor protocal="registry"></dubbo:monitor>
<!--Simple Monitor挂掉不会影响到 Consumer 和 Provider 之间的调用，所以用于生产环境没有风险。Simple Monitor采用磁盘存储统计信息，请注意安装机器的磁盘限制，如果要集群建议用mount共享磁盘。-->
<!-- 配置当前消费者统一规则，启动时检查提供者是否存在，true报错，false忽略 -->
<!-- 远程服务调用超时时间(毫秒) -->
<dubbo:consumer check="false" timeout="5000"></dubbo:consumer>

2.2.0及之前版本使用的是zkclient

2.3.0开始使用的是curator

整合SpringBoot

引入spring-boot-starter以及dubbo和curator的依赖

<dependency>
    <groupId>com.alibaba.boot</groupId>
    <artifactId>dubbo-spring-boot-starter</artifactId>
    <version>0.2.0</version>
</dependency>

注意starter版本适配:

配置application.properties

提供者配置

#application.name就是服务名，不能跟别的dubbo提供端重复
dubbo.application.name=gmall-user 
#registry.protocol 是指定注册中心协议
dubbo.registry.protocol=zookeeper
#registry.address 是注册中心的地址加端口号
dubbo.registry.address=192.168.67.159:2181 
#base-package  注解方式要扫描的包
dubbo.scan.base-package=com.weilong
#protocol.name 是分布式固定是dubbo,不要改。
dubbo.protocol.name=dubbo

消费者配置

dubbo.application.name=gmall-order-web
dubbo.registry.protocol=zookeeper
dubbo.registry.address=192.168.67.159:2181
dubbo.scan.base-package=com.weilong
dubbo.protocol.name=dubbo

dubbo注解

如果没有在配置中写dubbo.scan.base-package,还需要在主程序中使用@EnableDubbo注解

整合的三种方式

1. 导入dubbo-starter

   在application.properties配置属性，

   使用@Service 暴露服务

   ​ @Reference 调用服务

2. 保留dubbo xml配置文件

   导入dubbo-starter，使用@ImportResource导入dubbo的配置文件

Dubbo配置

配置原则

JVM 启动 -D 参数优先，这样可以使用户在部署和启动时进行参数重写，比如在启动时需改变协议的端口。

XML 次之，如果在 XML 中有配置，则 dubbo.properties 中的相应配置项无效。

Properties 最后，相当于缺省值，只有 XML 没有配置时，dubbo.properties 的相应配置项才会生效，通常用于共享公共配置，比如应用名。

超时时间

由于网络或服务端不可靠，会导致调用出现一种不确定的中间状态（超时）。为了避免超时导致客户端资源（线程）挂起耗尽，必须设置超时时间。

Dubbo消费端

<!-- 全局超时配置 -->
<dubbo:consumer timeout="5000" />
<!-- 指定接口以及特定方法超时配置 -->
<dubbo:reference interface="com.foo.BarService" timeout="2000">
    <dubbo:method name="sayHello" timeout="3000" />
</dubbo:reference>

Dubbo服务端

<!--全局超时配置 -->
<dubbo:provider timeout="5000" />
<!-- 指定接口以及特定方法超时配置 -->
<dubbo:provider interface="com.foo.BarService" timeout="2000">
    <dubbo:method name="sayHello" timeout="3000" />
</dubbo:provider>

配置原则

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

1)服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等

2)在Provider配置后，Consumer不配置则会使用Provider的配置值，即Provider配置可以作为Consumer

的缺省值。否则，Consumer会使用Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的

配置的覆盖规则：

1. 方法级配置别优于接口级别，即小Scope优先

2. Consumer端配置 优于 Provider配置 优于 全局配置，

3. 最后是Dubbo Hard Code的配置值（见配置文档）

重试次数

失败自动切换，当出现失败，重试其它服务器，但重试会带来更长延迟。

可通过 retries=“2” 来设置重试次数(不含第一次)。

<!-- 重试次数配置如下 -->
<!-- 密等 设置重试次数 [查询|删除|修改]  非密等 不能设置重试次数[新增] -->
<dubbo:service retries="2" />

<dubbo:reference retries="2" />

<dubbo:reference>
    <dubbo:method name="findFoo" retries="2" />
</dubbo:reference>

版本号

当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用（灰度发布）。

可以按照以下的步骤进行版本迁移：

1. 在低压力时间段，先升级一半提供者为新版本
2. 再将所有消费者升级为新版本
3. 然后将剩下的一半提供者升级为新版本

<!-- 版本服务提供者配置：-->
<dubbo:service interface="com.foo.BarService1" version="1.0.0" />
<!-- 新版本服务提供者配置：-->
<dubbo:service interface="com.foo.BarService2" version="2.0.0" />
<!-- 老版本服务消费者配置：-->
<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />
<!-- 新版本服务消费者配置：-->
<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />
<!-- 如果不需要区分版本，可以按照以下的方式配置：-->
<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />

本地存根

远程服务后，客户端通常只剩下接口，而实现全在服务器端，但提供方有些时候想在客户端也执行部分逻辑

比如：参数验证、本地缓存等操作

<!-- 配置本地存根 -->
<dubbo:service interface="com.foo.BarService" stub="true" />
<!-- 或者 -->
<dubbo:service interface="com.foo.BarService" stub="com.foo.BarServiceStub" />

存根实现：

package com.foo;
public class BarServiceStub implements BarService { 
    private final BarService barService;
    // 构造函数传入真正的远程代理对象
    public (BarService barService) {
        this.barService = barService;
    }
    public String sayHello(String name) {
        // 此代码在客户端执行, 你可以在客户端做ThreadLocal本地缓存，或预先验证参数是否合法，等等
        try {
            return barService.sayHello(name);
        } catch (Exception e) {
            // 你可以容错，可以做任何AOP拦截事项
            return "容错数据";
        }
    }
}

1. Stub 必须有可传入 Proxy 的构造函数。
2. 在 interface 旁边放一个 Stub 实现，它实现 BarService 接口，并有个传入远程 BarService 实例的构造函数