基于Dubbo框架的短信平臺的開發(fā)與設(shè)計(jì)

王 睿，趙 勇

（1.西安熱工研究院有限公司陜西西安710054；2.長安大學(xué)信息工程學(xué)院，陜西西安710064）

隨著我國經(jīng)濟(jì)的飛速發(fā)展，人們生活水平日益提高，手機(jī)用戶的數(shù)量也不斷增長，短信逐漸成為人與人之間交流的一種重要方式。短信業(yè)務(wù)一開始主要用于個(gè)人之間的信息交流，后來由于其快捷、無時(shí)空限制、價(jià)格低的優(yōu)勢而越來越多的被應(yīng)用在企業(yè)中[1-5]。現(xiàn)階段，企業(yè)短信平臺主要有兩方面作用：首先是與企業(yè)自身的客戶進(jìn)行交流或是向客戶宣傳推廣自己的品牌；其次是用于企業(yè)內(nèi)部交流，利用短信平臺向員工發(fā)送短信通知，例如會(huì)議通知、生日祝福等[6-7]。

現(xiàn)如今，隨著互聯(lián)網(wǎng)的高速發(fā)展，互聯(lián)網(wǎng)企業(yè)的客戶量也急劇增加。面對如此龐大的客戶群體，企業(yè)內(nèi)短信下發(fā)服務(wù)的壓力也與日俱增[8-9]。針對這一問題，本文開發(fā)了基于Dubbo框架的短信平臺，其采用了Dubbo框架實(shí)現(xiàn)分布式架構(gòu)，將短信服務(wù)注冊在zk中心，當(dāng)有業(yè)務(wù)需要進(jìn)行短信下發(fā)操作時(shí)則通過zk中心發(fā)現(xiàn)并消費(fèi)服務(wù)。當(dāng)短信下發(fā)需求量繼續(xù)增加時(shí)，則可以通過在zk中心繼續(xù)注冊提供短信業(yè)務(wù)的服務(wù)器即可。文中以公司自身短信平臺的實(shí)際開發(fā)為例，設(shè)計(jì)與實(shí)現(xiàn)了第三方支付短信平臺的核心功能部分，主要包括短信核心模塊、定時(shí)器模塊等。

1 系統(tǒng)設(shè)計(jì)

1.1 系統(tǒng)架構(gòu)設(shè)計(jì)

文中所開發(fā)的第三方支付短信平臺，通過調(diào)用短信代理商接口來實(shí)現(xiàn)短信的發(fā)送。這樣可以讓項(xiàng)目開發(fā)的側(cè)重點(diǎn)放在業(yè)務(wù)需求解決上，而無需關(guān)心短信如何具體下發(fā)。在這種接入模式下，以短消息平臺下發(fā)給手機(jī)用戶信息為例，短消息下發(fā)流程為：短信平臺—短信代理商—短信運(yùn)營商—手機(jī)用戶。

該第三方支付短信平臺中采用Spring MVC分層框架，通過RPC協(xié)議的Dubbo框架將公司業(yè)務(wù)邏輯層與短信平臺服務(wù)層進(jìn)行解耦，實(shí)現(xiàn)分布式架構(gòu)[10]。如圖1所示，本系統(tǒng)由四個(gè)層次模塊組成，分別是業(yè)務(wù)接入層、短信服務(wù)層、基礎(chǔ)服務(wù)層以及數(shù)據(jù)存儲層。接入層主要是接受公司不同業(yè)務(wù)短信下發(fā)的請求，調(diào)用短信服務(wù)層對外提供的接口，從而實(shí)現(xiàn)短信下發(fā)功能；短信服務(wù)層在處理短信下發(fā)前則會(huì)根據(jù)短信通道路由策略，選擇不同短信下發(fā)通道進(jìn)行請求處理；基礎(chǔ)服務(wù)層主要是為該短信平臺系統(tǒng)提供一些的基礎(chǔ)服務(wù)，例如消息服務(wù)、緩存服務(wù)以及日志服務(wù)等；數(shù)據(jù)存儲層主要是對數(shù)據(jù)庫進(jìn)行操作，將操作比較頻繁的數(shù)據(jù)保存在Redis緩存數(shù)據(jù)庫中，而對于其他一些數(shù)據(jù)則保存在Mysql數(shù)據(jù)庫中。

圖1 系統(tǒng)架構(gòu)圖

圖2 短信平臺部署架構(gòu)

