1. 背景簡介

優(yōu)惠券系統(tǒng)是互聯(lián)網(wǎng)電商時代最為常用運營手段，拉新，促活，留存，在運營的過程中，能快速的、靈活的支持運營頻繁多變的營銷需求。傳統(tǒng)的實現(xiàn)方案，不僅開發(fā)周期長、成本大，并且不能及時影響運營多變的需求，運營活動復(fù)用的效率較低。

車服務(wù)優(yōu)惠券系統(tǒng)提供了一種可裝配且通用優(yōu)惠券核心框架的實現(xiàn)，快速搭建滿足業(yè)務(wù)需要的優(yōu)惠券模板功能。僅需開發(fā)一次自定義業(yè)務(wù)組件，可靈活裝配多優(yōu)惠券模板，發(fā)券用券驗券接口無需二次開發(fā)，平行無縫對接第三方商家券，節(jié)省開發(fā)資源，減少開發(fā)成本，提高了運營效率。

2. 系統(tǒng)設(shè)計

2.1優(yōu)惠券的生命周期

組件創(chuàng)建：定義表單元素，生成自定義組件，存入組件庫中。

裝配模板：運營按業(yè)務(wù)需求，選擇組件，組合裝配在一起，生成優(yōu)惠券模板。

生成批次：選擇模板，關(guān)聯(lián)配置業(yè)務(wù)券，比如：加油券，充電券，洗車券，代步券等。模板組合裝配在一起，生成優(yōu)惠券批次。

投放活動：配置運營活動，關(guān)聯(lián)批次券信息。可組合裝配成券包，或單張券，投放客戶端或H5頁面。

兌換領(lǐng)?。喊l(fā)放形式，可分為3種，兌換碼兌換，運營活動用戶登錄領(lǐng)券，運營后臺定向發(fā)券，滿足業(yè)務(wù)規(guī)則，比如新注冊用戶，業(yè)務(wù)新老用戶，首單用戶發(fā)券進行間接發(fā)券。

核銷使用：用戶購買商品下單，拉取可用券，下單鎖定券，支付核銷券。

取消訂單還券：訂單取消，返還用戶券，券可再次使用。

券快過期提醒：推送提醒用戶使用。

結(jié)算：生成優(yōu)惠券，平臺與商家承擔(dān)比例，執(zhí)行結(jié)算補貼。

2.2優(yōu)惠券系統(tǒng)設(shè)計思維導(dǎo)圖

圖 2-3

2.3優(yōu)惠券系統(tǒng)基本流程圖示

 組件創(chuàng)建 >> 裝配模板 >> 裝配批次 >> 裝配活動 >> 發(fā)券 >> 核銷券 >> 結(jié)算

圖 2-4

2.4優(yōu)惠券系統(tǒng)架構(gòu)圖示

圖 2-5

3. 核心功能

3.1創(chuàng)建自定義組件

 自定義組件：創(chuàng)建優(yōu)惠券組件，生成優(yōu)惠券模板必要條件，因為模板生成時，需要加載裝配相關(guān)的表單組件。 

創(chuàng)建組件所需元素信息為：組件表單名稱，Placeholder文本信息，JS驗證功能，數(shù)據(jù)源，組件類型（包含文本框，數(shù)值框，下拉列表框，多選列表框控件，聯(lián)選日期控件，滿減金額控件，數(shù)據(jù)列表模態(tài)選擇框等常用組件)，表達式關(guān)鍵詞等。其中配置Js驗證功能，需要預(yù)先開發(fā)JS驗證插件，集成常用的驗證插件庫中，用于模板生成時自動檢查表單中元素。其中配置表達式關(guān)鍵詞，用于生成規(guī)則條件表達式。其中設(shè)置數(shù)據(jù)源，用于初始化組件下拉列表，數(shù)據(jù)可選模態(tài)框等。組件生成后，保存到組件庫表中，提供給模板創(chuàng)建使用。

解決的問題：

