关于java:Dubbo

Dubbo 是用于分布式系统的框架所以咱们要先理解什么是分布式
分布式系统是若干独立计算机的汇合，这些计算机对于用户来说就像单个相干零碎。

繁多利用架构 ：一个我的项目装到一个服务器当中，也能够运行多个服务器每一个服务器当中都装一个我的项目。
毛病：1. 如果要增加某一个性能的话就要把一个我的项目从新打包，在别离部署到每一个服务器当中去。2. 如果前期我的项目越来越大的话单台服务器跑一个我的项目压力会很大的。会不利于保护，开发和程序的性能。

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

分布式服务架构

利用之间交互不可避免，将外围业务抽取进去，作为独立的服务，逐步造成稳固的服务中心，使前端利用能更疾速的响应多变的市场需求。

什么叫 RPC

1.RPC 是指 近程过程调用 ，是一种过程问通信形式，他是一种 技术的思维，它容许程序调用另一个地址空间的办法

RPC（Remote Procedure Call）—近程过程调用，它是一种通过网络从近程计算机程序上申请服务，而不须要理解底层网络技术的协定。也就是说两台服务器 A，B，一个利用部署在 A 服务器上，想要调用 B 服务器上利用提供的办法，因为不在一个内存空间，不能间接调用，须要通过网络来表白调用的语义和传播调用的数据。

RPC 工作原理

Client 像调用本地服务似的调用近程服务；
Client stub 接管到调用后，将办法、参数序列化
客户端通过 sockets 将音讯发送到服务端
Server stub 收到音讯后进行解码（将音讯对象反序列化）
Server stub 依据解码后果调用本地的服务
本地服务执行 (对于服务端来说是本地执行) 并将后果返回给 Server stub
Server stub 将返回后果打包成音讯（将后果音讯对象序列化）
服务端通过 sockets 将音讯发送到客户端
Client stub 接管到后果音讯，并进行解码（将后果音讯发序列化）
客户端失去最终后果。

RPC 调用分以下两种：
同步调用 ：客户方期待调用执行实现并返回后果。
异步调用：客户方调用后不必期待执行后果返回，但仍然能够通过回调告诉等形式获取返回后果。若客户方不关怀调用返回后果，则变成单向异步调用，单向调用不必返回后果。

RPC 步骤解析

RPC 相干材料可拜访博客：
http://blog.csdn.net/smartbetter/article/details/100360835

SOA
流动计算架构 ：在分布式应用架构的根底上减少了一个 调度、治理核心 基于拜访压力实时治理集群容量、进步集群的利用率，用于进步机器利用率的资源调度和治理核心(SOA) 是要害 (不节约计算机资源)

Dubbo 官网: http://dubbo.apache.org/en-us…

Dubbo 是一款高性能、轻量级的开源 Java RPC 框架，它提供了三大外围能力：面向接口的近程办法调用，智能容错和负载平衡，服务主动注册和发现。分布式系统是将一个零碎拆分为多个不同的服务

该图来自 Dubbo 官网，形容了服务注册核心、服务提供方、服务生产方、服务监控核心之间的调用关系。

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

（1）服务注册核心

相比 Hessian 类 RPC 框架，Dubbo 有本人的服务中心，写好的服务能够注册到服务中心，客户端从服务中心寻找服务，而后再到相应的服务提供者机器获取服务。通过服务中心能够实现集群、负载平衡、高可用(容错) 等重要性能。
服务中心个别应用 zookeeper 实现，也有 redis 和其余一些形式。以应用 zookeeper 作为服务中心为例，服务提供者启动后会在 zookeeper 的 /dubbo 节点下创立提供的服务节点，蕴含服务提供者 ip、port 等信息。服务提供者敞开时会从 zookeeper 中移除对应的服务。
服务使用者会从注册核心 zookeeper 中寻找服务，同一个服务可能会有多个提供者，Dubbo 会帮咱们找到适合的服务提供者，也就是针对服务提供者的负载平衡。

（2）负载平衡

