1. 先搞清楚一件事这张图画给谁看我见过太多人一上来就打开画图工具恨不得把系统里所有组件都塞进一张图里最后画出来密密麻麻一团谁也看不懂。这种图说难听点除了浪费两个小时的加班时间没有任何价值。架构图的第一性原理是沟通不是展示。它不是用来证明你系统的技术含量有多高而是用来让看的人快速理解系统的组成、边界和关系。所以画架构图的第一步根本不是打开工具而是问自己一个问题这张图的受众是谁他们想从图里看到什么我给受众做过一个大致的分类你可以对照一下。**第一类是老板或者非技术出身的业务方。**他们不关心你用的是什么消息队列、服务网格也不关心Redis集群有几个节点。他们想看的是系统整体分几层、数据怎么流转、核心模块够不够健壮最好一眼能看出系统能覆盖哪些业务场景。给这类人看的图必须极度精简颜色层级要清晰术语要少最好配上简单的价值标注。**第二类是同级的技术同事。**比如你负责订单模块要跟支付模块、库存模块的负责人对齐接口和依赖关系。这类图关注的是模块边界、接口协议、数据流向、部署方式。画的时候要能体现“我的模块只依赖你的哪几个服务”以及“当某个下游挂了我的容错方案是什么”。这种图不追求全局完整局部细节反而更重要。第三类是新人或者接盘侠。比如团队进来一个新手或者你准备离职要把系统交接给别人。这类图应该画的是系统地图有哪些服务、每个服务的职责是什么、代码仓库在哪、关键配置文件在哪、部署在什么环境。画这类图要像画城市地铁图一样站点清晰、换乘关系明确让人能按图索骥找到自己需要的入口。搞清楚了受众你再决定这张图画到什么颗粒度、用什么风格、放多少技术细节。这是老鸟和新手之间最大的区别——新手靠‘画得全’来找安全感老鸟靠‘画得准’来传递有效信息。2. 画图前花30分钟做功课省下来的是后面3小时的返工很多人画图失败不是因为技术表达不行而是因为他脑子里对系统本身就没想清楚。你见过有人一边画一边改改到最后连模块名字都对不上的情况吗我见得多了。根源在于架构图是分析的结果不是分析的工具。所以在我真正动笔画图之前一定会先做三件事每件事大概花10到15分钟。2.1 列出系统的核心组成把系统里所有能叫得上名字的东西全部列出来。注意这里的“东西”不止是服务还包括数据存储、缓存、消息中间件、定时任务、外部依赖、管理后台、监控系统等等。我试过一个很笨但很有效的方法找一张白纸然后把系统中的每一项写成一个名词短语比如“订单服务”“支付网关”“MySQL主库”“Redis缓存集群”“Kafka消息队列”“用户行为埋点上报”“短信通知服务”。先不管分类对不对、层级对不对列出来就行目标是别遗漏。列完之后你大概率会有一种感慨原来我们的系统里挂了这么多外部依赖。这一步就是帮助你把系统的“家底”摸清楚后面所有分层的依据都从这些名词里来。2.2 明确边界和层级接着对上一步的清单做归类和圈定边界。这里有两个维度的判断系统的边界在哪里哪些东西是自己的哪些是第三方提供的哪些是基础设施。这个决定了你架构图的画布范围。我曾经接手过一个老系统画图时把对方的第三方服务也画得巨细无遗结果图变得又臭又长后来才意识到外部服务只需要在边界处用一个“外部依赖”的框表示就够了。系统内部有几层业务层、服务层、数据层、基础设施层……不用刻意追求七层八层的完美分层按你系统实际的情况分就行3到5层是常见的。这一步做完你的图的基本骨架就已经在大脑中成型了。一个有经验的架构师画图快不是因为他手速快而是因为他在动笔前就把边界、层级、位置都想明白了。2.3 梳理核心交互链路最后一步挑出系统里最关键的业务流程把流程走一遍然后把涉及到的组件之间的关系用箭头画出来。比如一个典型的“用户下单”流程用户从客户端发起请求 - 网关 → 订单服务 → 调用库存服务锁定库存 → 请求支付服务发起支付 → 支付回调更新订单状态 → 发送消息到Kafka → 通知物流和积分服务这一步的主要目的不是画一张时序图而是帮你意识到哪些组件之间是强依赖、哪些是异步解耦、哪些数据是关键链路。这些关系画到架构图里就变成了那些连线。连线比框更难画因为连线代表的是逻辑逻辑错了图就是废的。3. 先搭骨架再填肉一个不会乱的绘图顺序准备工作做完之后进入正式的绘制环节。这一部分我总结了一个可以无脑复用的顺序按这个顺序操作哪怕你是第一次画架构图出来的成品也不会太难看。3.1 画出画布确定图的方向打开工具后第一步先别急着放组件先把画布方向和阅读顺序定下来。架构图最常见的两种阅读顺序一种是自上而下的分层式——从用户入口到业务层到数据层从上往下看符合直觉另一种是自左向右的流转式——从请求方到服务方到存储方适合表达链路和数据流。大多数业务系统的架构图我建议用自上而下。因为分层架构天然适配这种方式读者一眼能看出系统分了哪几层每层大概有那些组件。自左向右适合偏流程型的架构图比如网关链路、数据中台管线这一类图更强调流转方向。3.2 用三个“先画”搭建主框架线路定了之后记住三个“先画”原则**第一个先画大层再画小模块。**比如你确定要画网关层、业务服务层、数据存储层就先画出三个横向的泳道或者大框然后再往每层里填入具体的模块。先有大容器再往容器里装东西这个顺序能保证图整体看起来非常整齐。**第二个先画核心服务再画外围依赖。**假设你的系统里有订单服务、支付服务、库存服务那就先把这三个核心服务的框画在画布的正中央偏上的位置占大一点的面积。然后把消息中间件、缓存、第三方SDK之类的功能组件放在周围。核心组件一定要有中心地位不要跟外围组件平起平坐这样看图的人才能一眼抓住重点。**第三个先画主链路再画分支链路。**比如系统最核心的下单链路你要用粗线条的箭头把它从入口一直连到数据层。等主链路的连接都完整了再去画那些边缘的、低频的、异步的分支链路。很多新手容易在主链路还没打通的时候就去画分支链路画到一半发现主链路走不通又推倒重来浪费时间。3.3 每个层级保持一致的框型和语义这一点看似简单但实际操作中翻车率极高。我举几个最常见的反面例子同一个层次里有的框用圆角矩形有的框用直角矩形还有的用了圆形结果视觉上显得非常乱。一个框代表的是一个服务另一个框代表的却是一个集群第三个框代表的又变成一台服务器。有的箭头是实线表示同步调用另一个地方的实线却表示链路流转语义表达前后不一致。要解决这个问题最直接的办法是绘制前先在草稿纸上定义好图例。比如圆角矩形业务服务直角矩形数据存储六边形外部依赖实线箭头同步调用虚线箭头异步消息或事件通知把这些统一规范写到画布的角落或者写到图下方的注释里这样看图的人对你的图例定义一目了然你自己在画的过程中也不容易跑偏。4. 六步画出一张完整架构图以模拟项目X为例子讲了这么多理论下面我用一个虚拟的“模拟项目X”给大家完整走一遍绘图流程。这个项目是一个常见的中型电商后台系统包含的商品、订单、支付、库存、用户五个核心域再加上一个运营后台使用微服务架构消息中间件用的是Kafka数据库用MySQL缓存用Redis整个系统部署在Kubernetes集群上——非常典型非常适合拿来做演示。4.1 第1步确定读者和意图假设这张图要给新加入团队的同学看目标是让人理解整体模块划分和核心业务链路。那么这张图的侧重点就是模块的边界和核心服务的位置不是某一段代码的调用细节。4.2 第2步准备素材料按照第2章的功课清单我列出来这张图涉及到的所有组件用户客户端、运营后台、API网关、用户服务、商品服务、订单服务、支付服务、库存服务、MySQL数据库3个分别是用户、商品、订单/支付、Redis缓存集群、Kafka消息队列、外部支付渠道如模拟渠道、物流服务、日志监控服务4.3 第3步确定骨架和画布排版我用自上而下的结构。最上面是访问入口层中间是核心业务服务层下面依次是中间件层和数据存储层。外部依赖放在右侧用独立的大框圈起来。整个画布控制在“一页纸能看全”的范围。一张典型的草图大概是这样的ASCII示意-------------------------------------------------------------- | 用户客户端 运营后台 | -------------------------------------------------------------- | | v v -------------- -------------- | API网关 | | 运营后台 | -------------- -------------- | v ------- ------ ------- ------- | 用户 |--| 商品 | | 订单 | | 支付 | | 服务 | | 服务 | | 服务 | | 服务 | ------- ------ ------- ------- | | | | v v v v ------------- ------------------ | Redis集群 | | Kafka消息队列 | ------------- ------------------ | | | -------- | --------- v v v --------------------------- ----------------- | MySQL主从多实例 | | 外部支付/物流 | --------------------------- -----------------这个阶段不需要用电脑画直接在纸上画就行甚至可以不画框只画一些方块加箭头帮自己把布局想清楚。这张草图是整张图最核心的一步因为排版是否均匀、层次是否合理全在这一步定调。如果这一步翻了车后面在电脑上怎么调都别扭。4.4 第4步按主链路优先的次序落组件打开画图工具按照第3章的三个“先画”原则先把访问入口、API网关、核心服务、存储层这些大件放到画布上。然后再往里面填充Redis、Kafka这些中间件最后在右侧标出外部依赖区。注意一个我踩过很多次的坑先填满了再放大是错误操作。很多新手习惯把所有模块画完发现展示不下了才开始整体缩小和拖动结果已经拉好的连线全部断裂整个布局乱成一锅粥。正确做法是先预留足够的空间比如每个组件周围预留一个半个组件左右的间距宁可图看上去松散一点也不要一开始就密密麻麻。4.5 第5步连线并标注语义所有组件都落位后开始画箭头连线。这时候参照第2.3步整理出来的核心链路先连主链路再连分支链路最后清理重复连线。连线的时候有个关键技巧箭头不能穿过其他组件在无法避免交叉的地方可以用跨线跳转的样式处理或者干脆把其中一个组件换个位置。连好线之后需要在关键链路上做简单标注比如“同步调用”“异步事件”“RPC”等。用词要短能理解就行不要写长篇大论挂在连线上。4.6 第6步审核和美化最后给自己留10分钟从头到尾检查这张图。重点检查这几个点每个组件名是否准确统一比如一会儿叫“订单中心”一会儿叫“订单服务”这种情况必须改成一模一样的名字。每根连线是否都传达了明确的关系有没有那种连了半天不知道在表达什么的线层次是否清晰从顶到底是否顺畅颜色是否克制一个系统里加上小色系不要超过4种不要五颜六色像开派对。这套流程走下来我大概需要40到60分钟。第一次按这个流程操作可能慢一点但多试两次之后速度和成图质量都会明显提升。5. 工具没那么重要但表达细节真的重要架构图工具这个话题每次聊都会引发争论。我的观点很明确工具只是辅助你的图和你的思维模型才是主角。但合适的工具确实能让你事半功倍。5.1 常用工具一览与选型建议工具类型代表工具适合场景优缺点在线协作画图常用在线白板类多人实时协作、快速记录草图模板丰富协作强但性能在超大图时会拖垮专业架构图工具桌面版专用绘图工具规范化交付、复杂系统架构出图专业但学习成本略高代码化绘图代码驱动绘图工具版本化归档、团队代码库化管理可维护性好但上手门槛略高手绘或PPT一切可以画方块的工具早期草图、日常快速沟通轻量快捷但不适合正式文档我个人的建议是日常画草图用在线白板工具正式交付用专业绘图工具如果团队里需要长期维护文档型架构图可以尝试代码化绘图。不用在这上面过度纠结画一张图花在调整格式上的时间不应该超过总时间的三分之一。5.2 配色和字体的基本纪律我在第2章草稿里提到过“色彩不超过4种”这里具体展开一下。架构图里颜色的价值只有一个区分不同类型或不同层次的信息。比如业务层用一个色系中间件用另一个色系数据层用第三种颜色外部依赖用第四种颜色。颜色的作用是建立视觉分组不是装饰。字体方面常见的规则是中文字体统一用系统默认无衬线字体即可英文和数字统一用统一字族字号差距不要太大。最忌讳的是同一个图里出现三四种不同字体看起来完全没有专业感。此外架构图中所有文字方向保持一致。竖排文字尽量少用能横排就横排实在放不下可以先考虑换行而不是旋转90度。看图的人不需要为了读你的标注而扭脖子。5.3 连线表达的进阶用法很多架构图最大的问题是连线一律用一个样式完全看不出调用方向和数据流向的差异。这里我建议两个进阶做法用线宽和线型强调层级关系主链路的粗实线代表核心业务调用普通实线代表同步接口虚线代表异步消息或事件通知点划线代表配置关联或部署依赖。这样读图的人能立刻分辨出关键链路。在关键节点标注约束条件比如“超时500ms”“失败重试3次”“写操作走主库读操作走从库”这些细节不要另起一张图直接标注在边上就能让图的信息密度一下子上来。但要注意避免过度标注每根连线都写注释图会变得非常嘈杂。一个按经验总结出来的平衡点是只标注那些容易引起歧义或对读图者决策关键的线其余一律不标。6. 老鸟避坑指南这5个错误我几乎每次都会看到最后这部分我整理了这些年看图和画图过程中最常踩的5个坑每一个我都亲自见过甚至自己也栽过跟头。6.1 错误一把架构图画成了组件拓扑图很多新手以为架构图就是把所有组件标出来然后用线连起来结果画出来的本质上是一张运维拓扑图每个服务占一个框端口号、IP地址全标上看的人根本分不清主次、理不清逻辑。架构图的核心信息是逻辑分层和关系方向不是物理部署细节。如果你要表达部署关系另画一张部署图别混在同一张图里。一张图只讲一个故事这是架构图的第一铁律。6.2 错误二箭头的方向混乱我见过一张图连线的箭头一会儿指向服务A一会儿指向服务B一会儿又指向数据库完全看不出是谁在调用谁。为什么会这样多半是因为画图的人自己也没搞清楚依赖关系全凭手指记忆在操作。解决办法很简单画的时候默认箭头指向被依赖方。比如订单服务调用库存服务箭头应该从订单服务指向库存服务。请求的方向就是箭头的方向这条规则适用于绝大多数同步场景。异步消息的时刻比如发送事件、订阅消息可以用虚线箭头加“订阅”字样做标注避免歧义。6.3 错误三图标滥用用贴纸式的图标去代表服务乍看很炫实际非常容易翻车。原因很简单图标表达不了层级关系也表达不了相似服务的隶属关系。比如你用钱包图标代表支付服务用户可能看不懂这个图标是支付还是账户。你用了3种不同形状的图标代表3个服务但读者无法立刻把它们归到同一个域下。如果你实在想让图生动一点我建议这样做主图案一律用规范几何框所有服务名用文字清晰标注图标只做辅助点缀或者干脆不用。专业的架构图不靠图标取胜靠的是排版秩序和信息密度。6.4 错误四不标注关键假设和边界条件举个例子你画了订单状态从“待支付”流转到“已支付”但没有说明“支付回调延迟超过30分钟时系统会对订单做超时关单处理”。读图的人看完以为这个流程是瞬间完成的。结果上线期间出现了延迟回调的问题新人对着架构图排查半天找不到原因。所以架构图里有一个很不起眼但极重要的元素图中的注释块。它通常放在图底部或右侧用于标注一些边界条件、关键配置、特殊处理逻辑。标注了这些图的信息才不算失真。画图的老手和新手的一个明显区别就在这里新手画完成图觉得自己什么都画完了老手会在关键节点旁边补几个字比如“超时关单”“消息重试3次”这些字才是真正值钱的信息。6.5 错误五追求一次画完而忽视迭代最后这个错误几乎是“完美主义害死人”的典型。很多新手画架构图总是要等到系统里所有逻辑都研究透了才肯动笔理由是“怕画错”。但架构图这个东西本来就是边画边想的大方向对了就画画完了找人评审改两版再定稿。我自己的习惯是初稿尽量控制在30分钟以内然后发给一个懂系统的同事看一眼确认大框架没问题再花时间补充细节和美化排版。架构图在评审中产生的信息增量往往比你自己闷头画一下午要多得多。这也是为什么老鸟的图总是比新手“值钱”不是老鸟画得快而是老鸟把评审和迭代的时间也算进去了。7. 实操结束后我个人的三个习惯这篇文章到这里该讲的方法论都讲得差不多了最后分享几个我个人的操作习惯算是画过几百张图之后的保留节目。第一个习惯我画完一张图之后一定会隔半天再回来看一眼。刚刚画完的时候人会处于一种“我画得真好”的兴奋状态很难发现问题。隔几个小时或者第二天再打开那些不合理的间距、混乱的箭头方向、含糊的名字就会自己跳出来。第二个习惯我会用一句话去测试这张图。具体做法是看完图片后合上图在心里默念“这个系统是……”然后尝试用一句话把架构说出来。如果能够顺利讲出“最外层是入口中间是业务服务下层是数据和中间件外部依赖在右侧”说明这张图传达信息成功。如果卡壳了那说明图里一定有干扰项。第三个习惯也是我觉得最有价值的保留一张“极简版”架构图。系统持续迭代架构图过几个月就会过时但整体的分层和边界往往变化慢得多。每次系统大改版之后我会花10分钟把当前那版最新的架构图简化成只剩核心组件和主链路的样子更新一次底稿。这版极简图用于跟新人讲上下文、跟上级汇报、跟合作方对齐每次都极其高效而且不用频繁维护。画架构图这件事本质上拼的是你对系统的理解深不深表达时够不够克制。工具永远是次要的逻辑秩序才是核心。希望这篇文章能帮你把下一次画图的时间缩减一半同时让看的人把理解成本也降低一半。