Dubbo尚硅谷笔记

Dubbo

网课链接 https://www.bilibili.com/video/BV1ns411c7jV?from=search&seid=15118301399131055657&spm_id_from=333.337.0.0

相关笔记链接 https://blog.csdn.net/qq_41157588/article/details/106737191

一.基础知识


网站规模扩大，常规的垂直应用架构无法应付



发展演变



单一应用架构	ORM

垂直应用架构	MVC

分布式服务架构	RPC

流动计算架构	SOA



RPC Remote Procedurer Call 远程过程调用	

是一种进程间通信方式



建立连接

信息序列化	传递	反序列化	调用本地服务	服务处理	返回处理结果	序列化返回	反序列化得到结果



性能

建立连接效率

序列化与反序列化速率



服务中心一般使用zookeeper实现



搭建 ZooKeeper注册中心

下载zookeeper



树型的目录结构

创建临时节点

create -e	/k	v



管理控制台

可以通过可视化界面管理服务

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

进入如下地址：dubbo-admin-master\dubbo-admin\src\main\resources\application.properties"

将zookeeper的监控中心的地址配置为本地端口

配置完毕后，我们在dubo-zookeeper\dubbo-admin-master\dubbo-admin文件夹下cmd打包测试下。

cmd命令 `java -jar dubbo-admin-0.0.1-SNAPSHOT.jar`运行打包好的jar包

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

要访问到监控中心，一定要启动zookeeper注册中心的启动类



SSM	Hello World

user-service-provider

order-service-consume

gmail-interface 用于存放共同的服务接口

将提供者和消费者项目中的所有实体类实体类及service放在当前公共的项目中。

引入公共模块依赖





服务提供者

引入dubbo依赖

注册中心是 zookeeper，引入zookeeper客户端依赖

配置配置文件

<?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>



服务消费者

引入依赖

配置配置文件

<?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>

把当前OrderServiceImpl实现类中加上注解

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

注意：消费者的运行测试需要先启动提供者。

启动服务提供者、消费者。及zookeeper的和dubbo-admin，查看监控信息。

localhost:7001



dubbo-monitor-simple简易监控中心

进入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>-->



Springboot Hello World

**`boot-user-service-provider`**

引入依赖

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

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
​~~~

启动类配置

@EnableDubbo //开启基于注解的dubbo功能 





**`boot-order-service-consumer`** 

引入依赖

创建application.properties 配置

启动类创建

二.dubbo配置

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



配置原则

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

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

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



启动时检查

Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常

<!--配置当前消费者的统一规则,当前所有的服务都不启动时检查--> <dubbo:consumer check="false"></dubbo:consumer>

可使得启动时不检查，在真正调用时再检查





全局超时配置

<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的配置值（见配置文档



精确优先(方法级优先.接口级次之,全局配置再次之)

消费者设置优先(如果级别一样，则消费方优提供方次之)





重试次数

幂等	设置重试次数	结果不变	查询	删除	修改

非幂等	不能设置重试次数	每次运行效果不一样	数据库新增



多版本

类似灰度发布

修改version









dubbo与springboot整合的三种方式

1）将服务提供者注册到注册中心(如何暴露服务)

导入Dubbo的依赖 和 zookeeper 客户端

properties配置属性

@Service暴露服务

@Reference引用服务

2）保留Dubbo 相关的xml配置文件

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

3）使用 注解API的方式

将每一个组件手动配置到容器中,让dubbo来扫描其他的组件

三.高可用


Zookeeper宕机

zookeeper注册中心宕机，还可以消费dubbo暴露的服务

存在本地缓存



监控中心宕掉不影响使用，只是丢失部分采样数据

数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务

注册中心对等集群，任意一台宕掉后，将自动切换到另一台

注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯

服务提供者无状态，任意一台宕掉后，不影响使用

服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

高可用：通过设计，减少系统不能提供服务的时间





dubbo直连

绕过注册中心











集群下dubbo负载均衡配置

1）**Random LoadBalance 基于权重的随机负载均衡机制**

随机，按权重设置随机概率。 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态

调整提供者权重。

2）**RoundRobin LoadBalance 基于权重的轮询负载均衡机制**

轮循，按公约后的权重设置轮循比率。 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在

那，久而久之，所有请求都卡在调到第二台上。

4）**LeastActive LoadBalance最少活跃数负载均衡机制**

最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。找响应时间快的服务器

5）**ConsistentHash LoadBalance一致性hash 负载均衡机制**

一致性 Hash，相同参数的请求总是发到同一提供者。 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供

者，不会引起剧烈变动。





服务降级

当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源

以保证核心交易正常运作或高效运作。





服务容错

集群容错模式

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

Failfast Cluster

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

Failsafe Cluster

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

Failback Cluster

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

Forking Cluster

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

大并行数。

Broadcast Cluster

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



整合hystrix

实现服务容错

四.dubbo原理


RPC原理

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

服务消费方（client）调用以本地调用方式调用服务；

client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；

client stub找到服务地址，并将消息发送到服务端；

server stub收到消息后进行解码；

server stub根据解码结果调用本地的服务；

本地服务执行并将结果返回给server stub；

server stub将返回结果打包成消息并发送至消费方；

client stub接收到消息，并进行解码；

服务消费方得到最终结果。



RPC框架的目标就是将中间这些步骤都封装起来，这些细节对用户来说是透明的，不可见的。





Netty原理

Netty是一个异步事件驱动的网络应用程序框架， 用于快速开发可维护的高性能协议服务器和客户端。它极大地简化并简化了TCP和UDP

套接字服务器等网络编程。

BIO：(Blocking IO)

NIO：(Non-Blocking IO)

Selector 一般称 为选择器 ，多路复用器，Connect（连接就绪）、Accept（接受就绪）、Read（读就绪）、Write（写就绪）

多路复用执行，就绪后再选择执行





dubbo原理

1）框架设计

Service层

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

2）启动解析，加载配置信息

3）服务暴露流程

4）服务引用流程

5）服务调用流程
版权声明：本文为weixin_47731342原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接和本声明。