採用註解方式注入消費者接口實力空指針
註解的方式在現在的項目中由於他的簡潔性越來越被大衆所喜歡,在我們集成dubbox的時候,發現dubbox支持了註解方式,但是在我們在用註解式集成的時候,發現消費者的對象在沒有注入進去,一直都是報空指針異常.
代碼如下:
/** * <p> * bug反饋業務接口 * </p> * * @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的服務,就會出現空指針,因爲在實例化的時候是沒有對應的消費者的實例的,所以就會造成無法注入,這也就是爲什麼在我們調用消費者服務的時候會造成空指針.
下面是博主編排成功的代碼.
<mvc:annotation-driven /> <!-- 查找xxx路徑下所有@Controller 註釋類,添加與項目相關的controller --> <dubbo:annotation package="XXX.XXX.XXX.controller" /> <context:component-scan base-package="XXX.XXX.XXX.controller"/>
然後在查閱資料之後,博主又發現了另一種解決辦法:
在一個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超時和重連配置示例
<!-- 服務調用超時設置爲6秒,超時不重試--> <dubbo:service interface="com.provider.service.DemoService" ref="demoService" retries="0" timeout="5000"/>
(3)Dubbo消費者端統一的超時和重連配置
<!--統一的消費者配置--> <dubbo:consumer timeout="30000" retries="0" version="1.0.0"/>
重連機制
dubbo在調用服務不成功時,默認會重試2次。Dubbo的路由機制,會把超時的請求路由到其他機器上,而不是本機嘗試,所以 dubbo的重試機器也能一定程度的保證服務的質量。但是如果不合理的配置重試次數,當失敗時會進行重試多次,這樣在某個時間點出現性能問題,調用方再連續重複調用,系統請求變爲正常值的retries倍,系統壓力會大增,容易引起服務雪崩,需要根據業務情況規劃好如何進行異常處理,何時進行重試。
在重試發送的時候也可能會出現這樣的問題:
比如有一個bug反饋,但是因爲數據庫io瓶頸,這時候這個服務阻塞了,然後過了一會查看數據庫裏有3條除了id外剩下都一樣的數據(id是在服務提供者裏生成的,這裏只做異常例子舉例).
這就是重試機制下,業務不合理的設計所造成的坑,這時候我們處理的方式有兩種:
合理規劃業務(例如id放在服務上游生成,數據庫主鍵唯一的機制)
吧服務增加冪等性設置(例如接口中增加消息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>