安全能力重构 | D002篇 一张电商架构图，用户点击购买后发生了什么

原创

陈看山
陈看山

安全诸子

2026年11月8日 18:03
上海

去阅读

所属模块：模块一 · 安全能力重构365天 · 第1周 企业技术环境与业务系统全景

很多安全同学第一次拿到电商架构图，习惯性去找“哪里能打”：登录口、支付回调、订单查询接口。但真要问“用户点下购买按钮之后，系统里到底发生了什么”，却说不清楚。说不清楚的直接后果是：你看到的“漏洞”只是某个孤立接口的问题，而业务方关心的是钱有没有丢、订单会不会重复、库存会不会超卖。这两套语言对不上，评审会上就只能互相耗着。

这篇是安全能力重构系列的第 2 天。上一篇我们聊了为什么安全工程师要先问业务。这一篇把视角落到一张图上：D002 一张电商架构图，D002 一张电商架构图，用户点击购买后发生了什么。它不是让你背组件清单，而是让你建立一张能跟研发、运维、业务对话的“全景底图”。本篇按产品/工具观察的思路写：这张图解决什么问题、适合谁、代价是什么、怎么接进现有流程。

先给定位：它不是架构文档，是“链路共识图”

市面上的架构图大致分两类。一类是给领导看的部署拓扑，画的是机房、集群、网络分区；另一类是给研发看的模块依赖，画的是服务调用关系。这两类图有个共同问题：安全同学看完，仍然不知道一次购买行为穿过了哪些信任边界。

这里说的“一张电商架构图”，定位是第三种东西：以一次用户行为为主线，把入口层、应用层、数据层、外部依赖串起来的链路图。它不追求组件齐全，追求的是“对象和关系可辨认”——用户、会话、订单、库存、支付单、消息队列，谁产生、谁消费、谁落库、谁对账。

判断标准很朴素：把这张图给一个没参与过项目的安全同学看，他能在十分钟内说出“如果我要在授权靶场里模拟一次异常下单，我需要关注哪几个环节”。说不出，图就没画对。

它解决的核心矛盾：安全视角和业务视角各说各话

真实场景里，矛盾通常长这样。研发说“下单接口做了幂等”，安全说“我测到重复提交能生成两笔订单”。吵到最后发现，研发说的是应用层幂等，安全测的是网关重试加客户端重复点击叠加后的效果，中间还隔着一层消息队列的重复消费。谁都没错，但没人把链路拉直看一遍。

这张图要解决的就是这个：把“一次点击”拆成可讨论的段落，让每一段的责任方、数据形态、失败模式都摆到台面上。拆完之后你会发现，很多所谓的安全问题，本质是链路某一段的语义没对齐。

具体拆法建议按“动作发生的位置”切，而不是按技术栈切。一次购买大致会经过：浏览器或 App 发起请求、接入层做路由和限流、业务服务校验和编排、库存与订单落库、支付渠道交互、异步消息驱动后续动作、对账与补偿兜底。每一段都问三个问题：这里有什么对象、对象之间什么关系、这一段失败了下游会怎样。

基于当前可见信息，这里不给具体公司的真实链路，只给一个脱敏模拟场景下的通用切法。你在自己环境里画的时候，组件名可以替换，但分段逻辑可以直接复用。

拆开看：一次点击穿过的几段链路

第一段是入口。用户点击购买，最先发生的是请求进入接入层。这一段的关键对象是会话、令牌、请求参数。安全上关心的是身份是否可信、参数是否被篡改、频率是否异常。但要注意，这一段的问题往往被下游放大：入口没拦住的重放，可能在下单环节变成重复订单。

第二段是业务编排。订单服务通常不自己干所有事，它要调商品、调价格、调库存、调优惠。这一段是关系最密集的地方，也是画图时最容易画糊的地方。建议只画“谁同步调谁、谁异步通知谁”，同步调用标实线，异步消息标虚线。这一条约定能省掉后面大量争论。

第三段是数据落库。订单、库存、支付单往往不在一个库，甚至不在一个存储引擎。这一段要标清楚哪些写操作是强一致要求，哪些可以最终一致。安全视角在这里关心的不是“有没有注入”，而是“越权读写会不会跨过业务边界”。

