共计 28914 个字符，预计需要花费 73 分钟才能阅读完成。
这篇文章是我学习整顿 Dubbo 的一篇文章，首先大部分内容参考了官网 + 某硅谷的视频，内容解说进行了从新编排，40 多张图片，也都是我批改重制的，尽管一万多字，然而其实也能够看进去，更多的内容集中在了概念或性能的介绍，具体环境的搭建，以及如何配置，疾速上手下面，然而对于这样一款优良的框架，文章中提到的每一个点其实开展来讲都能写这样篇幅的一篇文章，仅仅入门来看也没必要，总得学会走，才能够去试着跑
- 文章提及了 SSM 和 Springboot 下的不同配置形式，然而 Zookeeper 环境搭在了 Windows 下，前面筹备重新整理的 Redis 我思考在 Linux 中来跑，会更贴近理论一些
- 说句题外话，设计模式也没停，还有一篇存稿，不过想整顿的货色太多，还有学校等等的事件，真有点自闭了
- 有什么倡议和意见欢送在评论区和我交换哈，感激各位大佬的反对~
早安，学习人 & 打工人 ~ ~ ~
一 必备基础知识
(一) 分布式基础理论
在百度以及维基中的定义都绝对业余且艰涩，大部分博客或者教程常常会应用《分布式系统原理和范型》中的定义，即：“分布式系统是若干独立计算机的汇合，这些计算机对于用户来说就像是单个相干零碎”
上面咱们用一些篇幅来艰深的解释一下什么叫做分布式
(1) 什么是集中式零碎
提到分布式，不得不提的就是 “集中式零碎”，这个概念最好了解了，它就是将性能，程序等装置在同一台设施上，就由这一台主机设施向外提供服务
举个最简略的例子：你拿一台 PC 主机，将其改装成了一台简略的服务器，配置好各种内容后，你将 MySQL，Web 服务器，FTP，Nginx 等等，全副装置在其中，打包部署我的项目后，就能够对外提供服务了，然而一旦这台机器无论是软件还是硬件呈现了问题，整个零碎都会受到重大的株连谬误，鸡蛋放在一个篮子里，要打就全打了
(2) 什么是分布式系统
既然集中式零碎有这样一种牵一发而动全身的问题，那么分布式的其中一个作用，天然是来解决这样的问题了，正如定义中所知，分布式系统在用户的体验感官里，就像传统的单零碎一样，一些变动都是这个零碎自身外部进行的，对于用户并没有什么太大的感觉
例如：淘宝，京东这种大型电商平台，它们的主机都是数以万计的，否则基本没法解决大量的数据和申请，具体其中有什么划分，以及操作，咱们上面会说到，然而对于用户的咱们，咱们不须要也不想关怀这些，咱们仍能够单纯的认为，咱们面对的就是“淘宝”这一台“主机”
所以分布式的一个绝对业余一些的说法是这样的（过程粒度）两个或者多个程序，别离运行在不同的主机过程上，它们互相配合协调，实现独特的性能，那么这几个程序之间形成的零碎就能够叫做分布式系统
- 这几者都是雷同的程序 —— 分布式
- 这几者都是不同的程序 —— 集群
(3) 倒退过程
A：繁多利用架构
当网站流量很小时，只需一个利用，将所有性能都部署在一起，以缩小部署节点和老本。此时，用于简化增删改查工作量的数据拜访框架 (ORM) 是要害
长处：
- 所有性能集中在一起，开发以及前期保护均绝对简略
- 对于小型网站及管理系统，简略易用
毛病：
- 对于大型项目，降级保护艰难
- 无奈对于一个模块进行程度扩大或优化
- 模块之间耦合严密，容错率低
B：垂直利用架构
当访问量逐步增大，繁多利用减少机器带来的加速度越来越小，晋升效率的办法之一是将利用拆成互不相干的几个利用，以晋升效率。此时，用于减速前端页面开发的 Web 框架 (MVC) 是要害
长处：
- 通过切分业务达到各模块独立部署，保护和部署更加简略
- 能够对一个模块进行程度扩大或优化
毛病：
- 零碎之间无奈互相调用
- 具备反复代码，且专用模块无奈反复利用
C：分布式服务架构
当垂直利用越来越多，利用之间交互不可避免，将外围业务抽取进去，作为独立的服务，逐步造成稳固的服务中心，使前端利用能更疾速的响应多变的市场需求。此时，用于进步业务复用及整合的分布式服务框架 (RPC) 是要害
长处：
- 抽取公共代码，代码复用性进步
毛病：
- 调用关系简单，保护很麻烦
D：流动计算架构
当服务越来越多，容量的评估，小服务资源的节约等问题逐步浮现，此时需减少一个调度核心基于拜访压力实时治理集群容量，进步集群利用率。此时，用于进步机器利用率的资源调度和治理核心 (SOA) 是要害
长处：
- 简单的调用关系不再须要自行保护
毛病：
- 服务具备依赖性，一个服务呈现问题或者会导致其余零碎不可用
(4) RPC 介绍
RPC（Remote Procedure Call）是指近程过程调用 ，是一种过程间通信形式，他是一种技术的思维，而不是标准。 它容许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不必程序员显式编码这个近程调用的细节
这应该是很好了解的，调用本地 A 服务器上的函数或者办法的时候很简略，然而如果 A 想要拜访 B 的办法时，两者的内存空间压根都不是同一个，只能通过网络传输调用的相干内容，对于传输协定亦或者传输方式，都由 RPC 帮咱们背地实现
也就是说，即程序员无论是调用本地的还是近程的函数，实质上编写的调用代码基本相同
对于 RPC 更加粗疏业余的解释阐明
RPC 是一种通过网络从近程计算机程序上申请服务，而不须要理解底层网络技术的协定。RPC 协定假设某些传输协定的存在，如 TCP 或 UDP，为通信程序之间携带信息数据。在 OSI 网络通信模型中，RPC 逾越了传输层和应用层。RPC 使得开发包含网络分布式多程序在内的应用程序更加容易
RPC 采纳客户机 / 服务器模式。申请程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用过程发送一个有过程参数的调用信息到服务过程，而后期待应答信息。在服务器端，过程放弃睡眠状态直到调用信息达到为止。当一个调用信息达到，服务器取得过程参数，计算结果，发送回答信息，而后期待下一个调用信息，最初，客户端调用过程接管回答信息，取得过程后果，而后调用执行持续进行
某乎：谁能用艰深的语言解释一下什么是 RPC 框架？
本地过程调用
RPC 就是要像调用本地的函数一样去调近程函数。在钻研 RPC 前，咱们先看看本地调用是怎么调的。假如咱们要调用函数 Multiply 来计算 lvalue * rvalue 的后果:
…… 省略，此篇可细细看一下
问题答者：洪春涛
来看一下从 A 想要拜访 B 中办法的一个流程例子
顺着执行路线来捋一下
- ① 客户端 Client 收回一个调用近程服务的信号
- ② Client Stub 接管到调用，把办法参数进行序列化解决
- ③ 客户端 Client 通过 Sockets 将音讯发送到服务端
- ④ 服务端的 Server Stub，对收到的音讯进行解码，也就是反序列化的过程
- ⑤ 服务端 Server Stub，依据解码后果，调用服务端的本地服务
- ⑥ 服务端的本地服务执行，且将后果返回给本人的 Server Stub
- ⑦ Server Stub 打包后果成音讯，即序列化后果音讯
- ⑧ 服务端通过 Sockets 将音讯发送到客户端
- ⑨ 客户端的 Client Stub 接管到服务端传来的后果音讯，进行解码解决，即反序列化
- ⑩ 客户端失去从服务端传来的最初后果
第③点阐明：RPC 采纳客户机 / 服务器模式。申请程序就是一个客户机，而服务提供程序就是一个服务器。
(二) Dubbo 概念
(1) 介绍
Dubbo 官网：http://dubbo.apache.org/zh/
Apache Dubbo 是一款高性能、轻量级的开源 Java 服务框架
Apache Dubbo |ˈdʌbəʊ| 提供了六大外围能力：面向接口代理的高性能 RPC 调用，智能容错和负载平衡，服务主动注册和发现，高度可扩大能力，运行期流量调度，可视化的服务治理与运维。
面向接口代理的高性能 RPC 调用
- 提供高性能的基于代理的近程调用能力，服务以接口为粒度，为开发者屏蔽近程调用底层细节。
智能负载平衡
- 内置多种负载平衡策略，智能感知上游节点健康状况，显著缩小调用提早，进步零碎吞吐量。
服务主动注册与发现
- 反对多种注册核心服务，服务实例高低线实时感知。
高度可扩大能力
- 遵循微内核 + 插件的设计准则，所有外围能力如 Protocol、Transport、Serialization 被设计为扩大点，平等看待内置实现和第三方实现。
运行期流量调度
- 内置条件、脚本等路由策略，通过配置不同的路由规定，轻松实现灰度公布，同机房优先等性能。
可视化的服务治理与运维
- 提供丰盛服务治理、运维工具：随时查问服务元数据、服务衰弱状态及调用统计，实时下发路由策略、调整配置参数。
(2) 架构
这是 Dubbo 的架构图
首先介绍一下这五个节点的角色（五个圆角矩形框）
Provider：裸露服务的 服务提供方Consume：调用近程服务的 服务生产方Registry：服务注册与发现的 注册核心Monitor：统计服务的调用次数和调用工夫的 监控核心Container：服务 运行容器
再来看一下调用的关系和流程：
- ① 服务容器负责启动，加载，运行服务提供者
- ② 服务提供者在启动时，向注册核心注册本人提供的服务
- ③ 注册核心返回服务提供者地址列表给消费者，如果有变更，注册核心将基于长连贯推送变更数据给消费者
- ④ 服务消费者，从提供者地址列表中，基于软负载平衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用
- ⑤ 服务消费者和提供者，在内存中累计调用次数和调用工夫，定时每分钟发送一次统计数据到监控核心
(三) dubbo 环境搭建
阐明：以下为学习演示不便，均为 Windows 零碎搭建，实在 Linux 场景搭建会在前面出一篇，如何在 Linux 装置配置常见的软件
(1) 搭建 zookeeper 注册核心环境
A：下载 zookeeper
首先先将 zookeeper 下载下来
官网（查看文档，下载）：https://zookeeper.apache.org/
嫌麻烦就间接去下载页面：https://downloads.apache.org/zookeeper/
这里下载的版本是：apache-zookeeper-3.6.2
留神：下载，apache-zookeeper-3.6.2.tar.gz，apache-zookeeper-3.6.2-bin.tar.gz，尽管实质咱们是用前者，然而启动过程中遇到了报错，须要后者局部文件来进行修复
B：配置及排错
XXX\apache-zookeeper-3.6.2\bin，上面的 zkServer.cmd 和 zkCli.cmd 就是咱们想要运行的，能够在当前目录下关上 cmd（什么都行）运行 zkServer.cmd，首先可能会遇到第一个谬误——找不到或无奈加载主类
这个时候就须要解压方才下载的 apache-zookeeper-3.6.2-bin.tar.gz，而后在其目录下，复制整个 lib 文件夹到方才的 apache-zookeeper-3.6.2 文件夹下，这样就解决了
再次运行，会有第二个问题：一个配置文件的缺失
这个问题只须要在 XXX\apache-zookeeper-3.6.2\conf 中把 zoo_sample.cfg 文件复制一份，且名字改为 zoo.cfg
能够关上编辑这个新复制过去的 zoo.cfg 文件，其中就是一些配置内容，例如端口还有一个数据的存储地址，因为它默认用的是 linux 的地位，所以咱们如果想要批改，也能够将 dataDir=/tmp/zookeeper 批改为 dataDir=../data，就是在根目录下创立了一个 data 文件夹，也能够本人指定，也能够不论这个
C：运行服务端及客户端
都解决好了，来运行 zkServer.cmd，就启动胜利了
运行 zkCli.cmd，能够胜利连贯到 zookeeper 的服务器
服务端客户端都跑起来了，搭建 zookeeper 注册核心环境到这里就算 OK 了
(2) 配置 zookeeper 监控核心
dubbo 自身并不是一个服务软件。它其实就是一个 jar 包可能帮你的 java 程序连贯到 zookeeper，并利用 zookeeper 生产、提供服务。所以你不必在 Linux 上启动什么 dubbo 服务
然而为了让用户更好的治理监控泛滥的 dubbo 服务，官网提供了一个可视化的监控程序——dubbo-admin，不过这个监控即便不装也不影响应用
A：下载 dubbo-admin
下载地址：https://github.com/apache/dub…
从 github 上 down 到本地，有 dubbo-admin-master 一个文件夹，其中含有三个次要文件夹
- dubbo-admin
- dubbo-monitor-simple
- dubbo-registry-simple
B：先确认配置正确
咱们当初先只针对 dubbo-admin 操作
关上编辑配置文件：XXX\dubbo-admin-master\dubbo-admin\src\main\resources\application.properties
确认其中的配置，比方端口，明码什么等等都是失常的，例如服务端口 7001，明码 root，最要害的就是地址，因为咱们测试是在本机，所以地址如下就能够了
dubbo.registry.address=zookeeper://127.0.0.1:2181C：打包运行
既然没问题了，就在 xx\dubbo-admin-master\dubbo-admin，这个文件夹下进行打包，用 cmd 也都一样，命令如下：
mvn clean package
打包胜利后，target 文件夹中会多出一个 dubbo-admin-0.0.1-SNAPSHOT.jar，咱们把它复制到一个本人指定的地位，而后通过 cmd 运行这个 jar
java -jar dubbo-admin-0.0.1-SNAPSHOT.jar
其实就是运行了一个 springboot 的我的项目，而后控制台会有写到是一个 7001 端口，来去拜访一下，用户名，明码都是 root，呈现如下所图就是胜利了
留神：要想拜访到这个页面，请保障 zookeeper 注册核心启动了
(四) 第一个 Dubbo 我的项目
咱们第一个例子就照着这个网络上参考的例子来做（代码并不重要，要害是了解调用关系和配置形式）：
解释一下，订单生成前的时候，须要调用用户服务，查问到用户所有的收货地址，用户选定地址后，再生成订单，如果订单服务和用户服务分属于不同的服务器 A 和 B，而咱们要解决的就是如何在 A 的订单服务中，调用到 B 的用户服务
顺便提一句，很分明的能够看进去，用户服务是被调用的，所有它就是服务的提供者，而订单服务作为消费者
(1) 创立我的项目及各个模块
为了在一台机器上演示，我首先创立了一个 Maven 的空我的项目，而后别离创立几个子模块（程序很简略，不须要 Maven 骨架）
A：创立用户服务（服务提供者）
在空我的项目中创立第一个模块 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 构造方法 toString
}业务层接口：UserService
public interface UserService {
/**
* 依照用户 id 返回所有的收货地址
* @param userId
* @return
*/
public List<UserAddress> getUserAddressList(String userId);
}业务层实现类：UserServiceImpl
public class UserServiceImpl implements UserService {public List<UserAddress> getUserAddressList(String userId) {UserAddress address1 = new UserAddress(1, "广东省 xxx 市 xxx 区 xxx 路 xxx 小区 24 栋 1 单元 801 户", "1", "阿文", "13999999999", "Y");
UserAddress address2 = new UserAddress(2, "北京市 yyy 区 yyy 路 yyy 小区 19 号 3 单元 502 户", "1", "南方少女的梦", "13888888888", "N");
return Arrays.asList(address1,address2);
}
}程序很简略，数据都是拟进去的
以下是这个模块的结构图：
B：创立订单服务（服务消费者）
在我的项目中创立第二个模块 order-service-consumer
业务层接口：OrderService
public interface OrderService {
/**
* 初始化订单
* @param userID
*/
public void initOrder(String userID);
}业务层实现类：OrderServiceImpl
当初还是一个空实现，前面会补充好
public class OrderServiceImpl implements OrderService {public void initOrder(String userID) {// 查问用户的收货地址}
}
如果咱们想要在实现类中，调用用户服务，拿到所有地址，然而调用办法必定会报错的，毕竟咱们这个我的项目中并没有拿到用户地址的办法
有一种形式，就是将服务提供者，也就是用户服务的实体类以及它的 UserService 接口，复制到咱们这个订单的模块中，然而总不能当前有一个中央调用就复制一次吧，这也太麻烦了
所以通用的做法是再创立一个模块，将服务接口，模型等等全放在一起，保护以及调用会更好
C：创立接口模块
在我的项目中创立：mall-interface 模块
将用户模块（服务提供者）和订单模块（服务消费者）中的所有实体类和 service 接口复制到以后模块下
删除原有的实体类包及 service 包，也就是将实体类及 service 放在了以后公共的我的项目中了
既然原来两个模块都删掉了实体等内容，咱们想要用到这个公共的接口模块，只须要引入依赖即可
<dependency>
<groupId>cn.ideal.mall</groupId>
<artifactId>mall-interface</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>(2) 服务提供者配置及测试
A：引入依赖
咱们先对用户服务进行配置，首先要引入 dubbo 和 zookeeper 客户端的依赖
至于版本，能够去 maven 中去查
因为咱们应用 zookeeper 作为注册核心，所以须要操作 zookeeper
dubbo 2.6 以前的版本引入 zkclient 操作 zookeeper
dubbo 2.6 及当前的版本引入 curator 操作 zookeeper
上面两个 zk 客户端依据 dubbo 版本 2 选 1 即可
Dubbo 用了 2.6.9
curator 用了 5.1.0
B：创立配置文件
在 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 指向服务的真正实现对象，通过 ref 援用上面自定义的 bean-->
<dubbo:service interface="cn.ideal.mall.service.UserService" ref="userServiceImpl"></dubbo:service>
<!-- 服务的实现 -->
<bean id="userServiceImpl" class="cn.ideal.mall.service.impl.UserServiceImpl"></bean>
</beans>C：创立一个启动类
public class MailApplication {public static void main(String[] args) throws IOException {ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext("classpath:provider.xml");
applicationContext.start();
System.in.read();}
}如果除了 slf4j 以外没有报出什么正告或者异样，就是胜利了
- 别忘了关上，zookeeper 注册核心的 zkServer.cmd、和 zkCli.cmd 服务
- 还有运行 java -jar dubbo-admin-0.0.1-SNAPSHOT.jar
而后持续拜访 dubbo-admin 的治理页面 http://localhost:7001/，在服务治理的提供者中，曾经能够看到发现了这个提供者
(3) 服务消费者配置及测试
A：引入依赖
<!--dubbo-->
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>dubbo</artifactId>
<version>2.6.9</version>
</dependency>
<!-- 注册核心是 zookeeper，引入 zookeeper 客户端 -->
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
<version>5.1.0</version>
</dependency>B：创立配置文件
<?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="cn.ideal.mall.service.impl"/>
<!-- 指定以后服务 / 利用的名字(同样的服务名字雷同，不要和别的服务同名)-->
<dubbo:application name="order-service-consumer"></dubbo:application>
<!-- 指定注册核心的地位 -->
<dubbo:registry address="zookeeper://127.0.0.1:2181"></dubbo:registry>
<!-- 调用近程裸露的服务，生成近程服务代理 -->
<dubbo:reference interface="cn.ideal.mall.service.UserService" id="userService"></dubbo:reference>
<!--dubbo-monitor-simple 监控核心发现的配置 -->
<dubbo:monitor protocol="registry"></dubbo:monitor>
<!--<dubbo:monitor address="127.0.0.1:7070"></dubbo:monitor>-->
</beans>C：补充订单业务实现类代码
这个实现类，方才还空着，通过引入接口依赖，Dubbo 等依赖以及配置，曾经能够调用了，调用一下这个办法，当然上面的输入语句齐全能够不写，就是为了一个察看不便
@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());
}
}
}C：创立启动类
public class ConsumerApplication {public static void main(String[] args) throws IOException {ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext("consumer.xml");
OrderService orderService = applicationContext.getBean(OrderService.class);
// 调用办法查问出数据
orderService.initOrder("1");
System.out.println("调用实现...");
System.in.read();}
}运行后，持续去 查看 http://localhost:7001/
能够看到，消费者也被发现了，同时控制台也胜利的输入了内容
到这里，其实一个简略的调用过程曾经实现了
(4) 装置繁难的监控核心
dubbo-monitor-simple——繁难监控核心
其实这个货色就是方才 dubbo-admin-master 这个文件夹下除了 dubbo-admin 的其中一个，实质也是一个图形化的界面，不便查看服务提供和消费者的信息
首先还是打包，而后 target 文件夹中会生成这个文件 dubbo-monitor-simple-2.0.0.jar 以及 dubbo-monitor-simple-2.0.0-assembly.tar.gz
将 dubbo-monitor-simple-2.0.0-assembly.tar.gz 解压进去，解压后 config 文件查看 properties 的配置是否是本地的 zookeeper，配置文件的地位如下：
D:\develop\dubbo-monitor-simple-2.0.0\conf\dubbo.properties
- D:\develop 是我的门路
因为后面可能运行的问题，我前面有一些端口占用的问题，所以我把 dubbo.jetty.port=8080 批改成了 8081，这些能够依据须要自行批改
进入 assembly.bin 文件夹，而后双击运行 start.bat 呈现以下内容即启动胜利
在服务者和消费者的 XML 文件中增加以下内容
<!--dubbo-monitor-simple 监控核心发现的配置 -->
<dubbo:monitor protocol="registry"></dubbo:monitor>
<!--<dubbo:monitor address="127.0.0.1:7070"></dubbo:monitor>-->而后启动这两个模块的启动类
注：这时候要保障 zookeeper 服务客户端等后面的内容放弃开着
拜访 localhost:8081，能够看到一个监控核心
点进去 Services 能够看到服务提供者和消费者的信息
到这里，这个监控核心也算装置好了！！！
(五) SpringBoot 整合 Dubbo
下面这个我的项目就是一个一般的 maven 我的项目，通过 XML 配置文件进行配置，在 SSM 我的项目中就能够这样应用，而 SpringBoot 作为当初开发的主力军之一，天然也要再讲一下它的一个配置运行形式
(1) 创立用户服务（服务提供者）
创立一个 SpringBoot 我的项目，名为：boot-user-service-provider
导入依赖
依据其 github 中的提醒，因为咱们抉择的是 2.6.9 所以咱们抉择 0.2.1.RELEASE 这个版本就行了
https://github.com/apache/dub…
https://github.com/apache/dub…
点进去查看 0.2.1.RELEASE，依据其提醒导入依赖
注：0.2.0 的版本中，导入 dubbo-spring-boot-starter 即同步背地帮你导入了 dubbo，curator 等等，然而我拿 0.2.1 的版本测试的时候却发现并没有（可能是我的问题），所以你也不能运行，能够思考像我一样，显式的引入这些内容
记得别忘了引入这个咱们自定义公共的接口模块喔
<dependency>
<groupId>cn.ideal.mall</groupId>
<artifactId>mall-interface</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<!-- Dubbo Spring Boot Starter -->
<dependency>
<groupId>com.alibaba.boot</groupId>
<artifactId>dubbo-spring-boot-starter</artifactId>
<version>0.2.1.RELEASE</version>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>dubbo</artifactId>
<version>2.6.9</version>
</dependency>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-all</artifactId>
</dependency>
<!-- 注册核心是 zookeeper，引入 zookeeper 客户端 -->
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
<version>5.1.0</version>
</dependency>在咱们方才的 user-service-provider 中将 service 的实现类按门路复制过去
留神：这个 @Service 是 dubbo 的，而 @Component 是因为，如果仍应用 Spring 的 @Service 会使得 dubbo 的那个以全称显示，不是很难看，不过你非要的话，也能够哈
package cn.ideal.mall.service.impl;
import cn.ideal.mall.pojo.UserAddress;
import cn.ideal.mall.service.UserService;
import com.alibaba.dubbo.config.annotation.Service;
import org.springframework.stereotype.Component;
import java.util.Arrays;
import java.util.List;
/**
* @ClassName: UserServiceImpl
* @Author: BWH_Steven
* @Date: 2020/12/2 20:58
* @Version: 1.0
*/
@Service
@Component
public class UserServiceImpl implements UserService {public List<UserAddress> getUserAddressList(String userId) {UserAddress address1 = new UserAddress(1, "广东省 xxx 市 xxx 区 xxx 路 xxx 小区 24 栋 1 单元 801 户", "1", "阿文", "13999999999", "Y");
UserAddress address2 = new UserAddress(2, "北京市 yyy 区 yyy 路 yyy 小区 19 号 3 单元 502 户", "1", "南方少女的梦", "13888888888", "N");
return Arrays.asList(address1,address2);
}
}配置 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
spring.main.allow-bean-definition-overriding=true
server.port=8082增加启动类注解
@EnableDubbo // 开启基于注解的 dubbo 性能
@SpringBootApplication
public class BootUserServiceProviderApplication {public static void main(String[] args) {SpringApplication.run(BootUserServiceProviderApplication.class, args);
}
}(2) 创立订单服务（服务消费者）
创立 springboot 我的项目boot-order-service-consumer，此我的项目应该是一个 web 我的项目，留神引入 web 的 starter
同样引入一样的依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>cn.ideal.mall</groupId>
<artifactId>mall-interface</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<!-- Dubbo Spring Boot Starter -->
<dependency>
<groupId>com.alibaba.boot</groupId>
<artifactId>dubbo-spring-boot-starter</artifactId>
<version>0.2.1.RELEASE</version>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>dubbo</artifactId>
<version>2.6.9</version>
</dependency>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-all</artifactId>
</dependency>
<!-- 注册核心是 zookeeper，引入 zookeeper 客户端 -->
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
<version>5.1.0</version>
</dependency>把之前 order-service-consumer 我的项目中的 service 实现类按门路复制过去
有两点留神：
- @Autowired ==> @Reference
- 因为是一个 web 我的项目，要在浏览器查看后果，所以将后果从 void 改成 List 返回回去，因而须要批改公共的接口模块中的此办法接口，将返回类型改为 List
package cn.ideal.mall.service.impl;
import cn.ideal.mall.pojo.UserAddress;
import cn.ideal.mall.service.OrderService;
import cn.ideal.mall.service.UserService;
import com.alibaba.dubbo.config.annotation.Reference;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import java.util.List;
/**
* @ClassName: OrderServiceImpl
* @Author: BWH_Steven
* @Date: 2020/12/2 22:38
* @Version: 1.0
*/
@Service
public class OrderServiceImpl implements OrderService {
@Reference
public 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;
}
}编写 controller
@Controller
public class OrderController {
@Autowired
OrderService orderService;
@RequestMapping("/initOrder")
@ResponseBody
public List<UserAddress> initOrder(@RequestParam("uid")String userId) {return orderService.initOrder(userId);
}
}配置 application.properties
dubbo.application.name=boot-order-service-consumer
dubbo.registry.address=zookeeper://127.0.0.1:2181
#连贯监控核心 注册核心协定
dubbo.monitor.protocol=registry
spring.main.allow-bean-definition-overriding=true
server.port=8083启动类增加注解
@EnableDubbo // 开启基于注解的 dubbo 性能
@SpringBootApplication
public class BootOrderServiceConsumerApplication {public static void main(String[] args) {SpringApplication.run(BootOrderServiceConsumerApplication.class, args);
}
}(3) 测试
首先保障关上了，zookeeper 注册核心的 zkServer.cmd、和 zkCli.cmd 服务
还有运行 java -jar dubbo-admin-0.0.1-SNAPSHOT.jar，想开的话还能够关上监控核心 dubbo-monitor-simple-2.0.0
而后就能够运行服务提供者 boot-user-service-provider，而后运行 服务消费者 boot-order-service-consumer，运行胜利后能够看一下成果
这是应用 http://localhost:7001/ 拜访的后果
或者 http://localhost:8001 (我的监控核心端口设置的是 8081)
以及依据本人设置的我的项目端口号去申请
能够看到后果都是没问题的，SpringBoot 整合 Dubbo 就是这样一个形式
(4) 其余几种形式
一 将服务提供者注册到注册核心(如何裸露服务)
- ① 导入 Dubbo 的依赖 和 zookeeper 客户端
二 让服务消费者去注册核心订阅服务提供者的服务地址
Springboot 与 Dubbo 整合的三种形式
- ① 导入 dubbo-starter。在 application.properties 配置属性，应用 @Service【裸露服务】，应用 @Reference【援用服务】
-
② 保留 Dubbo 相干的 xml 配置文件
- 导入 dubbo-starter，应用 @ImportResource 导入 Dubbo 的 xml 配置文件
- 例如：在启动类增加 @ImportResource(locations = “classpath:provider.xml”)
-
③ 应用 注解 API 的形式
- 将每一个组件手动配置到容器中，让 dubbo 来扫描其余的组件
例如创立一个 config，其本质就是为了放弃掉 xml 和配置文件，这种形式在学习 Spring 配置的时候也有用过哈
@Configuration
public class MyDubboConfig {
@Bean
public ApplicationConfig applicationConfig() {ApplicationConfig applicationConfig = new ApplicationConfig();
applicationConfig.setName("boot-user-service-provider");
return applicationConfig;
}
//<dubbo:registry protocol="zookeeper" address="127.0.0.1:2181"></dubbo:registry>
@Bean
public RegistryConfig registryConfig() {RegistryConfig registryConfig = new RegistryConfig();
registryConfig.setProtocol("zookeeper");
registryConfig.setAddress("127.0.0.1:2181");
return registryConfig;
}
//<dubbo:protocol name="dubbo" port="20882"></dubbo:protocol>
@Bean
public ProtocolConfig protocolConfig() {ProtocolConfig protocolConfig = new ProtocolConfig();
protocolConfig.setName("dubbo");
protocolConfig.setPort(20882);
return protocolConfig;
}
/**
*<dubbo:service interface="com.atguigu.gmall.service.UserService"
ref="userServiceImpl01" timeout="1000" version="1.0.0">
<dubbo:method name="getUserAddressList" timeout="1000"></dubbo:method>
</dubbo:service>
*/
@Bean
public ServiceConfig<UserService> userServiceConfig(UserService userService){ServiceConfig<UserService> serviceConfig = new ServiceConfig<>();
serviceConfig.setInterface(UserService.class);
serviceConfig.setRef(userService);
serviceConfig.setVersion("1.0.0");
// 配置每一个 method 的信息
MethodConfig methodConfig = new MethodConfig();
methodConfig.setName("getUserAddressList");
methodConfig.setTimeout(1000);
// 将 method 的设置关联到 service 配置中
List<MethodConfig> methods = new ArrayList<>();
methods.add(methodConfig);
serviceConfig.setMethods(methods);
//ProviderConfig
//MonitorConfig
return serviceConfig;
}
}二 Dubbo 配置
(一) 重写与配置优先级
http://dubbo.apache.org/zh/do…
优先级从高到低：
- JVM -D 参数：当你部署或者启动利用时，它能够轻易地重写配置，比方，扭转 dubbo 协定端口；
- XML：XML 中的以后配置会重写 dubbo.properties 中的；
- Properties：默认配置，仅仅作用于以上两者没有配置时。
- 如果在 classpath 下有超过一个 dubbo.properties 文件，比方，两个 jar 包都各自蕴含了 dubbo.properties，dubbo 将随机抉择一个加载，并且打印谬误日志。
- 如果
id没有在protocol中配置，将应用name作为默认属性。
(二) 启动时查看
Dubbo 缺省会在启动时查看依赖的服务是否可用，不可用时候就会抛出异样，同时阻止 Spring 初始化实现，益处就是上线的时候能够及早的发现问题，注：默认 check=“true”
- 能够通过 check=“false”敞开查看，比方，测试时，有些服务不关怀，或者呈现了循环依赖，必须有一方先启动。
- 另外，如果你的 Spring 容器是懒加载的，或者通过 API 编程提早援用服务，请敞开 check，否则服务长期不可用时，会抛出异样，拿到 null 援用，如果 check=“false”，总是会返回援用，当服务复原时，能主动连上
比方在 order-service-consumer 消费者中，在 consumer.xml 中增加配置
<!-- 配置以后消费者的对立规定, 以后所有的服务都不启动时查看 -->
<dubbo:consumer check="false"></dubbo:consumer>也能够在每一个下面加 check
(三) 全局超时配置
因为网络或服务端不牢靠，会导致调用呈现一种不确定的中间状态（超时），为了防止超时导致客户端资源（线程）挂起耗尽，必须设置超时工夫
(1) Dubbo 生产端
<!-- 全局超时配置 -->
<dubbo:consumer timeout="5000" />
<!-- 调用近程裸露的服务，生成近程服务代理 -->
<dubbo:reference interface="cn.ideal.mall.service.UserService" id="userService" timeout="2000">
<dubbo:method name="getUserAddressList" timeout="3000"/>
</dubbo:reference>(2) Dubbo 服务端
<!-- 全局超时配置 -->
<dubbo:consumer timeout="5000" />
<!-- 调用近程裸露的服务，生成近程服务代理 -->
<dubbo:service interface="cn.ideal.mall.service.UserService" ref="userServiceImpl" timeout="2000">
<dubbo:method name="getUserAddressList" timeout="3000"/>
</dubbo:service>设置超时工夫其实算蛮简略的，然而最次要留神的问题就是优先级问题，在下面不论是消费者还是服务者，我都配置了三种档次的超时配置，这几者的优先级别简略总结就是：
- ① 更细，更精准的优先：1. 办法级别 <== 2. 接口级别 <== 3. 全局级别
- ② 消费者设置优先：级别统一的状况下，消费者优先于提供者
补充：
- dubbo:consumer 超时默认值为 1000
http://dubbo.apache.org/zh/do…
| 属性 | 对应 URL 参数 | 类型 | 是否必填 | 缺省值 | 作用 | 形容 | 兼容性 |
|---|---|---|---|---|---|---|---|
| timeout | default.timeout | int | 可选 | 1000 | 性能调优 | 近程服务调用超时工夫(毫秒) |
(3) 配置准则
dubbo 举荐在 Provider 上尽量多配置 Consumer 端属性
- 作服务的提供者，比服务应用方更分明服务性能参数，如调用的超时工夫，正当的重试次数，等等
- 在 Provider 配置后，Consumer 不配置则会应用 Provider 的配置值，即 Provider 配置能够作为 Consumer 的缺省值。否则，Consumer 会应用 Consumer 端的全局设置，这对于 Provider 不可控的，并且往往是不合理的
(四) 多版本问题
https://dubbo.apache.org/zh/d…
当一个接口实现，呈现不兼容降级时，能够用版本号过渡，版本号不同的服务相互间不援用。
能够依照以下的步骤进行版本迁徙：
- 在低压力时间段，先降级一半提供者为新版本
- 再将所有消费者降级为新版本
- 而后将剩下的一半提供者降级为新版本
老版本服务提供者配置：
<dubbo:service interface="cn.ideal.mall.service.UserService" ref="userServiceImpl" version="1.0.0"/>
<!-- 服务的实现 -->
<bean id="userServiceImpl" class="cn.ideal.mall.service.impl.UserServiceImpl"/>新版本服务提供者配置：
<dubbo:service interface="cn.ideal.mall.service.UserService" ref="userServiceImpl" version="2.0.0"/>
<!-- 服务的实现 -->
<bean id="userServiceImpl" class="cn.ideal.mall.service.impl.UserServiceImpl"/>老版本服务消费者配置：
<dubbo:reference id="userService" interface="cn.ideal.mall.service.UserService version="1.0.0" />新版本服务消费者配置：
<dubbo:reference id="userService" interface="cn.ideal.mall.service.UserService version="2.0.0" />如果不须要辨别版本，能够依照以下的形式配置（2.2.0 以上版本反对）
<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />三 Dubbo 高可用
这一块的解说次要是针对，在一些突发的谬误，或者大并发下等如何保障 Dubbo 仍为高可用状态的一些概念，以及措施
注：高可用，即通过设计，缩小零碎不能提供服务的工夫
(一) zookeeper 宕机 和 Dubbo 直连
(1) zookeeper 宕机
zookeeper 作为注册核心，如果部署运行着它的服务器出问题了，呈现了 zookeeper 宕机，那么这个时候消费者岂不是找不到被裸露的服务了
然而咱们被动关掉 zookeeper 的服务，在 dubbo-admin 监控中能够看到服务呈现了谬误，然而咱们去申请接口，能够发现依然能申请失去后果，即，还能够生产 dubbo 裸露的服务
这一点与 Dubbo 设计时实现的健壮性无关
- 监控核心宕掉不影响应用，只是失落局部采样数据
- 数据库宕掉后，注册核心仍能通过缓存提供服务列表查问，但不能注册新服务
- 注册核心对等集群，任意一台宕掉后，将主动切换到另一台
- 注册核心全副宕掉后，服务提供者和服务消费者仍能通过本地缓存通信
- 服务提供者无状态，任意一台宕掉后，不影响应用
- 服务提供者全副宕掉后，服务消费者利用将无奈应用，并有限次重连期待服务提供者复原
高可用：通过设计，缩小零碎不能提供服务的工夫
https://dubbo.apache.org/zh/d…
Dubbo 的服务注册核心
目前服务注册核心应用了数据库来保留服务提供者和消费者的信息。注册核心集群不同注册核心也通过数据库来进行同步数据，以感知其它注册核心上提供者的变动。注册核心会在内存中保留一份提供者和消费者数据，数据库不可用时，注册核心独立对外提供服务以保障失常运行，只是拿不到其它注册核心的数据。当数据库复原时，重试逻辑会将内存中批改的数据写回数据库，并拿到数据库中新数据。
服务的消费者
服务消费者从注册核心拿到提供者列表后，会保留提供者列表到内存和磁盘文件中。这样注册核心宕机后消费者能够失常运行，甚至能够在注册核心宕机过程中重启消费者。消费者启动时，发现注册核心不可用，会读取保留在磁盘文件中提供者列表。重试逻辑保障注册核心复原后，更新信息。
(2) Dubbo 直连
如果注册核心当初有点问题，或者无意的不想拜访注册核心上的服务，而是想要间接在本地上调试 dubbo 接口，也能够应用 Dubbo 直连
- 第一种：通过 @Reference 的 url 属性（Springboot）
@Reference(url = "127.0.0.1:20081")
public UserService userService;- 第二种：在 consumer.xml 中指定 url（SSM）
<dubbo:reference interface="cn.ideal.mall.service.UserService" id="userService" url="127.0.0.1:20081">-
第三种：增加映射配置文件
- 如果不想要批改工程内容，能够思考应用这个形式
在本地电脑用户下新建一个叫 dubbo-resolve.properties 的文件门路是 ${user.home}/dubbo-resolve.properties
而后就不须要批改本地工程的其余配置信息，在文件里配置好须要直连的服务信息即可
# 直连本地的服务
cn.ideal.mall.service.UserService=dubbo://localhost:20890(二) 集群下 Dubbo 的负载平衡策略
这一块，咱们只对几种负载平衡策略做一些阐明和解释，具体的算法实现，不是几句话能说的分明地，须要再深刻的去学习以及钻研，以下是官网对于负载平衡具体的阐明
https://dubbo.apache.org/zh/d…
(1) 什么是负载平衡
LoadBalance 中文意思为负载平衡，它的职责是将网络申请，或者其余模式的负载“均摊”到不同的机器上。防止集群中局部服务器压力过大，而另一些服务器比拟闲暇的状况。
通过负载平衡，能够让每台服务器获取到适宜本人解决能力的负载。在为高负载服务器分流的同时，还能够防止资源节约，两全其美。
负载平衡可分为软件负载平衡和硬件负载平衡。在咱们日常开发中，个别很难接触到硬件负载平衡。但软件负载平衡还是能够接触到的，比方 Nginx。
在 Dubbo 中，也有负载平衡的概念和相应的实现。Dubbo 须要对服务消费者的调用申请进行调配，防止多数服务提供者负载过大。服务提供者负载过大，会导致局部申请超时。因而将负载平衡到每个服务提供者上，是十分必要的。
Dubbo 提供了 4 种负载平衡实现，别离是
- 基于权重随机算法的 Random LoadBalance
- 以及基于加权轮询算法的 RoundRobin LoadBalance
- 基于起码沉闷调用数算法的 LeastActive LoadBalance
- 基于 hash 一致性的 ConsistentHash LoadBalance
(2) 四种负载平衡策略
A：Random LoadBalance
基于权重随机算法的 RandomLoadBalance
随机算法，按权重设置随机概率
在一个截面上碰撞的概率高，但调用量越大散布越平均，而且按概率使用权重后也比拟平均，有利于动静调整提供者权重
依据权重的这个比重来决定到底用哪个
注：weight 代表权重，即在所有份数中所占的比例
B：RoundRobin LoadBalance
RoundRobin LoadBalance 基于权重的轮询负载平衡机制
如果只思考轮轮询的意思就是，比方拜访 1 –> 2 –> 3，再一轮又是 1 –> 2 –> 3，然而如果还要基于权重，是这样的，比方第一次是 1 –> 2 –> 3 的程序，而后第二轮 1 –> 2，当应该到 3 时候，依照这个权重比例，总共看成 7 份机会，1 和 2 调用了两次了，各自占据了 2 份，然而 3 服务应该只能占据 1 份，所以只能跳过 3 了，再第三轮，1 曾经两份了，所以也不应该用了，所以思考取去 2，所以这几轮的程序就是 1 –> 2 –> 3 –>1 –> 2 –> 2 –> 2
毛病：存在慢的提供者累积申请的问题，比方：第二台机器很慢，但没挂，当申请调到第二台时就卡在那，长此以往，所有申请都卡在调到第二台上
C：LeastActiveLoad Balance
LeastActive LoadBalance 起码沉闷数负载平衡机制
沉闷数指调用前后计数差，计算沉闷数使慢的提供者收到更少申请，因为越慢的提供者的调用前后计数差会越大
注：如果沉闷数雷同，就随机
D：ConsistentHash LoadBalance
ConsistentHash LoadBalance 一致性 hash 负载平衡机制
这个算法会对，办法调用的第一个参数进行 Hash，例如就是对下面的 param 参数前面的 1、2、3 进行哈希，一致性 Hash，雷同参数的申请总是发到同一提供者
益处就是，当某一台提供者挂时，本来发往该提供者的申请，基于虚构节点，平摊到其它提供者，不会引起激烈变动
(三) 整合 hystrix，服务熔断与降级解决
(1) 服务降级
当服务器压力剧增的状况下，依据理论业务状况及流量，对一些服务和页面有策略的不解决或换种简略的形式解决，从而开释服务器资源以保障外围交易失常运作或高效运作
能够通过服务降级性能长期屏蔽某个出错的非关键服务，并定义降级后的返回策略
向注册核心写入动静配置笼罩规定：
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"));其中：
mock=force:return+null示意生产方对该服务的办法调用都间接返回 null 值，不发动近程调用。用来屏蔽不重要服务不可用时对调用方的影响- 还能够改为
mock=fail:return+null示意生产方对该服务的办法调用在失败后，再返回 null 值，不抛异样。用来容忍不重要服务不稳固时对调用方的影响
(2) 集群容错
在集群调用失败时，Dubbo 提供了多种容错计划，缺省为 failover 重试
A：集群容错模式
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
播送调用所有提供者，一一调用，任意一台报错则报错。通常用于告诉所有提供者更新缓存或日志等本地资源信息。
B：集群模式配置（2.1.0 开始反对）
依照以下示例在服务提供方和生产方配置集群模式，缺省为 failover 重试
<dubbo:service cluster="模式名" />或
<dubbo:reference cluster="模式名" />(四) 整合 Hystrix
在微服务架构中存在多个可间接调用的服务，这些服务若在调用时呈现故障会导致连锁效应，也就是可能会让整个零碎变得不可用，这种状况咱们称之为服务雪崩效应，在这种时候，就须要咱们的 熔断机制 来解救整个零碎
在微服务架构下，很多服务都相互依赖，如果不能对依赖的服务进行隔离，那么服务自身也有可能产生故障，Hystrix 通过 Hystrix Command 对调用进行隔离，这样能够阻止故障的连锁反应，可能让接口调用疾速失败并迅速恢复正常，或者回退并优雅降级
对于 Hystrix，会在 SpringCloud 的学习文章整顿中进行介绍，这里只做一个简略的应用
首先引入依赖
留神，留神！如果拟引入的 hystrix 版本绝对较新，或者会报错
Error creating bean with name ‘configurationPropertiesBeans…….
一种状况就是你的 springboot 版本太新了，须要升高一下，spring 官网能够看到 当初的 cloud 对应能反对到哪个版本的 boot
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
<version>2.2.5.RELEASE</version>
</dependency>启动类增加 @EnableHystrix 注解
@EnableDubbo // 开启基于注解的 dubbo 性能
@EnableHystrix // 开启服务容错性能
@SpringBootApplication
public class BootUserServiceProviderApplication {public static void main(String[] args) {SpringApplication.run(BootUserServiceProviderApplication.class, args);
}
}在提供者中增加注解
能够间接应用 @HystrixCommand，前面都是一些属性设置，上面的随机数判断是为了模仿异样
@Service
@Component
public class UserServiceImpl implements UserService {
@HystrixCommand(commandProperties = {@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "2000") })
// @HystrixCommand
public List<UserAddress> getUserAddressList(String userId) {UserAddress address1 = new UserAddress(1, "广东省 xxx 市 xxx 区 xxx 路 xxx 小区 24 栋 1 单元 801 户", "1", "阿文", "13999999999", "Y");
UserAddress address2 = new UserAddress(2, "北京市 yyy 区 yyy 路 yyy 小区 19 号 3 单元 502 户", "1", "南方少女的梦", "13888888888", "N");
if (Math.random() > 0.5){throw new RuntimeException();
}
return Arrays.asList(address1,address2);
}
}在消费者中增加注解
method 上配置 @HystrixCommand。当调用出错时，会走 fallbackMethod = “testError”
@Service
public class OrderServiceImpl implements OrderService {
@Reference
public UserService userService;
@HystrixCommand(fallbackMethod = "testError")
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;
}
public List<UserAddress> testError(){
return Arrays.asList(new UserAddress(10,"谬误测试地址",
"1","测试 BWH","15555555555","N"));
}
}
