分库分表实战：最初的我们—了解一下单库外卖订单系统

​​上一期内容我们整体了解了分库分表实战项目当前使用的分库分表系统架构​​，也就是实战单库版本订单系统的系统架构。同时，最初我们也知道了未来要做的单库订单分库分表版本的订单系统架构。现在，解下我们就从单库版本的外卖订单系统开始，一步一步的系统来进行优化。

如果想要优化单库版本的分库分表订单系统，首先要了解目前的实战订单系统有哪些核心功能，核心功能的最初业务流程是什么。

如果你刚入职了这家初创型互联网公司，单库订单而你所在的解下部门又刚好是做外卖APP的订单系统的，那你认为入职之后要干的外卖第一件事是什么呢？

必须是了解整个订单系统，你的系统leader可能会直接给你发个wiki，这个wiki中包含了单库版本的网站模板分库分表系统架构图，如下图：

通过这张系统架构图，可以知道整个订单系统目前有哪些核心功能，都使用了哪些技术栈。

并且，在这个wiki中除了有系统架构图之外，还有很多核心接口的业务流程图，通过这些业务流程图，可以快速了解到订单系统核心接口的业务流程。

那订单系统中，有哪些核心接口的业务流程图？现在，我们一起来看一下。

大家或多或少都是点过外卖的，订单系统涉及用户和商家两个角色的功能，先来看一下C端，即用户端的一些业务流程，首先就是用户下单的操作。

用户可以在外卖APP中点外卖，当用户选中一个商品之后，会提交订单，接着就会发起一个创建订单的请求，如下图：

可以看到，创建订单的WordPress模板请求首先会转发给Controller组件，Controller组件再把请求交给Service组件处理，在Service组件中会先生成一个订单号，然后为新的订单组装好订单信息以及订单明细信息。

随后，Service组件再将组装好的订单信息转交给Repository组件处理，Repository组件通过Mapper组件，最终将订单的信息保存到数据库中。

当然，用户正式下单之后，是需要支付订单的，但是支付相关的功能，这里可以暂时不用关注。

当用户完成下单之后，用户可能要看一下自己曾经下过哪些订单，所以，订单系统还支持订单列表查询，如下图：

可以看到，用户可以向外卖订单系统，发起一个查询订单列表的请求，请求同样先转发到Controller组件上，因为是查询订单列表的信息，所以我们只需要传递查询的免费信息发布网参数即可。

然后，Controller组件会把请求参数，通过Service组件传到Repository组件上，然后Repository组件可以调用Mapper组件的接口，再到数据库中查询用户的所有订单信息，查询结果最后会形成一个订单列表，最后一步步返回给用户。

最终，用户就可以从订单列表中，看到自己下过的所有订单信息了。

如果用户还想要看下某个订单里面的详细信息，此时业务流程图如下所示：

可以看到，查询订单明细请求会先转发到Controller组件上，然后Controller组件把请求交给Service组件处理。

随后，Service组件携带着订单号，将查询订单明细的请求交给Repository组件来查询，Repository组件根据订单号调用Mapper组件的接口，接口会到数据库中查询订单及订单明细的信息，最后将查询出来的订单明细信息返回给用户。

另外，用户下单之后也是支持取消订单的，当用户要取消一个订单时，也会发送一个取消订单的请求，如下图：

如所有请求一样，取消订单的请求首先发送给Controller组件，Controller组件会将请求交给Service组件处理，Service组件会把需要取消订单的订单号发送给Repository组件，Repository组件拿着订单号调用Mapper组件中的接口，更新订单将订单取消掉。

现在，外卖订单系统中，C端也就是用户端的一些操作我们已经了解了，而B端也就是商家的功能，和用户端的功能是比较类似的。

商家也会查看订单列表以及订单的明细信息，而且，当用户下单之后，商家可以选择接单或者拒接，一旦商家选择接单，那么订单状态就会变为“已接单”，这些功能在我们的外卖订单系统中都是支持的。

最后，在这个wiki中不仅有一堆的流程图，还有订单系统代码仓库的Git地址，然后你将代码拉到本地，接着，你一边看着这些wiki中的业务流程图，一边慢慢开始熟悉起来了代码......

最新评论