java项目介绍

电商

订单服务：订单流程

***订单流程

订单流程是指从订单产生到完成整个流转的过程，从而行程了一套标准流程规则。而不同的产品类型或业务类型在系统中的流程会千差万别，比如上面提到的线上实物订单和虚拟订单的流程，线上实物订单与 O2O 订单等，所以需要根据不同的类型进行构建订单流程。不管类型如何订单都包括正向流程和逆向流程，对应的场景就是购买商品和退换货流程，正向流程就是一个正常的网购步骤：

订单生成–>支付订单–>卖家发货–>确认收货–>交易成功。而每个步骤的背后，订单是如何在多系统之间交互流转的，可概括如下图

订单业务流程
1.商品详情页面—点击立即购买或加入购物车，此时会将购买的商品存入redis
2.如果是立即购买会自动跳转至商品结算页面，如果是加入购物车，需要进入购物车页面点击结算，跳转至商品结算页面
3.商品结算页面—获取结算详情(总价格，优惠活动等)
4.商品结算页面—用户设置收货地址、支付类型、发票、送货时间等参数信息。
5.商品结算页面—点击提交订单，此时进行交易入库和订单入库
1、订单创建与支付
(1) 、订单创建前需要预览订单，选择收货信息等
(2) 、订单创建需要锁定库存，库存有才可创建，否则不能创建
(3) 、订单创建后超时未支付需要解锁库存
(4) 、支付成功后，需要进行拆单，根据商品打包方式，所在仓库，物流等进行拆单
(5) 、支付的每笔流水都需要记录，以待查账
(6) 、订单创建，支付成功等状态都需要给 MQ 发送消息，方便其他系统感知订阅

通过统一收单交易支付接口（‌条码支付）‌，‌当输入付款码后，‌接口调用成功后订单即创建。‌

拆单操作

在电商系统中，‌当用户将不同商家主体的商品加入购物车并一起下单时，‌这些商品会按照不同的商家主体进行拆分，‌形成不同的订单，‌即拆单操作。‌这种拆分是基于商家主体的不同，‌而不是基于物流或财务的维度。‌
拆单操作主要解决的是财务和物流两个维度的问题。‌财务维度上的拆单关注于是否可以将多次购买行为合并成一个父订单，‌而物流维度则关注于同一个父订单中的商品是否可以放在同一个包裹中。‌拆单的指标包括商品体积、‌数量、‌存储条件、‌仓库位置、‌供应商等。‌每个父订单可以有多个子订单，‌子订单的信息包括父订单Id、‌子订单Id、‌skuId、‌购买数量、‌sku单价、‌分摊后平台优惠金额、‌分摊后店铺优惠金额、‌分摊后用户权益抵扣金额、‌实付金额、‌供应商、‌订单状态等

2、逆向流程
(1) 、修改订单，用户没有提交订单，可以对订单一些信息进行修改，比如配送信息， 优惠信息，及其他一些订单可修改范围的内容，此时只需对数据进行变更即可。
(2) 、订单取消，用户主动取消订单和用户超时未支付，两种情况下订单都会取消订 单，而超时情况是系统自动关闭订单，所以在订单支付的响应机制上面要做支付的限时处理，尤其是在前面说的下单减库存的情形下面，可以保证快速的释放库存。 另外需要需要处理的是促销优惠中使用的优惠券，权益等视平台规则，进行相应补 回给用户。

(3) 、退款，在待发货订单状态下取消订单时，分为缺货退款和用户申请退款。如果是 全部退款则订单更新为关闭状态，若只是做部分退款则订单仍需进行进行，同时生 成一条退款的售后订单，走退款流程。退款金额需原路返回用户的账户。

(4) 、发货后的退款，发生在仓储货物配送，在配送过程中商品遗失，用户拒收，用户收货后对商品不满意，这样情况下用户发起退款的售后诉求后，需要商户进行退款的审核，双方达成一致后，系统更新退款状态，对订单进行退款操作，金额原路返回用户的账户，同时关闭原订单数据。仅退款情况下暂不考虑仓库系统变化。如果发生双方协调不一致情况下，可以申请平台客服介入。在退款订单商户不处理的情况下，系统需要做限期判断，比如 5 天商户不处理，退款单自动变更同意退款。

