1、北京理工大學(xué)工程碩士學(xué)位論文中期報(bào)告 學(xué) 號(hào): 姓 名: 工程領(lǐng)域: 軟件工程 兼職導(dǎo)師: 學(xué)校導(dǎo)師: 開(kāi)題時(shí)間: 2016.11 研究生院學(xué)位辦公室制表二O一 七 年 十 月 十六 日兼職指導(dǎo)教師審核意見(jiàn)（根據(jù)前期工作情況，綜合介紹學(xué)員的研究能力、工作量、工作態(tài)度及論文工作現(xiàn)狀和能否達(dá)到預(yù)期目標(biāo)等） 兼職指導(dǎo)教師簽字： 年 月 日學(xué)校指導(dǎo)教師審核意見(jiàn)（重點(diǎn)審核論文工作內(nèi)容及進(jìn)展是否符合碩士學(xué)位論文的基本要求和開(kāi)題報(bào)告的工作計(jì)劃） 指導(dǎo)教師簽字: 年 月 日北京理工大學(xué)工程碩士學(xué)位論文中期檢查考核表姓 名入學(xué)時(shí)間2016.3工程領(lǐng)域軟件工程論文題目項(xiàng)目來(lái)源公司業(yè)務(wù)專 家 組 成 員姓 名職 稱

2、工 作 單 位學(xué)術(shù)專長(zhǎng)簽 字專 家 組 意 見(jiàn)所做內(nèi)容是否符合開(kāi)題報(bào)告的要求課題進(jìn)展是否正常論文工作可否繼續(xù)進(jìn)行中期檢查結(jié)果（ ）通過(guò)， （ ）基本通過(guò)， （ ）不通過(guò)專家評(píng)語(yǔ)：專家組組長(zhǎng)簽字： 年 月 日專家組成員不得少于3名，專家應(yīng)具有高級(jí)職稱。附論文中期檢查報(bào)告正文部分。論文工作進(jìn)展情況16年11月論文工作在老師的指導(dǎo)下已完成學(xué)位論文開(kāi)題的程序，包括確定企業(yè)導(dǎo)師、填寫“工程碩士學(xué)位論文選題申請(qǐng)表”、撰寫“文獻(xiàn)綜述”、撰寫“開(kāi)題報(bào)告”等。現(xiàn)正進(jìn)行論文提綱的撰寫工作，為了保證論文工作有效開(kāi)展，前期進(jìn)行了大量理論資料和相關(guān)技術(shù)總結(jié)，歸納了目前出現(xiàn)的技術(shù)問(wèn)題及解決途徑。由于以往訂單系統(tǒng)中接單不及

3、時(shí)，房客體驗(yàn)不佳，用戶量流失。論文定位是提高用戶體驗(yàn)度，提高CVR轉(zhuǎn)化率。在設(shè)計(jì)方式上借鑒目前比較流行的有限狀態(tài)機(jī)模式，并在現(xiàn)有基礎(chǔ)進(jìn)行優(yōu)化。綜上，論文初稿于2017年11月完成。論文工作中已采用的原理、手段、技術(shù)方案該文設(shè)計(jì)中采用的基本原理有：?jiǎn)我宦氊?zé)，訂單狀態(tài)流轉(zhuǎn)采用有限狀態(tài)機(jī)模式，擺脫了以往的if判斷模式，根據(jù)目前狀態(tài)和event事件，自動(dòng)轉(zhuǎn)向目標(biāo)狀態(tài)。開(kāi)放封閉原則：針對(duì)不同供應(yīng)商的接口，接口設(shè)計(jì)采用多態(tài)模式，針對(duì)不同供應(yīng)商實(shí)現(xiàn)自由模式，耦合度低。冪等性：對(duì)于訂單下單這塊，冪等性要求比較嚴(yán)格，訂單判重復(fù)要求冪等性設(shè)計(jì)。技術(shù)方案：數(shù)據(jù)庫(kù)設(shè)計(jì)針對(duì)不同業(yè)務(wù)采用分庫(kù)分表模式，數(shù)據(jù)耦合度降低。程序

