北里_中期报告模板

北京理工大学

工程硕士学位论文中期报告

学号:

姓名:

工程领域: 软件工程

兼职导师:

学校导师:

开题时间: 2016.11

研究生院学位办公室制表

二O一七年十月十六日

北京理工大学工程硕士学位论文中期检查考核表

专家组成员不得少于3名，专家应具有高级职称。

附论文中期检查报告正文部分。

1．论文工作进展情况

16年11月论文工作在老师的指导下已完成学位论文开题的程序，包括确定企业导师、填写“工程硕士学位论文选题申请表”、撰写“文献综述”、撰写“开题报告”等。

现正进行论文提纲的撰写工作，为了保证论文工作有效开展，前期进行了大量理论资料和相关技术总结，归纳了目前出现的技术问题及解决途径。由于以往订单系统中接单不及时，房客体验不佳，用户量流失。论文定位是提高用户体验度，提高CVR转化率。在设计方式上借鉴目前比较流行的有限状态机模式，并在现有基础进行优化。

综上，论文初稿于2017年11月完成。

2．论文工作中已采用的原理、手段、技术方案

该文设计中采用的基本原理有：

单一职责，订单状态流转采用有限状态机模式，摆脱了以往的if判断模式，根据目前状态和event事件，自动转向目标状态。

开放封闭原则：针对不同供应商的接口，接口设计采用多态模式，针对不同供应商实现自由模式，耦合度低。

幂等性：对于订单下单这块，幂等性要求比较严格，订单判重复要求幂等性设计。

技术方案：

数据库设计针对不同业务采用分库分表模式，数据耦合度降低。

程序上针对不同业务进行分模块部署，多模块集群部署，提高系统响应能力。

在安全性上，系统上游采用分流，防刷，监控等模式保证系统的安全运行。

2.1 系统采用原理

系统中针对不同的接口要求不同。如接口响应时间：直接内部接口<50 ms，有外部依赖接口<500ms。超时率：0.0001%

2.1.1幂等性原理

在订单设计中首先要考虑的是重复订单问题。如用户不小心多点了两次，下了多个订单就不可靠了。针对相同的请求，相应一致性。

2.1.2单一职责设计

一个功能的变化，在某一个时刻应该仅有一个引起变化的原因，这点引出了有限状态机原理。订单状态的设计采用了有限状态机原理，针对不同状态，采用起始状态+事件event，流转到目的状态的设计。减少了if else等繁琐方式。

2.1.3多态模式

针对不同供应商接口的设计：多态模式，同一接口，实现方式不同，针对不同供应商的需求采用不同的实现类。减小代码耦合，降低下同负责度。

2.2 采用手段

2.2.1故障迁移

单个实例发送故障后，踢出负载均衡，线下处理

如果单个set或者物理机发生故障，需要将相关的服务器全部踢出负载均衡，这要求在配备服务器的时候，每个中心服务器分配到不同的set、不同的物理机上；如果单个idc发生故障，需要将前端所有流量导向另一个IDC。

2.2.2重试机制

回调失败：支付平台有可能回调失败，一方面对方系统系有重试机制，另一方面订单支付系统会主动去查询；

供应商下单失败：针对供应商下单失败多种情况，采用定时重试机制，防止因为网络延时，系统异常等原因造成。

2.2.3监控报警机制

针对外部依赖接口：通常添加监控机制，对于异常率报警机制，超时设置都有报警。及时处理出现的问题。

2.3 技术方案

2.3.1整体设计

基于移动端和H5的订单系统，其前端分流和其他支付、风控、报警、监控等都为公司内部研发系统已成型。所有业务系统只需要关注自己业务线开发和配置。订单系统设计使用多服务、多层结构和面向服务的设计思想。依靠J2EE技术，使得系统具有与平台无关性、数据库无关性、应用服务器具有无关性的高移植性。根据平

台自身业务的特点，系统需要具有高度的水平扩展能力和垂直扩展能力，这就要求在平台搭建中必须要引入分层架构，各层次要求必须清晰、稳定。

手机app用户或H5用户的请求域名首先通过公司DNS，统一架构LVS进行分流转发到特定的ICDI中心，然后根据EFE随机选择一台订单tomact服务。

对外提供api统一是http请求+json格式的请求。其中对于支付和退款的有公司特定的Payment（支付系统）调用，支付时有风控系统进行监控。客服和高级管理员操作的是MIS前端系统，mis统一调用mis系统。系统中发送短息和推送有对外的服务。系统中大量使用了异步消息，异步消息避免线程堵塞、提高相应率。

订单系统的设计采用MVC和三层架构设计模式。

表现层使用MVC的设计模式，以及SpringMVC框架，支持BootStrap和Velocity 和FreeMaker展现

整体架构设计采用三层模式。BLL业务逻辑层以Spring的IOC为系统核心，面向接口编程，同时也使用了AOP的声明式事物。

DAO数据访问层支持DBCP，C3P0和各种web容器等多种数据库链接池，支持多种数据访问方式，如Mybatis，JDBC，Hibernate。

Model实体层为数据实体映射，将数据库数据映射为实体数据。

2.3.2数据库设计

针对不同业务，数据库设计采用分库分表模式。其中订单采用三层设计。

一个订单对应一个三层订单架构。

订单号是通过sequence进行生成，在分布式环境下，需要注意生成方式。

分布式环境下，数据库端sequence唯一性确认设计如

3．得到的结论、成果及新见解

本文制定出了具体的设计方法、设计原理及实现设计，为论文的顺利进行打下了坚实的基础。

总结出了针对该民俗订单类型的架构设计，同时优化了用户的体验度，使得房客与房东及时通信。

初步建立了订单系统模型，为进一步研究系统设计做好了准备。

4．存在的问题和拟采取的解决办法

4.1 如何保证幂等性问题是设计中常遇到的问题。

解决方式：下单这个流程幂等性通常是校验订单信息，交易号和规则，同时根据还要校验是否生成该订单，若生成该订单直接返回订单号，否则直接生产。若对外有唯一号则根据唯一号判断是否有生产该订单。

4.2 如何保证支付的可靠与安全。

解决方式：首先获取支付token

获取token接口，首先查询库里面，是否存在了token，如果不存在就调用payment 的接口，获取token，并且做存储到payrecord表中，然后将token返还给用户。

②、payment支付成功回调

app获取了token，跳转到艺龙收银台，用户进行支付，用户支付成功/支付失败