收藏 | 架构设计的基础认知

写在前面： 架构系列文章源自付费课程《从0开始学架构》——阿里P9技术专家实战架构心法。 为了更加系统化的提升架构设计认知水平，更好了指导以后的设计、开发实战，我将课程中核心的知识点、精彩评论进行了梳理。

01 架构的本质

1.1 架构的定义

软件架构指软件系统的顶层结构。

1.2 架构、框架、组件、模块、系统的本质

• 架构是顶层设计；
• 框架是面向编程或配置的半成品；
• 组件是从技术维度上的复用；
• 模块是从业务维度上职责的划分；
• 系统是相互协同可运行的实体。

1.3 架构与框架的区别？

1. 软件架构：软件系统的“基础结构”，创造这些基础结构的准则，以及对这些结构的描述。
2. 软件框架：为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。

架构关注的是“结构”，框架关注的是“规范”。

02 架构的产生背景

2.1 背景探寻

只有规模较大的软件系统才面临软件架构相关的问题。 例如： 1）系统规模庞大、内部耦合严重，开发效率低； 2）系统耦合严重，牵一发动全身，后续修改和扩展困难； 3）系统逻辑复杂，容易出问题，出问题后很难排查和修复。

2.2 设计的重要性

• 布鲁克斯发表《人月神话》三十年后，又写了《设计原本》。他认为一个成功的软件项目的最重要的因素就是设计。
• 架构师、设计师需要在业务需求和IT技术中寻找一个平衡点。而对这个平衡点的把握，就是架构设计中的取舍问题。
• 这种取舍的决策大部分是靠技术（新工具、方法论、管理模式的提升），但一定程度上也依赖于架构师的“艺术”（无法量化，需要权衡）。

03 架构设计的目的

3.1 架构设计的主要目的

为了解决软件系统功能复杂度带来的问题。

3.2 架构设计的认知

1. 认知1：需求驱动架构。 通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计。
2. 认知2：架构设计并不是要面面俱到。 不需要每个架构都具备高性能、高可用、高扩展性等特点，而是要识别出复杂点，然后有针对的解决问题。
3. 认知3：架构是为了应对软件复杂度而提出的解决方案。 理解每个架构方案背后所需要解决的复杂点，才能对比自己业务复杂点，参考复杂点相似的方案。

架构即（重要）决策，是在一个有约束的盒子里去求解出或接近求解出最合适的解。 有约束的盒子=团队经验、成本、资源、进度、业务所处的阶段等编织、掺杂在一起的综合体（人，财，物，时间）。

架构无优劣，但是存在恰当的架构用在合适的软件系统中，而这些都是决策的结果。

04 小结

• 最大收获：认清了架构设计的主要目的是——为了解决软件系统功能复杂度带来的问题。
• 反过来说，如果要对一个新产品、项目开发进行架构设计，先需要结合需求、排出软件系统功能复杂度，
• 针对软件系统功能复杂度最高的部分进行架构选型、设计。