当同一个服务有多个提供者在提供服务时，客户端如何正确的抉择提供者实现负载平衡呢？dubbo 也给咱们提供了几种计划：
- random 随机 选提供者，并能够给提供者设置权重
- roundrobin 轮询 抉择提供者
- leastactive 起码沉闷调用数，雷同沉闷数的随机，沉闷数：指调用前后计数差。使慢的提供者收到更少申请，因为越慢的提供者的调用前后计数差会越大。
- consistenthash 一致性 hash，雷同参数的申请发到同一台机器上。

（3）简化测试，容许直连提供者
在开发阶段为了不便测试，通常零碎客户端能指定调用某个服务提供者，那么能够在援用服务时加一个 url 参数去指定服务提供者。配置如下：

 `<dubbo:reference id="xxxService"interface="com.alibaba.xxx.XxxService"url="dubbo://localhost:20890"/>` 

*   1

（4）服务版本，服务分组
在 Dubbo 配置文件中能够通过制订版本实现连贯制订提供者，也就是通过服务版本能够管制服务的不兼容降级；当同一个服务有多种实现时，能够应用服务分组进行辨别。

Dubbo 官网文档: http://dubbo.apache.org/en-us/docs/user/quick-start.html
在 zookeeper 官网下载 zookeeper
http://mirror.bit.edu.cn/apache/zookeeper/zookeeper-3.4.14/

在 bin 文件下，启动 zkServer.cmd 会有报错，解决须要在 condif 文件中将 zoo_sample.cfg 文件复制一份，将名字改为 zoo.cfg。
在 zookeeper 的文件夹下创立 data 文件夹，关上 zoo.cfg，批改 datadir，将 dataDir 数据保留为咱们自定义的文件中 (此步骤可省略)

配置结束后，咱们再次在 conf 下启动 zkServer.cmd，这次能够胜利启动

持续运行 zkCli.cmd，能够连贯到 zookeeper 的服务器。

此时，咱们 zookeeper 的注册核心及环境以及搭建结束。

1、下载 dubbo-admin

dubbo-admin 下载地址：https://github.com/apache/dubbo-admin/tree/master

2、解压后进入目录批改指定 zookeeper 地址
进入如下地址：dubbo-admin-masterdubbo-adminsrcmainresourcesapplication.properties”
将 zookeeper 的监控核心的地址配置为本地端口

`# 注册核心的地址
dubbo.registry.address=zookeeper://127.0.0.1:2181` 

*   1
*   2

配置结束后，咱们在 dubo-zookeeperdubbo-admin-masterdubbo-admin 文件夹下 cmd 打包测试下。

`mvn clean package` 

*   1

在 target 文件中打包实现的 jar 包

cmd 命令 java -jar dubbo-admin-0.0.1-SNAPSHOT.jar 运行打包好的 jar 包
启动胜利后，能够看到一个 7001 的端口

此时咱们的 zookeeper 的服务都为启动状态，在浏览器中拜访 localhost:7001，拜访到注册核心，输出账号密码 root。

此时，咱们 zookeeper 监控核心的配置实现。留神，要拜访到监控核心，肯定要启动 zookeeper 注册核心的启动类

基于以下图实现服务提供者、消费者

创立 Maven 我的项目 => user-service-provider 服务提供者

UserAddress

`public class UserAddress implements Serializable{
    private Integer id;
    private String userAddress; // 用户地址
    private String userId; // 用户 id
    private String consignee; // 收货人
    private String phoneNum; // 电话号码
    private String isDefault; // 是否为默认地址    Y- 是     N- 否
    //get     set 
    // 有参结构  无参结构
  }` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8
*   9
*   10

UserService

`// 用户服务
public interface UserService {
    /**
     * 依照用户 id 返回所有的收货地址
     * @param userId
     * @return
     */
    public List<UserAddress> getUserAddressList(String userId);
}` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8
*   9

UserServiceImpl

`public class UserServiceImpl implements UserService {public List<UserAddress> getUserAddressList(String userId) {UserAddress address1 = new UserAddress(1, "河南省郑州巩义市宋陵大厦 2F", "1", "坦然", "150360313x", "Y");
        UserAddress address2 = new UserAddress(2, "北京市昌平区沙河镇沙阳路", "1", "情话", "1766666395x", "N");

        return Arrays.asList(address1,address2);
    }
}` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8
*   9

创立 Maven 我的项目 => order-service-consumer 服务消费者(订单服务)

OrderService

