管道模式在电商售后中的一点思考

背景介绍

首先介绍一下实体电商通用的售后流程。

1. 用户申请：在用户申请操作时需要填写退货、换货，以及原因。
2. 商家审核：商家会根据沟通情况审核售后申请。
3. 用户回寄：审核通过后需要用户回寄商品。
4. 确认退换：商家收货确认后会给用户退款或者邮寄新货。

虚拟商品的售后通用流程如下：

1. 管理员发起退换操作
2. 处理退换

• 退：先退货后退款
• 换：先退货后发货

在以上两个流程的处理流程有个共通的地方，就是一次操作需要涉及多个子流程的处理，这就是接下来需要讲的通用售后流程抽象。多个子流程的处理意味着要和多个子系统分别进行沟通处理退货、换货和退款。

这里就涉及到分布式系统的一致性问题了，售后模块作为资源的协调方，我们是否可以采用 TCC 的强一致性方案？答案是 No，成本有点高。普遍的做法是采用弱一致性方案保证最终一致性，我们可以考虑采用 Pipeline 机制。

概念比较

Pipeline 管道模式

在 Pipeline 机制中有三个基本概念：

• Pipeline 管道
• Valve 阀门
• Context 上下文数据

一个 Pipeline 管理多个 Valve，多个 Valve 共享一个 Context 数据。用类图来表达如下：