爱购商城（AIGO）是一套完整的电商业务项目，由两个系统组成：面向消费者的商城用户端（C 端），承载从注册登录、浏览商品、加购下单、支付收货到售后开票的整条购物链路；面向运营人员的运营管理后台（B 端），围绕商品、营销、订单与售后组织运营能力。

第 01 篇从业务视角看了这两套系统「做什么」，后续文章还会拆开它们的页面与接口面。这一篇先补上两者中间的「地基」：这些系统是用什么技术搭起来的、为什么这么选、在整体上怎样分层，以及它们实际上被部署成了什么样子。

这一篇我们我们讲 C 端所有流量的入口：商城网关。

第 01 篇拆了业务全景，第 02 篇讲了技术选型与整体分层，第 03 篇走到了所有 C 端请求的入口——网关。这一篇继续往里走一步，进入网关背后的五个领域服务：会员、商品、营销、购物车、搜索，看每个域里「模型长什么样、流程按什么规则走、请求在其中如何流转」。

这一篇进入整条链路上最重的一段——订单与交易域：从确认单、下单、支付、发货、收货，一直走到售后与发票。

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

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

这篇文章我们来讨论基于本地和Redis实现的二级缓存公共组件，它的定位很明确：在一次 cache-aside 读请求中，先查当前进程的 L1，再查 Redis L2，最后才调用业务 loader。组件同时处理了 TTL、并发回源、空结果、批量漏键、主动失效和指标，但没有把自己包装成一个完整的分布式缓存一致性系统。

这篇文章我们来讲讲订单状态的两个问题：

前面几篇文章已经把订单域、网关和端到端消息链路拆开了。支付是其中最容易被“一个支付接口”掩盖复杂度的部分：订单服务既要生成收银台或二维码，又要接收浏览器回跳和支付平台通知；支付结果还可能在回调、用户刷新、前端轮询之间重复到达。