该项目主要分为两个发展阶段。

第一阶段使用spring mvc搭建单体应用，为了方便功能迭代和技术人员水平参差不齐，规范开发流程、接口文档和开发规范。当前阶段使用的技术比较少，主要为后期服务化做准备。准备内容主要有几个方面。1、总体规划方面，利用maven进行功能模块化管理，构建自有的手脚架。主要分成分成用户模块、商品模块、库存模块、订单模块、积分模块、搜索模块、支付模块、公共组件模块、基础核心模块等组件模块，对相应表结构的命名及规范。2、业务方面，对业务闭环的梳理。如用户模块的用户体系，有会员体系，后台管理体系，商户体系三大体系的用户和商户等级，操作权限，数据权限的设计又或者支付模块中支付流程账单流程等的关键性业务流程的梳理。3、技术方面，做了以下准备，如读写分离，多级缓存，sql监控，分布式锁，rocketmq消息队列，log日志规范，利用explain对mysql进行相关优化，JVM调优包括大对象代码的优化、耗时线程的阻塞代码判断。

第二阶段电商系统服务化，该阶段涉及的相关组件有，如dubbo服务调用负载组件，其中使用了hystrix补充了dubbo对熔断和限流方面的不足，zk注册中心，skywalking作为trace跟踪组件，prometheus+grafna作为metric监控跟踪组件，EFK作为统一日志收集组件等。

用户体系系统包含单点登录子系统，会员体系子系统，商户体系子系统；

商品库存系统包含商品系统，库存系统，抢购系统等商品相关功能；

金融支付系统包含订单系统，支付系统，对账系统，积分系统，优惠券系统；

期间涉及到的技术点包括，水平分库分表，历史分销库的平滑表扩容，分布式锁，接口网关等相关分布式系统架构知识。

other模块主要配合第三方组件进行改造，如mybatis读写分离，rocketmq客户端，分布式缓存组件，分布式锁，公共日志组件，分布式事务等

子系统

1、单点登录系统

主要是根据认证中心对用户认证状态进行管理，使用redis存储用户状态，302进行登录跳转。

2、最终一致性分布式事务模块组件，该组件主要用于支付过程中的各个订单，支付流水，积分，库存等用户状态的一致性。以支付流程为例，

2.1、用户下单后根据用户选择的积分方式和优惠券生成一笔主订单号和多笔商户订单号。

2.2、用户将主订单号发送给支付系统，支付系统向mq发送待确认后，在本地生成一笔支付流水并根据用户支付方式调用第三方支付。

2.3、等第三方支付异步回调后，变更订单状态和支付流水状态，同时发起积分和优惠券的预扣减。

该流程主要有几个问题

1、订单系统和库存系统等会有预扣减库存的操作，

2、下游支付系统支付失败需要订单系统等其他系统回滚的接口

3、各个系统需要提供查询消息状态的接口

4、各个接口需要保证其幂等性操作，解决方案是唯一业务标识作为查询和重复判断。

5、消息确认子系统和消息回复子系统需要有容灾的，解决方案利用了zk的临时节点。

3、支付系统

主要根据不同支付渠道，目前公司对接的有支付宝、微信和渤海银行，三种对接渠道。向内网提供统一支付接口，根据CAP原理，使用支付需要注意业务接口的幂等性，事务等问题。

这里主要的解决方案使用的是消息中间件rabbitmq实现的事务最终一致性，主要有两个子系统，消息确认子系统和消息恢复子系统来保证事务一致性和完整性。当前两个子系统的主要实现方式使用的是zk做容灾的定时查询匹配对事务消息进行补发。

4、对账系统

需求分析，前期对账，主要是人工对账。后期由于业务扩展，手工对账已经不现实。

对账系统整体设计主要分为三个模块，数据处理模块，对账模块，异常数据处理模块。

数据处理模块，主要根据不同支付渠道获取的对账文件的方式不同编写的获取方式，然后统一成对应的待对账数据格式，主要包含，商户类型、商户订单号、流水号、交易日期、交易金额、手续费、退款金额，原订单号等关键数据。这里主要要注意允许多次获取对账数据，且保证对账数据不可重复。

对账模块，主要是通过订单号核对支付或退款金额是否一致。

异常数据处理模块，主要是由上一步对账模块产生异常数据，如我方多账或对方多账进行数据数据校验。主要产生异常数据的常见原因有几个方面，1、与切割日期有关；2、订单状态更新不及时，也有金额不一致的情况，这种情况一般都是手工对账。可能跟优惠券和积分系统的扣减不及时有关，进行相应的积分