該短信平臺系統(tǒng)采用Spring MVC框架，不同層次之間采用依賴注入的方式進(jìn)行分離解偶，使得各個(gè)層次容易進(jìn)行定制，提高了系統(tǒng)性能，也增強(qiáng)了系統(tǒng)的擴(kuò)展性能。同時(shí)，使用Dubbo框架也可以將短信服務(wù)層與接入層進(jìn)行分離，將短信下發(fā)服務(wù)注冊到Zookeeper中心并對外暴露服務(wù)。業(yè)務(wù)接入層需要短信下發(fā)操作時(shí)，通過在注冊中心上發(fā)現(xiàn)并消費(fèi)短信服務(wù)即可。基礎(chǔ)服務(wù)中的消息服務(wù)采用的是RabbitMQ，由于短信下發(fā)數(shù)量巨大，每條短信下發(fā)成功后立即存入數(shù)據(jù)庫中會(huì)極大的影響系統(tǒng)性能，若數(shù)據(jù)庫出現(xiàn)異常狀況也會(huì)導(dǎo)致短信入庫記錄異常。因此，本系統(tǒng)中采用RabbitMQ作為消息隊(duì)列，短信下發(fā)成功后，將信息放入消息列隊(duì)中，再由消息隊(duì)列異步的進(jìn)行入庫操作。數(shù)據(jù)存儲層采用的是Mybatis框架。

1.2 系統(tǒng)架構(gòu)部署

根據(jù)第三方支付短信平臺系統(tǒng)設(shè)計(jì)的要求，以及對系統(tǒng)各方面性能要求的把握，形成了該第三方支付短信平臺系統(tǒng)總體架構(gòu)，如圖2所示。

其中，接入層與短信服務(wù)層通過Dubbo框架解耦，并通過zk中心聯(lián)系起來，而Dubbox監(jiān)控系統(tǒng)則負(fù)責(zé)管理Dubbo服務(wù)。消息服務(wù)通過RabbitMQ實(shí)現(xiàn)，其每成功發(fā)送一條短信就異步的將短信發(fā)送結(jié)果下發(fā)到消息隊(duì)列中，再從消息隊(duì)列中寫入到數(shù)據(jù)庫中，從而減少了系統(tǒng)負(fù)擔(dān)以及數(shù)據(jù)庫異常所帶來的問題。數(shù)據(jù)庫緩存由redis來完成，其將操作頻繁的數(shù)據(jù)保存在redis中，大幅提高了數(shù)據(jù)操作的速率和系統(tǒng)性能。在Zookeeper中，使用Zabbix對系統(tǒng)CPU、內(nèi)存等的使用情況進(jìn)行管理監(jiān)控。

2 系統(tǒng)實(shí)現(xiàn)

2.1 短信下發(fā)流程

系統(tǒng)短信發(fā)送時(shí)序，如圖3所示。

圖3 短信發(fā)送時(shí)序圖

短信發(fā)送流程如圖4所示，當(dāng)有短信下發(fā)請求時(shí)，業(yè)務(wù)平臺首先會(huì)通過類Smscontroller接收業(yè)務(wù)平臺傳送的請求參數(shù)，包括手機(jī)號、短信內(nèi)容等并調(diào)用SmsFacade短信下發(fā)接口sendSms（）方法。該接口由類SmsFacadeImpl進(jìn)行實(shí)現(xiàn)，同時(shí)在該實(shí)現(xiàn)類中通過路由策略選出具體短信下發(fā)通道，在具體通道中將短信發(fā)出。

具體通道下發(fā)流程：從配置中心獲取已經(jīng)設(shè)置好的該指定通道的用戶名、密碼以及請求地址（短信代理商提供），接著根據(jù)具體通道所指定的報(bào)文格式進(jìn)行拼裝參數(shù)Params。最后，通過doPost方法進(jìn)行下發(fā)短信請求，代碼如下：

wsdlUrl_ww為微網(wǎng)通聯(lián)短信通道的url地址，"/g_Submit"為短信下發(fā)命令，相應(yīng)的"/Sm_GetRemain"為短信余額查詢命令。Params為拼裝接口所需參數(shù)，responseStr則是微網(wǎng)通聯(lián)響應(yīng)信息。通過將responseStr字符串轉(zhuǎn)為XML解析后，得到State參數(shù)，若為“0”則表示響應(yīng)成功。

圖4 短信下發(fā)流程圖

2.2 短信核心模塊

2.2.1 短信通道的路由策略