`public interface OrderService {
    /**
     * 初始化订单
     * @param userID
     */
    public void initOrder(String userID);
}` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7

OrderServiceImpl

`public class OrderServiceImpl implements OrderService {public void initOrder(String userID) {// 查问用户的收货地址}
}` 

*   1
*   2
*   3
*   4
*   5
*   6

因服务消费者要拿到提供者的办法
将服务提供者中的实体类及 UserService 复制到以后消费者同级文件中。

OrderServiceImpl

`public class OrderServiceImpl implements OrderService {
    public UserService userService;
    public void initOrder(String userID) {
        // 查问用户的收货地址
        List<UserAddress> userAddressList = userService.getUserAddressList(userID);
        System.out.println(userAddressList);
    }
}` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8

此时咱们调用 userservice 必定是要报错的。这种面向接口的形式，咱们这里只是调到了接口，而接口理论是在另外一个我的项目中，如果咱们两个我的项目工程都创立独特的实体类，太过于麻烦了，咱们能够将服务接口，服务模型等独自放在一个我的项目中，更为不便调用。

创立 Maven 我的项目 => gmail-interface 用于寄存独特的服务接口

将提供者和消费者我的项目中的所有实体类复制到以后相干的文件包下，删除原有的实体类包及 service 包，也就是将实体类及 service 放在了以后公共的我的项目中。

把服务提供者和消费者我的项目中引入以下依赖，引入后我的项目不在报错.

 `<dependency>
        <groupId>com.lemon.gmail</groupId>
        <artifactId>gmail-interface</artifactId>
        <version>1.0-SNAPSHOT</version>
    </dependency>` 

*   1
*   2
*   3
*   4
*   5

在 user-service-provider 服务提供者我的项目中引入依赖

 `<!--dubbo-->
    <dependency>
        <groupId>com.alibaba</groupId>
        <artifactId>dubbo</artifactId>
        <version>2.6.2</version>
    </dependency>
    <!-- 注册核心是 zookeeper，引入 zookeeper 客户端 -->
    <dependency>
        <groupId>org.apache.curator</groupId>
        <artifactId>curator-framework</artifactId>
        <version>2.12.0</version>
    </dependency>` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8
*   9
*   10
*   11
*   12

在 resource 文件中创立provider.xml

`<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
        http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd
        http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
    <!--1、指定以后服务 / 利用的名字(同样的服务名字雷同，不要和别的服务同名)-->
   <dubbo:application name="user-service-provider"></dubbo:application>
    <!--2、指定注册核心的地位 -->
    <!--<dubbo:registry address="zookeeper://127.0.0.1:2181"></dubbo:registry>-->
    <dubbo:registry protocol="zookeeper" address="127.0.0.1:2181"></dubbo:registry>
    <!--3、指定通信规定（通信协议? 服务端口）-->
    <dubbo:protocol name="dubbo" port="20880"></dubbo:protocol>
    <!--4、裸露服务 让他人调用 ref 指向服务的真正实现对象 -->
    <dubbo:service interface="com.lemon.gmail.service.UserService" ref="userServiceImpl"></dubbo:service>

    <!-- 服务的实现 -->
    <bean id="userServiceImpl" class="com.lemon.gmail.service.impl.UserServiceImpl"></bean>
</beans>` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8
*   9
*   10
*   11
*   12
*   13
*   14
*   15
*   16
*   17
*   18
*   19
*   20

编写一个 ProviderApplication 启动类程序，运行测试配置

`public class MailApplication {public static void main(String[] args) throws IOException {ClassPathXmlApplicationContext applicationContext= new ClassPathXmlApplicationContext("provider.xml");
        applicationContext.start();
        System.in.read();}
}` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7

启动 zookeeper 注册核心的的 zkServer.cmd、和 zkCli.cmd 服务
在 dubbo-admin target 中 cmd 运行 java -jar dubbo-admin-0.0.1-SNAPSHOT.jar
再次启动我的项目，咱们能够看到在 zookeeper 中曾经发现服务提供者。
服务提供者的配置和测试实现

