架构原则（三）：架构模式的选型方法 —— 没有银弹，只有适配

站在巨人肩膀，何必平地而起。抄作业、套公式不失为一种聪明的解决思路。

引言：从架构原则到架构模式

前面的文章我们通过对架构原则的描述，相信很多读者已经能够把“高内聚、低耦合”以及SOLID原则应用于架构设计以及决策。对于一个初级架构师或者想要迈入架构师岗位的工程师而言，这可能还不够，可能还是会无从下手，因为在日常的工作中，面对不同的域，架构问题不尽相同。

央视之前有个广告词叫：站在巨人肩膀，何必平地而起。在一个互联网企业中，商品、导购、交易、财务等系统是完全不同的，前辈们帮我们总结过很多“现成的公式”（架构模式），我们可以通过抄作业、套公式来解决不同业务特性的系统架构设计，不失为一种聪明、高效的思路。

另外，很多初级架构师常常会陷入一个误区：追逐“银弹”。他们听说微服务很流行，就想把所有系统都微服务化；听说事件驱动很高性能，就想在所有地方都用上消息队列。这就像一个手握F1赛车图纸的工程师，却试图用它去造一辆高速的越野车，结果可想而知。

因此，这篇文章的核心，就是要为大家建立一套系统性的架构模式选型方法论。我们将学习如何基于业务系统的特性对于质量属性——那些关于性能、可用性、成本和效率的非功能需求——来做出最合理的架构决策。记住，架构的世界里，没有绝对的好与坏，只有永恒的适配与权衡。

一、 架构师的决策罗盘：基于质量属性的选型框架

面对一个复杂的业务问题，我们如何避免“拍脑袋”式的决策？我们不光需要此前提到的架构思维、架构原则，更需要一个能引导我们穿越技术迷雾、做出理性判断的思维框架。这个框架包含四个关键步骤：

第一步：理解业务诉求与约束

在选择任何模式之前，首先要深刻理解你要解决的问题。

• 业务目标：我们要做的是什么？是一个支撑日常销售的交易系统，还是一个应对双十一大促的秒杀系统？

• 核心驱动力：这个系统最重要的成功标准是什么？是极致的用户体验，是99.999%的稳定性，还是超高效的运营效率？

• 现实约束：我们的团队规模和技术栈是怎样的？我们有多长的开发时间？我们的预算是多少？

第二步：识别并排序“质量属性”

这一步是整个框架的核心，这里的质量属性（也称非功能性需求）是衡量一个系统“好坏”的关键指标。架构师的工作，就是在这些常常相互冲突的属性之间进行权衡和决策。

常见的质量属性包括：

• 性能（Performance）：系统处理请求的速度，如响应时间、吞吐量。

• 可伸缩性（Scalability）：系统应对负载增长的能力，是否可以通过简单扩容就能满足持续发展的诉求。

• 可用性（Availability）：系统正常运行的时间比例，即“几个9”。