北里-中期報告模板

北京理工大學工程碩士學位論文中期報告學 號： 姓 名： 工程領域： 軟件工程 兼職導師： 學校導師： 開題時間： 2016.11研究生院學位辦公室制表二O一七年十月十六日

北京理工大學工程碩士學位論文中期檢查考核表姓名入學時間 2016.3工程領域軟件工程論文題目項目來源公司業(yè)務專家組成員姓名職稱工作單位學術(shù)專長簽字專家組意見所做內(nèi)容是否符合開題報告的要求課題進展是否正常論文工作可否繼續(xù)進行中期檢查結(jié)果 （ ）通過，（ ）基本通過， （）不通過專家評語：專家組組長簽字： 年 月日專家組成員不得少于3名，專家應具有高級職稱。附論文中期檢查報告正文部分。北京理工大學工程碩士學位論文中期報告論文工作進展情況16年11月論文工作在老師的指導下已完成學位論文開題的程序，包括確定企業(yè)導師、填寫“工程碩士學位論文選題申請表”、撰寫“文獻綜述”、撰寫“開題報告”等。現(xiàn)正進行論文提綱的撰寫工作，為了保證論文工作有效開展，前期進行了大量理論資料和相關技術(shù)總結(jié)，歸納了目前出現(xiàn)的技術(shù)問題及解決途徑。由于以往訂單系統(tǒng)中接單不及時，房客體驗不佳，用戶量流失。論文定位是提高用戶體驗度，提高CVR轉(zhuǎn)化率。在設計方式上借鑒目前比較流行的有限狀態(tài)機模式，并在現(xiàn)有基礎進行優(yōu)化。綜上，論文初稿于2017年11月完成。論文工作中已采用的原理、手段、技術(shù)方案該文設計中采用的基本原理有：單一職責，訂單狀態(tài)流轉(zhuǎn)采用有限狀態(tài)機模式，擺脫了以往的if判斷模式，根據(jù)目前狀態(tài)和event事件，自動轉(zhuǎn)向目標狀態(tài)。開放封閉原則：針對不同供應商的接口，接口設計采用多態(tài)模式，針對不同供應商實現(xiàn)自由模式，耦合度低。冪等性：對于訂單下單這塊，冪等性要求比較嚴格，訂單判重復要求冪等性設計。技術(shù)方案：數(shù)據(jù)庫設計針對不同業(yè)務采用分庫分表模式，數(shù)據(jù)耦合度降低。程序上針對不同業(yè)務進行分模塊部署，多模塊集群部署，提高系統(tǒng)響應能力。在安全性上，系統(tǒng)上游采用分流，防刷，監(jiān)控等模式保證系統(tǒng)的安全運行。系統(tǒng)采用原理系統(tǒng)中針對不同的接口要求不同。如接口響應時間：直接內(nèi)部接口<50ms,有外部依賴接口<500ms。超時率：0.0001%北京理工大學工程碩士學位論文中期報告冪等性原理在訂單設計中首先要考慮的是重復訂單問題。如用戶不小心多點了兩次，下了多個訂單就不可靠了。針對相同的請求，相應一致性。單一職責設計一個功能的變化，在某一個時刻應該僅有一個引起變化的原因，這點引出了有限狀態(tài)機原理。訂單狀態(tài)的設計采用了有限狀態(tài)機原理，針對不同狀態(tài)，采用起始狀態(tài)+事件event，流轉(zhuǎn)到目的狀態(tài)的設計。減少了ifelse等繁瑣方式。多態(tài)模式針對不同供應商接口的設計：多態(tài)模式，同一接口，實現(xiàn)方式不同，針對不同供應商的需求采用不同的實現(xiàn)類。減小代碼耦合，降低下同負責度。采用手段故障遷移單個實例發(fā)送故障后，踢出負載均衡，線下處理如果單個set或者物理機發(fā)生故障，需要將相關的服務器全部踢出負載均衡，這要求在配備服務器的時候，每個中心服務器分配到不同的set、不同的物理機上；如果單個idc發(fā)生故障，需要將前端所有流量導向另一個IDC。重試機制回調(diào)失?。褐Ц镀脚_有可能回調(diào)失敗，一方面對方系統(tǒng)系有重試機制，另一方面訂單支付系統(tǒng)會主動去查詢；供應商下單失?。横槍滔聠问《喾N情況，采用定時重試機制，防止因為網(wǎng)絡延時，系統(tǒng)異常等原因造成。北京理工大學工程碩士學位論文中期報告監(jiān)控報警機制針對外部依賴接口：通常添加監(jiān)控機制，對于異常率報警機制，超時設置都有報警。及時處理出現(xiàn)的問題。技術(shù)方案整體設計基于移動端和H5的訂單系統(tǒng)，其前端分流和其他支付、風控、報警、監(jiān)控等都為公司內(nèi)部研發(fā)系統(tǒng)已成型。所有業(yè)務系統(tǒng)只需要關注自己業(yè)務線開發(fā)和配置。訂單系統(tǒng)設計使用多服務、多層結(jié)構(gòu)和面向服務的設計思想。依靠J2EE技術(shù)，使得系統(tǒng)具有與平臺無關性、數(shù)據(jù)庫無關性、應用服務器具有無關性的高移植性。根據(jù)平臺自身業(yè)務的特點，系統(tǒng)需要具有高度的水平擴展能力和垂直擴展能力，這就要求在平臺搭建中必須要引入分層架構(gòu)，各層次要求必須清晰、穩(wěn)定。手機app用戶或H5用戶的請求域名首先通過公司DNS，統(tǒng)一架構(gòu)LVS進行分流轉(zhuǎn)發(fā)到特定的ICDI中心，然后根據(jù)EFE隨機選擇一臺訂單tomact服務。對外提供api統(tǒng)一是http請求+json格式的請求。其中對于支付和退款的有公司特定的Payment（支付系統(tǒng)）調(diào)用，支付時有風控系統(tǒng)進行監(jiān)控。客服和高級管理員操作的是MIS前端系統(tǒng)，mis統(tǒng)一調(diào)用mis系統(tǒng)。系統(tǒng)中發(fā)送短息和推送有對外的服務。系統(tǒng)中大量使用了異步消息，異步消息避免線程堵塞、提高相應率。訂單系統(tǒng)的設計采用MVC和三層架構(gòu)設計模式。表現(xiàn)層使用MVC的設計模式，以及SpringMVC框架，支持BootStrap和Velocity和FreeMaker展現(xiàn)整體架構(gòu)設計采用三層模式。BLL業(yè)務邏輯層以Spring的IOC為系統(tǒng)核心，面向接口編程，同時也使用了AOP的聲明式事物。DAO數(shù)據(jù)訪問層支持DBCP，C3P0和各種web容器等多種數(shù)據(jù)庫鏈接池，支持多種數(shù)據(jù)訪問方式，如Mybatis，JDBC，HibernateoModel實體層為數(shù)據(jù)實體映射，將數(shù)據(jù)庫數(shù)據(jù)映射為實體數(shù)據(jù)。3北京理工大學工程碩士學位論文中期報告數(shù)據(jù)庫設計針對不同業(yè)務，數(shù)據(jù)庫設計采用分庫分表模式。其中訂單采用三層設計。一個訂單對應一個三層訂單架構(gòu)。訂單號是通過sequence進行生成，在分布式環(huán)境下，需要注意生成方式。分布式環(huán)境下，數(shù)據(jù)庫端sequence唯一性確認設計如得到的結(jié)論、成果及新見解本文制定出了具體的設計方法、設計原理及實現(xiàn)設計，為論文的順利進行打下了堅實的基礎?？偨Y(jié)出了針對該民俗訂單類型的架構(gòu)設計，同時優(yōu)化了用戶的體驗度，使得房客與房東及時通信。初步建立了訂單系統(tǒng)模型，為進一步研究系統(tǒng)設計做好了準備。存在的問題和擬采取的解決辦法如何保證冪等性問題是設計中常遇到的問題。解決方式：下單這個流程冪等性通常是校驗訂單信息，交易號和規(guī)則，同時根據(jù)還要校驗是否生成該訂單，若生成該訂單直接返回訂單號，否則直接生產(chǎn)。若對外有唯一號則根據(jù)唯一號判斷是否有生產(chǎn)該訂單。如何保證支付的可靠與安全。解決方式：首先獲取支付token獲取token接口，首先查詢庫里面，是否存在了token,如果不存在就調(diào)用payment的接口，獲取token,并且做存儲到payrecord表中，然后將token返還給用戶。②、payment支付成功回調(diào)app獲取了token,跳轉(zhuǎn)到藝龍收銀臺，用戶進行支付，用戶支付成功支付失敗北京理工大學工程碩士學位論文中期報告以后，payment回調(diào)訂單對做相關的業(yè)務處理。支付成功，如果訂單為新單狀態(tài)，那么更改訂單狀態(tài)為；如果訂單狀態(tài)為接單成功狀態(tài)，那么更改訂單狀態(tài)。支付失?。焊挠唵螤顟B(tài).異步給房東和房客發(fā)相關狀態(tài)更改短。③、payment退款成功回調(diào)通過批處理，向payment發(fā)起退款通知，payment退款成功后，通知訂單，更改payrecord當前訂單退款處理狀態(tài)，并且異步給用戶發(fā)送退款成功短信。狀態(tài)機如何資助流轉(zhuǎn)根據(jù)有限狀態(tài)流轉(zhuǎn)原理，初始狀態(tài)+事件=目的狀態(tài)。利用SpringlOC容器和反射原理