在 order-service-consumer 服务消费者我的项目中引入依赖

 `<!--dubbo-->
        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>dubbo</artifactId>
            <version>2.6.2</version>
        </dependency>
        <!-- 注册核心是 zookeeper，引入 zookeeper 客户端 -->
        <dependency>
            <groupId>org.apache.curator</groupId>
            <artifactId>curator-framework</artifactId>
            <version>2.12.0</version>
        </dependency>` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8
*   9
*   10
*   11
*   12

创立consumer.xml

`<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-4.3.xsd
        http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd
        http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
   <!-- 包扫描 -->
    <context:component-scan base-package="com.lemon.gmail.service.impl"/>

    <!-- 指定以后服务 / 利用的名字(同样的服务名字雷同，不要和别的服务同名)-->
    <dubbo:application name="order-service-consumer"></dubbo:application>
    <!-- 指定注册核心的地位 -->
    <dubbo:registry address="zookeeper://127.0.0.1:2181"></dubbo:registry>

    <!-- 调用近程裸露的服务，生成近程服务代理 -->
    <dubbo:reference interface="com.lemon.gmail.service.UserService" id="userService"></dubbo:reference>
</beans>` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8
*   9
*   10
*   11
*   12
*   13
*   14
*   15
*   16
*   17
*   18
*   19
*   20

把以后 OrderServiceImpl 实现类中加上注解

`@Service
public class OrderServiceImpl implements OrderService {
    @Autowired
    public UserService userService;
    public void initOrder(String userID) {
        // 查问用户的收货地址
        List<UserAddress> userAddressList = userService.getUserAddressList(userID);
        
        // 为了直观的看到失去的数据，以下内容也可不写
        System.out.println("以后接管到的 userId=>"+userID);
        System.out.println("**********");
        System.out.println("查问到的所有地址为：");
        for (UserAddress userAddress : userAddressList) {
            // 打印近程服务地址的信息
            System.out.println(userAddress.getUserAddress());
        }
        
    }
}` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8
*   9
*   10
*   11
*   12
*   13
*   14
*   15
*   16
*   17
*   18
*   19

编写一个 ConsumerApplication 启动类程序，运行测试配置

`public class ConsumerApplication {public static void main(String[] args) {ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext("consumer.xml");
        OrderService orderService = applicationContext.getBean(OrderService.class);

        // 调用办法查问出数据
        orderService.initOrder("1");
        System.out.println("调用实现...");
        System.in.read();}
}` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8
*   9
*   10
*   11

留神：消费者的运行测试须要先启动提供者。
启动服务提供者、消费者。及 zookeeper 的和 dubbo-admin，查看监控信息。
localhost:7001
此时能够看到一个提供者，一个消费者的信息监控信息。

进入 dubbo-monitor-simple 文件，执行 cmd 命令，mvn package 打包成 jar 包
将 dubbo-monitor-simple-2.0.0-assembly.tar.gz 压缩包解压至以后文件夹，解压后 config 文件查看 properties 的配置是否是本地的 zookeeper。
关上解压后的 assembly.bin 文件，start.bat 启动 dubbo-monitor-simple 监控核心
在浏览器 localhost:8080，能够看到一个监控核心。
在服务提供者和消费者的 xml 中配置以下内容，再次启动服务提供和消费者启动类。

 `<!--dubbo-monitor-simple 监控核心发现的配置 -->
    <dubbo:monitor protocol="registry"></dubbo:monitor>
    <!--<dubbo:monitor address="127.0.0.1:7070"></dubbo:monitor>-->` 

*   1
*   2
*   3

能够看到，这个监控核心也捕捉到了服务提供和消费者信息

创立 Maven 我的项目 boot-user-service-provider 服务提供者
导入以下依赖

`<parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.0.4.RELEASE</version>
        <relativePath />
    </parent>

    <dependencies>
        <dependency>
            <groupId>com.lemon.gmail</groupId>
            <artifactId>gmail-interface</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter</artifactId>
        </dependency>

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

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8
*   9
*   10
*   11
*   12
*   13
*   14
*   15
*   16
*   17
*   18
*   19
*   20
*   21
*   22
*   23
*   24
*   25

把 user-service-provider 中的 service 拿到此我的项目中。
留神，以此办法为返回的须要更改 interface 包中的 void 为 List

`@Service//dubbo 的服务裸露
@Component
public class UserServiceImpl implements UserService {public List<UserAddress> getUserAddressList(String userId) {UserAddress address1 = new UserAddress(1, "河南省郑州巩义市宋陵大厦 2F", "1", "坦然", "150360313x", "Y");
        UserAddress address2 = new UserAddress(2, "北京市昌平区沙河镇沙阳路", "1", "情话", "1766666395x", "N");

