电商微服务业务架构拆分技巧

分享内容

1. 流程分析整理
2. 从表开始拆分系统
3. 常用抽象拆分方法
4. 总结

下面基于一个案例来说明微服务架构拆分的方法。

假设你现在是某行业知名电商的供货商，供应链比较长，而且供应品类和规格复杂。为确保生产计划平滑运转，系统还需要调配多个子工厂和材料商的生产排期。

原本调配订单需要电话沟通，但这样太过随机。为了保证生产链稳定供货，同时提高协调效率，朋友基于订单预订系统增加了排期协商功能，具体就是将 “排期” 作为下订单主流程里的一个步骤，并将协商出的排期按照日历样式来展示，方便上游供应商和各个工厂以此协调生产周期。

整个供货协商流程如下图所示：

​

如图，上游项目会先发布生产计划（或采购计划），供货商根据计划拆分采购列表（分单），并联系不同的工厂协调做预排期（预约排期）。之后，上游采购方对工厂产品进行质量审核，然后下单支付、确认排期。

工厂根据确认好的排期制定采购材料计划，并通知材料供货商分批供货，开始分批生产制造产品。每当制造好一批产品后，工厂就会通知物流按批次发货到采购方（即供货商），同时更新供货商系统内的分批订单信息。接着，上游对产品进行验收，将不合格的产品走退换流程。

但系统运行了一段时间后朋友发现，由于之前系统是以订单为主体的，增加排期功能后还是以主订单作为聚合根（即主要实体），这就导致上游在发布计划时需要创建主订单。而主订单一直处于开启状态，随着排期不断调整和新排期的不断加入，订单数据就会持续增加，一年内订单数据量达到了一亿多条。因为数据过多、合作周期长，并且包含了售后环节，所以这些数据无法根据时间做归档，导致整个系统变得越来越慢。

考虑到这是核心业务，如果持续存在问题影响巨大，如何对数据进行分表拆分?

其实这不是分表分库维护的问题，而是系统功能设计不合理导致了系统臃肿。于是经过沟通，我们决定对系统订单系统做一次领域拆分。

​

1 流程分析整理

我先梳理了主订单的 API 和流程，从上到下简单绘制了流程和订单系统的关系，如下图所示：

可以看到，有多个角色在使用这个“订单排期系统”。通过这张图与产品、研发团队进行沟通，来确认我理解的主要流程的数据走向和系统数据依赖关系都没有问题。

接着我们将目光放在了订单表上，订单表承载的职能过多，导致多个流程依赖订单表无法做数据维护，而且订单存在多个和订单业务无关的状态，比如排期周期很长，导致订单一直不能关闭。一个数据实体不要承担太多职能，否则很难管理，所以我们需要对订单和排期的主要实体职能进行拆分。

经过分析我们还发现了另一个问题，现在系统的核心并不是订单，而是计划排期。原订单系统在改造前是通过自动匹配功能实现上下游订单分单的，所以系统的主要模块都是围绕订单来流转的。而增加排期功能后，系统的核心就从围绕订单实现匹配分单，转变成了围绕排期产生订单的模式，这更符合业务需要。

排期和订单有关联关系，但职能上有不同的方向用途，排期只是计划，而订单只为工厂后续生产运输和上游核对结果使用。这意味着系统的模块和表的设计核心已经发生了偏移，我们需要拆分模块才能拥有更好的灵活性。

综上所述，我们总体的拆分思路是：要将排期流程和订单交付流程完全拆分开。要知道在创业公司，我们做的项目一开始的设计初衷常常会因为市场需求变化，逐渐偏离原有设计，这就需要我们不断重新审视我们的系统，持续改进，才能保证系统的完善。

因为担心研发团队摆脱不了原有系统的思维定势，拆分做得不彻底，导致改版失败，所以我对角色和流程做了一次梳理，明确了各个角色的职责和流程之间的关系。我按角色及其所需动作画出多个框，将他们需要做的动作和数据流穿插起来，如下图所示：

基于这个图，我再次与研发、产品沟通，找出了订单与排期在功能和数据上的拆分点。具体来讲，就是将上游的职能拆分为：发布进货计划、收货排期、下单、收货/退换； 而供货商主要做协调排期分单，同时提供订单相关服务；工厂则主要负责生产排期、生产和售后。这样一来，系统的流程就可以归类成几个阶段：

1.计划排期协调阶段- 2.按排期生产供货+周期物流交付阶段- 3.售后服务调换阶段

可以看到，第一个阶段不牵扯订单，主要是上游和多个工厂的排期协调；第二、三阶段是工厂生产供货和售后，这些服务需要和订单交互，而上游、工厂和物流的视角是完全不同的。

基于这个结论，我们完全可以根据数据的主要实体和主要业务流程（订单 ID 做聚合根， 将流程分为订单和排期两个领域）将系统拆分成两个子系统：排期调度系统、订单交付系统。

在计划排期协调阶段，上游先在排期调度系统内提交进货计划和收货排期，然后供货商根据上游的排期情况和进货需求，与多家合作工厂协调分单和议价。多方达成一致后， 上游对计划排期和工厂生产排期进行预占。