自定義組件的實現(xiàn)，存入組件庫中，提高了代碼復(fù)用性，常用的組件，任何業(yè)務(wù)券都可以復(fù)用，避免多次開發(fā)，增加了業(yè)務(wù)的靈活性，對系統(tǒng)進行解耦，也可以分組開發(fā)，部署。后臺優(yōu)惠券模板可以自由組合，根據(jù)運營需求，快速自行裝配。提高運營工作效率，支持多業(yè)務(wù)券場景配置。

優(yōu)惠券自定義組件生成，方便快速構(gòu)建業(yè)務(wù)優(yōu)惠券模板，需求靈活實現(xiàn)。不管是優(yōu)惠類型，還是業(yè)務(wù)需求方可變的條件，我們都能從設(shè)計層面去實現(xiàn)它。來節(jié)約開發(fā)運營成本。并且生成可配置的多規(guī)則條件表達式。下單使用時，一次驗證，所有的條件是否可達，滿足優(yōu)惠券下單使用。使優(yōu)惠券系統(tǒng)結(jié)構(gòu)簡潔清晰，同時將可變的部分，完全開放給使用者，提供了非常大的靈活性。

創(chuàng)建組件頁面圖示如下：

圖：3-1-1

組件創(chuàng)建流程圖示如下：

圖 3-1-2

3.2創(chuàng)建自定義模板

自定義模板創(chuàng)建：由3.1中創(chuàng)建的組件，按業(yè)務(wù)需求，進行動態(tài)裝配。優(yōu)惠券模板可設(shè)置3種類型，分別為商家券模板，平臺券模板，公共模板。用于批次生成時，對運營進行不同角色權(quán)限隔離使用。其中配置業(yè)務(wù)類型，用于客戶端拉券時按業(yè)務(wù)隔離展示使用。配置滿減券，立減券，折扣券，用于區(qū)分券的使用條件。模板可選組件分為兩部分，固定區(qū)域，可變區(qū)域。固定區(qū)域為優(yōu)惠券中的常用組件區(qū)域，系統(tǒng)自動加載固定類型組件信息，見圖3-2-1所示，固定類型組件是每張優(yōu)惠券共有的屬性。比如：優(yōu)惠券標(biāo)題，面額，庫存數(shù)量，使用時間，平臺與商家承擔(dān)比例，折扣，最高金額，使用跳轉(zhuǎn)Url等。可變區(qū)域為運營活動用券時需要驗證的組件區(qū)域，比如限制的商家，門店，滿減條件等組件。若組件庫中組件元素為非固定類型，系統(tǒng)會區(qū)分當(dāng)前組件為可變組件，展示在選擇組件區(qū)域，提供運營人員按業(yè)務(wù)券的需求，可從組件庫中進行拖拉組件到指定可變區(qū)域中。最后模板生成，系統(tǒng)會保存模板庫中，以供批次創(chuàng)建生成使用。至此，模板再次加載或編輯時，其中的業(yè)務(wù)部分，基礎(chǔ)屬性部分，可變部分，系統(tǒng)會根據(jù)所存的模板信息，關(guān)聯(lián)到批次中，同時相應(yīng)的加載出元素組件。

解決的問題：

運營人員可根據(jù)業(yè)務(wù)券需求，自定義裝配優(yōu)惠券模板。通過界面，進行拖拉組件，支持組件元素拖拉排序，快速生成優(yōu)惠券模板，簡潔快捷，動態(tài)裝配。存入模板庫中。提供運營創(chuàng)建批次時，多次復(fù)用，減少開發(fā)成本，提高工作效率。

創(chuàng)建模板頁面圖示如下：

 圖 3-2-1

模板流程圖示：

圖 3-2-2 

3.3創(chuàng)建自定義批次券包

