编辑导语：OMS即订单管理中心，可以看作是电商系统的核心，其所需要具备的功能包括汇集数据、分发、跟踪汇总等等。那么，如何依据实际业务场景、搭建一个可支撑的、稳固强大的OMS系统？本文作者针对分布式场景下的OMS系统设计做了总结，一起来看一下。

最近对接了个微信公众号，access_token，open_id，带参二维码，事件推送，自定义菜单。做个记录。

微信官方文档 | 公众号：开发文档。

支付系统就一定需要对账，需要下载支付平台侧的账单与自己业务系统的交易数据时行对账。

YL行业支付前置平台交易账单：获取商户交易对账文件，根据请求头部serId和svcId来获取服务商和商户的对应文件。

支付系统就一定需要对账，需要下载支付平台侧的账单与自己业务系统的交易数据时行对账。

支付宝账单：为方便商户快速查账，支持商户通过本接口获取商户离线账单下载地址。

支付系统就一定需要对账，需要下载支付平台侧的账单与自己业务系统的交易数据时行对账。

微信账单：商户（支付通道）通过下载历史交易清单。比如掉单、系统错误等导致商户侧和微信侧数据不一致，通过对账单核对后可校正支付状态。

最近在做支付通道开发，需要对接微信和支付宝，银联，云闪付，各大银行等。

微信支付的开放接口对于开发者来说，相对支付宝并不那么友好，主要是有些小坑，开放文档描述的不够一致。

例如，同一个属性，返回的字段名与调起支付的字段名不一致，对开发者来说容易搞混。微信支付的 SDK 中定义为抽象的方法却使用 private 控制修饰符，导致外部不能重写。

最近先后接手了 2 个项目，接第一个项目觉的好乱，花了好几天略有理清；接第二个项目时觉的第一个项目还行，就这样认知底线又被突破。

一个没有规范化的团队和项目，项目经过多人多次迭代，简直是一团乱，属性、方法、表字段命名不规范，表关系设计不清晰，Mapper 层与业务强耦合，注释与实际功能不一致，业务包结构不规范，公共功能不抽出独立，新人接手难以通过代码快速了解业务，真是太糟糕了。

本篇基于个人在项目中遇到的以上原因而记录需要的规范。

重构了一个项目，项目相对复杂，对外提供了很多接口产品给第三方调用，也调用多个第三方的数据，数据结构各种格式都有，业务有用户、登录、产品、订单、预付费/扣费、报表、客户、财务、对账等十多项服务。由单一架构拆分成多个Spring Boot微服务,Spring Cloud做服务管理。

重构后的项目也许在架构上仍存在缺陷，但比之前的单一架构则有较大的改进，非常方便横向扩展，大大降低了业务系统之间的耦合。本篇记录下重构的思路。

重构的目的主要是解决问题，如果问题不存在则重构没有意义，如果重构没有解决问题那更没有意义还浪费资源带来不可预知的风险，主要问题有：

• 架构开发效率低，业务高耦合，难以扩展，不适合现在的业务体系。
• 系统功能和性能遇到了瓶颈，难以支撑高速扩展的业务。
• 代码不规范，难以理清逻辑，改动风险大，代价高。　　

Web管理后台绝大部分都会有左侧导航菜单功能，同时使用管理后台会有多组用户，每组用户所拥有的菜单权限是存在差异的，这就涉及到用户角色权限。

系统在设计时就需要考虑用户，角色，菜单三者之间的关系。如果一个用户有多种角色，则至少涉及5张表，如果一个用户只属于一种角色，则会涉及4张表。

项目中对订单号进行重新设计，参考了网上的方案加上自己的思路，根据不同的业务场景进行分析。