1. 架构图设计的本质思考
架构图不是简单的方框连线游戏,而是工程师思维的可视化表达。从业15年来,我见过太多"看起来很美"却毫无信息密度的架构图——它们要么是产品经理用PPT画的玩具,要么是开发人员随手拼凑的草图。真正有价值的架构图应该像外科手术刀一样精准,能在一页纸内讲清楚三个核心问题:系统如何分工、组件如何协作、数据如何流动。
好的架构图首先需要明确受众。给CTO看的和给应届生看的绝对不是同一张图。我曾经犯过把Kafka消费者组细节放进高管汇报材料的错误,结果整场会议都在解释"为什么这些小人在排队"。后来我总结出分层表达法:顶层只保留3-5个关键模块,中层展开接口协议,底层才放实现细节。就像电影分级制度,不同观众看到不同版本。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 架构图制作的黄金标准
2.1 信息密度法则
每平方英寸图纸应该传递至少一个关键设计决策。我常用"5秒测试":把图给同事看5秒后拿走,看他能复述出多少信息点。优秀的架构图就像地铁线路图——不需要任何解释就能看懂换乘关系。建议用以下元素控制密度:
- 模块不超过9个(遵循米勒定律)
- 连线不超过3种类型(实线/虚线/点线)
- 颜色不超过4种(推荐使用色盲友好配色)
2.2 视觉语法规范
经过上百次架构评审,我整理出这套视觉词典:
- 矩形=有状态服务,圆角矩形=无状态服务
- 圆柱体=存储,六边形=外部系统
- 粗箭头=强依赖,细箭头=弱依赖
- 红色边框=单点故障,绿色阴影=弹性设计
重要提示:在金融级系统架构中,一定要用虚线框明确标注合规边界,这是很多架构师踩过的坑。
3. 工具链选择与实操技巧
3.1 工具选型三维度
- 协作性:用Draw.io画初稿,转到Excalidraw细化,最终用Mermaid生成代码化版本
- 版本控制:拒绝PPT/Visio,推荐用PlantUML+Git管理迭代
- 自动化:Kubernetes架构图应该用kubectl-neat自动生成底座
3.2 我的私藏技巧清单
- 在Draw.io中按住Alt拖动可以复制连线样式
- 用CSS变量统一管理颜色代码(示例:
--db-color: #8dd3c7) - 对复杂系统采用"洋葱剥皮法":先画整体容器,再逐层双击进入子模块
- 给每个组