•  自定義批次：設(shè)定批次的通用屬性，動態(tài)加載優(yōu)惠券模板，自動校驗表單控件三部分組成。
• 通用屬性配置：發(fā)券的形式，包含直接領(lǐng)取券與兌換券碼形式。限制領(lǐng)取次數(shù)，可限當(dāng)天每人領(lǐng)取次數(shù)，或者批次總領(lǐng)取次數(shù)。領(lǐng)取人群的配置限制，包含業(yè)務(wù)新老用戶限制，注冊新老用戶的限制。短信釘釘提醒功能配置，過期券預(yù)提配置，運營庫存提醒配置。商家單位配置，財務(wù)PR單號配置等。預(yù)提醒功能技術(shù)實現(xiàn)，通過延遲隊列，定時任務(wù)執(zhí)行實現(xiàn)。
• 動態(tài)優(yōu)惠券模板：
• 優(yōu)惠券批次創(chuàng)建，加載可用的優(yōu)惠券模板。運營可根據(jù)需求，在下拉列表中選擇優(yōu)惠券模板。此處優(yōu)惠券模板，是根據(jù)可視化組件，分布式控件動態(tài)加載渲染呈現(xiàn)，去除了冗余的模板組件。可以無限制的加載需要配置的優(yōu)惠券。比如：加油，充電，洗車。
• 自動校驗證表單：
• 由于模板是動態(tài)加載的組件，多個優(yōu)惠券模板，會有很多組件，組件類型不同，一個個寫表單校驗，會顯得很繁瑣，代碼臃腫，維護復(fù)雜 ?，F(xiàn)對所有的元素組件，進行動態(tài)提取組件配置的JS，然后根據(jù)JS校驗類庫，自動加載表單驗證，維護簡單，代碼簡潔。

解決問題：

批次可以多張券模板組合，最終生成一個券包。支持不同業(yè)務(wù)券組合，相同業(yè)務(wù)券組合。支持批次復(fù)制，模板復(fù)用。發(fā)券可以按券包形式發(fā)，也可以按單張券針對性發(fā)放。批次創(chuàng)建，是由模板動態(tài)加載自定義組件完成。多個券模板，如果按傳統(tǒng)模式開發(fā)，會很多組件元素要書寫，js功能也要逐個書寫，每當(dāng)有新券需求，或者券限制條件升級變動，都會需要大量的控件開發(fā)，費時費力。本批次的設(shè)置，代碼簡潔，界面明了，所見即所得，無須過度開發(fā)，一勞永逸。

批次創(chuàng)建圖示如下：

圖 3-3-1

模板加載圖示如下：

圖 3-3-2

批次創(chuàng)建流程圖：

圖 3-3-3

3.4創(chuàng)建自定義活動

創(chuàng)建活動，可以配置整個業(yè)務(wù)的領(lǐng)券中心。聚合所有待領(lǐng)取的券，券包展示，同時提供對外輸出領(lǐng)券接口關(guān)鍵配置，需要設(shè)置活動名稱，活動的起始時間，活動KEY，互斥KEY，活動限制數(shù)量，活動的跳轉(zhuǎn)鏈接，活動所投放平臺渠道。可選擇關(guān)聯(lián)不同的券批次模板，通過活動KEY的領(lǐng)取維度，鎖定不同的批次券包，鎖定整個活動領(lǐng)取量，進行發(fā)券。通過互斥KEY的維度，鎖定不同的活動，用戶在活動A中可以領(lǐng)取哪些券，在活動B可以領(lǐng)取哪些券。通過活動中啟動，停止進行領(lǐng)取功能的控制，將活動中配置信息進行保存，存入活動領(lǐng)取中心庫中。

解決的問題：

適應(yīng)于一個或多個活動場景，比如領(lǐng)券中心，領(lǐng)單張券，券包，一鍵批量領(lǐng)券，新老用戶領(lǐng)券。通過活動Key，關(guān)聯(lián)出整個活動配置的券包。通過活動控制券上線下線功能。對外輸出領(lǐng)券接口，提供領(lǐng)券的活動標(biāo)識隨機碼Key，保證業(yè)務(wù)的保密性、可控性、復(fù)用性。

活動創(chuàng)建圖示3-4如下：

圖 3-4-1

      活動配置流程圖示：

圖 3-4-2

4. 技術(shù)難點

4.1技術(shù)如何實現(xiàn)自定義組件

圖 4-1-1

