孤海岛主

group:适用于一个接口有多个实现的场景。有点类似设计模式中的工厂方法，只不过工程方法是根据传入的实例对象确定具体调用哪个方法，而dubbo则根据group来具体调用接口的哪个实现。例如：发送短信接入了多家运营商，但是每个运营商都有发送短信的功能，这样就可以定义一个dubbo接口，然后分别给每个运营商加一个group去实现这个接口，具体使用哪个运营商发短信的时候只需要引用不同group的dubbo服务就行了。version：适用于一个dubbo服务有多个不同版本，但是多个版本需要共存的情况，一般用

问题原因1.由于dubbo服务的负载模式是轮询模式，导致每台机器上分配的任务数量是基本上相同的，但是由于服务部署并不是单机部署的（一台机器上面部署了多个服务），导致有些机器处理的速度较快，有些机器处理的较慢2.由于dubbo的业务线程池设置的默认核心线程数量为200，并且线程队列为0（设置队列为0，目的也是为了防止队列堆积任务过多，导致上游调用超时），因此当机器处理任务缓慢时，任务一直占用线程未释放就会导致任务占用线程越来越多，最终导致线程池打满的问题。解决过程初步解决方案：增大线程数，增加

springcloudAlibaba+dubbo整合sentinel在sentinel-apache-dubbo-adapter包中其实已经做了默认的降级处理。但是默认的降级处理只不过是将捕获到的异常进行包装进行返回。大多数情况下这种默认的处理方式肯定不是我们需要的。于是参考了一下sentinel在web应用下的处理方式，发现应用在dubbo服务上依然可以。下面就讲一下两种降级方式。默认服务降级：在sentinel-apache-dubbo-adapter包中有一个com.alibaba.csp.s

产生问题：sentinel整合dubbo中在sentinel-apache-dubbo-adapter包中会有一个dubbo来源解析器的接口DubboOriginParser，该接口有一个默认实现会把来源设置为空字符串。然后sentinel在进行黑白名单规则校验的时候取的拦截信息就是来源的值，所以会造成授权规则不生效备注：如果dubbo版本为2.7.x以下的话整合dubbo的包为sentinel-dubbo-adapter解决方案：自定义dubbo访问则来源1.自定义dubbo访问者来源i

springcloudAlibaba+dubbo全局异常处理的方案基本上就是两种，一种是使用dubbo filter，虽然是com.alibaba.dubbo.rpc.Filter其实实际上还是用的原生dubbo框架的东西因为看代码可以得出com.alibaba.dubbo.rpc.Filter其实是继承org.apache.dubbo.rpc.Filter类的。另外一种就是通过AOP的方式实现。使用dubbofilter输出结果是org.apache.dubbo.rpc.Result,但是如果想自定