本短信平臺目前對接了5個(gè)短信代理商（大漢三通、建周等），即為5個(gè)短信通道。根據(jù)每個(gè)短信通道的收費(fèi)、發(fā)送速率、到達(dá)率等因素為不同的通道劃分優(yōu)先級和權(quán)重。因此，當(dāng)有短信下發(fā)請求時(shí)，短信平臺的路由策略可以先根據(jù)短信通道的優(yōu)先級進(jìn)行選擇，級別越高則優(yōu)先選擇。當(dāng)優(yōu)先級相同時(shí)，則再依據(jù)權(quán)重大小進(jìn)行選擇。同時(shí)，若以后需要增加短信通道，只需配置通道的優(yōu)先級與權(quán)重即可，為企業(yè)今后的短信通道接入提供了便利。具體代碼如下所示：

RouteStrategyCacheFacaderouteStrategyCacheFac ade=（RouteStrategyCacheFacade）

通過以上代碼，將所有短信通道按照優(yōu)先級和權(quán)重進(jìn)行排序，將排序后的結(jié)果放入route StrategyList集合當(dāng)中。arrayFlag[currentSmsFlag]代表當(dāng)前通道，將SERVER_KEY+"_"+arrayFlag[currentSmsFlag]這一參數(shù)傳入serverCache.get（）方法可唯一確定短信下發(fā)的具體通道。當(dāng)currentSmsFlag所代表的當(dāng)前通道發(fā)送失敗，則將currentSmsFlag+1來獲取下一個(gè)通道重新下發(fā)短信。若仍然失敗，則以此類推直到routeStrategyList當(dāng)中的所有通道全部執(zhí)行完成。

2.2.2 短信通道自動(dòng)降級

由于目前短信平臺對接了5個(gè)短信通道，每個(gè)通道也分配了優(yōu)先級和權(quán)重。在選擇具體通道時(shí)，會(huì)優(yōu)先選擇優(yōu)先級高、權(quán)重大的通道[11]。但由于分配的優(yōu)先級與權(quán)重是在理論基礎(chǔ)上的設(shè)值，所以在實(shí)際項(xiàng)目中會(huì)依據(jù)短信通道下發(fā)短信的質(zhì)量（主要指發(fā)送成功率）進(jìn)行相應(yīng)調(diào)整。當(dāng)優(yōu)先級高的通道發(fā)送短信失敗條數(shù)達(dá)到設(shè)定值后，短信平臺則會(huì)自動(dòng)降低該通道的優(yōu)先級或權(quán)重，從而減少系統(tǒng)因發(fā)送失敗再重新發(fā)送而增加的負(fù)擔(dān)。同時(shí)，也可以將失敗的短信條數(shù)控制在相當(dāng)?shù)偷乃剑岣邩I(yè)務(wù)服務(wù)水平，增加客戶友好度。

2.2.3 個(gè)性化短信業(yè)務(wù)

當(dāng)消費(fèi)者需要個(gè)性化業(yè)務(wù)時(shí)，比如（彩鈴提示、語音提示），則短信平臺會(huì)優(yōu)先選擇在該業(yè)務(wù)上與公司合作密切的短信通道進(jìn)行發(fā)送。通過smsSendVo.getBusinessType（）方法獲取客戶所需發(fā)送的業(yè)務(wù)類型，若是與短信類型所對應(yīng)的code不匹配，則由通過該業(yè)務(wù)類型的指定通道進(jìn)行發(fā)送。

2.3 通道報(bào)警模塊

通道報(bào)警主要實(shí)現(xiàn)定時(shí)調(diào)度，即基于時(shí)間點(diǎn)、間隔時(shí)間以及執(zhí)行次數(shù)的任務(wù)調(diào)度過程[12]。在如今各式各類的業(yè)務(wù)系統(tǒng)中，基本上均存在周期性的任務(wù)需求，只要存在周期性的任務(wù)就離不開定時(shí)調(diào)度。在Java語言中，定時(shí)調(diào)度的實(shí)現(xiàn)方式主要有3種，分別為：Timer調(diào)度、線程池調(diào)度和Quartz調(diào)度[13-15]。

Timer調(diào)度簡單方便，實(shí)現(xiàn)過程也相對簡便，能實(shí)現(xiàn)簡單的調(diào)度需求。但時(shí)間設(shè)置上不靈活，且以單線程方式運(yùn)行，若出現(xiàn)異常容易掛起。