創(chuàng)建模板時，是由多個組件裝配完成。新創(chuàng)建模板時，如何動態(tài)渲染加載多個組件？編輯模板如何對組件進行賦值？模板組件從技術(shù)層面是由多個Freemark模板視圖文件組合而成，比如圖 4-1-1 中propType_text.ftl 文件，propType_List.ftl文件，propType_Select.ftl文件等，在創(chuàng)建模板中頁面中，會根據(jù)組件池中，根據(jù)組件類型，通過<#include>進行文件加載傳遞數(shù)據(jù)完成。如下圖 4-1-2所示。 

圖 4-1-2

模板視圖文件需要Html+Freemark+Jquery 預(yù)先開發(fā)創(chuàng)建好。其中表單控件中name為組件生成時配置的name屬性，文件中所有的${}語法屬性，均對應(yīng)組件生成時配置屬性。比如4-1-3中：${prop.placeholder} 文本框描述提示信息，${prop.flagword} 是使用條件占位符，${prop.jsfunction} js自定義驗證功能方法名，${prop.id} 組件Id，${prop.type} 組件類型，${prop.formnameExt} 模板Id+組件名稱，${prop.datasource}等不再一一列舉。

動態(tài)組件插件示例：舉個文本框組件propType_Text.ftl 示例：后端讀取模板中文本框?qū)傩灾祩鬟f賦值。

圖4-1-3

模板視圖文件中 ${prop}是整個頁面渲染控件主要引擎對象。又是后端模板通用對象模型，對應(yīng)的后端開發(fā)類名為：CouponTempPropView ，如下面代碼所示。后端接口通過模板Id，關(guān)聯(lián)所有模板中的組件屬性信息。然后封裝成CouponTempPropView數(shù)據(jù)對象，進行初始化值賦值。若模板頁面首次新頁面加載，后端接口HandlAdapter處理適配器響應(yīng)CouponTempPropView對象數(shù)據(jù)，通過ViewResolver視圖解析器初始化組件頁面表單，進行渲染呈現(xiàn)。若模板頁面編輯時，需要對組件表單input元素進行賦值。由${prop}對象取CouponTempPropView對象數(shù)據(jù)中的${prop.formvalue}，然后jquery查找當(dāng)前prop.formvalue的input隱藏域控件的value值，該value是由多個屬性值組合而成，根據(jù)當(dāng)前組件，需要進行拆解，然后將值傳遞給name=${prop.formnameExt}的input控件，進行傳遞賦值。到此組件技術(shù)裝配屬性完成。創(chuàng)建批次時，選擇優(yōu)惠券模板，動態(tài)加載標(biāo)簽自定義組件呈現(xiàn)后臺UI，如何加載模板的相關(guān)的組件信息呢，同樣是引用模板視圖文件完成的。技術(shù)運用了動靜分離技術(shù)手段及組件化模板插件響應(yīng)，運營人員選擇優(yōu)惠券業(yè)務(wù)模板，后端數(shù)據(jù)根據(jù)運營的選擇模板，程序進行準(zhǔn)備模板及控件所需數(shù)據(jù)。通過模板數(shù)據(jù)裝載，初始化需要加載的模板中關(guān)聯(lián)組件，前端頁面不需要堆積實現(xiàn)未知的組件，僅根據(jù)后端數(shù)據(jù)，注入到模板關(guān)聯(lián)組件的插件中，傳遞數(shù)據(jù)，需要呈現(xiàn)哪一塊插件，就會渲染所關(guān)聯(lián)的組件，完全數(shù)據(jù)來驅(qū)動實現(xiàn)組件的呈現(xiàn)，實現(xiàn)方式和現(xiàn)在的Vue想法一致。完全數(shù)據(jù)初始化控件，數(shù)據(jù)傳遞控件的實現(xiàn)。

編輯批次時，關(guān)聯(lián)多個模板信息，后端如何進行動態(tài)傳值：由批次信息，找到批次所關(guān)聯(lián)的一個或多個模板信息，再由模板查找，加載出模板對應(yīng)的組件信息，組件信息包含表單元素，通過批次信息表中的存儲的字段值，轉(zhuǎn)化成Key-value，key為表單元素，value為對應(yīng)值。對模板組件屬性結(jié)構(gòu)類型進行一一映射，通過Action傳遞前端頁面進行渲染優(yōu)惠券模板組件視圖。最終實現(xiàn)和創(chuàng)建模板時的加載視圖文件一致，不再詳細贅述。

