采用注解方式注入消費(fèi)者接口實(shí)力空指針

注解的方式在現(xiàn)在的項(xiàng)目中由于他的簡潔性越來越被大眾所喜歡,在我們集成dubbox的時(shí)候,發(fā)現(xiàn)dubbox支持了注解方式,但是在我們在用注解式集成的時(shí)候,發(fā)現(xiàn)消費(fèi)者的對象在沒有注入進(jìn)去,一直都是報(bào)空指針異常.

/**
 * <p>
 * bug反饋業(yè)務(wù)接口
 * </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進(jìn)行實(shí)例掃描的時(shí)候根本無法識別dubbo中的注解 Reference,同時(shí),在dubbo掃描的時(shí)候也無法識別Spring Controller,所以兩個(gè)框架的掃描順序要排列好,如果先掃了controller,這時(shí)候把控制器都實(shí)例化好了,再掃dubbo的服務(wù),就會出現(xiàn)空指針,因?yàn)樵趯?shí)例化的時(shí)候是沒有對應(yīng)的消費(fèi)者的實(shí)例的,所以就會造成無法注入,這也就是為什么在我們調(diào)用消費(fèi)者服務(wù)的時(shí)候會造成空指針.

下面是編排成功的代碼.

    <mvc:annotation-driven />
    
    <!-- 查找xxx路徑下所有@Controller 注釋類,添加與項(xiàng)目相關(guān)的controller -->
    
    <dubbo:annotation package="XXX.XXX.XXX.controller" />
    
    <context:component-scan base-package="XXX.XXX.XXX.controller"/>

然后在查閱資料之后,樓主又發(fā)現(xiàn)了另一種解決辦法:

在一個(gè)spring對象中注入dubbo消費(fèi)者實(shí)例,然后在controller中注入這個(gè)服務(wù)實(shí)例即可,這種方法不受dubbo和spirng掃描順序的影響.其實(shí)在項(xiàng)目中我們可能也會有這樣的設(shè)計(jì)(有些的架構(gòu)改進(jìn)會進(jìn)行這樣的設(shè)計(jì),比如我吧所有的服務(wù)細(xì)粒度化拆分,并作為提供者注冊給dubbo的server,然后我在消費(fèi)者端多架構(gòu)一個(gè)組合服務(wù)層(業(yè)務(wù)編排service層),進(jìn)行dubbo子服務(wù)的組合,再講組合后的服務(wù)注入到controller中供業(yè)務(wù)側(cè)使用)

    @Component
    public class DubboSupport
    {
        @Reference(version = "1.0.0",interfaceClass = BugReportService.class)
         BugReportService bugReportService;     
        public BugReportService getBugReportService(){
            return bugReportService;
        }
    }

Dubbo超時(shí)和重連

dubbo啟動(dòng)時(shí)默認(rèn)有重試機(jī)制和超時(shí)機(jī)制,某些業(yè)務(wù)場景下,如果不注意配置超時(shí)和重試,可能會引起一些異常。

超時(shí)機(jī)制的規(guī)則是如果在一定的時(shí)間內(nèi),provider沒有返回，則認(rèn)為本次調(diào)用失敗

重試機(jī)制在出現(xiàn)調(diào)用失敗時(shí)，會再次調(diào)用。如果在配置的調(diào)用次數(shù)內(nèi)都失敗，則認(rèn)為此次請求異常，拋出異常。(dubbo默認(rèn)重試2次)

如果出現(xiàn)超時(shí)，通常是業(yè)務(wù)處理太慢或者發(fā)送io阻塞,可在服務(wù)提供方執(zhí)行：jstack PID>jstack.log分析線程都卡在哪個(gè)方法調(diào)用上，這里就是慢的原因。如果這個(gè)服務(wù)接口不能調(diào)優(yōu)性能，請將timeout設(shè)大。

超時(shí)設(shè)置

DUBBO消費(fèi)端設(shè)置超時(shí)時(shí)間需要根據(jù)業(yè)務(wù)實(shí)際情況來設(shè)定，如果設(shè)置的時(shí)間太短，一些復(fù)雜業(yè)務(wù)需要很長時(shí)間完成，導(dǎo)致在設(shè)定的超時(shí)時(shí)間內(nèi)無法完成正常的業(yè)務(wù)處理。這樣消費(fèi)端達(dá)到超時(shí)時(shí)間，那么dubbo會進(jìn)行重試機(jī)制，不合理的重試在一些特殊的業(yè)務(wù)場景下可能會引發(fā)很多問題，需要合理設(shè)置接口超時(shí)時(shí)間。

比如發(fā)送郵件，可能就會發(fā)出多份重復(fù)郵件，執(zhí)行注冊請求時(shí)，就會插入多條重復(fù)的注冊數(shù)據(jù)。

1.合理配置超時(shí)和重連的思路

對于核心的服務(wù)中心，去除dubbo超時(shí)重試機(jī)制，并重新評估設(shè)置超時(shí)時(shí)間。

業(yè)務(wù)處理代碼必須放在服務(wù)端，客戶端只做參數(shù)驗(yàn)證和服務(wù)調(diào)用，不涉及業(yè)務(wù)流程處理

2.Dubbo超時(shí)和重連配置示例

    <!-- 服務(wù)調(diào)用超時(shí)設(shè)置為6秒,超時(shí)不重試--> 
    <dubbo:service interface="com.provider.service.DemoService" ref="demoService"  retries="0" timeout="5000"/>

3.Dubbo消費(fèi)者端統(tǒng)一的超時(shí)和重連配置

    <!--統(tǒng)一的消費(fèi)者配置-->
    <dubbo:consumer timeout="30000" retries="0" version="1.0.0"/>

以上就是動(dòng)力節(jié)點(diǎn)小編介紹的"Dubbo的使用注意點(diǎn)"，希望對大家有幫助，想了解更多可查看Dubbo教程，如有疑問，請?jiān)诰€咨詢，有專業(yè)老師隨時(shí)為您服務(wù)。