★ FEATURED ARTICLE 软件架构图这东西我见过太多团队画得热闹最后却没人看。业务方觉得是技术自嗨开发觉得是产品经理的PPT配图运维看了直摇头——一张图三方不讨好问题往往不在画工而在画之前没想清楚“这张图到底给谁看、要回答什么问题”。业务架构图、应用架构图、技术架构图、数据架构图这四类图不是四种画法而是四个视角的切片切错了位置图画得再漂亮也是废纸。我这些年参与过不少系统从零搭建到重构的周期也帮人梳理过一堆历史遗留的“祖传架构”踩过的坑基本都集中在“图不对题”上。这篇内容就把这四类图拆开揉碎讲清楚每类图解决什么沟通问题、核心元素怎么定、画的时候先画什么后画什么、哪些细节新手最容易漏。不管你是刚接手架构梳理任务的开发还是需要跟技术团队对齐方案的产品或项目经理看完都能直接上手画出一张“有人愿意看”的架构图。1. 先想清楚图给谁看四类架构图的定位拆解画架构图最常见的翻车现场是拿着一张应用架构图去给业务方讲业务流程或者用技术架构图去回答“我们的数据资产有哪些”。图本身没错错在拿错了切片。四类图各自服务的沟通对象和回答的问题完全不同先把这层定位理清楚后面画的时候才知道该保留什么、该舍弃什么。1.1 业务架构图回答“这门生意怎么运转”业务架构图的读者是业务负责人、产品经理和刚进项目的新人。它要回答的核心问题是这个系统支撑的业务由哪些环节组成、各环节之间怎么衔接、谁在什么节点做什么事、产生什么结果。注意这里的主角是“业务动作”和“业务角色”不是服务器也不是数据库。我习惯把业务架构图理解成一张“业务流水线全景图”。比如一个订单履约场景从用户下单、支付确认、库存锁定、拣货出库到配送签收每个环节对应哪些角色用户、客服、仓储、配送方、每个环节的输入输出是什么、异常分支往哪走这些才是业务架构图该承载的信息。技术组件在这张图里最多以“能力标签”的形式出现比如“库存锁定”旁边标注一句“由库存服务支撑”但绝不能把服务名、中间件名堆上去那会让业务方瞬间失去阅读兴趣。画业务架构图有个很实用的判断标准把图拿给一个不懂技术的业务同事看他能不能顺着图把自己的日常工作流程对号入座。如果能说明图画对了如果他开始问你“这个框是什么意思”那大概率是你把技术概念混进来了。1.2 应用架构图回答“系统由哪些模块拼起来”应用架构图的读者是开发、测试和技术负责人。它要回答的是整个系统被拆成了哪些应用或服务、每个应用负责哪块职责、应用之间怎么调用、边界在哪里。这张图是技术团队日常讨论最频繁的一张也是重构时最先被拿出来改的一张。应用架构图的核心元素是“应用/服务”和“依赖关系”。画的时候要克制住把所有东西都画上去的冲动重点体现分层和边界。常见的分层方式是接入层、业务应用层、公共服务层、基础设施层但分层不是目的目的是让读者一眼看出“哪个应用依赖了哪个应用”“哪些是核心链路”“哪些是旁路能力”。这里有个容易忽略的点应用架构图要体现“职责单一”原则的落地情况。如果一个应用框里塞了五六个不相关的职责描述那这张图其实在提醒你——这个服务该拆了。图是照妖镜画的过程本身就是一次架构体检。1.3 技术架构图回答“底层靠什么撑住”技术架构图的读者是运维、架构师和对部署形态关心的技术骨干。它回答的是应用跑在什么基础设施上、用了哪些中间件、网络怎么划分、部署单元怎么组织、高可用和容灾怎么落地。这张图离业务最远但对系统稳定性最关键。技术架构图里常见的元素包括计算资源、存储资源、网络分区、中间件集群、监控与日志链路等。画这张图最忌讳的是“只画静态不画动态”——只标了有哪些组件没标数据流向和故障隔离边界。我见过一张技术架构图画得整整齐齐结果一问“数据库主库挂了流量往哪走”图上完全看不出来这种图在故障演练时基本帮不上忙。技术架构图的颗粒度要跟团队规模匹配。小团队画到“应用集群数据库主从缓存集群”这个层级就够了大团队才需要细化到可用区、网络策略和资源配额。画太细维护成本高画太粗又指导不了运维这个平衡点得根据实际运维复杂度来定。1.4 数据架构图回答“数据从哪来到哪去”数据架构图的读者是数据开发、后端开发和需要做数据对接的团队。它回答的是核心数据实体有哪些、数据在系统间怎么流转、存储在哪里、谁生产谁消费、数据一致性怎么保证。这张图在数据驱动的项目里价值极高但在很多团队里却是最容易被敷衍的一张。数据架构图的核心不是画数据库表结构那是ER图干的事。它要体现的是“数据流”和“数据归属”。比如用户数据在注册服务产生、在订单服务被引用、同步到数据仓库做分析这条链路才是数据架构图该画的东西。画的时候要标清楚每个数据实体的“权威来源”是哪个系统避免出现多个系统都认为自己拥有某份数据写权限的混乱局面。四类图的定位对比如下画之前先对号入座图类型核心读者回答的问题核心元素常见误区业务架构图业务方、产品、新人业务怎么运转业务环节、角色、输入输出混入技术组件名应用架构图开发、测试、技术负责人系统怎么拆分应用/服务、依赖关系、分层职责描述过粗或过细技术架构图运维、架构师底层怎么支撑资源、中间件、网络、部署只画静态不画流向数据架构图数据开发、后端数据怎么流转数据实体、流向、归属画成表结构ER图2. 业务架构图从业务动作出发的拆解方法业务架构图是四类图里最“软”的一张没有统一的标准符号也正因如此最容易画得五花八门。但它的价值恰恰在于“软”——它要跨越技术和业务的鸿沟让两边用同一张图对话。我梳理业务架构图有一套固定的动作顺序照着走基本不会跑偏。2.1 先列业务角色再列业务动作很多人一上来就画流程框画到一半发现角色对不上返工。正确的顺序是先做两张清单一张是“谁参与”一张是“做什么”。角色清单要覆盖所有直接和间接参与者包括外部用户、内部操作人员、合作方系统动作清单按业务阶段分组每个动作标注触发条件和产出物。拿一个内容审核场景举例。角色清单可能是内容创作者、审核员、运营人员、风控系统作为自动审核角色。动作清单按阶段分提交阶段创作者上传内容、初审阶段风控系统自动扫描、人工复审阶段审核员判定、处置阶段运营人员执行下架或放行。这两张清单列完图的骨架就有了。这里的心得是角色清单宁多勿漏动作清单宁粗勿细。角色漏了会导致流程断头动作太细会让图变成操作手册失去全景视角的意义。一般一个业务架构图控制在10到15个核心动作比较合适超过20个就该考虑拆成子图了。2.2 用泳道串起角色与动作的对应关系角色和动作列完后用泳道图把它们串起来是最直观的方式。每个角色一条泳道动作按时间顺序在泳道间流转跨泳道的箭头表示交接。这种画法的好处是“谁在什么时候把什么东西交给谁”一目了然业务方看着亲切因为这就是他们日常工作的样子。泳道图有个细节要注意异常分支怎么处理。正常流程一条线画下来很清爽但业务方最关心的往往是“出错了怎么办”。我的做法是主流程用实线异常分支用虚线并在旁边标注触发条件和处理动作比如“支付超时→自动取消订单并释放库存”。异常分支不用画全挑三到五个高频或高影响的场景标出来即可画太多会让图变得像蜘蛛网。注意泳道图里不要出现“调用XX接口”“写入XX表”这类技术描述业务方看不懂也不需要看。如果某个动作确实需要说明技术支撑用括号标注能力名称即可比如“库存锁定库存服务”。2.3 标注业务规则与关键指标一张只有流程框的业务架构图是半成品真正让它有决策价值的是业务规则和关键指标的标注。业务规则指的是那些“必须满足的条件”比如“同一用户单日退款申请不超过3次”“库存低于安全水位时触发补货提醒”。关键指标则是每个环节的衡量标准比如“初审自动通过率”“人工复审平均时长”。这些标注不用多每个核心环节挑一到两条最重要的写上去。它们的价值在于当业务方和技术方讨论“这个环节能不能自动化”“这个规则能不能配置化”时图上有依据可查不用回去翻文档。我习惯用不同颜色的便签样式标注规则和指标跟流程框区分开视觉上一眼能分辨。2.4 业务架构图的验收标准画完之后怎么判断这张图合格我总结了三问第一问业务方能不能指着图说出自己每天的工作对应哪个框第二问新入职的开发能不能通过这张图理解“我们系统到底在解决什么业务问题”第三问当业务规则变更时能不能快速定位到图上哪个环节需要调整。三问都过这张业务架构图就算立住了。如果第一问就卡住说明角色或动作有遗漏第二问卡住说明业务价值表达不清第三问卡住说明规则标注不到位。这个验收方法比任何评审会都直接建议画完自己先过一遍。3. 应用架构图分层、边界与依赖的克制表达应用架构图是技术团队用得最多的一张图也是最容易画成“大杂烩”的一张。我见过不少应用架构图一个框里塞了七八个职责箭头横七竖八看完比不看还糊涂。问题出在没守住“分层清晰、边界明确、依赖克制”这三条底线。3.1 分层不是目的是让依赖方向可见分层几乎是应用架构图的标准动作接入层、业务层、公共服务层、基础设施层这套分法大家都熟。但很多人分层只是为了“看起来整齐”没想明白分层的真正价值——让依赖方向可见。好的分层应该满足上层依赖下层同层之间尽量少依赖跨层依赖必须显式标注。举个具体的例子。接入层负责协议转换和流量管控业务层按业务域拆成订单、库存、支付等应用公共服务层放消息、缓存、配置等通用能力基础设施层是数据库和存储。这样分完之后如果订单应用直接调用了基础设施层的数据库图上就应该有一条跨层的箭头评审时一眼就能发现“这里绕过了公共服务层可能有隐患”。分层的颗粒度也要控制。三层到四层是比较舒服的区间层数太少体现不出边界层数太多图会变得又高又窄不好读。如果业务域特别多建议按业务域拆成多张应用架构图每张聚焦一个域用一张总图做索引。3.2 应用框里写什么职责描述的三段式应用框里的文字是最见功力的地方。写太粗比如只写“订单服务”读者不知道它到底管什么写太细把每个接口都列上图就变成了接口文档。我习惯用三段式描述第一段写核心职责一句话第二段写关键能力两到三个关键词第三段写对外依赖调用了谁、被谁调用。以订单应用为例框里可以这样写核心职责是“订单全生命周期管理”关键能力是“下单、取消、状态流转”对外依赖是“依赖库存服务锁库存、依赖支付服务查支付状态、被履约服务调用”。这样一段描述开发看了知道边界在哪测试看了知道影响范围在哪架构评审时也能快速判断依赖是否合理。三段式描述还有个好处它强迫你在画图时就想清楚这个应用的职责是否单一。如果一段描述写下来发现“关键能力”列了六七个不相关的词那说明这个应用该拆了。图是架构的镜子画不清楚往往是因为设计本身就不清楚。3.3 依赖箭头的画法与常见陷阱依赖箭头是应用架构图里信息密度最高的元素也是最容易画错的地方。画箭头要区分三种关系同步调用实线箭头、异步消息虚线箭头、数据依赖点线箭头。三种关系混在一起画读者根本分不清哪条是实时链路、哪条是最终一致。常见陷阱有三个。第一个是“双向箭头泛滥”A调B、B也调A画成双向箭头看似省事实则掩盖了循环依赖的问题正确做法是拆成两条单向箭头分别标注调用场景。第二个是“箭头不标动作”只画一条线不写“查库存”还是“锁库存”读者得猜。第三个是“把消息队列画成调用方”异步消息应该从生产者指向消息中间件再从中间件指向消费者不能直接生产者连消费者否则就看不出解耦点了。提示依赖箭头超过15条的图建议按核心链路和旁路链路拆成两张。一张图讲清楚一件事比一张图讲清楚所有事更有价值。3.4 用颜色区分变更影响范围应用架构图在重构和排期时特别好用前提是你用了颜色标注。我的习惯是用三种底色区分应用状态绿色表示本期不改动、黄色表示本期有改造、红色表示本期新增。这样一张图往排期会上一放谁的工作量在哪、哪些依赖需要提前对齐一目了然。这个做法在跨团队协作时尤其管用。比如订单域要改造依赖库存域提供新接口图上库存应用标黄双方一看就知道需要拉通排期。颜色标注不用多三种足够多了反而眼花。每次架构评审前更新一次颜色图就始终是“活”的不会画完就锁进文档库吃灰。4. 技术架构图部署形态与故障边界的表达技术架构图回答的是“东西跑在哪、挂了怎么办”这两个问题决定了它的画法跟应用架构图完全不同。应用架构图关心逻辑拆分技术架构图关心物理部署和故障隔离。很多团队把这两张图画成一张结果逻辑和物理混在一起运维看了直挠头。4.1 从部署单元开始画而不是从服务器开始新手画技术架构图容易从“有几台服务器”开始画画完发现应用一扩容图就过期。正确的起点是部署单元——也就是“哪些东西是打包在一起部署的”。一个部署单元可能是一个应用集群、一个中间件集群、一个数据库主从组先把这个层级定下来再往里填具体的资源规格。比如一个典型的部署单元划分接入网关集群、业务应用集群按域分、缓存集群、消息集群、数据库主从组、对象存储。每个部署单元画成一个框框里标注实例数量范围和规格档位比如“4到8台4核8G”而不是写死具体台数。这样扩容缩容时图不用改只需要更新规格档位。部署单元之间用网络连线表示通信关系连线上标注协议和端口范围。这一步很多人偷懒不标结果排查网络策略问题时还得回去翻配置。标上之后技术架构图就同时具备了“部署视图”和“网络视图”两个用途。4.2 故障边界必须显式画出来技术架构图最有价值的信息是故障边界也就是“一个组件挂了影响范围到哪为止”。这个信息在故障演练和容量规划时是刚需但绝大多数架构图都没画。我的做法是用虚线框把“故障域”圈出来同一个故障域内的组件共享故障风险跨故障域之间有隔离机制。举个具体的画法。数据库主从组画一个虚线框标注“主库故障时读流量切从库、写流量降级”缓存集群画一个虚线框标注“缓存全挂时回源数据库需评估回源压力”。这些标注不用长篇大论一句话说清楚降级策略即可。评审时如果有人问“这个组件挂了怎么办”图上直接有答案比口头解释强十倍。故障边界的画法还倒逼了一个好习惯画图时会主动想“这个单点能不能消除”。我见过一个团队在画技术架构图时发现某个定时任务调度器是单点当场决定改成集群部署。图没画完架构先优化了一轮这就是画图的实际价值。4.3 监控与日志链路不能省技术架构图如果只画业务组件不画监控链路那它在运维眼里就是半张图。监控和日志是故障定位的眼睛画清楚“指标从哪采集、日志往哪汇聚、告警怎么触达”才算把可观测性这块补齐。具体画法是在部署单元旁边加一条旁路链路各部署单元指向监控采集器标注采集方式比如“推模式、15秒间隔”采集器指向监控存储和告警引擎日志链路单独画一条指向日志汇聚和检索。这条旁路不用画太细但必须存在因为它回答了“出问题时我们怎么知道、怎么查”这个关键问题。注意监控链路画出来后顺手检查一下有没有“监控盲区”——比如某个新加的中间件没接监控、某个批处理任务没有心跳上报。画图的过程就是查漏的过程这个习惯能省下不少故障排查的冤枉路。4.4 技术架构图的版本管理技术架构图比另外三张图更容易过期因为基础设施变动频繁。我的经验是给技术架构图定一个“保鲜期”比如每季度评审一次有重大变更时随时更新。版本管理不用搞得太复杂图里加一个角落标注“最后更新日期变更摘要”就够了。另外建议技术架构图和应用架构图建立对应关系比如应用架构图里的每个应用在技术架构图里都能找到对应的部署单元。两张图对不上往往意味着有应用漏部署或者有部署单元没人认领这种不一致在故障时是致命的。5. 数据架构图数据流、归属与一致性的表达数据架构图在四类图里存在感最低但数据出问题时它的价值最高。很多团队的数据架构图就是一张ER图画了表结构和外键关系却回答不了“这份数据谁说了算”“数据延迟多久”“对不上账怎么办”这些真正要命的问题。数据架构图的核心是数据流和归属不是表结构。5.1 先定数据实体再定权威来源画数据架构图的第一步是列核心数据实体比如用户、订单、商品、库存、支付流水。列完之后给每个实体标注“权威来源系统”——也就是这份数据由哪个系统负责写入和维护其他系统只能读或者通过同步获取。这一步是数据架构图区别于ER图的关键。现实中常见的问题是多个系统都能改同一份数据最后对不上账谁也不知道以谁为准。图上把权威来源标清楚就等于立了规矩权威来源系统负责数据质量其他系统通过订阅或接口获取不允许直接写。这个规矩在图上白纸黑字写着比开会强调管用。数据实体不用列太多挑十到十五个核心实体即可边缘实体可以归并到核心实体下作为属性。列的时候按业务域分组比如交易域、商品域、用户域分组之后图的结构自然就出来了。5.2 数据流向要标清同步方式和延迟数据实体和权威来源定完后画数据流向。流向的起点是权威来源系统终点是消费方连线上必须标注两件事同步方式实时接口、消息订阅、批量抽取和延迟量级秒级、分钟级、小时级、天级。这个标注看着琐碎实际价值极高。比如订单数据从订单系统流向数据仓库做报表标注“批量抽取、T1”那报表使用者就知道今天看到的数据是昨天的不会拿实时性去要求它。再比如库存数据从库存系统流向搜索系统做展示标注“消息订阅、秒级”那搜索侧就知道库存展示可能有秒级延迟下单时必须以库存系统实时校验为准。同步方式和延迟标注清楚后数据一致性的讨论就有了基础。哪些链路是强一致、哪些是最终一致、最终一致的收敛时间是多少图上都能看出来。这比在文档里写一大段“数据同步说明”直观得多。5.3 数据血缘与影响分析数据架构图进阶用法是画数据血缘——也就是一份数据从产生到消费经过哪些环节、被哪些下游使用。血缘图在数据变更时特别好用某个字段要改类型顺着血缘图一查就知道哪些报表、哪些接口、哪些下游系统会受影响。画血缘不用一次画全从核心实体开始先把“产生→主存储→主要消费方”这条主干画出来边缘消费方后续补充。血缘图跟数据流向图的区别在于颗粒度流向图看的是系统间关系血缘图看的是字段级或实体级的加工链路。两者可以画在一张图上用不同线型区分。我个人的习惯是数据架构图分两层上层画实体流向和权威来源下层画关键实体的血缘主干。一张图两个视角评审时按需展开既不臃肿也不遗漏。5.4 数据架构图的常见坑数据架构图最容易踩的坑是“画成数据库文档”把每个库每个表都列上图大得没法看。记住这张图的服务对象是数据开发和对数据对接的团队他们关心的是“数据在哪、怎么拿、准不准”不是表有几个字段。第二个坑是“只画生产不画消费”数据流只画到存储就结束了没画谁在用。这导致数据变更时找不到下游经常是改完之后某个报表挂了才发现有人在用。画消费方不用画全把核心报表、核心接口、核心下游系统标上即可。第三个坑是“忽略数据质量规则”比如某个实体标注了权威来源但没标校验规则和异常处理。建议在权威来源旁边加一句质量规则摘要比如“订单金额必须大于零、支付流水号全局唯一”让看图的人知道这份数据的可信度边界在哪。6. 四类图的协同从单张图到架构视图体系四类图分开画只是第一步真正发挥价值的是它们之间的对应关系。业务架构图里的每个业务环节应该能在应用架构图里找到支撑它的应用应用架构图里的每个应用应该能在技术架构图里找到部署单元数据架构图里的每个权威来源应该能在应用架构图里找到对应的应用。这四条对应关系立住了四张图就从“四张画”变成了“一套视图体系”。6.1 建立图与图之间的追溯关系追溯关系不用搞复杂的工具在每张图的角落加一个“关联索引”就够了。比如业务架构图里每个业务环节标注对应的应用名应用架构图里每个应用标注对应的部署单元编号数据架构图里每个权威来源标注对应的应用名。这样从任何一张图出发都能顺着索引找到另外几张图的对应位置。这个做法在架构评审时特别高效。评审业务架构图时有人问“这个环节的系统支撑是什么”直接翻到应用架构图对应位置评审应用架构图时有人问“这个应用部署在哪”直接翻到技术架构图。四张图互为索引评审效率能提升一大截。6.2 变更时四张图同步更新架构变更最怕的是图不同步改了应用架构忘了改技术架构最后图成了误导。我的经验是定一个“变更触发规则”凡是新增或下线应用四张图必须同步更新凡是业务规则变更业务架构图和数据架构图必须更新凡是部署形态变更技术架构图必须更新。规则写进团队的架构管理约定里比靠自觉靠谱。同步更新听着麻烦实际做起来每张图改动量都不大关键是养成习惯。我见过一个团队把四张图的更新做成变更流程的一个检查项不做完不算变更完成坚持了半年之后图的可信度明显提升新人也愿意看图了。6.3 按读者组织视图而不是按图类型组织最后分享一个组织架构视图的思路不要按“业务图、应用图、技术图、数据图”分类存放而是按读者组织。给业务方的视图包里放业务架构图加一张精简版应用架构图只标业务支撑关系给开发团队的视图包里放应用架构图加数据架构图给运维的视图包里放技术架构图加应用架构图的部署标注版。同一个底层图针对不同读者做裁剪和标注比让所有人看同一张全量图有效得多。业务方不需要看技术架构图运维也不需要看业务泳道图按需分发才能让每张图都有人看、有人用。我在实际项目里踩过最深的坑是早期把四类图画成了一张“万能图”结果谁看都觉得不是给自己画的。后来拆成四张、按读者分发架构评审的沟通成本反而降下来了。画架构图这件事克制比全面更重要一张图讲清楚一件事四张图讲清楚一个系统这个账怎么算都划算。
阅读完成 · 觉得有帮助？