第四段是外部依赖。支付渠道、短信、物流查询，这些是信任边界之外的部分。画图时要把它们画在图的最外侧，并标注“返回值不可全信”。很多订单状态错乱，根子是把外部回调当成了可信输入。

第五段是异步与补偿。消息队列、定时对账、失败重试，这一段在部署拓扑图里经常被省略，但它恰恰是“钱和货对不上”的高发区。图画到这里，才算把一次点击讲完整。

能力点、场景与代价，放在一张表里看

下面这张表是给“要不要在自己的团队里推这张图”做判断用的。左边是这张图能提供的具体能力，右边是接入的现实成本。别只看能力，成本那一列才是决定它能不能活下来的关键。

从表里能看出一个判断：这张图的价值不在“画得漂亮”，而在“逼着各方把关系说清楚”。它的成本主要不是画图时间，而是协调成本。如果团队里没人愿意花半天跟安全对齐链路，这张图推不动。

和老做法比，差别在哪

老做法通常有两种。一种是直接看代码或接口文档，从实现反推链路。优点是细，缺点是慢，而且容易陷进某个服务的实现细节，看不到全局。另一种是看运维的部署图，优点是环境清楚，缺点是它回答不了“一次购买经过了哪些业务对象”。

这张链路图的差别在于：它以行为为轴，天然对齐业务语言。你跟业务方说“下单到支付这段”，他立刻能接话；你跟运维说“这一段走了异步”，他也知道该看哪个中间件。代价是它不精确到接口级别，需要配合接口文档一起用。

还有一个现实差别：老做法往往是安全单方面输出，研发被动配合。这张图如果画得好，研发会发现它对自己排查问题也有用，配合意愿会明显不一样。这不是情怀，是利益对齐。

真实限制：它不适合什么，做错会怎样

第一，它不适合替代详细设计。图上的一个方框背后可能是一个几十个接口的服务，别指望用它做代码级评审。

第二，它对“非主链路”覆盖弱。退款、售后、优惠叠加这些分支，如果全画上去，图会迅速失控。建议主图只画购买主链路，分支另开小图。

第三，也是最容易做错的地方：把图画成“组件堆砌”。见过不少图，方框里写满中间件名字，箭头乱飞，但看不出一次请求的流向。这种图对安全判断没有帮助，反而制造“我们已经有架构图了”的错觉。做错的代价是评审时大家对着图各说各话，比没有图更耗时间。

第四，脱敏边界要守住。本篇所有讨论都基于本地授权靶场和虚构公司场景，图里不应出现真实 IP、内部域名、凭据信息。这不是形式要求，而是这张图一旦流出，本身就是攻击面说明书。

怎么接进现有流程

接入建议从最小闭环开始，别一上来就搞全公司架构治理。

第一步，选一条主链路，通常是“浏览到下单到支付”。找一名熟悉这块的研发，花半天把对象和关系画出来，只画到能辨认的程度。

第二步，在图上标三类标记：信任边界、异步环节、外部依赖。这三类标记直接对应后续的安全评审关注点。

第三步，把图上的核心对象整理成一份核心业务清单，作为资产梳理的输入。清单不用长，能覆盖订单、库存、支付、用户会话这几个关键对象即可。

第四步，在下次涉及这条链路的评审或靶场演练前，把图拿出来对一遍。用不上就说明画偏了，及时改。

这套流程的产出是两张东西：一张企业技术环境全景图的主链路版本，一份核心业务清单。它们不追求一次到位，追求的是每次讨论都能往上叠一点。

给读者的实践建议

如果你打算动手，建议本周内完成一件事：在你的授权靶场或脱敏模拟环境里，画一张只包含购买主链路的简图，限定一页纸，方框不超过十五个。画完做两个自检：一是能不能指着图说清楚“重复点击会在哪一段被拦住”，二是能不能指出“哪一段的失败会导致订单和支付状态不一致”。两个都能答上来，这张图就及格了。

下一阶段再考虑扩展分支链路和细化对象清单。记住这张图的定位：它是共识工具，不是文档工程。判断值不值得继续投入的标准只有一个——它有没有让安全、研发、业务在同一个问题上少吵半小时。

下一步动作：把这张图带到你最近一次安全评审里，看它能不能替代掉你原本要讲的三页 PPT。能替代，就留下；不能，就回来改图，而不是加 PPT。