基于redis实现扣减库存的具体实现

我们使用redis的lua脚本来实现扣减库存

由于是分布式环境下所以还需要一个分布式锁来控制只能有一个服务去初始化库存

需要提供一个回调函数，在初始化库存的时候去调用这个函数获取初始化库存

将库存放到缓存，利用redis的incrby特性来扣减库存，解决了超扣和性能问题。但是一旦缓存丢失需要考虑恢复方案。比

订单业务

1、订单体系

订单体系从角色上看，主要涉及：用户、商户、平台三个核心参与方，其订单流程的搭建就是围绕三方的交易场景展开；

这里需要说明一些细节：商户可以是第三方商家，也可以是平台方自己，不影响概念上的划分；商品也存在多种形式，所以用交付来描述，可以覆盖物流的定义；

用户：通过应用端，进行商品的选择和下单；
平台：实现订单交易链路和支付能力，以及对整个流程的调度；
商户：提供商品和交付能力

2、流程管理

2.1 流程拆分
订单的业务属性是极高的，流程本身也比较复杂，从不同的参与方来看，其流程分段策略完全不一样，这里仅站位研发视角，把订单逻辑分为：创建、支付、交付三个阶段；

分库分表

数据在到达一定体量之后，需要进行分库分表的操作，从而解决各种性能方面的问题；将订单数据按照特定的维度进行计算，从而将数据分流到不同的库表中，解决读和写的瓶颈；

基于订单ID计算拆分的逻辑是最常见的，在特殊情况下，也会基于用户ID或商户ID进行计算，从而将相关的数据堆放在一起，如果有必要，也可以考虑多维度拆分的多写模式；

数据同步

订单数据分库分表虽然解决存储问题，但是也带来了很多查询方面的阻碍，通过搜索引擎来解决查询问题也是常用的技术选型；
订单数据在库和搜索引擎之间同步的方法有很多：
同步双写，对数据的实时性要求极高；
异步解耦，流程存在轻微的延迟；
定时任务，存在明显的时效问题；
组件同步，采用第三方数据同步组件；订单场景的话推荐同步双写的方式。

订单服务有那些接口

电商订单微服务包括订单创建、查询、管理等接口。在现代电商平台中，订单微服务是其核心组成部分，负责处理与订单相关的各种业务操作。具体分析如下：

1. 订单创建接口：

   • 用户通过购物车或直接选购进行下单操作，接口需要处理商品库存的锁定与订单的生成。
   • 订单创建时，需要进行支付类型的选择（如支付宝、微信支付等），并对接相应的支付服务接口。

2. 订单查询接口：

   • 提供订单列表查询，包括用户的订单历史和当前订单状态。
   • 订单详情查询，展示订单的具体商品信息、数量、价格等。

3. 订单管理接口：

   • 允许用户进行订单的修改，比如添加或删除订单中的商品、修改收货地址等。
   • 支持订单的取消与退款操作，并与支付微服务交互实现资金的回流。

4. 订单物流跟踪接口：

   • 提供实时的物流信息跟踪，包括配送状态更新和预计送达时间。
   • 支持用户确认收货功能，以及在有问题时的物流投诉功能。

5. 订单评价接口：

   • 用户完成购物后，可以通过此接口对购买的商品进行评价。
   • 收集用户的评价数据，供后续消费者参考及商家改进服务。

除了以上对电商订单微服务的接口的介绍外，在实际应用中还需考虑其他因素：

• 高可用性设计：确保订单微服务能够处理高并发请求，通过负载均衡、服务熔断等机制提高系统稳定性。
• 安全性保证：涉及到用户敏感数据的接口，如支付、个人信息等，需要特别关注数据加密和接口安全。
• 可扩展性和灵活度：订单微服务应易于扩展与维护，以支持快速变化的商业需求和技术演进。

总的来说，订单微服务在电商平台中承担着极其重要的角色，它不仅需要处理复杂的业务逻辑，还要与其他服务如商品、用户、支付等密切协作，共同构成一个高效、稳定的电商生态系统。