这一篇文章我们来介绍这个项目的重要角色：管理后台。它既不是 C 端商城的另一个页面，也不是订单服务的简单管理界面，而是一套面向运营人员的 B 端系统。

前面的文章已经从业务和链路角度介绍过 B 端管理后台。这一篇文章我们来看看一个后台管理的请求，究竟如何从 Gin 路由走到 Service、Repository、DAO 和具体的 MySQL 实例；订单状态消息如何进入后台并按版本收敛；物流策略、秒杀填充和物流同步又分别由谁负责。

这一篇主要解决一个问题：如果第三方服务迟早可能更换，代码应该把“可替换”放在哪里？

这篇主要梳理项目中的异步任务：主请求先把必须完成的事实写下来，积分、投影、自动收货、超时关单和售后处理再沿着 MQ 或定时任务继续推进。

这一篇我们讲讲：消息队列客户端到底应该依赖什么。

前面几篇文章分别拆过网关、会员、商品、订单和管理端。如果只从单个服务的角度看，系统像是一组相互独立的 CRUD；但用户真正经历的是一条连续链路：注册或登录，浏览商品，加购，下单，支付，等待积分和成长值到账，查看投放卡片，等待发货和物流，确认收货，最后可能进入售后或开票。