4、上針對(duì)不同業(yè)務(wù)進(jìn)行分模塊部署，多模塊集群部署，提高系統(tǒng)響應(yīng)能力。在安全性上，系統(tǒng)上游采用分流，防刷，監(jiān)控等模式保證系統(tǒng)的安全運(yùn)行。系統(tǒng)采用原理系統(tǒng)中針對(duì)不同的接口要求不同。如 接口響應(yīng)時(shí)間：直接內(nèi)部接口50 ms，有外部依賴接口500ms。超時(shí)率：0.0001%冪等性原理在訂單設(shè)計(jì)中首先要考慮的是重復(fù)訂單問(wèn)題。如用戶不小心多點(diǎn)了兩次，下了多個(gè)訂單就不可靠了。針對(duì)相同的請(qǐng)求，相應(yīng)一致性。單一職責(zé)設(shè)計(jì)一個(gè)功能的變化，在某一個(gè)時(shí)刻應(yīng)該僅有一個(gè)引起變化的原因，這點(diǎn)引出了有限狀態(tài)機(jī)原理。訂單狀態(tài)的設(shè)計(jì)采用了有限狀態(tài)機(jī)原理，針對(duì)不同狀態(tài)，采用起始狀態(tài)+事件event，流轉(zhuǎn)到目的狀態(tài)的設(shè)計(jì)。減少了if el

5、se等繁瑣方式。多態(tài)模式針對(duì)不同供應(yīng)商接口的設(shè)計(jì)：多態(tài)模式，同一接口，實(shí)現(xiàn)方式不同，針對(duì)不同供應(yīng)商的需求采用不同的實(shí)現(xiàn)類。減小代碼耦合，降低下同負(fù)責(zé)度。采用手段故障遷移單個(gè)實(shí)例發(fā)送故障后，踢出負(fù)載均衡，線下處理如果單個(gè)set或者物理機(jī)發(fā)生故障，需要將相關(guān)的服務(wù)器全部踢出負(fù)載均衡，這要求在配備服務(wù)器的時(shí)候，每個(gè)中心服務(wù)器分配到不同的set、不同的物理機(jī)上；如果單個(gè)idc發(fā)生故障，需要將前端所有流量導(dǎo)向另一個(gè)IDC。重試機(jī)制回調(diào)失敗：支付平臺(tái)有可能回調(diào)失敗，一方面對(duì)方系統(tǒng)系有重試機(jī)制，另一方面訂單支付系統(tǒng)會(huì)主動(dòng)去查詢；供應(yīng)商下單失敗：針對(duì)供應(yīng)商下單失敗多種情況，采用定時(shí)重試機(jī)制，防止因?yàn)榫W(wǎng)絡(luò)延時(shí)，

6、系統(tǒng)異常等原因造成。監(jiān)控報(bào)警機(jī)制針對(duì)外部依賴接口：通常添加監(jiān)控機(jī)制，對(duì)于異常率報(bào)警機(jī)制，超時(shí)設(shè)置都有報(bào)警。及時(shí)處理出現(xiàn)的問(wèn)題。技術(shù)方案整體設(shè)計(jì)基于移動(dòng)端和H5的訂單系統(tǒng)，其前端分流和其他支付、風(fēng)控、報(bào)警、監(jiān)控等都為公司內(nèi)部研發(fā)系統(tǒng)已成型。所有業(yè)務(wù)系統(tǒng)只需要關(guān)注自己業(yè)務(wù)線開(kāi)發(fā)和配置。訂單系統(tǒng)設(shè)計(jì)使用多服務(wù)、多層結(jié)構(gòu)和面向服務(wù)的設(shè)計(jì)思想。依靠J2EE技術(shù)，使得系統(tǒng)具有與平臺(tái)無(wú)關(guān)性、數(shù)據(jù)庫(kù)無(wú)關(guān)性、應(yīng)用服務(wù)器具有無(wú)關(guān)性的高移植性。根據(jù)平臺(tái)自身業(yè)務(wù)的特點(diǎn)，系統(tǒng)需要具有高度的水平擴(kuò)展能力和垂直擴(kuò)展能力，這就要求在平臺(tái)搭建中必須要引入分層架構(gòu)，各層次要求必須清晰、穩(wěn)定。手機(jī)app用戶或H5用戶的請(qǐng)求域名首先