4.2技術(shù)如何動態(tài)生成條件表達式

由于優(yōu)惠券批次包含多個優(yōu)惠券模板，每個優(yōu)惠券模板的使用條件是隨業(yè)務(wù)需求變化，所以我們?nèi)绻鎯@樣動態(tài)可變的值，數(shù)據(jù)表中每次需升級擴展字段，同時又要升級系統(tǒng)的數(shù)據(jù)讀取Mybatis文件，以及優(yōu)惠券模板文件中限制條件規(guī)則等。顯然這種方式比較笨拙，粗曠，又不利于優(yōu)惠券系統(tǒng)的維護。我們自定義的規(guī)則條件表達式，應(yīng)運而生。

? 什么是規(guī)則條件表達式：

它是多個模板組件使用限制內(nèi)容組合一起，生成一種可變的自定義表達式。參考借鑒逆波蘭表達式生成規(guī)則而設(shè)置。

? 如何生成：

創(chuàng)建優(yōu)惠券批次時，通過模板Id關(guān)聯(lián)出多個組件信息，封裝到數(shù)據(jù)模型中ListpropDtoList，然后根據(jù)條件表達式方法，篩選出組件prop.getType()類型，比如數(shù)值類型，獲取prop.getFlagword條件表達式關(guān)鍵字為coupon_cityid，prop.getFlagdesc=10010。拼裝生成條件表達式為：(coupon_cityid=10010)。生成使用描述為：限城市為北京使用。其他類型視條件生成表達式。示例如下：

 ? 舉車品券生成示例：

在創(chuàng)建優(yōu)惠券時，業(yè)務(wù)限定多條件表達式隨批次動態(tài)生成，舉例：車品券表達式：[coupon_city]_in(111010,120000)&&(coupon_[order]>10&&coupon_[order]<100)&&[coupon_tag]in(123),表達式條件翻譯為：優(yōu)惠券滿足城市北京或天津，訂單金額滿10元小于1000元，且優(yōu)惠券品類標(biāo)簽為123的商品使用，提交保存，生成優(yōu)惠券批次相關(guān)信息，生成驗證優(yōu)惠券表達式，存儲數(shù)據(jù)表中，及緩存中。

驗證券表達式條件，解析表達式代碼如下：

用戶下單使用券，系統(tǒng)校驗券的使用條件，由條件表達式多條件驗證，從用券接口取出訂單號，訂單金額，訂單商品，商家信息，運費服務(wù)費等作為檢驗條件，將請求參數(shù)存入Map字典中，驗證用戶優(yōu)惠券時，通過Map中對應(yīng)名稱，正則匹配組件中標(biāo)簽名、標(biāo)簽參數(shù)、操作符、操作數(shù)值進行標(biāo)簽名的替換，執(zhí)行commonBLL.EvalExpr表達條件運算，結(jié)果滿足條件，當(dāng)前券可進行下單結(jié)算使用。否則，將不能使用。

舉例，車品券表達式：

（[coupon_city]in(10110)&&(coupon_[order]>10&&coupon_[order]<100)&&[coupon_tag]in(123)），[coupon_city]:10110, coupon_[order]:20 , [coupon_tag]:123,最終替換為（10110=10110)&& 20>10 && 20<100 && 123 =123）。

表達式執(zhí)行完成后，生成訂單,省去傳統(tǒng)多個字段，循環(huán)迭代的邏輯驗證，有些字段關(guān)聯(lián)的屬性可能比較多，驗證的時候加載的時間會加長。有條件表達式，我們不用再做上面的多次驗證。只需要根據(jù)訂單參數(shù)，替換可變參數(shù)，執(zhí)行表達式規(guī)則計算，完成所需要的條件驗證。

4.3技術(shù)如何實現(xiàn)發(fā)券，限制超發(fā)并發(fā)

