前阵子带团队梳理供应链系统的架构有个同学交上来一张系统架构图几十个方框每个方框里写着系统名线条从最左边密密麻麻连到最右边。看起来很“全面”但评审的时候大家面面相觑——没人能说清楚这张图到底想表达什么。这是很多团队画系统架构图的通病把“画图”理解成“把框框用线连起来”却没有意识到架构图本质上是一个团队对系统的认知投影。这篇文章我就以供应链系统为例从零开始聊怎么画出一张合格的系统架构图它要回答哪些问题、按什么顺序画、画到什么程度算合格以及为什么说画图的过程本身才是你真正收获项目认知的地方。1. 画图之前先搞清楚架构图到底在表达什么1.1 架构图不是框线图是团队认知的投影我见过太多人一上来就打开绘图工具边画边想画到哪算哪。结果往往是图越画越复杂人越画越糊涂。正确的顺序应该是倒过来的先用文字把系统想清楚再动手画图。系统架构图本质上是一次“降维表达”把系统里最关键的组成部分、它们之间的协作关系、数据流转路径压缩到一页纸以内让任何一个人都能在几分钟内建立起对系统的整体认知。拿装修来类比一下。装修时设计师会给你出效果图、平面布局图、水电点位图、吊顶尺寸图每种图解决不同的问题。系统架构图也一样它不是一个万能图而是一类图的统称。如果你拿着一张水电图去问橱柜颜色那显然是问错了对象。很多画得很糟糕的架构图问题不在于画工而在于作者根本不清楚自己画的是什么类型的图、要回答什么问题、给谁看。一张合格架构图的底层作用只有一个让团队对系统的认知对齐。开发人员看它理解模块归属新同学看它快速上手业务方看它确认流程覆盖技术负责人看它评估扩展性。如果一张图没法承载这些作用那它画得再漂亮也是废纸。所以动笔之前先花十分钟问自己三个问题这张图给谁看要回答什么问题系统的边界在哪里1.2 供应链场景下先分清四种架构图系统架构相关的图其实有好几种很多人混着画画着画着就“四不像”了。我在供应链项目中经常遇到的情况是一张图里既有子系统划分又有数据库表名还标着服务器IP和端口。这种图本质上什么都没说清楚。为了避免这个问题请先认清楚下面四类图图类型核心关注点典型读者供应链场景举例业务架构图业务流程、角色、单据流转业务方、产品经理采购入库流程、销售出库流程系统/应用架构图子系统划分、模块职责、接口调用关系开发、架构评审、技术负责人采购中心与库存中心的调用关系部署架构图物理节点、网络、容器、中间件实例运维、DBA订单服务部署了几台机器、Redis集群拓扑数据架构图数据实体、数据模型、数据流向数据开发、后端开发库存流水表、订单表、结算表之间的关系本文讲的“系统架构图”特指第二类应用架构图。它描述的是“系统由哪些模块组成模块之间怎么协作”而不是“代码部署在哪台机器上”。这点先立住后面很多坑都能避开。供应链系统是典型的强流程型业务一张合格的系统架构图几乎都要沿着“计划—采购—入库—库存—订单—履约—结算”这条主链路展开先有业务这根主轴图才不会散。1.3 以供应链系统为例画图前的业务认知地图在打开任何绘图工具之前我强烈建议你先用一张表格把供应链系统的业务认知地图搭出来。所谓“从零构建项目认知”第一步不是画系统架构图而是把业务主干走一遍知道钱、货、单据是怎么流动的。我通常会把供应链系统拆成八个业务环节来看供应商管理供应商准入、资质、评级、配额采购管理采购计划、采购下单、到货跟踪、异常处理入库管理收货、质检、上架、入库单确认库存管理库存查询、库存占用、库存流水、盘点、安全库存订单履约订单接收、拆单、分配仓库、波次拣货、出库物流协同运单、轨迹回传、配送异常对账结算应付应收、发票、账单核对退货售后退货入库、退款、质量追溯每个业务环节背后都对应着系统里的一个或几个模块。如果你拿到的是一个已经存在的供应链系统画图前的调研工作就是把每个环节对应的代码模块、接口、数据表找出来标注“业务环节→系统模块”的映射关系。这一步很枯燥但恰恰是最有认知增量的地方因为你会开始明白业务上的一个“收货动作”技术上可能涉及采购单状态流转、质检任务生成、库存预占、库存流水写入、消息通知等多个技术点。先把这张“业务认知地图”填写完整再来谈画图。地图没建好图画出来一定是一盘散沙。2. 供应链系统架构拆解把复杂业务切成可绘制的模块2.1 核心子系统划分沿着单据走主链路供应链系统最大的特点是“单据驱动”。从采购订单到入库单从销售订单到出库单从结算单到发票每一笔业务都靠单据串联。所以在划分系统模块时最自然的做法就是沿着单据流转方向把强相关的业务聚合到一起形成领域边界。我常用的划分方式如下表子系统/中心职责一句话核心单据/模型商品中心维护SKU、品类、价格、条码商品、SKU、价格表采购中心供应商协同、采购订单管理采购订单、收货单库存中心库存查询、预占、扣减、流水库存、库存流水、库存快照订单中心订单模型、拆单合单、状态机订单、订单条目、状态变更记录履约中心仓库分配、波次、出库指令履约单、波次、出库单结算中心对账、计费、应付应收结算单、账单、发票基础数据/权限组织、用户、角色、字典用户、角色、组织你可能注意到我把“商品中心”也列进来了因为供应链系统几乎都离不开商品主数据。但要注意商品中心在很多企业里也承担着多渠道发布的职责所以画图前要和团队确认清楚“商品”这个模块到底划在供应链系统内部还是归属更大的主数据平台。这看起来是个小问题却直接决定你的系统边界画在哪。沿着主链路切分模块还有一个明显的好处依赖关系好梳理。正常情况下订单中心依赖库存中心履约中心依赖库存中心和订单中心结算中心依赖采购和履约的单据。这种单向依赖画出来很清爽不会出现“圈圈绕”的循环依赖。如果画图时发现两个中心必须互相调用那通常说明边界切得不对值得重新讨论。2.2 分层视角接入层、服务层、数据层与横切组件模块划分解决的是“有哪些子系统”接下来还要解决“系统按什么层次组织”。供应链系统很少是单一平面结构我一般会在架构图层级上体现四层加一组横切组件接入层Web管理端、商家端、开放API接口、对外Webhook应用服务层订单服务、采购服务、库存服务等业务服务基础服务层权限认证、消息通知、文件存储、任务调度、配置中心数据层业务数据库、缓存、消息队列、搜索引擎、日志存储横切组件网关、日志链路、监控告警、分布式事务举个例子接入层通过API网关统一接入所有上游请求网关负责鉴权、限流、路由这是供应链系统对外提供开放能力时的咽喉。应用服务层才是业务逻辑的载体采购服务负责生成采购订单库存服务负责处理库存预占和扣减。基础设施层解决的是通用问题比如定时任务每天凌晨扫描超时未入库的采购单发消息提醒跟单员。这里有一个关键点分层是逻辑概念不是物理部署。你可以在一个代码仓库里同时包含“采购服务”和“库存服务”的代码模块架构图上仍然可以画成两个逻辑服务。千万不要把架构图的分层和部署图的主机、容器混为一谈。我见过有人把“Redis集群”“MySQL主从”画在系统架构图的正中间标注着IP地址结果整张图彻底变成了一张部署图谁也没法从里面看清业务逻辑。2.3 单体还是微服务不要画一张实现不了的架构图很多同学一听到“架构图”就想画微服务仿佛不画出一堆服务、网关、注册中心、配置中心就不够高级。但在供应链系统里微服务不是目的而是手段。选型必须基于团队规模、业务复杂度、发布频率和基础设施成熟度来决策不能拍脑袋。我个人通常这么判断如果团队只有十几二十个人供应链系统虽然业务链条长但每个环节的内部复杂度还没有高到需要独立团队维护的程度那么“模块化单体”是最务实的方案。代码里按模块分好目录数据库可以分库系统架构图上按逻辑模块画但不需要画注册中心。如果订单、库存、采购、结算已经分别由不同团队负责且各自独立部署、独立发布那么才有必要把架构图拆成多个服务节点并补充服务注册、网关、配置中心等基础设施。如果公司有现成的微服务基座统一脚手架那可以顺势而为但也要避免“为了微服务而微服务”。供应链系统里面库存扣减和订单状态流转一旦拆成跨服务调用事务一致性会变成非常棘手的问题。开源社区有很多快速开发框架比如你打开芋道这类集成度很高的脚手架项目的文档都能看到它自带的系统架构图通常是“网关层—服务层—基础设施层”的结构并且会附带模块依赖关系图。这类参考图最大的价值在于帮你建立标准的画图范式明白分层怎么分、横切组件放哪里、模块命名怎么统一。但切记不要照搬因为几个人的团队和几十个人的团队对架构图的表达粒度是不同的。你的架构图必须和你真实要交付的架构一致画一张团队实现不了的微服务架构图评审的时候一定被问倒。3. 手把手绘制一版“合格”的供应链系统架构图3.1 第一步先画外部系统与角色边界供应链系统几乎不可能独立存在它一定会和外部系统打交道。画图的第一步是把外部角色和外部系统立在边界外侧。常见的包括供应商侧的供应商门户或供应商系统上游的ERP系统或财务系统仓储侧的WMS仓储管理系统物流侧的TMS运输管理系统电商前台或商家运营后台支付网关或银行接口这一步的核心动作是画一条明确的“系统边界”把外部系统和内部系统分开。外部系统在边界外内部子系统在边界内。边界线一定要画得醒目因为它表达了一个重要判断哪些能力是自研的哪些是第三方提供的。比如很多供应链系统的“物流轨迹”并不自研而是接TMS但“订单履约调度”往往是自研核心能力。边界分明架构的取舍就一目了然。有个细节要提醒外部系统不要画太多字段细节比如“供应商系统”就是一个框最多标个“采购单下发/对账接口”不要在里面画供应商系统的内部模块。架构图关注的是你的系统和别人的系统之间的协作点不是别人的内部结构。3.2 第二步放入域内子系统定义职责与依赖接着把2.1里梳理的子系统摆进边界内。摆放顺序我建议从左到右或从上到下沿着主链路走比如商品中心—采购中心—库存中心—订单中心—履约中心—结算中心。这样看图的人能顺着方向把业务讲下来不会迷路。摆好框之后逐个定义依赖关系。这里说的依赖是指在运行时“谁调用谁”。依赖关系是画图时最需要克制的部分也是大多数图画坏的地方。我给自己定的规矩是每个子系统画一句职责描述不超过15个字写不清就说明边界没定好依赖线必须有箭头没箭头等于没画线旁边如果可以标注调用类型HTTP接口、消息、事件效果会更好先画主链路依赖再画旁路依赖最后还纠缠不清的依赖回到边界讨论中去比如采购中心依赖基础数据中心的供应商信息但采购中心不应该直接改库存数据它通过入库动作触发库存中心的接收接口。这种“通过事件/接口协作”而不是“直接改库”的原则一定要在架构图上体现出来。如果发现采购中心直接依赖库存中心的数据库表这张图画不出来不说真实代码里也一定是隐患。3.3 第三步标注核心链路与数据流向系统架构图虽然不像业务流程图那样把每个节点画出来但为了让人看懂通常要标注三条左右的核心链路。我会在架构图下方或者图的一侧用简短的文字标注链路走向。供应链系统里必须有的三条链路是链路名称起点关键流转节点终点采购入库链路供应商门户采购中心→收货/质检→库存中心入库单、库存增加、对账销售出库链路电商前台/商家后台订单中心→库存中心→履约中心→WMS出库单、物流单、签收补货链路销售预测/库存分析库存中心→采购中心建议补货单、采购订单这第三条链路补货链路很多架构图会漏掉但实际上它是供应链系统里连接“库存”和“采购”的隐性闭环。没有这条链路的架构图只能算“能跑通的单据链条图”算不上完整的供应链系统架构图。数据流向标注要注意一致性。比如“库存扣减”这条线正确画法是从订单中心发请求到库存中心库存中心先“预占”履约后“扣减”失败则“释放”。如果图上只是简单一条订单中心→库存中心的箭头别人会默认成“调一次接口就完事”那对库存一致性的理解就漏掉了。所以在核心链路上可以用文字附注的方式补充关键约束不用画得很细但要把关键机制点出来。3.4 第四步补充中间件与基础组件业务服务和外部系统画完后把中间件和基础组件放进图的最底层。供应链系统常见的基础组件是这几类MySQL集群存订单、库存、采购等核心业务数据Redis做热点库存缓存、分布式锁、会话Kafka或RabbitMQ用MQ表示做事件通知、异步解耦、削峰Elasticsearch做订单与商品检索分布式定时调度平台做日结、补货计算、超时单处理配置中心和注册中心做动态配置和服务发现对象存储存对账单、证照、质检图片这些组件画成一条独立“基础组件层”放在服务层下方用虚线表示被依赖。注意不要画太细比如不需要画MySQL有哪些库表、Redis分了几组集群除非你画的是部署架构图。系统架构图里中间件是“被依赖的资源”不是主角。供应链系统还有一个特有的设计组件值得单独画出来就是“幂等控制和状态机”。供应链单据的状态极其多草稿、已提交、部分入库、已完成、已作废任何一个状态漏画都会在真实业务里漏判断。所以我在架构图上会建议加一个小的附属模块叫“单据状态中心”或者“状态机引擎”它不属于业务子系统但却是供应链系统能稳定运行的基础服务。虽然这个模块很小但它承载了跨中心单据协作的一致性逻辑。3.5 第五步排版、命名、收敛线——从“能看”到“合格”图的内容都有了最后一步是排版和收敛。这一步最容易被忽略但恰恰决定了架构图能不能在评审会上撑住场面。我会按下面几条标准反复打磨框的数量控制在20个左右子系统加外部系统再加基础组件超过30个就要考虑拆成“主图附图”线条数量尽可能少目标是整个图的核心依赖线不超过15条线条交织成蜘蛛网基本等于重画命名统一用“模块名”不要出现“采购系统”“采购模块”“purchase-service”三种叫法混在一起颜色有语义外部系统用一种色内部核心服务用一种色基础组件用一种色边界线用最深的颜色图角落标注版本号、日期、作者方便下次迭代排版上的小技巧是外部系统区放左侧或上侧核心业务服务区放中间基础组件区放下方横切组件放最右侧或独立一栏。读者第一眼先看到边界再扫到主链路最后下探到基础设施这个视线路径最自然。你甚至可以拿这个顺序做一次“30秒讲解测试”一个不熟悉系统的人看着图能不能在30秒内说出“系统有哪些部分、主线是什么、依赖了哪些外部系统”。如果能这张图基本合格了。4. 常见画法误区与自查清单一张图是如何被画烂的4.1 踩坑实录我画废过的几张架构图第一张废图是刚入行时画的一张“巨细无遗”的架构图。把每个模块的接口名、每个方法名都标在线上结果整张图密得跟电路板一样评审时根本没人看只会让人头皮发麻。后来才明白系统架构图的粒度只到“模块关键交互”接口级别的细节应该由API文档去管画进架构图反而失去了它应有的层级。第二张废图是一张“微服务全家桶”图。当时项目团队只有五个人系统还没到需要拆分微服务的地步我却按主流架构范式画了十几个服务节点加网关、注册中心、配置中心。图看起来很漂亮但实际上代码仓库只有一个运维也没搞容器化。评审会上被问“这套架构准备什么时候落地”我哑口无言。架构图必须反映现状或近期可达成的目标画一张理想国地图没有意义。第三张废图是把部署内容混进去的图。项目里有人把Nginx、Jenkins、Kubernetes、具体服务器IP全画进去还标了“mysql-1:3306”。这张图既不是应用架构图也不是严格的部署架构图。最后我让他重新画了两张图一张讲逻辑模块一张讲部署拓扑。从那以后我定了一个规矩一张图只回答一个问题。4.2 合格架构图自查清单每次画完图我会用下面的清单过一遍不满足就直接打回修改检查项合格标准我的常见问题信号图种清晰明确是系统/应用架构图不含部署细节出现IP、端口、主机名边界明确外部系统和内部系统一眼可分外部框与内部框混在一起粒度统一全部是模块级粒度不混入接口和表名线上标注了方法名、字段名依赖有方向每根线都有箭头和语义线是光秃秃的一条没有方向链路可讲能沿主链路把业务顺下来图上看不出采购、销售、库存的走向命名一致同一模块只有一个叫法中文名和英文服务名混用信息可消化30秒能讲完主线细节有附表承载框超过30个、线超过20根提示我常用的一个土办法是把最终架构图缩小到手机屏幕上看。如果缩到50%就看不清层级说明图的层次和信息密度有问题。好的架构图应该做到缩略图状态下依然能看出三大区块外部系统区、核心服务区、基础组件区。4.3 工具怎么选、评审怎么开画图工具真的不重要重要的是团队协作的便捷性和版本可追溯性。我推荐优先考虑这三类工具draw.io / diagrams.net免费、支持本地文件、能存进Git做版本管理适合技术团队Excalidraw手绘风适合白板协作快速画思路但不适合正式架构交付ProcessOn在线协作方便适合和产品、业务方一起评审但免费版有文件数限制如果要精细控制矢量图Visio或Figma也可以但维护成本偏高我个人的项目习惯是架构图源文件放进代码仓库的docs目录和代码一起走MR评审。这样架构图的每次变更都有记录不会出现“文档里的图早过期了代码里已经重构过两轮”的情况。评审会的开法也有讲究。画图人不要一上来就逐行介绍模块而是先花两分钟讲“系统边界在哪、主链路是什么、依赖了谁”再引导大家对着自查清单提出疑问。评审的人只需要盯住四个问题每个框有没有存在的必要每条线能不能说清调用协议有没有循环依赖这张图能不能指导接口设计和数据库建模这四个问题问完比漫无边际地讨论一下午都有效。5. 从架构图到项目认知这件事的真正价值5.1 架构图是倒逼需求梳理的抓手画架构图的过程本质上是把模糊的业务理解“逼”成精确的技术判断。我做过一个供应链系统的库存模块重构动手之前团队对“可用库存”的理解就从来没对齐过。业务方说“有货”仓库说“账上有但实物没有”采购说“在途也算库存吗”。这些问题不解决架构图根本画不出来因为库存中心的职责没法定义。后来我们花了两天先把“物理库存、可用库存、在途库存、锁定库存”这几个概念在表里逐一定义清楚再回到架构图上画库存中心的依赖和数据流一下子就顺了。所以如果你觉得一张图难画大概率不是因为绘图水平差而是因为你还没有真正理解业务。把自己扔进业务流程里走一遍比任何画图技巧都重要。尤其是供应链系统很多隐性规则都藏在异常处理里收货多了怎么办质检不合格怎么办订单缺货拆单怎么办你把这些场景在架构图上的旁路流程里标出来这张图就有“项目认知”的味道了。5.2 用一张图做新人交付与跨团队沟通我带新人有一个固定的“一周上手计划”入职第一天只给三样东西——一张系统架构图、一张核心业务链路图、一篇对外接口清单。新人照着架构图把主链路讲一遍基本就能把“这个系统是做什么的”搭出骨架。比上来就扔十几篇文档让他自己啃高效得多。这也说明架构图不是给架构师自嗨的它应该是一个团队的知识门面。跨团队沟通时架构图的作用更明显。和WMS团队对接出库流程、和财务系统对接对账付款双方各讲各的系统设计如果没有一张双方共识的边界图很容易在接口字段上反复扯皮。我习惯在接口评审前先拉着对方团队过一遍各自系统架构图上的对应模块让大家把“我这边在哪个框”、“你那边在哪个框”指出来后续聊字段、聊协议都会顺畅很多。5.3 版本管理让架构图成为持续生长的认知索引架构图是活文档不是一次性交付物。系统每一次重大迭代都至少应该触发一次架构图更新。我会在每个迭代周期结束时检查一遍新增了模块吗模块之间的依赖变了吗中间件有替换吗有变化就当天更新绝不要攒到“有空再说”。因为等到积压三个月以后再更新你会发现想不起来当时的背景改了哪几个地方、为什么改全都靠猜。我每次更新架构图时会在图的变更说明里写一行字本轮变更了什么、为什么变更。这不是形式主义而是让架构图自带“历史注解”它就不再是一张静态图片而是一个持续生长的认知索引。新同事接手系统时不但能看到现在的结构还能沿着变更记录理解系统走向的来龙去脉。最后分享一个我坚持了很多年的小习惯每次重大需求评审之前我会在白板上把业务主流程画一遍然后在旁边把系统架构图叠上去对照。两张图一叠哪里有业务但缺技术模块哪里有技术模块但业务根本用不上当场就能暴露出来。画架构图的功夫其实不在手上而在于你对业务边界和协作链路有没有持续追问的习惯。希望这篇以供应链系统为例的拆解能帮你在从零构建项目认知的路上少走几步我在架框连线时走过的弯路。