画网站架构图，网站第一件事是架构打开画图工具之前，先拿张纸把用户从哪进来、图画每一步看到什么、网站数据往哪走，架构用箭头连起来。图画这步做完，网站图已经成了七成。架构剩下三成才是图画拖框框、调颜色。网站

我见过不少人一上来就开Visio，架构拖几个大方块写上“前端”“后端”“数据库”，图画然后用直线连起来，网站交差。架构这种图拿给运维看，图画运维问：负载均衡在哪？拿给开发看，开发问：消息队列呢？最后谁也没用上。

问题出在画图之前没想清楚这张图给谁看。给老板看，画三层就够了：用户、服务器、数据。给开发看，得把网关、缓存、服务拆分、数据库主从都标出来。给运维看，机房、CDN节点、监控探针一个不能少。同一套系统，三张不同的图，不是一张图画三遍。

先定层级，再填内容

我的习惯是先画一条竖线，从上到下切三刀。最上面是用户侧：浏览器、App、小程序，各画一个框。中间是服务侧：CDN、负载均衡、网关、应用服务器，按请求经过的顺序排。最下面是数据侧：缓存、主库、从库、对象存储。这条竖线就是数据流向，从左到右是调用关系。

有一次帮朋友画一个电商架构图，他非要把推荐系统画在网关前面。我说用户请求还没进来，推荐个什么？他想了想，把推荐挪到了应用服务器后面，通过消息队列异步处理。图一改，整个链路就通了。

连线比框框重要

架构图的核心不是方块画得多好看，是箭头指得对不对。实线代表同步调用，虚线代表异步消息，粗线代表数据量大。这些约定不用写在图例里，画图的人自己心里得有数。

我见过一张图，所有服务之间都是双向箭头。问为什么，答曰“它们互相调用”。再问具体谁调谁，答不上来。这种图就是废的。每一条线都应该能回答：谁发起、谁响应、走什么协议、超时多少。

工具选顺手的

draw.io够用，免费，导出SVG不糊。ProcessOn也行，模板多，但免费版有数量限制。Visio太重，打开慢，适合画完存档。真正快速的场景是白板，几个人站着，马克笔一画，拍照存档，比什么工具都快。

别在工具上纠结超过十分钟。我见过一个团队为了统一用哪款画图软件开了三次会。图没画一张，会开了不少。

一个具体例子

假设做一个短链接服务。用户访问短链，跳转到长链。架构图这样画：顶部一个浏览器框，箭头向下到DNS，再到CDN，再到负载均衡。负载均衡后面接两个应用服务器。应用服务器先查Redis缓存，命中直接返回301。没命中查MySQL，写入缓存，再返回。底部还有一个异步写入点击日志的箭头，指向Kafka，再指向日志处理服务。

这张图里，每个框都有存在的理由，每条线都能说出为什么。Redis为什么在MySQL前面？因为读多写少。Kafka为什么在应用服务器后面？因为日志写入不能阻塞跳转。这些理由不需要写在图上，但画图的人必须清楚。

画完自己走一遍。从用户点击到返回结果，每经过一个节点，问一句：如果这里挂了会怎样？答案如果是一句“那就挂了”，说明图上缺东西。补上降级方案、熔断策略、备用节点，图才算完整。

架构图不是艺术品，是施工图。好看不重要，能让人看懂、能指导编码和部署，才重要。画完发给团队，没人提问，说明画清楚了。有人提问，说明还有盲区。改就是了。