Java生鲜电商平台-微服务生鲜电商平台的订单设计架构实战(APP/小程序)
说明：生鲜电商系统中微服务订单的主要作用是从商品微服务中获取与订单相关的商品条目信息，进而完成对于订单数据的请求操作。
由于这里采用的是分布式的微服务架构，因而订单微服务中的商品条目信息是从两个商品微服务中以某种规则进行访问的。在开始本文之前，先学习下以下基础知识：
一、主流生鲜电商产品的订单状态
生鲜电商常见的订单状态主要有待付款、待发货、待收货、待评价、已关闭、以及退款中。
二、订单是什么
订单的本意是指你购买商品之后生成的单据凭证，只是在电商中，它是虚拟的。
主流的下单方式
整个电商体系中常见的下单方式有2种，购物车下单和直接下单。
淘宝称之为购物车结算和立即购买，正常情况下你可以任选一种去购物。但是在秒杀之类的特殊场景中，只支持直接下单。
京东也称之为购物车结算和立即购买，不同的是，正常情况下你必须通过购物车去结算，秒杀情况下你可以选择立即购买和购物车结算。
订单的类型
由于不同的下单方式，其实导致订单的类型有2种。
简单来说购物车结算的订单肯定包含了基于sku不同的多个子订单，而每个子订单包含n件同一sku。而立即购买的订单是包含n件同一sku。
然后淘宝的PM因为后续增加了购物车结算这一下单方式，而不得不想出一套规则，那就是父订单和子订单。当然还有很多其他原因。
此次购物，整体称之为交易，生成了一个父订单号。如果它是购物车结算，那么有N个子订单。如果他是立即购买，那么只有1个子订单。
从技术角度来定义，那就是trade称为父订单，order称为子订单，或者说trade是一笔交易单，子订单是每笔交易中的商品明细单，trade与order可以是一对多的关系，trade是由使用购物车生成。
当一笔交易只有一个子订单，那么tid=oid，这个时候主要看trade结构体里面的内容,当一笔交易有多笔子订单(类似于购物车购买方式)，那么tid=oid，这个时候主要看order结构体里面的内容。
三、订单的逻辑拆分
根据以上的规则，订单逻辑上面应该按照这样的方式来拆分。
+运费等等（根据自己的业务来定义）
基于这样的设计方式，才可以去支持退款退货，以及设计活动、优惠券等营销功能。
四、订单的金额拆分
进而得到订单的金额是如何拆分的，其中营销得来的优惠拆分到每一个子订单，以及每一个sku的实际支付单价。
五、订单状态机
订单的状态是一个很复杂的事情，决定着用户，商家的每一个操作。
不含退款退货
如果你们的商城比较特殊，无需提供退款退货功能，那么订单状态机比较简单。
六、总结
订单模块的架构设计，以上基本上把主要的内容讲了一遍。按照这样的方式去设计，至少可以兼顾大部分商城的订单需求。
以上内容可以点击我的订单模块原型来详细查看。
至于订单模块和商品模块，和营销模块的耦合，后续的文章会再讲讲。
主要讲讲生鲜电商服务端的架构设计以及商品呈现逻辑。可能对某些PM来说有点难理解，但是我认为这是设计商城系统的PM必须具备的架构能力，而且算是比较基础和底层的部分。
7. 代码与架构如何编写呢？
说明：基于springcloud alibaba做的微服务的订单架构设计，需要在实战中进行提高，可以根据自己的业务自己进行调整，切记生搬硬套.
8. 复盘与总结.
总结：
做互联网应用，无论是生鲜小程序还是APP，目的是为了留住与激活用户，形成用户购买力，提高满意度，最终达成交易的，当然本文只是抛砖引玉，希望本文可以给大家一点思考与建议。
微服务的更大的作用是项目的解耦，切记不要为了微服务而微服务。
QQ:137071249
共同学习QQ群：793305035