作为架构师，你需要了解的五个高层认知~-CSDN博客

一、架构设计是权衡的艺术

架构设计不是 “非0即1” 的完美主义，设计的过程即是权衡决策的过程。

资源约束：每个架构决策都是在有限资源比如时间、人力、技术、预算下的权衡的结果。选择微服务架构可能带来部署复杂性，而单体架构则可能面临扩展瓶颈。没有绝对的好坏，只有适合当前场景的平衡点。

质量属性权衡：性能vs可维护性、一致性vs可用性、灵活性vs稳定性——不同的架构属性并不全都是正相关，有些则相互制约。架构并不是要一次性满足所有的质量属性，而是在当时的环境下，对系统所关注的质量属性给与设计满足。比如，CAP定理就是典型的架构权衡案例，是追求可用性还是强一致性，架构师需要根据业务优先级做出取舍。

成本考量：设计不足则会增加未来重构成本。过度的简化虽然能够降低成本，但也可能在后期的稳定性和扩展等维度存在潜在瓶颈和风险。过度设计会导致资源浪费、成本增加、实现复杂度增加，同时也可能随着时间推移，过度设计会快速僵化，阻碍后续系统迭代。架构师需要在"现在够用"和"未来可扩展"之间找到平衡点，这需要敏锐的业务洞察力以及技术专业能力。

二、架构演进优于大规模预先设计

针对系统大规模预先架构设计并不是首选，演进式架构思维才是架构师必备的核心能力。实践证明，如同熵增定律，架构腐化是不可避免的自然过程。花费大量精力和时间对系统进行 “完备” 设计在后续持续的环境变化中会逐渐僵化，难以适应变化。对抗腐化的关键不是一劳永逸的"防腐设计"，而是建立持续演进的机制和文化。更好的思维方式是基于演进思维持续优化现有系统架构，基于当前的上下文诉求，快速构建最小可行架构并通过实际运行验证假设，并在不破坏现有功能的前提下持续演进的能力。

在工程实践中，有如下实践可以支持

反馈驱动优化：架构演进需要指标输入作为决策依据，构建监控告警、日志和用户反馈形成的闭环为团队提供更丰富的、准确的、定量的指标数据输入，驱动系统架构演进
定义架构适应度函数，建立系统架构约束的自动化验证机制和能力，确保演进方向不发生偏离。

三、上下文决定一切

"什么是最好的架构？"——这其实是个不合理的问题。因为，没有最好的酒架构，只有最合适的架构，架构的价值永远取决于其所处的上下文环境。

业务上下文：架构必须服务于业务目标而非技术视角驱动。比如，初创公司的的快速迭代需求与金融机构的稳定安全需求必然导致不同的架构选择。

技术生态上下文：架构必须与现有技术生态和谐共存。比如大厂都会有自己的基础设施团队和产品，多数情况下技术栈中对基础设施的选型多会在公司运维支持的产品上下文中决策，而不会选择开源产品进行自部署。如果是初创型的公司，在线产品多基于云环境进行快速构建，选择特定的云厂商以及云厂商所支持的PaaS或IaaS产品组合。

团队上下文：架构设计必须考虑团队能力，同样的架构方案，不同的团队实施可能产生截然不同的结果。如果架构方案跳出了团队技能范围，则需要权衡其带来的学习成本、是错成本和潜在的风险是否可以接受。

四、故障必然发生：接受不完美

追求"零故障"的架构是不现实的，且很有可能导致过度复杂的设计。为了满足 “完美架构”，单个细节可能会对系统设计和实现带来巨大成本。因此，成熟的架构思维承认故障的必然性并为之做适当设计。

容错而非避错：通过断路器模式、重试机制、隔离设计等手段容忍故障而非试图消除所有潜在故障点。

优雅降级策略：识别并定义系统的核心功能与非核心功能，确保在系统压力下能优先保障核心业务流，对非核心业务流程进行降级设计。如电商网站在大促时可能暂时关闭商品评论功能。

可观测性设计：构建全面的系统监控告警体系，确保故障发生时能快速定位和恢复

文化机制：建立故障复盘文化，将每次故障视为学习机会而非追责理由，培养团队的韧性思维。

五、架构意图高于图表

架构意图是本元，架构图则是其可视化模型之一。好的架构图有助于架构意图的传递，相反，可能无法表述架构意图，从而无法在干系人间进行有效传递。其间存在两个问题：

如何通过架构图高效的表述架构意图：团队在建模工具、建模语言、表述模型、图标等多个维度进行权衡选择。针对不同受众采用不同架构视图（如逻辑视图、部署视图、数据视图等），但始终保持各视图背后的核心意图一致。
架构评审不应陷入对图表本身的争论，而是需要深入到设计者背后的架构意图的理解。
将架构文档与代码一样对待，建立版本控制和变更追踪机制，确保文档与实现同步演进。