采用注解方式注入消费者接口实力空指针
注解的方式在现在的项目中由于他的简洁性越来越被大众所喜欢,在我们集成dubbox的时候,发现dubbox支持了注解方式,但是在我们在用注解式集成的时候,发现消费者的对象在没有注入进去,一直都是报空指针异常.
创新互联服务项目包括工农网站建设、工农网站制作、工农网页制作以及工农网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，工农网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到工农省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！
代码如下:
/**
*
* bug反馈业务接口
*
*
* @author wangguangdong
* @version 1.0
* @Date 2016年10月12日16:18:30
*/@AuthAnnotation@Controllerpublic class BugReportResource { private static final Logger LOG = Logger.getLogger(BugReportResource.class); @Reference(version = "1.0.0",interfaceClass = BugReportService.class)
BugReportService bugReportService;
}
经过博主辛苦的查找原因,后来终于找到问题所在:
在spirng进行实例扫描的时候根本无法识别dubbo中的注解@Reference ,同时,在dubbo扫描的时候也无法识别Spring @Controller ,所以两个框架的扫描顺序要排列好,如果先扫了controller,这时候把控制器都实例化好了,再扫dubbo的服务,就会出现空指针,因为在实例化的时候是没有对应的消费者的实例的,所以就会造成无法注入,这也就是为什么在我们调用消费者服务的时候会造成空指针.
下面是博主编排成功的代码.
然后在查阅资料之后,博主又发现了另一种解决办法:
在一个spring对象中注入dubbo消费者实例,然后在controller中注入这个服务实例即可,这种方法不受dubbo和spirng扫描顺序的影响.其实在项目中我们可能也会有这样的设计(有些的架构改进会进行这样的设计,比如我吧所有的服务细粒度化拆分,并作为提供者注册给dubbo的server,然后我在消费者端多架构一个组合服务层(业务编排service层),进行dubbo子服务的组合,再讲组合后的服务注入到controller中供业务侧使用)
@Component
public class DubboSupport
{ @Reference(version = "1.0.0",interfaceClass = BugReportService.class)
BugReportService bugReportService;
public BugReportService getBugReportService(){ return bugReportService;
}
}Dubbo超时和重连
dubbo启动时默认有重试机制和超时机制,某些业务场景下,如果不注意配置超时和重试,可能会引起一些异常。
超时机制的规则是如果在一定的时间内,provider没有返回，则认为本次调用失败
重试机制在出现调用失败时，会再次调用。如果在配置的调用次数内都失败，则认为此次请求异常，抛出异常。(dubbo默认重试2次)
如果出现超时，通常是业务处理太慢或者发送io阻塞,可在服务提供方执行：jstack PID > jstack.log 分析线程都卡在哪个方法调用上，这里就是慢的原因。如果这个服务接口不能调优性能，请将timeout设大。
超时设置
DUBBO消费端设置超时时间需要根据业务实际情况来设定，如果设置的时间太短，一些复杂业务需要很长时间完成，导致在设定的超时时间内无法完成正常的业务处理。这样消费端达到超时时间，那么dubbo会进行重试机制，不合理的重试在一些特殊的业务场景下可能会引发很多问题，需要合理设置接口超时时间。
比如发送邮件，可能就会发出多份重复邮件，执行注册请求时，就会插入多条重复的注册数据。
（1）合理配置超时和重连的思路
对于核心的服务中心，去除dubbo超时重试机制，并重新评估设置超时时间。
业务处理代码必须放在服务端，客户端只做参数验证和服务调用，不涉及业务流程处理
（2）Dubbo超时和重连配置示例
（3）Dubbo消费者端统一的超时和重连配置
重连机制
dubbo在调用服务不成功时，默认会重试2次。Dubbo的路由机制，会把超时的请求路由到其他机器上，而不是本机尝试，所以 dubbo的重试机器也能一定程度的保证服务的质量。但是如果不合理的配置重试次数，当失败时会进行重试多次，这样在某个时间点出现性能问题，调用方再连续重复调用，系统请求变为正常值的retries倍，系统压力会大增，容易引起服务雪崩，需要根据业务情况规划好如何进行异常处理，何时进行重试。
在重试发送的时候也可能会出现这样的问题:
比如有一个bug反馈,但是因为数据库io瓶颈,这时候这个服务阻塞了,然后过了一会查看数据库里有3条除了id外剩下都一样的数据(id是在服务提供者里生成的,这里只做异常例子举例).
这就是重试机制下,业务不合理的设计所造成的坑,这时候我们处理的方式有两种:
合理规划业务(例如id放在服务上游生成,数据库主键唯一的机制)
吧服务增加幂等性设置(例如接口中增加消息id)
附带上使用dubbo你所需要的mavne依赖
org.springframework
spring-expression
4.2.5.RELEASE
com.alibaba
dubbo
2.8.4
org.springframework
spring
com.101tec
zkclient
org.apache.zookeeper
zookeeper
3.4.6
com.101tec
zkclient
0.7
分享文章：使用dubbo时你需要注意的
URL标题：
http://bjjierui.cn/article/ijesej.html
