你的架构图是谎言，会议上的所有人都知道。
看起来您只提供了来源链接，但没有贴出需要翻译的正文内容。请把要翻译的文本粘贴过来，我会按照要求保留链接并将正文翻译成简体中文。
图表幻觉
架构图已经成为企业神话。我们绘制它们并不是为了记录现实，而是想象我们希望现实的样子。它们是软件系统的 Instagram 滤镜。
回想一下你最近审阅的系统图。它是否展示了：
- 仍然运行在 Oracle 11g 上的遗留数据库，因为迁移被标记为“计划在下个季度进行”？
- 实际上是因为六个月前的紧急截止日期而被胶带拼凑在一起的三个服务的微服务？
- 现在对系统功能至关重要且无人知道如何安全移除的“临时” Redis 缓存？
- 在预发布环境与生产环境完全不同工作的认证服务？
当然没有。那些细节属于“实现细节”。
真正的架构体现在生产日志中
想要看到真实的架构吗？别去看 Visio，去看错误日志吧。
系统的真实设计来源于故障模式、真正重要的瓶颈以及在出现小问题时会导致整体崩溃的依赖关系。每周二下午 2 点就达到上限的数据库连接池，比任何图示都能更好地揭示你的架构。
我曾参与一个项目，项目中我们那张漂亮的服务网格图显示了干净、独立的服务。现实呢？服务 A 无法在没有服务 B 的情况下运行，而服务 B 暗中依赖一个根本没有文档记录的共享文件系统。当该文件系统被占满时，我们一半的“微服务”像纸牌屋一样一起倒塌。
为什么我们不断绘制谎言
这并非恶意。这些图表有其用途，只是并非我们声称的那种。
架构图是愿景文档。它们代表我们正在尝试构建的系统，或我们认为正在构建的系统。它们对于需要一个思维模型来入门的新团队成员非常有用。它们帮助我们与不需要了解 Oracle 11g 问题的利益相关者进行沟通。
但我们把地图和实际情况混淆了。
会议室剧场
Presenter: “所以这是我们的高可用性设置，具备自动故障转移……”
Everyone else: 想到那次“自动故障转移”实际上需要手动干预四个小时的情形。
Someone brave: “上个月我们在支付服务上遇到的那个问题怎么办？”
Presenter: “哦，已经解决了。下一页。”
Everyone else: 知道这仍是一个未关闭的工单。
这并不高效。它更像是表演。我们都在假装图示是准确的，因为指出问题就意味着承认我们并没有把事情做好。
更好的前进方式
- 在构建任何新东西之前： 创建一张展示理想状态的图。用它来识别潜在问题、讨论权衡，并对齐目标。然后把它收起来。
- 对于已有系统： 创建“现状”图，展示真实的情况。包括技术债务、变通方案以及实际的数据流。系统变化时更新它们，而不是等到它们本该变化时才更新。
- 对于利益相关者： 创建聚焦业务能力的简化视图，而不是技术实现细节。他们不需要了解你们的十二个微服务；他们只需要知道订单会被处理，客户会被收费。
- 对于新成员： 先给他们理想图，等他们入职两周后再给真实的图。上下文很重要。
不舒服的真相
你的生产系统比任何图表能捕捉的都要更混乱、更复杂、更相互依赖。这不是失败——这就是软件开发。
我所认识的最佳架构师并不回避这种复杂性。他们记录它、衡量它，并逐步改进。他们创建的图表是为特定受众、特定目的服务的，而不是取悦所有人的“普遍真理”文档。
下次参加架构评审时，问问如果把每一个实际依赖、每一项共享资源以及每一块技术债务都包括进来，图表会怎样变化。观察现场的尴尬氛围，然后开启一次关于你们真正在构建什么的真实对话。
您的行动项
明天，请执行以下操作：
- 将您当前的架构图中所有与生产实际不符的组件标记为 红色。
- 部分准确的标记为 黄色。
- 只有真正准确的部分保持 绿色。
如果您的图大部分是红色和黄色，恭喜——您已经好几个月首次保持诚实。
现在您可以开始构建更好的东西。