spring与dubbo整合的一个问题大佬求解答_springbootdubbo

一、spring与dubbo整合的一个问题大佬求解答_springbootdubbo

很难受，不知不觉期末要到了，中间件技术的大作业也马上要到ddl了，于是打算学习一下仿滚Dubbo，做个大作业。

一、Dubbo是什么

一款分布式服务框架

高性能和透明化的RPC远程服务调用方案

SOA服务治理方案

消费者的Dubbo配置

创建一个maven项目

该项目必须包兆升含相应的Service接口以及model对象，并族大老且代码与服务的

二、dubbo的docker解决方案思路

我衡档们之前对系统进行了拆分，将单一的应用，被拆分了很多的服务。RPC框架使用的是dubbo，但是这样就带来了其他的一些问题。比如，应用的不断增加，导致消耗的虚拟机也越来越多，这样导致的运维的凳拦搭成本也非常的高。

所以我们就想着使用 docker+dubbo 的方式来解决。

但是众所周知，dubbo与docker想要结合可不是那么容易的一件事情，所有怎么弄一个，整理了一个完整的流程。

所以以上两点都是基于端口，集群的端口管理不再赘述

[站枣拿外图片上传中...(image-5c137a-)]

现在alibaba研发团队重新开始维护dubbo，之后dubbo对docker的支持也会更好。在没有成熟之前，这些方案还没有使用的线上环境。不过我相信容器化，是一种趋势。作为一个高龄程序猿，还是需要不断的接触新的事物，这是一个终生学习的时代。

三、Dubbo之限流分析

在前面的一篇中分析了Dubbo是如何降级的，除了降级，有时限流也是一种很有效的解决高并发的性能问题，那在本篇中开始分析Dubbo是如何限流的。我们知道限流主要是通过控制连接数来实现的，防止某一片段内请求处理过大，导致重要服务的失效。

服务端连接控制

限制当前提供者在使用dubbo协议最多接受10个消费者链接

或者

并发控制

限制 com.foo.BarService 的每个方法，服务端并发执行（或占用线程池线程数）不能超过10个：

限制 com.foo.BarService 的 sayHello 方法段基裤，服务器并发执行（或占用线程池线程数）不能超过10个。

actives限流

该限流方式与前两种不同，其可以设置在提供端，也可以设置在消费者端。可以设置为接口级别，也可以设置为方法级别。

根据消费者与握简提供者建立的连接类型，其意义也不同。

长连接 : 表示当前的长连接最多可以处理的请求个数。与长连接的数量没有问题。

短连接：表示当前服务可以同时处理的短连接数量。

类级别

方法级别

connections限流

可以设置在提供端，也可以设置在消费者端。限定连接的个数。对于短连接，和actives相同。但对于长连接，表示长连接的个数。

一般情况下，会使connections与actives联用，让connections限制长连接的个数，让actives限制长连接中可以处理的请求个数。

限制客户端服务使用连接不能超过10个

或

如果 <dubbo:service> 和 <dubbo:reference> 都配置了connections， <dubbo:reference> 优先。

延迟连接

延迟连接仅可以设置在消费者端，并且不能设置为方法级别。仅作用于Dubbo服务暴露协议。将长连接的建立推迟到消费者真正调用提供者时。可以减少长连接的数量。

我们已经讲解了如何设置控制链接数的，那么它们底层是如何实现的呢？

实际上上面的逻辑都是一个个Filter，所有的Filter会连接成一个过滤器链，每次请求都会经过整个链路中的每一个Filter。那它是在什么时候构造成一个过滤器链的呢。

在服务暴露的时候会调用 buildInvokerChain , 将真正执行的 invoker 放到过滤链的尾部，再执行 protocol.expert(buildInvokerChain(invoker, ...)) 方法来进行服务暴露。

在服务引用的时候会调用 protocol.refer() 方法先生成 Invoker ，再调用 buildInvokerChain(protocol.refer(type, url), ...) 来生成消费类型的调用链。

ExecuteLimitFilter

它用于限制每个服务中每个方法的最大并发数，有接口级别和方法级别的配置方式。

其基本原理：在框架中使用一个ConcurrentMap缓存了并发数的计数器，为每个请求URL生成一个IdentityString，并以此为key；再将每个IdentityString生成一个RpcStatus对象，将此作为value。RpcStatus对象锋散用于记录对应的并发数。在调用开始之前，会通过URL获得RpcStatus对象，把对象中的并发数计数器原子+1，在finally中再将原子减1。只要在计数器+1的时候，发现当前计数器比设置的并发数大时，就会抛出异常。

TpsLimitFilter

TpsLimitFilter的限流是基于令牌的，即一段时间内只分配N个令牌，每次请求都会消耗一个令牌，耗完为止，后面再来的请求都会被拒绝。

具体的逻辑是在 DefaultTPSLimiter#isAllowable ，会用这个方法判断是否触发限流。

在DefaultTPSLimiter内部用一个ConcurrentHashMap缓存每个接口的令牌数，key是interface+group+version，value是一个StatItem对象，它包装了令牌刷新时间间隔、每次发放的令牌数等。首先判断当前时间减去上次发放令牌的时间是否超过了时间间隔，超过了就重新发放令牌，之前剩余的令牌会被直接覆盖掉。然后，通过CAS的方式减去1令牌，减掉后小于0就会触发限流。

ActiveLimitFilter

和服务提供者的 ExecuteLimitFilter 相似，它是消费者端的过滤器，限制的是客户端的并发量。

但是它与 ExecuteLimitFilter 有所不同，它不会直接抛出异常。而是当到达阈值的时候，会先加锁抢占当前接口的RpcStatus对象，然后通过wait方法进行等待，等待是有时间的，因为请求是有 timeout 属性的。然后如果某个Invoker在调用结束后，并发把计数器减-1并触发一个notify，此时会有一个在wait状态的线程被唤醒并继续执行，判断现在是否超时，如果超时则抛出异常。如果当前并发数仍然超出阈值，则继续执行wait方法；如果没有超出阈值在，则跳出循环，CAS+1，并调用invoke方法，调用结束后CAS-1，最后通过notify唤醒另外一个线程。

参考文章：

Dubbo之限流TpsLimitFilter源码分析

Dubbo服务限流

Dubbo源码分析----过滤器之ActiveLimitFilter