1.什么是SPI技术？

参考博客：https://blog.csdn.net/qiangcai/article/details/77750541

 

   SPI的全名为Service Provider Interface.大多数开发人员可能不熟悉，因为这个是针对厂商或者插件的。在java.util.ServiceLoader的文档里有比较详细的介绍。简单的总结下java spi机制的思想。我们系统里抽象的各个模块，往往有很多不同的实现方案，比如日志模块的方案，xml解析模块、jdbc模块的方案等。面向的对象的设计里，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。 java spi就是提供这样的一个机制：为某个接口寻找服务实现的机制。有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要，java spi的具体约定为:当服务的提供者，提供了服务接口的一种实现之后，在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。 基于这样一个约定就能很好的找到服务接口的实现类，而不需要再代码里制定。jdk提供服务实现查找的一个工具类：java.util.ServiceLoader

2 .多版本

http://dubbo.apache.org/zh-cn/docs/user/demos/multi-versions.html

 

3.本地存根

http://dubbo.apache.org/zh-cn/docs/user/demos/local-stub.html

https://www.cnblogs.com/hzhuxin/p/8250602.html

 

远程服务后，客户端通常只剩下接口，而实现全在服务器端，但提供方有些时候想在客户端也执行部分逻辑，比如：做 ThreadLocal 缓存，提前验证参数，调用失败后伪造容错数据等等，此时就需要在 API 中带上 Stub，客户端生成 Proxy 实例，会把 Proxy 通过构造函数传给 Stub [1]，然后把 Stub 暴露给用户，Stub 可以决定要不要去调 Proxy。

4.负载均衡策略

http://dubbo.apache.org/zh-cn/docs/user/demos/loadbalance.html

 

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

Random LoadBalance

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

RoundRobin LoadBalance

• 轮询，按公约后的权重设置轮询比率。
• 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

LeastActive LoadBalance

• 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
• 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance

• 一致性 Hash，相同参数的请求总是发到同一提供者。
• 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
• 缺省只对第一个参数 Hash，如果要修改，请配置 <dubbo:parameter key="hash.arguments" value="0,1" />
• 缺省用 160 份虚拟节点，如果要修改，请配置 <dubbo:parameter key="hash.nodes" value="320" />

 

配置：

服务端服务级别

<dubbo:service interface="..." loadbalance="roundrobin" />

客户端服务级别

<dubbo:reference interface="..." loadbalance="roundrobin" />

服务端方法级别

<dubbo:service interface="...">

    <dubbo:method name="..." loadbalance="roundrobin"/></dubbo:service>

客户端方法级别

<dubbo:reference interface="...">

    <dubbo:method name="..." loadbalance="roundrobin"/></dubbo:reference>

5.服务降级

服务降级，当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。

服务降级方式：

 

• 服务接口拒绝服务：无用户特定信息，页面能访问，但是添加删除提示服务器繁忙。页面内容也可在Varnish或CDN内获取。
• 页面拒绝服务：页面提示由于服务繁忙此服务暂停。跳转到varnish或nginx的一个静态页面。
•  延迟持久化：页面访问照常，但是涉及记录变更，会提示稍晚能看到结果，将数据记录到异步队列或log，服务恢复后执行。
•  随机拒绝服务：服务接口随机拒绝服务，让用户重试，目前较少有人采用。因为用户体验不佳。

 

https://blog.csdn.net/wsm0712syb/article/details/61413276

Mock 配置：

 

在消费方指定配置

<!-- 生成远程服务代理，可以和本地bean一样使用demoService --> <dubbo:reference id="fooService" interface="com.test.service.FooService" timeout="10000" check="false" mock="return null"> </dubbo:reference>

 

• mock="return null" 表示消费方对该服务的方法调用都直接返回 null 值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
• 还可以改为 mock=fail:return+null 表示消费方对该服务的方法调用在失败后，再返回 null 值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响。

dubbo服务降级具体实现

通过Dubbo的Filter对Dubbo进行扩展，从而使得每次服务发起调用都可以得到监控，从而可以监控每次服务的调用。

对自动判断服务提供端是否宕机：通过一个记录器对每个方法出现RPC异常进行记录，并且可以配置在某个时间段内连续出现多少个异常可判定为服务提供端出现了宕机，从而进行服务降级。

自动恢复远程服务调用：通过配置检查服务的频率来达到定时检查远程服务是否可用，从而去除服务降级。

6.<dubbo:application name="XXXX" /> 作用

用于计算依赖关系

7.RPC原理

自定义RPC实例  https://www.cnblogs.com/swordfall/p/8683905.html

8.Dubbo  Spring Boot 事务测试

 

 

在controller 调用该测试方法

1. 在类级别使用事务 且 没有@Service没有任何属性

结果：事务没有回滚

2. 需要在@Service 里添加提供服务的接口

 结果：服务提供方报错

 

InterfaceName  改为interfaceClass