運營活動配置券包，客戶端進行活動發(fā)券。用戶登錄領(lǐng)券，領(lǐng)券接口驗證當(dāng)前請求參數(shù)，首先請求攔截進行簽名校驗，網(wǎng)關(guān)授權(quán)認證，并發(fā)管控請求限流桶，分布式Redis鎖。然后進行登錄用戶及風(fēng)控校驗，校驗通過，讀取活動關(guān)聯(lián)的批次券包，讀取用戶領(lǐng)券信息存入Redis中HashTable，通過領(lǐng)券信息HashMap集合進行批次限制校驗，包含新老用戶，批次是否停止使用，批次每天領(lǐng)取量，總的領(lǐng)取限制量，活動是否停止校驗，校驗通過后，組合領(lǐng)券基本信息，存入jetcache+redis 二級緩存中，然后異步發(fā)送MQ。MQ消費者讀取信息入庫，同時創(chuàng)建多線程進行同步通知第三方券入庫，領(lǐng)券完成。

解決的問題：

領(lǐng)取接口整個流程，增加分布式Redis鎖+請求限流桶，比如秒殺券活動，短時間會增加百萬+的流量，由于服務(wù)器數(shù)據(jù)承載響應(yīng)能力，帶寬流量有限，加入切面攔截請求，做容錯處理，同時加入分布式Redis原子鎖，進行并發(fā)控制，防止券因并發(fā)而超發(fā)的現(xiàn)象發(fā)生。同時驗證領(lǐng)取限制條件，解決了并發(fā)領(lǐng)取，權(quán)限領(lǐng)取，異步領(lǐng)取，攔截了一些風(fēng)險用戶，實時反饋給用戶領(lǐng)取結(jié)果信息。整個過程，從1級，2級緩存中讀取更新數(shù)據(jù)，根據(jù)后臺配置分層進行校驗，極大提高了請求的響應(yīng)速度，代碼更加簡潔，安全性、可擴展性、可維護性增強。

領(lǐng)券流程圖示如下：

圖 4-3-1

? 如何互斥？

一般在秒殺商品，直降商品，下單用券時，會進行拉取可用券列表時，對優(yōu)惠券列表先進行按金額排序 ，輪循驗證當(dāng)前券金額，與秒殺金額，直降金額進行比較，取最優(yōu)惠的價格給用戶展示使用。節(jié)省運營投入成本。

有時平臺券與商家券，如果都是平臺采購券的運營場景，也需要用互斥規(guī)則。分別拉取平臺券，與商家券可用券列表，再進行取最大的券進行比對。擇取優(yōu)惠力度最大券提供給用戶使用。

? 如何疊加?

平臺券與商家券，通常下單時，可以共同疊加使用。下單時，需要同時關(guān)聯(lián)兩張券的權(quán)益碼。兩張券同時變成核銷狀態(tài)。需要同時驗證訂單的總金額是否滿足券使用條件，一般用在滿減或湊單時使用。

? 如何平臺券轉(zhuǎn)發(fā)多家商家券?

車服務(wù)加油業(yè)務(wù)，油站屬于不同供應(yīng)商，運營采購多家供應(yīng)商的券，由于采購庫存有限。如何讓用戶在選擇油站用券時，僅能給用戶發(fā)一張商家券使用，不浪費采購庫存，又能促進業(yè)務(wù)拉新。我們在系統(tǒng)引用了平臺券關(guān)聯(lián)多商家券的模式，最終落地使用商家券。

比如：加油優(yōu)惠券模板，新增供應(yīng)商選擇組件，在運營后臺創(chuàng)建加油券時候，選擇關(guān)聯(lián)三家供應(yīng)商。用戶通過領(lǐng)券活動得到一張平臺券，這張平臺券使用條件限制了三家供應(yīng)商，用戶下單用這張券時，根據(jù)油站所屬供應(yīng)商，平臺券校驗當(dāng)前供應(yīng)商可用條件，校驗通過調(diào)用商家發(fā)券接口發(fā)對應(yīng)供應(yīng)商商家券，商家券核銷完成后，更新當(dāng)前平臺券。到此完成平臺券轉(zhuǎn)發(fā)商家券的邏輯。配置如圖所示：

圖 4-3-2

