架构设计图

我见过最糟糕的架构一张架构图，画在一张A4纸上，设计密密麻麻堆了四十多个方框，架构箭头像蛛网一样交叉。设计没人能看懂它，架构包括画图的设计人自己。三天后那个系统上线，架构第一周就崩了三次。设计这不是架构绘图技术的问题，是设计思考的混乱被忠实记录了下来。

架构图本质上是架构一份思想的自白书。你脑子里是设计清晰的模块划分、明确的架构数据流向，画出来就干净利落；你脑子里是设计一团浆糊，画出来就是架构那团浆糊的拓扑结构。别怪工具不好用，Visio、draw.io都挺无辜的。

有一次我给一个创业团队做技术咨询，他们的CTO掏出一张精心美化的架构图——渐变底色、圆角矩形、图标精致得像苹果发布会幻灯片。但我盯着看了十分钟，问他：“这个订单服务调用支付服务，失败以后怎么办？”他愣了一下：“我们还没考虑失败场景。”那张漂亮的图瞬间变成了一张废纸。架构图不是用来展示的，是用来发现问题的。

好的架构图有个特征：你能沿着一条线从入口走到出口，中途不迷路。它像一张地铁图，而不是一张城市道路图。地铁图故意省略了街道的弯曲、站间的距离，只保留换乘关系和方向。架构图也该这样——你得狠心砍掉那些“细节的真实”，才能换来“结构的真实”。我见过太多人舍不得删任何一个服务、任何一条虚线，最后画出来的东西连他自己都要花五分钟才能找到想看的那条线。

还有个反直觉的观察：真正复杂的系统，架构图反而简单。因为复杂系统必须靠清晰的边界和严格的接口来管理复杂度，画出来自然层次分明。倒是那些“看起来很简单”的中型项目，最容易画出灾难性的图——因为还没被逼到必须做架构决策的地步，每个模块都“顺便”依赖一下别人，箭头就乱成一锅粥。

我有个习惯，画架构图第一版永远只用黑白两色、方框和直线。如果这样画出来自己都觉得逻辑通顺，再上颜色、加细节不迟。彩色和图标是糖衣，不是药本身。你要是先被糖衣迷住了，往往会忘了检查药片有没有过期。

说到底，架构图是给未来那个要接手你代码的可怜人看的，也是给三个月后忘了自己当初为什么这么设计的你本人看的。它不需要漂亮，需要诚实。诚实到能让你在图上指着一个箭头反问自己：“这里真的需要跨服务调用吗？还是我把一个简单的函数调用硬拆成了微服务？”

画图的过程，就是逼自己把“我觉得应该没问题”变成“我看见了问题在哪”。这一关过不去，图越精致，系统越危险。