结果  ：服务方成功  消费方不能发现该服务

取消版本号

 结果 事务不能回滚

 

 9: dubbo  配置信息 解析

Dubbo.shutdown.hook=ture :

 

1 概要说明

我们在关闭或重启dubbo服务时往往会出现请求超时而导致pv lost。

2 原因分析

• 关闭dubbo服务：部分请求未处理完被直接关闭；
• 启动dubbo服务：服务刚启动完毕就瞬间涌入大量流量，而此时的服务吞吐能力有限，服务处理不过来而导致请求超时，因为服务往往有一个慢热的过程。深层原因分析：服务一般会使用各种连接池，而刚启动的服务各种资源连接数有限，如果此时服务瞬间涌入大量流量，则会花较多的时间去创建新的资源连接）。

3 解决之道

dubbo为我们提供了优雅停机

3.1 使用方式

• 对于通过dubbo Main方式启动dubbo容器的，只需在启动前添加java环境变量-Ddubbo.shutdown.hook=true即可。
• 对于tomcat等web容器方式启动dubbo的，需要在关闭时执行方法ProtocolConfig.destroyAll();

3.2 注意事项：

• kill -9 默认对于dubbo Main方式启动的，优雅停机不生效
• 对于tomcat等web容器方式启动，注意tomcat等容器关闭等待超时时长（tomcat默认为等待5s）应大于等于dubbo优雅停机等待超时时长（dubbo默认为10s）
• 针对刚启动dubbo服务吞吐能力有限场景，dubbo2.6.2版本增强了优雅停机，可以考虑升级dubbo至2.6.2版本以上。

作者：会飞之鱼
链接：https://www.jianshu.com/p/8f721ccb7deb
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

 

 

Dubbo.token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx:

Dubbo提供了对消费者的 token验证，防止消费者：

     1.防止消费者绕过 注册中心访问提供者 
     2.在注册中心控制权限，以决定要不要下发令牌给消费者。 

     3.注册中心可灵活改变授权方式，而不需要修改或升级提供者。

 

经过测试，只有消费商提供了与提供商一致的token，才能访问提供商提供的服务。

 

Dubbo.service.loadbalance=roundrobin

 

负载均衡策略

 RoundRobin LoadBalance

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

 

 

Dubbo.registry-www.file=/xxxxxxxxxxxx/:

 

1. dubbo Can not lock the registry cache file：

    当本地同时启动服务端和客户端的时候就可能产生这个问题。

    解决方案

    Dubbo通过注册中心发现服务，发现的服务Dubbo同时也会保存到本地缓存一份，缓存的好处有很多，比如不需要每次使用的时候都通过注册中心获取，注册中心不可用了，不影响消费端的调用，

    因为本地缓存了一份服务提供者列表。Dubbo本地缓存默认采用的文件，会根据注册中心自动在当前用户目录下生成一个缓存文件，类似/home/newad/.dubbo/dubbo-registry-*.*.*.*.cache，

    星号表示注册中心的IP地址，当同一台机器上同时启动多个进程，就会出现多个进程争夺此文件的写入权限，觖此问题的方法也很简单，日志里面都说了重新配置一下这个缓存文件就。

    主要在启动脚本里面添加配置： -Ddubbo.registry.file=C:\Users\dell.dubbo\dubbo-registry-192.168.1.62-junit.cache 文件名自己配置一个

    -Ddubbo.registry.file=C:\Users\dell.dubbo\dubbo-registry-192.168.1.62-junit.cache

    参见：http://ask.csdn.net/questions/233826

    出现java.io.IOException: Can not lock the registry cache file /home/deployer/.dubbo/dubbo-registry-xxxxx.cache, ignore and retry later的问题解决方法

    这个问题的出现是因为dubbo在用户目录下使用一个文件来缓存注册中心的服务提供者的信息，那么在使用前会加上文件锁，所以再一次使用这个文件是获取锁就会失败，解决的方式是：

    1:确认应用内只有一个<registry>标签，不同文件的情况下，也只能有一个

    2:在<registry>标签内指定一个文件，使用file属性 <registry address="xxx" file="xxx"/>

    参见：http://www.cnblogs.com/it-zhoujian/p/4326087.html

10 Dubbo  线程模型

11 Dubbo Invoker

 这张图是站在服务消费方的视角来看的（dubbo的服务治理都是针对服务消费方的），当业务逻辑中需要调用一个服务时，你真正调用的其实是dubbo创建的一个proxy，该proxy会把调用转化成调用指定的invoker（cluster封装过的）。而在这一系列的委托调用的过程里就完成了服务治理的逻辑，最终完成调用。

12.Dubbo限制大数据(文件)传输的解决方案

 

<!-- dubbo默认payload为8M。为了传输文件，加大上限 -->
   <dubbo:provider timeout="${dubbo.provider.timeout}" retries="0" cache="false"
        payload="30000000"/>

13.Dubbo服务治理