文档介绍：-
. z.
理工大学
工程硕士学位论文平安运行。
系统采用原理
系统中针对不同的接口要求不同。如 接口响应时间：直接内部接口<50 ms，有外部依赖接口<500ms。超时率：%
幂等性原理
在订单设计中首先要考虑的是重复订单问题。如用户不小心多点了两次，下了多个订单就不可靠了。针对一样的请求，相应一致性。
-
. z.
单一职责设计
一个功能的变化，在*一个时刻应该仅有一个引起变化的原因，这点引出了有限状态机原理。订单状态的设计采用了有限状态机原理，针对不同状态，采用起始状态+事件event，流转到目的状态的设计。减少了ifelse等繁琐方式。
多态模式
针对不同供给商接口的设计：多态模式，同一接口，实现方式不同，针对不同供给商的需求采用不同的实现类。减小代码耦合，降低下同负责度。
采用手段
故障迁移
单个实例发送故障后，踢出负载均衡，线下处理
如果单个set或者物理机发生故障，需要将相关的效劳器全部踢出负载均衡，这要求在配备效劳器的时候，每个中心效劳器分配到不同的set、不同的物理机上；如果单个idc发生故障，需要将前端所有流量导向另一个IDC。
重试机制
回调失败：支付平台有可能回调失败，一方面对方系统系有重试机制，另一方面订单支付系统会主动去查询；
供给商下单失败：针对供给商下单失败多种情况，采用定时重试机制，防止因为网络延时，系统异常等原因造成。
监控报警机制
针对外部依赖接口：通常添加监控机制，对于异常率报警机制，超时设置都有报警。及时处理出现的问题。
-
. z.
技术方案
整体设计
基于移动端和H5的订单系统，其前端分流和其他支付、风控、报警、监控等都为公司内部研发系统已成型。所有业务系统只需要关注自己业务线开发和配置。订单系统设计使用多效劳、多层构造和面向效劳的设计思想。依靠J2EE技术，使得系统具有与平台无关性、数据库无关性、应用效劳器具有无关性的高移植性。根据平台自身业务的特点，系统需要具有高度的水平扩展能力和垂直扩展能力，这就要求在平台搭建中必须要引入分层架构，各层次要求必须清晰、稳定。
手机app用户或H5用户的请求域名首先通过公司DNS，统一架构LVS进展分流转发到特定的ICDI中心，然后根据EFE随机选择一台订单tomact效劳。
对外提供api统一是 请求+json格式的请求。其中对于支付和退款的有公司特定的Payment〔支付系统〕调用，支付时有风控系统进展监控。客服和高级管理员操作的是MIS前端系统，mis统一调用mis系统。系统中发送短息和推送有对外的效劳。系