1. 架构流程图到底在画什么从一张图看懂系统骨架很多人第一次接触“架构流程图”这个词脑子里浮现的是一堆方框和箭头觉得无非就是把系统画出来而已。但真正动手画过几套系统的人都知道一张好的架构流程图价值不亚于一份浓缩的技术方案文档。它要回答的核心问题只有一个这个系统由哪些部分组成它们之间怎么协作数据和控制怎么流动。把这几个问题讲清楚了图才有意义讲不清楚画得再花哨也是废纸。我这些年画过的架构图没有一百也有八十张踩过的坑足够写一本小册子。最开始我也犯过典型的新手错误——把架构图画成了部署图把服务器、容器、数据库实例全堆上去结果评审的时候被人问“你这个服务的边界在哪”当场卡壳。后来才慢慢明白架构流程图和部署图、网络拓扑图、时序图是几个不同的东西混在一起画只会让读者抓不住重点。这篇文章适合几类人看刚入行不久、需要独立输出架构设计的新同学做了几年开发、想往架构方向转的工程师还有需要评审别人架构图、但自己不太画图的技术负责人。我会从设计思路、核心要素、实操步骤、常见坑几个角度把“架构流程图”这件事拆开讲透尽量做到你看完就能上手画一张像样的图。需要先说明一点架构流程图没有唯一标准答案不同团队、不同场景下的画法差异很大。我下面讲的方法是基于常见工程实践总结出来的你可以根据自己的项目特点做调整不必照搬。2. 画之前先想清楚架构流程图的设计思路与选型逻辑2.1 先定视角再定图三种常见视角的取舍画架构图最容易犯的错就是一上来就打开画图工具开始拖方框。正确的顺序应该是先确定这张图给谁看、要回答什么问题再决定画什么。我一般把架构流程图的视角分成三类业务视角面向产品、运营、非技术管理者。重点画业务模块之间的关系比如“下单”这个动作会经过哪些业务环节每个环节由哪个系统负责。技术细节全部隐藏只保留业务语义。应用视角面向开发、测试、运维工程师。重点画服务拆分、模块依赖、接口调用关系。这是最常画的一类也是本文重点讨论的对象。数据视角面向数据团队、DBA。重点画数据从产生到落库、到消费的完整链路包括存储选型、同步方式、一致性策略。这三种视角不是互斥的一个成熟的项目往往会同时维护多张图分别对应不同视角。但一张图只能有一个主视角混着画必然导致信息过载。我见过最离谱的一张图业务名词和技术组件混在一起箭头既有“用户点击”又有“HTTP调用”评审的时候没人看得懂。选视角的判断标准很简单如果这张图是给老板汇报用的选业务视角如果是给开发做设计评审用的选应用视角如果是排查数据不一致问题用的选数据视角。视角选对了图就成功了一半。2.2 分层还是不分层架构图的结构化原则确定视角之后接下来要决定的是要不要分层。分层是架构图最重要的结构化手段它把系统按职责切成若干层每层只关心自己该关心的事。常见的分层方式有分层方式典型层次适用场景经典三层接入层、逻辑层、存储层大多数业务系统四层扩展接入层、应用层、领域层、基础设施层中大型系统、领域驱动设计数据流分层采集层、处理层、存储层、消费层数据平台、大数据系统客户端分层客户端、网关、服务端、外部依赖移动端、前后端分离项目分层的核心价值在于降低认知负担。读者看一张分层清晰的图可以一层一层往下读每层只需要理解几个模块。而不分层的图所有模块平铺在一起读者要自己在脑子里建立结构效率极低。但分层也不是越多越好。我见过有人把系统分成七八层每层就一两个模块图看起来很高大上实际上信息密度极低读者反而抓不住重点。我的经验是中小型系统三层足够大型系统四到五层超过五层就要考虑是不是拆成多张图了。2.3 工具选型别在工具上纠结太久画架构图的工具五花八门我列几个自己用过的说说各自的适用场景draw.iodiagrams.net免费、跨平台、支持离线是我用得最多的工具。优点是上手快、模板多、导出格式全缺点是复杂图的排版需要手动调整自动布局能力弱。Excalidraw手绘风格适合快速表达想法、做草图。正式文档里用得少但头脑风暴阶段非常好用。PlantUML / Mermaid代码化画图适合需要版本管理的场景。缺点是布局不可控复杂图容易画得很难看。Mermaid 在 Markdown 文档里嵌入很方便但复杂架构图还是建议用可视化工具。专业工具如某些商业建模工具功能强大支持模型驱动、自动布局但学习成本高团队协作时容易因为授权问题卡住。我的建议是团队统一一个工具就行别追求最强大的追求最顺手的。工具换来换去最后图都散落在不同地方维护成本极高。另外无论用什么工具源文件一定要纳入版本管理架构图是会随系统演进的没有版本管理的图很快就会过时。3. 架构流程图的核心要素方框、箭头、边界怎么画才专业3.1 方框每个模块的粒度怎么定方框代表系统的组成单元但“单元”的粒度是个大学问。粒度太粗图上看不出关键设计粒度太细图变成代码结构图失去架构层面的价值。我判断粒度的标准是一个方框应该对应一个可以独立部署、独立演进、有明确职责边界的单元。具体来说如果一个模块可以单独打包部署它应该是一个方框。如果一个模块的职责可以用一句话说清楚它应该是一个方框。如果两个模块总是同时变更、同时部署它们应该合并成一个方框。举个例子一个电商系统的订单服务内部可能有创建订单、查询订单、取消订单等多个功能但这些功能共享同一套数据模型、同时部署所以它们应该画成一个方框“订单服务”而不是拆成三个。反过来如果订单服务和支付服务虽然都属于交易域但独立部署、独立演进那就必须画成两个方框。方框的命名也有讲究。用名词不用动词。“订单服务”比“处理订单”好“用户中心”比“管理用户”好。动词描述的是行为而架构图描述的是结构结构用名词表达更准确。3.2 箭头调用关系、数据流向、依赖方向要分清箭头是架构图里信息量最大的元素也是最容易画乱的地方。我见过一张图所有箭头都是实线没有任何标注读者根本不知道这条线代表调用、数据同步还是依赖。箭头的画法要遵循几个原则第一区分同步和异步。同步调用用实线箭头异步消息用虚线箭头这是最常见的约定。如果团队有自己的约定比如用不同颜色区分也可以但一定要在图例里说明。第二标注协议或方式。箭头旁边应该标注调用方式比如“HTTP”“RPC”“MQ”“DB查询”。不标注的话读者只能猜猜错了就会误解系统设计。第三箭头方向要一致。要么统一“调用方指向被调用方”要么统一“数据流向”不能混着来。我倾向于调用关系用调用方指向被调用方数据流用数据流向两类箭头用不同样式区分。第四避免交叉和绕线。箭头交叉太多图就没法看了。如果实在避免不了可以用“跳线”符号或者把相关模块调整位置。这一步很费时间但值得因为一张清爽的图能省下评审时大量的解释成本。3.3 边界系统边界、团队边界、信任边界边界是架构图里最容易被忽略、但最重要的元素之一。它回答的是“什么在系统内什么在系统外”这个问题。常见的边界有三类系统边界区分本系统和外部系统。外部系统通常用灰色或虚线框表示内部系统用实线框。团队边界在大型项目里不同团队负责不同模块边界可以标出职责划分。这类边界在跨团队协作的架构评审里特别有用。信任边界区分可信区域和不可信区域比如内网和公网、用户输入和系统内部。安全相关的架构图必须画清楚信任边界。边界的画法没有统一标准但一定要在图例里说明每种边界的含义。我见过有人用不同颜色的虚线表示不同边界但没写图例读者完全看不懂。3.4 图例别让读者猜你的符号图例是架构图的“说明书”但很多人不画。我强烈建议每张架构流程图都带图例哪怕符号很简单。图例要说明的内容包括方框类型服务、数据库、外部系统、消息队列等箭头类型同步调用、异步消息、数据流等边界类型系统边界、团队边界等颜色含义如果有用颜色区分的话图例不用很复杂放在图的角落占一小块地方就行。但它的存在能极大降低读者的理解成本尤其是当这张图要给不熟悉项目的人看的时候。4. 实操从零画一张架构流程图的完整步骤4.1 第一步梳理系统清单和依赖关系动手画图之前先在纸上或文档里把系统清单列出来。这一步不用考虑排版就是把所有需要画上去的模块、外部依赖、存储组件列全。我一般会问自己几个问题这个系统对外提供哪些能力对应哪些模块这些模块依赖哪些内部服务依赖哪些外部系统或第三方服务用了哪些存储组件数据库、缓存、消息队列、对象存储等有没有定时任务、批处理、异步消费者这类非请求驱动的模块把这些问题回答完清单基本就全了。然后梳理依赖关系谁调用谁、谁依赖谁用文字先记下来。这一步看起来笨但比直接画图效率高得多因为改文字比改图快。4.2 第二步确定分层和布局清单和依赖关系理清之后开始确定分层。我一般按数据流向从上到下排最上面是接入层客户端、网关、负载均衡中间是应用层各个业务服务下面是领域层或基础设施层存储、消息、缓存最下面是外部依赖第三方服务、外部系统布局上同一层的模块横向排列层与层之间纵向排列。这样读者从上往下读符合数据流动的直觉。如果某个模块跨层比如一个服务既处理请求又直接访问数据库那就把它放在它主要职责所在的层然后用箭头连到其他层。4.3 第三步画方框、连箭头、加标注布局确定后开始画。这一步的实操建议先画方框不连线。把所有模块按布局摆好调整大小和位置确保整体平衡。再连主要调用关系。先连核心链路的箭头比如用户请求从网关到服务到数据库这条主链路。然后补充次要关系。异步消息、定时任务、监控上报这些次要关系后补。最后加标注和图例。箭头标注、边界说明、图例一个都不能少。画的过程中要不断问自己这张图如果给一个不熟悉项目的人看他能不能看懂主流程。如果看不懂说明哪里画得不够清楚回去改。4.4 第四步评审、迭代、归档图画出第一版之后一定要找人评审。评审的对象最好是不参与这个项目、但技术能力过关的同事。他们能发现你自己看不到的问题比如某个箭头含义不清、某个模块命名有歧义、某个边界没画出来。评审之后根据反馈迭代一般两到三轮就能定稿。定稿后归档到团队文档库并注明版本和更新日期。架构图不是画完就完了系统演进之后要同步更新否则过几个月就没人敢用了。5. 常见问题与排查技巧实录5.1 图太乱怎么办三个降乱技巧架构图画乱是新手最常见的问题。我总结了三个降乱技巧技巧一拆图。一张图只讲一件事。如果一张图既要讲业务模块关系又要讲部署拓扑还要讲数据流那必然乱。拆成三张图每张讲清楚一件事。技巧二抽象。把不重要的细节隐藏掉。比如数据库不用画出具体表结构消息队列不用画出具体 topic只画到组件级别就行。技巧三对齐。方框对齐、箭头对齐、文字对齐。对齐能让图看起来清爽很多虽然调整起来费时间但值得。5.2 箭头交叉太多怎么破箭头交叉是架构图的顽疾。我的处理顺序是调整模块位置。把关联紧密的模块放近一点交叉自然就少了。合并同类箭头。如果多个模块都调用同一个服务可以画一条总线式的箭头而不是每个模块画一条。使用跳线符号。实在避免不了交叉用跳线符号表示“这两条线不相交”。分层画。如果同一层内交叉太多考虑把这一层拆成两个子层。5.3 图例和标注的常见遗漏我评审别人架构图时最常发现的遗漏有箭头没标注协议或方式外部系统没标出来读者以为是自己系统的一部分异步关系没区分全画成同步没有图例符号含义靠猜没有版本和日期不知道这张图是不是最新的这些问题看起来小但每一个都会导致读者误解。画图的人觉得理所当然的事读者往往一无所知所以标注要尽可能详细。5.4 架构图维护的坑架构图最大的坑不是画是维护。系统改了图没改过几个月图就废了。我的经验是把架构图纳入代码仓库和代码一起版本管理。在 CI 流程里加检查比如某个关键模块改名了提醒更新架构图。指定维护人每张图都要有人负责不能大家都能改、结果没人改。定期 review比如每个季度过一遍架构图看是否和系统一致。6. 不同场景下的架构流程图变体6.1 微服务架构图怎么画微服务架构图的核心是服务拆分和调用关系。我一般会画三层接入层网关、BFF、服务层各个微服务、基础设施层注册中心、配置中心、消息队列、数据库。服务之间的调用关系要标清楚是同步 RPC 还是异步消息这直接影响系统的可用性和一致性设计。微服务图容易画得太细把每个服务的内部模块都画出来。我的建议是只画到服务级别服务内部的结构用另外的图比如组件图表达。一张微服务架构图上有十几个服务是正常的超过二十个就要考虑拆图了。6.2 数据平台架构图怎么画数据平台架构图的核心是数据流向。从数据采集、到数据处理、到数据存储、到数据消费每个环节用了什么组件、数据怎么流转要画清楚。数据平台图一般比较长横向铺开因为数据链路本身就长。画数据平台图要注意区分批处理和流处理这两条链路的组件和特性完全不同。另外数据质量监控、元数据管理这些支撑组件也要画上否则图不完整。6.3 客户端架构图怎么画客户端架构图的核心是模块划分和依赖方向。客户端项目容易变成一团乱麻架构图的价值就是理清模块边界和依赖关系。我一般会画UI 层、业务逻辑层、数据层、基础设施层每层内部的模块和层与层之间的依赖方向要标清楚。客户端图要特别注意依赖方向比如 UI 层依赖业务逻辑层业务逻辑层依赖数据层不能反过来。如果出现反向依赖说明架构有问题图上一眼就能看出来。7. 我个人的一些实操心得画了这么多年架构图有几个心得是踩坑踩出来的分享给你第一先想清楚再动手。我早期画图喜欢直接开工具边画边想结果画到一半发现结构不对全部推翻重来。后来改成先在纸上画草图草图定了再上工具效率高很多。第二图是给人看的不是给自己看的。自己画图的时候脑子里有完整的上下文觉得怎么画都清楚。但读者没有这个上下文所以标注要尽可能详细宁可啰嗦一点也不要让读者猜。第三架构图要跟着系统走。系统改了图要改。我见过太多项目架构图还是两年前的版本早就和实际系统对不上了。这种图不但没用还会误导人。所以维护机制比画图本身更重要。第四别追求完美。架构图没有完美的一天够用就行。一张能说清楚核心结构的图比一张追求完美但迟迟画不出来的图有价值得多。第五多画多练。画架构图是个手艺活看再多教程不如自己动手画几张。画完找人评审根据反馈改改几次就上手了。最后分享一个小技巧如果你不确定一张图该怎么画可以先找几个成熟开源项目的架构图看看学习别人的画法和表达方式。看得多了自然就有感觉了。架构流程图这件事说到底就是把复杂系统用简单图形表达出来的能力这个能力值得花时间打磨。