4.4技術(shù)如何實現(xiàn)用券驗券

 用戶請求下單，拉取用戶可用券，從緩存中取出用戶所有券，根據(jù)業(yè)務(wù)規(guī)則動態(tài)加載請求參數(shù)，比如加油券，驗證訂單金額，油品類型，供應(yīng)商，油站等條件，利用鍵值對key-value的形式，存儲請求參數(shù)，然后讀取每一張券的規(guī)則條件表達式。比如(coupon_seller in(12,23)) &&（[order]>=50）&&（oil_product=3)，通過正則表達式，取表達式中標(biāo)簽占位符，由鍵值對中獲取key值替換占位符，然后執(zhí)行表達式檢驗，完成驗券拉券過程。

用戶選擇券，進行創(chuàng)建訂單時，再次請求驗證當(dāng)前券，判斷表達式條件是否滿足，券是否過期，是否被停用，檢驗領(lǐng)券賬戶，防止被篡改。然后訂單表中鎖定當(dāng)前券碼。

用戶支付時，支付成功回調(diào)，再次驗證當(dāng)前券碼是否可用，核銷當(dāng)前券碼，券碼表中同時更新訂單號，使用時間，用券金額，券變更為核銷狀態(tài)。當(dāng)支付失敗，視訂單未完成，訂單將定時自動取消，券被歸還。

解決的問題：

接口中根據(jù)業(yè)務(wù)不同，用券的場景不同，傳遞的參數(shù)通過鍵值對形式動態(tài)傳遞。用于替代券條件表達式占位符，快速驗券。不用關(guān)心哪個業(yè)務(wù)，哪個條件進行固定判斷。完全依賴Key-value中請求參數(shù)，動態(tài)驗證，實現(xiàn)接口裝配。核銷的時候，訂單與券進行雙向綁定，增加安全性，可靠性。

用券流程圖示如下：

圖 4-4-1

5. 總結(jié) 

本系統(tǒng)將優(yōu)惠券業(yè)務(wù)進行了高度的提煉和抽象，將系統(tǒng)中的變與不變進行了完全隔離。

通過不斷的開發(fā)積累組件化控件，使得運營可以更靈活的設(shè)計營銷方案，極大的提高了代碼復(fù)用和系統(tǒng)靈活性和效率，優(yōu)惠券模板只需拖拽即可完成人機交互功能。

通過對優(yōu)惠券系統(tǒng)模板的高度提煉抽象，使其與業(yè)務(wù)系統(tǒng)完全解耦，從上面的介紹中我們可以看到，業(yè)務(wù)系統(tǒng)只有一個動作，整理配置屬性參數(shù)，獲取結(jié)果，除此之外，業(yè)務(wù)系統(tǒng)不需要知道優(yōu)惠券系統(tǒng)的任何其他細節(jié)，這就保證了兩個系統(tǒng)完全分離，分開開發(fā)、獨立部署，互不影響，提高開發(fā)效率和系統(tǒng)穩(wěn)定性。

本系統(tǒng)具有明顯的降低開發(fā)成本、提高開發(fā)效率、提升系統(tǒng)穩(wěn)定性的優(yōu)點。更重要的是提供完全開放的優(yōu)惠券可定義的控件，自由可變優(yōu)惠券模板生成，即使后期業(yè)務(wù)需求變更，也不會重新回歸測試開發(fā)。只需要修改模板條件。即可0開發(fā)成本新增優(yōu)惠券玩法，極大的滿足了運營頻繁多變的優(yōu)惠券營銷需求。

作者簡介

吳彥斌

■ 曾任職于服務(wù)端研發(fā)部-服務(wù)端買用技術(shù)團隊-用車組。

■  高級研發(fā)工程師，2015年加入公司，主要從事優(yōu)惠券系統(tǒng)的研發(fā)，訂單系統(tǒng)的研發(fā)，物流管理系統(tǒng)的研發(fā)。

張東生

■ 服務(wù)端研發(fā)部-服務(wù)端買用技術(shù)團隊-用車組。

■ 服務(wù)端買用技術(shù)團隊用車組組長，負責(zé)之家用戶用車場景的各用車服務(wù)權(quán)益產(chǎn)品及用車工具產(chǎn)品的研發(fā)和架構(gòu)工作。