在工作和学习的进程中,具体应用Dubbo的时候遇到了很多的问题,这些问题1方面让自己进1步了解所谓的dubbo,另外一方面通过对它们的总结和分析能够在工作中加倍的提高效力,接下来将会对遇到的和他人总结的1些常见的问题进行汇总.
1.增加提供服务版本号和消费服务版本号.
这个具体来讲不算是1个问题,而是1种问题的解决方案,在我们的实际工作中会面临各种环境资源短缺的问题,也是很实际的问题,刚开始我们还可以提供1个服务进行相干的开发和测试,但是当有多个环境多个版本,多个任务的时候就不满足我们的需求,这时候候我们可以通过给提供方增加版本的方式来辨别.这样能够剩下很多的物理资源,同时为今后更换接口定义发布在线时，可不停机发布，使用版本号.
援用只会找相应版本的服务,例如
<dubbo:serviceinterface=“com.xxx.XxxService”ref=“xxxService” version=“1.0” />
<dubbo:referenceid=“xxxService”interface=“com.xxx.XxxService” version=“1.0”/>
dubbo服务的版本号在项目中非常实用,如果后续系列允许的话,我会专门对dubbo的版本进行1个详细的文章说明.
2.dubbo reference注解问题
@Reference只能在springbean实例对应确当前类中使用，暂时没法在父类使用；如果确切要在父类声明1个援用，可通过配置文件配置dubbo:reference，然后在需要援用的地方跟援用springbean1样就能够了.
3.服务超时问题.
此问题也是在项目中非常常见的1个问题,但是这个问题背后多是各种缘由致使.
目前如果存在超时，情况基本都在以下：
(1) 1种情况是服务要求超时.
客户端耗时大，也就是超时异常时的client elapsedxxx，这个是从创建Future对象开始到使用channel发出要求的这段时间，中间没有复杂操作，只要CPU没问题基本不会出现大耗时，顶多1ms属于正常IOThread繁忙，默许情况下，dubbo协议1个客户端与1个服务提供者会建立1个同享长连接，如果某个客户端处于特别繁忙而且1直往1个服务提供者塞要求，可能造成IOThread阻塞，1般非常特殊的情况才会出现服务端工作线程池中线程全部繁忙，接收消息后塞入队列等待，如果等待时间比料想长会引发超时网络抖动，如果上述情况都排除，还出现在要求发出后，服务接收要求前超过料想时间，只能归类到网络抖动了，需要SA1起查看问题服务本身耗时大，这个需要利用本身做好耗时统计，当出现这类情况的时候需要用数据来讲明问题及计划优化方案，建议采取缓存埋点的方式统计服务中各个履行阶段的耗时情况，终究如果超过料想时间则把缓存统计的耗时情况打日志，减少日志量，且能够得到更明确的信息现在我们利用使用进程中发现两种类型的耗时，1种我们目前只能归类到网络抖动，后续需要找运维1起关注这个问题，另外1种是由于1些历史缘由，数据库查询容易产生抖动，总有1个时间点会突然多出很多超时。
(2) 2大类的情况是调用的版本不对.
在上面我们已说了具体的版本问题,如果你调用的对方版本不对的话,就相当于你的消费者没有提供者.所以会出现超时,此时只需要把版本对应好便可.
(3)提供者的服务被制止.
这是1种人为的控制,通过监控中心我们可以对具体的服务,和它的权重进行控制,当我将1个具体的服务制止以后消费者就调不到相干的服务,此时就会出现超时的问题.解决方案,取消制止便可.注意这里有1定时间的缓存,实际操作的时候应当注意.
4.服务保护
服务保护的原则上是避免产生类似雪崩效应，尽可能将异常控制在服务周围，不要分散开。说到雪崩效应，还得提下dubbo本身的重试机制，默许3次，当失败时会进行重试，这样在某个时间点出现性能问题，然后调用方再连续重复调用，很容易引发雪崩，建议的话还是很据业务情况计划好如何进行异常处理，什么时候进行重试。服务保护的话 斟酌服务的dubbo线程池类型（fix线程池的话斟酌线程池大小）、数据库连接池、dubbo连接数限制是不是都适合.
5.注册中心的分组group和服务的不同实现group
这两个东西完全不同的概念，使用的时候不要弄混了。registry上可以配置group，用于辨别不同分组的注册中心，比如在同1个注册中心下，有1部份注册信息是要给开发环境用的，有1部份注册信息时要给测试环境用的，可以分别用不同的group辨别开，目前对这个理解还不透彻，大致就是用于辨别不同环境。service和reference上也能够配置group，这个用于辨别同1个接口的不同实现，只有在reference上指定与service相同的group才会被发现。
以上为5类我们所遇到的问题,总结下来为了以后的路走的更顺畅.