        return Arrays.asList(address1,address2);
    }
}` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8
*   9
*   10
*   11

配置 application.properties

`dubbo.application.name=boot-user-service-provider
dubbo.registry.address=127.0.0.1:2181
dubbo.registry.protocol=zookeeper

dubbo.protocol.name=dubbo
dubbo.protocol.port=20880

#连贯监控核心
dubbo.monitor.protocol=registry` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8
*   9

BootProviderApplication 启动类配置

`@EnableDubbo // 开启基于注解的 dubbo 性能
@SpringBootApplication
public class BootProviderApplication {public static void main(String[] args) {SpringApplication.run(BootProviderApplication.class, args);
    }
}` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8

启动注册核心，启动以后服务提供者，能够在浏览器看到一个服务提供者。

创立 Maven 我的项目 boot-order-service-consumer 服务消费者
导入以下依赖

`<parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.0.4.RELEASE</version>
        <relativePath /> <!-- lookup parent from repository -->
    </parent>

    <dependencies>
        <dependency>
            <groupId>com.lemon.gmail</groupId>
            <artifactId>gmail-interface</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

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

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8
*   9
*   10
*   11
*   12
*   13
*   14
*   15
*   16
*   17
*   18
*   19
*   20
*   21
*   22
*   23
*   24
*   25

把 order-service-consumer 我的项目中的 service 复制到以后我的项目。

`@Service
public class OrderServiceImpl implements OrderService {

    @Reference// 援用近程提供者服务
    UserService userService;

    public List<UserAddress> initOrder(String userID) {
        // 查问用户的收货地址
        List<UserAddress> userAddressList = userService.getUserAddressList(userID);

        System.out.println("以后接管到的 userId=>"+userID);
        System.out.println("**********");
        System.out.println("查问到的所有地址为：");
        for (UserAddress userAddress : userAddressList) {
            // 打印近程服务地址的信息
            System.out.println(userAddress.getUserAddress());
        }
        return userAddressList;
    }
}` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8
*   9
*   10
*   11
*   12
*   13
*   14
*   15
*   16
*   17
*   18
*   19
*   20

创立 OrderController 控制器

`@Controller
public class OrderController {
    @Autowired
    OrderService orderService;

    @RequestMapping("/initOrder")
    @ResponseBody
    public List<UserAddress> initOrder(@RequestParam("uid")String userId) {return orderService.initOrder(userId);
    }
}` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8
*   9
*   10
*   11

创立 application.properties 配置

`server.port=8081
dubbo.application.name=boot-order-service-consumer
dubbo.registry.address=zookeeper://127.0.0.1:2181

#连贯监控核心 注册核心协定
dubbo.monitor.protocol=registry` 

*   1
*   2
*   3
*   4
*   5
*   6

BootConsumerApplication 启动类创立

`@EnableDubbo // 开启基于注解的 dubbo 性能
@SpringBootApplication
public class BootConsumerApplication {public static void main(String[] args){SpringApplication.run(BootConsumerApplication.class,args);
    }
}` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7

配置结束，此时启动 zookeeper 注册核心及监控。
启动 springboot 配置的服务提供者和消费者
在浏览器输出 localhost:7001 查看后果
http://localhost:8081/initOrder?uid=1 查问到地址信息
duboo 的 springboot 整合配置实现。

dubbo 配置官网参考：http://dubbo.apache.org/zh-cn/docs/user/references/xml/dubbo-service.html
1、配置准则

JVM 启动 -D 参数优先，这样能够使用户在部署和启动时进行参数重写，比方在启动时需扭转协定的端口。
XML 次之，如果在 XML 中有配置，则 dubbo.properties 中的相应配置项有效。
Properties 最初，相当于缺省值，只有 XML 没有配置时，dubbo.properties 的相应配置项才会失效，通常用于共享公共配置，比方利用名。
2、启动时查看
Dubbo 缺省会在启动时查看依赖的服务是否可用，不可用时会抛出异样，阻止 Spring 初始化实现，以便上线时，能及早发现问题，默认 check=“true”。

