采用注解方式注入消費者接口實力空指針
注解的方式在現(xiàn)在的項目中由于他的簡潔性越來越被大眾所喜歡,在我們集成dubbox的時候,發(fā)現(xiàn)dubbox支持了注解方式,但是在我們在用注解式集成的時候,發(fā)現(xiàn)消費者的對象在沒有注入進去,一直都是報空指針異常.
代碼如下:
/**
* <p>
* bug反饋業(yè)務接口
* </p>
*
* @author wangguangdong
* @version 1.0
* @Date 2016年10月12日16:18:30
*/
@AuthAnnotation
@Controller
public class BugReportResource {
private static final Logger LOG = Logger.getLogger(BugReportResource.class);
@Reference(version = "1.0.0",interfaceClass = BugReportService.class)
BugReportService bugReportService;
}
經(jīng)過樓主辛苦的查找原因,后來終于找到問題所在:
在spirng進行實例掃描的時候根本無法識別dubbo中的注解@Reference ,同時,在dubbo掃描的時候也無法識別Spring @Controller ,所以兩個框架的掃描順序要排列好,如果先掃了controller,這時候把控制器都實例化好了,再掃dubbo的服務,就會出現(xiàn)空指針,因為在實例化的時候是沒有對應的消費者的實例的,所以就會造成無法注入,這也就是為什么在我們調用消費者服務的時候會造成空指針.
下面是樓主編排成功的代碼.
<mvc:annotation-driven />
<!-- 查找xxx路徑下所有@Controller 注釋類,添加與項目相關的controller -->
<dubbo:annotation package="XXX.XXX.XXX.controller" />
<context:component-scan base-package="XXX.XXX.XXX.controller"/>
然后在查閱資料之后,樓主又發(fā)現(xiàn)了另一種解決辦法:
在一個spring對象中注入dubbo消費者實例,然后在controller中注入這個服務實例即可,這種方法不受dubbo和spirng掃描順序的影響.其實在項目中我們可能也會有這樣的設計(有些的架構改進會進行這樣的設計,比如我吧所有的服務細粒度化拆分,并作為提供者注冊給dubbo的server,然后我在消費者端多架構一個組合服務層(業(yè)務編排service層),進行dubbo子服務的組合,再講組合后的服務注入到controller中供業(yè)務側使用)
@Component
public class DubboSupport
{
@Reference(version = "1.0.0",interfaceClass = BugReportService.class)
BugReportService bugReportService;
public BugReportService getBugReportService(){
return bugReportService;
}
}
Dubbo超時和重連
dubbo啟動時默認有重試機制和超時機制,某些業(yè)務場景下,如果不注意配置超時和重試,可能會引起一些異常霹陡。
超時機制的規(guī)則是如果在一定的時間內,provider沒有返回瞭吃，則認為本次調用失敗
重試機制在出現(xiàn)調用失敗時，會再次調用尊蚁。如果在配置的調用次數(shù)內都失敗或粮，則認為此次請求異常遗增，拋出異常结蟋。(dubbo默認重試2次)
如果出現(xiàn)超時招刹，通常是業(yè)務處理太慢或者發(fā)送io阻塞,可在服務提供方執(zhí)行：jstack PID > jstack.log 分析線程都卡在哪個方法調用上妥粟，這里就是慢的原因审丘。如果這個服務接口不能調優(yōu)性能，請將timeout設大勾给。
超時設置
DUBBO消費端設置超時時間需要根據(jù)業(yè)務實際情況來設定滩报，如果設置的時間太短，一些復雜業(yè)務需要很長時間完成锦秒，導致在設定的超時時間內無法完成正常的業(yè)務處理露泊。這樣消費端達到超時時間，那么dubbo會進行重試機制旅择，不合理的重試在一些特殊的業(yè)務場景下可能會引發(fā)很多問題惭笑，需要合理設置接口超時時間。
比如發(fā)送郵件生真，可能就會發(fā)出多份重復郵件沉噩，執(zhí)行注冊請求時，就會插入多條重復的注冊數(shù)據(jù)柱蟀。
（1）合理配置超時和重連的思路
- 對于核心的服務中心川蒙，去除dubbo超時重試機制，并重新評估設置超時時間长已。
- 業(yè)務處理代碼必須放在服務端畜眨，客戶端只做參數(shù)驗證和服務調用，不涉及業(yè)務流程處理
（2）Dubbo超時和重連配置示例
<!-- 服務調用超時設置為6秒,超時不重試-->
<dubbo:service interface="com.provider.service.DemoService" ref="demoService" retries="0" timeout="5000"/>
（3）Dubbo消費者端統(tǒng)一的超時和重連配置
<!--統(tǒng)一的消費者配置-->
<dubbo:consumer timeout="30000" retries="0" version="1.0.0"/>
重連機制
dubbo在調用服務不成功時术瓮，默認會重試2次康聂。Dubbo的路由機制，會把超時的請求路由到其他機器上胞四，而不是本機嘗試恬汁，所以 dubbo的重試機器也能一定程度的保證服務的質量。但是如果不合理的配置重試次數(shù)辜伟，當失敗時會進行重試多次氓侧，這樣在某個時間點出現(xiàn)性能問題，調用方再連續(xù)重復調用导狡，系統(tǒng)請求變?yōu)檎Ｖ档膔etries倍约巷，系統(tǒng)壓力會大增，容易引起服務雪崩旱捧，需要根據(jù)業(yè)務情況規(guī)劃好如何進行異常處理独郎，何時進行重試。
在重試發(fā)送的時候也可能會出現(xiàn)這樣的問題:
比如有一個bug反饋,但是因為數(shù)據(jù)庫io瓶頸,這時候這個服務阻塞了,然后過了一會查看數(shù)據(jù)庫里有3條除了id外剩下都一樣的數(shù)據(jù)(id是在服務提供者里生成的,這里只做異常例子舉例).
這就是重試機制下,業(yè)務不合理的設計所造成的坑,這時候我們處理的方式有兩種:
- 合理規(guī)劃業(yè)務(例如id放在服務上游生成,數(shù)據(jù)庫主鍵唯一的機制)
- 吧服務增加冪等性設置(例如接口中增加消息id)
附帶上使用dubbo你所需要的mavne依賴
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-expression</artifactId>
<version>4.2.5.RELEASE</version>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>dubbo</artifactId>
<version>2.8.4</version>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
</exclusion>
<exclusion>
<groupId>com.101tec</groupId>
<artifactId>zkclient</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<version>3.4.6</version>
</dependency>
<dependency>
<groupId>com.101tec</groupId>
<artifactId>zkclient</artifactId>
<version>0.7</version>
</dependency>