7、通過(guò)公司DNS，統(tǒng)一架構(gòu)LVS進(jìn)行分流轉(zhuǎn)發(fā)到特定的ICDI中心，然后根據(jù)EFE隨機(jī)選擇一臺(tái)訂單tomact服務(wù)。對(duì)外提供api統(tǒng)一是http請(qǐng)求+json格式的請(qǐng)求。其中對(duì)于支付和退款的有公司特定的Payment（支付系統(tǒng)）調(diào)用，支付時(shí)有風(fēng)控系統(tǒng)進(jìn)行監(jiān)控。客服和高級(jí)管理員操作的是MIS前端系統(tǒng)，mis統(tǒng)一調(diào)用mis系統(tǒng)。系統(tǒng)中發(fā)送短息和推送有對(duì)外的服務(wù)。系統(tǒng)中大量使用了異步消息，異步消息避免線程堵塞、提高相應(yīng)率。訂單系統(tǒng)的設(shè)計(jì)采用MVC和三層架構(gòu)設(shè)計(jì)模式。表現(xiàn)層使用MVC的設(shè)計(jì)模式，以及SpringMVC框架，支持BootStrap和Velocity和FreeMaker展現(xiàn)整體架構(gòu)設(shè)計(jì)采用三層

8、模式。BLL業(yè)務(wù)邏輯層以Spring的IOC為系統(tǒng)核心，面向接口編程，同時(shí)也使用了AOP的聲明式事物。DAO數(shù)據(jù)訪問(wèn)層支持DBCP，C3P0和各種web容器等多種數(shù)據(jù)庫(kù)鏈接池，支持多種數(shù)據(jù)訪問(wèn)方式，如Mybatis，JDBC，Hibernate。Model實(shí)體層為數(shù)據(jù)實(shí)體映射，將數(shù)據(jù)庫(kù)數(shù)據(jù)映射為實(shí)體數(shù)據(jù)。數(shù)據(jù)庫(kù)設(shè)計(jì)針對(duì)不同業(yè)務(wù)，數(shù)據(jù)庫(kù)設(shè)計(jì)采用分庫(kù)分表模式。其中訂單采用三層設(shè)計(jì)。一個(gè)訂單對(duì)應(yīng)一個(gè)三層訂單架構(gòu)。訂單號(hào)是通過(guò)sequence進(jìn)行生成，在分布式環(huán)境下，需要注意生成方式。分布式環(huán)境下，數(shù)據(jù)庫(kù)端sequence唯一性確認(rèn)設(shè)計(jì)如得到的結(jié)論、成果及新見(jiàn)解本文制定出了具體的設(shè)計(jì)方法、設(shè)計(jì)原理及實(shí)

9、現(xiàn)設(shè)計(jì)，為論文的順利進(jìn)行打下了堅(jiān)實(shí)的基礎(chǔ)。總結(jié)出了針對(duì)該民俗訂單類型的架構(gòu)設(shè)計(jì)，同時(shí)優(yōu)化了用戶的體驗(yàn)度，使得房客與房東及時(shí)通信。初步建立了訂單系統(tǒng)模型，為進(jìn)一步研究系統(tǒng)設(shè)計(jì)做好了準(zhǔn)備。存在的問(wèn)題和擬采取的解決辦法如何保證冪等性問(wèn)題是設(shè)計(jì)中常遇到的問(wèn)題。解決方式：下單這個(gè)流程冪等性通常是校驗(yàn)訂單信息，交易號(hào)和規(guī)則，同時(shí)根據(jù)還要校驗(yàn)是否生成該訂單，若生成該訂單直接返回訂單號(hào)，否則直接生產(chǎn)。若對(duì)外有唯一號(hào)則根據(jù)唯一號(hào)判斷是否有生產(chǎn)該訂單。如何保證支付的可靠與安全。解決方式：首先獲取支付token獲取token接口，首先查詢庫(kù)里面，是否存在了token，如果不存在就調(diào)用payment的接口，獲取tok

10、en，并且做存儲(chǔ)到payrecord表中，然后將token返還給用戶。、payment支付成功回調(diào)app獲取了token，跳轉(zhuǎn)到藝龍收銀臺(tái)，用戶進(jìn)行支付，用戶支付成功/支付失敗以后，payment回調(diào)訂單對(duì)做相關(guān)的業(yè)務(wù)處理。支付成功，如果訂單為新單狀態(tài)，那么更改訂單狀態(tài)為；如果訂單狀態(tài)為接單成功狀態(tài)，那么更改訂單狀態(tài)。支付失敗：更改訂單狀態(tài).異步給房東和房客發(fā)相關(guān)狀態(tài)更改短。、payment退款成功回調(diào)通過(guò)批處理，向payment發(fā)起退款通知，payment退款成功后，通知訂單，更改payrecord當(dāng)前訂單退款處理狀態(tài)，并且異步給用戶發(fā)送退款成功短信。狀態(tài)機(jī)如何資助流轉(zhuǎn)根據(jù)有限狀態(tài)流轉(zhuǎn)原理，初始狀態(tài)+事件=目的狀態(tài)。利用SpringIOC 容器和反射原