能够通过 check=“false”敞开查看，比方，测试时，有些服务不关怀，或者呈现了循环依赖，必须有一方先启动。

另外，如果你的 Spring 容器是懒加载的，或者通过 API 编程提早援用服务，请敞开 check，否则服务长期不可用时，会抛出异样，拿到 null 援用，如果 check=“false”，总是会返回援用，当服务复原时，能主动连上。

以 order-service-consumer 消费者为例，在 consumer.xml 中增加配置

`<!-- 配置以后消费者的对立规定, 以后所有的服务都不启动时查看 -->
 <dubbo:consumer check="false"></dubbo:consumer>` 

*   1
*   2

增加后，即便服务提供者不启动，启动以后的消费者，也不会呈现谬误。
3、全局超时配置

` 全局超时配置
<dubbo:provider timeout="5000" />

指定接口以及特定办法超时配置
<dubbo:provider interface="com.foo.BarService" timeout="2000">
    <dubbo:method name="sayHello" timeout="3000" />
</dubbo:provider>` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7

配置准则
dubbo 举荐在 Provider 上尽量多配置 Consumer 端属性

`1、作服务的提供者，比服务应用方更分明服务性能参数，如调用的超时工夫，正当的重试次数，等等
2、在 Provider 配置后，Consumer 不配置则会应用 Provider 的配置值，即 Provider 配置能够作为 Consumer 的缺省值。否则，Consumer 会应用 Consumer 端的全局设置，这对于 Provider 不可控的，并且往往是不合理的 ` 

*   1
*   2

配置的笼罩规定：