Quartz調(diào)度的配置也靈活簡便，可以實(shí)現(xiàn)復(fù)雜的調(diào)度需求。Quartz采用的是多線程的調(diào)度方式，因而可以多任務(wù)并發(fā)執(zhí)行。Quartz的另一顯著優(yōu)點(diǎn)在于持久化，即將任務(wù)調(diào)度的相關(guān)數(shù)據(jù)保存下來。這樣，當(dāng)系統(tǒng)重啟后，任務(wù)被調(diào)度的狀態(tài)依然存在于系統(tǒng)中，不會(huì)丟失。Quartz任務(wù)調(diào)度的核心元素是scheduler、trigger和 job，其中 trigger和 job是任務(wù)調(diào)度的元數(shù)據(jù)，scheduler是實(shí)際執(zhí)行調(diào)度的控制器。

線程池調(diào)度以線程池為基礎(chǔ)實(shí)現(xiàn)調(diào)度，是目前比較完美的定時(shí)調(diào)度。線程池采用的是多線程的調(diào)度方式，因而可以允許多任務(wù)并發(fā)執(zhí)行；線程池中增加了守護(hù)線程來監(jiān)測工作線程的生命狀態(tài)，因而即使在極端復(fù)雜環(huán)境中也不存在調(diào)度任務(wù)會(huì)突然中斷的問題。而缺點(diǎn)是配置比較復(fù)雜。

在本項(xiàng)目中，考慮到有5個(gè)短信通道需要實(shí)現(xiàn)定時(shí)調(diào)度，為防止不同通道之間的定時(shí)任務(wù)互相影響，所以采用多線程的調(diào)度方式。另外，該系統(tǒng)中不存在其他定時(shí)調(diào)度任務(wù)，故調(diào)度環(huán)境并不復(fù)雜，所以選擇采用Quartz調(diào)度實(shí)現(xiàn)定時(shí)報(bào)警功能。

每個(gè)通道內(nèi)公司均會(huì)預(yù)先充值一定的金額，每走相應(yīng)的通道發(fā)送短信均會(huì)在該通道扣除相應(yīng)的費(fèi)用。當(dāng)通道內(nèi)余額不足時(shí)，就會(huì)導(dǎo)致下發(fā)短信失敗，從而影響客戶收到短信的速率。因此必須時(shí)刻了解通道內(nèi)的余額狀況，減少因余額不足而導(dǎo)致的短信下發(fā)失敗。若是采用人工監(jiān)督的方式，不僅費(fèi)時(shí)費(fèi)力，且準(zhǔn)確率也沒有保障。因此，采用了Quartz定時(shí)器進(jìn)行監(jiān)聽，每隔一定時(shí)間查看一下余額，確保余額大于設(shè)定值。一旦小于設(shè)定值，則產(chǎn)生報(bào)警，提醒負(fù)責(zé)人進(jìn)行充值。

文中首先，通過TaskAddMonitor類負(fù)責(zé)添加任務(wù)并啟動(dòng)任務(wù)。然后，采用QuartzManager定時(shí)任務(wù)管理類負(fù)責(zé)添加或移除定時(shí)任務(wù)，修改定時(shí)任務(wù)觸發(fā)時(shí)間等。最后，通過TaskJobManager類實(shí)現(xiàn)了org.quartz.Job接口，可以使Java類變成可執(zhí)行的，當(dāng)匹配到已有的定時(shí)任務(wù)時(shí)則執(zhí)行指定通道定時(shí)任務(wù)。

3 結(jié)束語

現(xiàn)如今，隨著互聯(lián)網(wǎng)的高速發(fā)展，互聯(lián)網(wǎng)企業(yè)的客戶量也急劇增加。面對如此龐大的客戶群體，企業(yè)內(nèi)短信下發(fā)服務(wù)的壓力也與日俱增。針對這一問題，本文開發(fā)了基于Dubbo框架的短信平臺，其采用了Dubbo框架實(shí)現(xiàn)分布式架構(gòu)，將短信服務(wù)注冊在zk中心，當(dāng)有業(yè)務(wù)需要進(jìn)行短信下發(fā)操作時(shí)則通過zk中心發(fā)現(xiàn)并消費(fèi)服務(wù)。當(dāng)短信下發(fā)需求量繼續(xù)增加時(shí)，則可以通過在zk中心繼續(xù)注冊提供短信業(yè)務(wù)的服務(wù)器即可。本文以短信平臺的實(shí)際開發(fā)為例，設(shè)計(jì)與實(shí)現(xiàn)了第三方支付短信平臺的核心功能部分，主要包括短信核心模塊、定時(shí)器模塊等。