办法级配置别优于接口级别，即小 Scope 优先
Consumer 端配置优于 Provider 配置优于全局配置，
最初是 Dubbo Hard Code 的配置值（见配置文档）
多版本控制
[
http://dubbo.apache.org/zh-cn…](http://dubbo.apache.org/zh-cn…
在服务提供者中复制多个 impl。起不同的名字

配置多个文件的门路及信息。
服务消费者调用时，可自在配置版本

1、将服务提供者注册到注册核心(如何裸露服务)
1.1 导入 Dubbo 的依赖和 zookeeper 客户端

2、让服务消费者去注册核心订阅服务提供者的服务地址
Springboot 与 Dubbo 整合的三种形式
2.1 导入 dubbo-starter。在 application.properties 配置属性，应用 @Service【裸露服务】，应用 @Reference【援用服务】
2.2 保留 Dubbo 相干的 xml 配置文件
导入 dubbo-starter，应用 @ImportResource 导入 Dubbo 的 xml 配置文件

3、应用注解 API 的形式
将每一个组件手动配置到容器中, 让 dubbo 来扫描其余的组件

zookeeper 宕机与 dubbo 直连
景象：zookeeper 注册核心宕机，还能够生产 dubbo 裸露的服务。
起因：

健壮性↓

监控核心宕掉不影响应用，只是失落局部采样数据
数据库宕掉后，注册核心仍能通过缓存提供服务列表查问，但不能注册新服务
注册核心对等集群，任意一台宕掉后，将主动切换到另一台
注册核心全副宕掉后，服务提供者和服务消费者仍能通过本地缓存通信
服务提供者无状态，任意一台宕掉后，不影响应用
服务提供者全副宕掉后，服务消费者利用将无奈应用，并有限次重连期待服务提供者复原
高可用：通过设计，缩小零碎不能提供服务的工夫；

在集群负载平衡时，Dubbo 提供了多种平衡策略，缺省为 random 随机调用。

负载平衡策略如下

Random LoadBalance 基于权重的随机负载平衡机制

随机，按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大散布越平均，而且按概率使用权重后也比拟平均，有利于动静调整提供者权重。

RoundRobin LoadBalance 基于权重的轮询负载平衡机制

轮循，按公约后的权重设置轮循比率。存在慢的提供者累积申请的问题，比方：第二台机器很慢，但没挂，当申请调到第二台时就卡在那，长此以往，所有申请都卡在调到第二台上。

LeastActive LoadBalance 起码沉闷数负载平衡机制
起码沉闷调用数，雷同沉闷数的随机，沉闷数指调用前后计数差。使慢的提供者收到更少申请，因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance 一致性 hash 负载平衡机制

一致性 Hash，雷同参数的申请总是发到同一提供者。当某一台提供者挂时，本来发往该提供者的申请，基于虚构节点，平摊到其它提供者，不会引起激烈变动。算法参见：http://en.wikipedia.org/wiki/Consistent_hashing 缺省只对第一个参数 Hash，如果要批改，请配置 <dubbo:parameter key="hash.arguments" value="0,1" /> 缺省用 160 份虚构节点，如果要批改，请配置 <dubbo:parameter key="hash.nodes" value="320" />

当服务器压力剧增的状况下，依据理论业务状况及流量，对一些服务和页面有策略的不解决或换种简略的形式解决，从而开释服务器资源以保障外围交易失常运作或高效运作。
能够通过服务降级性能长期屏蔽某个出错的非关键服务，并定义降级后的返回策略。
向注册核心写入动静配置笼罩规定：

`RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181"));
registry.register(URL.valueOf("override://0.0.0.0/com.foo.BarService?category=configurators&dynamic=false&application=foo&mock=force:return+null"));` 

*   1
*   2
*   3

其中：
mock=force:return+null 示意生产方对该服务的办法调用都间接返回 null 值，不发动近程调用。用来屏蔽不重要服务不可用时对调用方的影响。
还能够改为 mock=fail:return+null 示意生产方对该服务的办法调用在失败后，再返回 null 值，不抛异样。用来容忍不重要服务不稳固时对调用方的影响。

在集群调用失败时，Dubbo 提供了多种容错计划，缺省为 failover 重试。
集群容错模式

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

重试次数配置如下：
<dubbo:service retries=“2”/>
或
<dubbo:reference retries=“2”/>
或
dubbo:reference
<dubbo:method name=“findFoo”retries=“2”/>
</dubbo:reference>

Failfast Cluster
疾速失败，只发动一次调用，失败立刻报错。通常用于非幂等性的写操作，比方新增记录。

Failsafe Cluster
失败平安，出现异常时，间接疏忽。通常用于写入审计日志等操作。

Failback Cluster
失败主动复原，后盾记录失败申请，定时重发。通常用于音讯告诉操作。

Forking Cluster
并行调用多个服务器，只有一个胜利即返回。通常用于实时性要求较高的读操作，但须要节约更多服务资源。可通过 forks=“2”来设置最大并行数。

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

集群模式配置
依照以下示例在服务提供方和生产方配置集群模式
<dubbo:service cluster=“failsafe”/>
或
<dubbo:reference cluster=“failsafe”/>

服务熔断错解决配置参考 => https://www.cnblogs.com/xc-xinxue/p/12459861.html

Hystrix 旨在通过管制那些拜访近程零碎、服务和第三方库的节点，从而对提早和故障提供更弱小的容错能力。Hystrix 具备领有回退机制和断路器性能的线程和信号隔离，申请缓存和申请打包，以及监控和配置等性能
配置 spring-cloud-starter-netflix-hystrix
spring boot 官网提供了对 hystrix 的集成，间接在 pom.xml 里退出依赖：

 `<dependency>
     <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
      <version>1.4.4.RELEASE</version>
</dependency>` 

*   1
*   2
*   3
*   4
*   5

而后在 Application 类上减少 @EnableHystrix 来启用 hystrix starter：

`@SpringBootApplication
@EnableHystrix // 开启服务容错性能
public class ProviderApplication {... 启动办法}` 

*   1
*   2
*   3
*   4
*   5

配置 Provider 端
在 Dubbo 的 Provider 上减少 @HystrixCommand 配置，这样子调用就会通过 Hystrix 代理。

`@Service(version = "1.0.0")
public class HelloServiceImpl implements HelloService {
    @HystrixCommand(commandProperties = {@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),
     @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "2000") })
    @Override
    public String sayHello(String name) {// System.out.println("async provider received:" + name);
        // return "annotation: hello," + name;
        throw new RuntimeException("Exception to show hystrix enabled.");
    }
}` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8
*   9
*   10
*   11
*   12

配置 Consumer 端
对于 Consumer 端，则能够减少一层 method 调用，并在 method 上配置 @HystrixCommand。当调用出错时，会走到 fallbackMethod = “reliable” 的调用里。

`@Reference(version = "1.0.0")
    private HelloService demoService;

    @HystrixCommand(fallbackMethod = "reliable")
    public String doSayHello(String name) {return demoService.sayHello(name);
    }
    public String reliable(String name) {return "hystrix fallback value";}` 

*   1
*   2
*   3
*   4
*   5
*   6
*   7
*   8
*   9
*   10

一次残缺的 RPC 调用流程（同步调用，异步另说）如下：

服务生产方（client）调用以本地调用形式调用服务；
client stub 接管到调用后负责将办法、参数等组装成可能进行网络传输的音讯体；
client stub 找到服务地址，并将音讯发送到服务端；
server stub 收到音讯后进行解码；
server stub 依据解码后果调用本地的服务；
本地服务执行并将后果返回给 server stub；
server stub 将返回后果打包成音讯并发送至生产方；
client stub 接管到音讯，并进行解码；
服务生产方失去最终后果。

dubbo 只用了两步 1 和 8，两头的过程是通明的看不到的。RPC 框架的指标就是要 2~8 这些步骤都封装起来，这些细节对用户来说是通明的，不可见的。

Netty 是一个异步事件驱动的网络应用程序框架，用于疾速开发可保护的高性能协定服务器和客户端。它极大地简化并简化了 TCP 和 UDP 套接字服务器等网络编程。
BIO：(Blocking IO)
NIO (Non-Blocking IO)
Selector 个别称为选择器，也能够翻译为多路复用器，
Connect（连贯就绪）、Accept（承受就绪）、Read（读就绪）、Write（写就绪）

Netty 基本原理：
netty 基本原理，可参考 https://www.sohu.com/a/272879207_463994

config 配置层：对外配置接口，以 ServiceConfig, ReferenceConfig 为核心，能够间接初始化配置类，也能够通过 spring 解析配置生成配置类
proxy 服务代理层：服务接口通明代理，生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy 为核心，扩大接口为 ProxyFactory
registry 注册核心层：封装服务地址的注册与发现，以服务 URL 为核心，扩大接口为 RegistryFactory, Registry, RegistryService
cluster 路由层：封装多个提供者的路由及负载平衡，并桥接注册核心，以 Invoker 为核心，扩大接口为 Cluster, Directory, Router, LoadBalance
monitor 监控层：RPC 调用次数和调用工夫监控，以 Statistics 为核心，扩大接口为 MonitorFactory, Monitor, MonitorService
protocol 近程调用层：封装 RPC 调用，以 Invocation, Result 为核心，扩大接口为 Protocol, Invoker, Exporter
exchange 信息替换层：封装申请响应模式，同步转异步，以 Request, Response 为核心，扩大接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer
transport 网络传输层：形象 mina 和 netty 为对立接口，以 Message 为核心，扩大接口为 Channel, Transporter, Client, Server, Codec
serialize 数据序列化层：可复用的一些工具，扩大接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool

分布式简要阐明

利用架构及倒退演变

Dubbo 和 SpringCloud 比照

倒退演变

RPC 简介

Dubbo 外围概念

Dubbo 个性一览

dubbo 设计架构

Dubbo 的个性

dubbo 环境搭建 ZooKeeper 注册核心

搭建 zookeeper 注册核心环境

zookeeper 监控核心的配置

Dubbo 环境搭建，创立提供者、消费者我的项目

Dubbo 服务提供消费者接口搭建

服务提供者配置及测试

服务消费者配置及测试

dubbo-monitor-simple 繁难监控核心

Dubbo 与 SpringBoot 整合

boot-user-service-provider 服务提供者

boot-order-service-consumer 服务消费者

Dubbo 配置

dubbo 与 springboot 整合的三种形式

高可用

集群下 dubbo 负载平衡配置

整合 hystrix，服务熔断与降级解决

服务降级

集群容错

整合 hystrix

dubbo 原理

RPC 原理

netty 通信原理

dubbo 原理

1.dubbo 原理 - 框架设计

2.dubbo 原理 - 启动解析、加载配置信息

3.dubbo 原理 - 服务裸露

4.dubbo 原理 - 服务援用

5.dubbo 原理 - 服务调用