不知道大家平常在学习架构的时候，是否有问过自己一个问题，什么是架构，我们真的理解架构吗？该如何去培养自己的架构思维？今天我结合《Fundamentals of Software Architecture》一书展开聊聊。
什么是架构
与其讲架构定义，不如我们先来看以下一张图：
图片通过上述我们可以看到，软件架构师所承担的责任以及范畴都十分庞大且还在持续扩大中，比如当前如日中天的AI大模型，作为架构师，我们至少要了解AI大模型基础知识，比如Prompt提示工程、RAG工作原理、模型微调、MCP以及A2A等知识，当我们对这些知识建立到自己的认知系统之后，我们就需要思考如何将这些知识与我们的业务需求结合起来去解决我们业务交付过程中面临的问题。即架构涉及的范围广，我们需要建立起快速学习并扩宽知识的广度。
其次就是我们软件生态正是一个迅速发展且不断演变的过程，软件架构是一个不断变化的目标。如今给出的任何定义，在几年后都极有可能过时。维基百科对软件架构的定义提供了一个合理的概述，但其中很多表述已经过时了，比如“软件架构关乎做出根本性的结构选择，而这些选择一旦实施，要进行更改的成本是很高的”。但是架构师们在设计诸如微服务这样的现代架构风格时，融入了渐进式构建的理念——在微服务中进行结构更改不再成本高昂。
第三是软件架构资料存在历史意义，即很多过往架构师采用有效的解决方案在如今可能会失效，甚至会产生副作用，因为环境发生了变化，过去我们解决的方案如今却成为我们要解决的问题。因此当我们看对应的软件架构资料时候需要注意一点就是要理解对应的业务背景，即我们需要识别到当时的背景，设计的思路、采用的决策以及后续影响。
从上面分析我们都看到，架构一词很难进行定义，就如在著名的白皮书《Who Needs an Architect?》中，马丁·福勒（Martin Fowler）就以拒绝尝试对软件架构进行定义而闻名，他引用了拉尔夫·约翰逊（Ralph Johnson）的那句名言来回应：
Architecture is about the important stuff…whatever that is. 翻译为架构关乎重要的事情……不管那重要的事情具体是什么。 ——拉尔夫·约翰逊
这个时候我们再来看什么是架构，其实这个定义并不重要，反而是我们要关注重要的事情，什么是重要的事情？就是我们在学习架构的时候要关注当下的背景以及对应的实际环境情况，这个时候我们谈论架构才有意义，所有架构都是其所处背景的产物。
就好比我们的微服务架构，在20世纪后期架构的主要目标之一是最有效地利用共享资源，因为当时所有的基础设施都很昂贵且是商业化的：操作系统、应用服务器、数据库服务器等等，如果在那个环境下说我要构建一个微服务架构，那架构的成本肯定高得难以想象；但是如今我们要来构建一个微服务架构却很容易，为什么？因为期间开源技术的崛起以及DevOps的变更带来的工程实践才得让我们的微服务架构落地。
什么是架构思维
通过上述的阐述，其实我们可以提取几个关键词，涵盖范畴广、持续变化、特定背景以及关注重要的事情。那么这个时候我们就需要有一种架构思维来辅助我们进行软件架构的方式，即思考在面临持续变化的环境下，就特定背景下我们如何去扩宽我们的架构知识解决实际业务中重要的事情。
那有什么样的软件思考方式呢？可以从以下四个维度去进行思考我们的软件架构：
图片什么是架构风格
对于架构风格，我想可以换一个词，那就是系统的结构，即如何去描述系统的结构，我相信大多数都比较熟悉，比如分层架构，微服务架构，微内核架构甚至是管道过滤架构等等，这些都是属于架构风格，那么我们培养自己的架构思维之一就是要了解有哪些架构风格，比如以下不同的架构风格：
图片什么是架构特征
对于架构特征，我相信大家也并不陌生，比如高可用是一个架构特征，高性能也是一个架构特征，那架构特征作用是什么呢？架构特征定义了一个系统的成功标准，这通常与系统的功能是相互独立的，它也是我们建立业务需求过程中不可缺少的因素，通过它我们可以澄清我们的需求不确定性，通过它我们也可以识别到我们的架构复杂度主要是什么。但请注意，所列出的所有特征并不需要了解系统的功能，然而为了使系统能够正常运行，这些特性却是必不可少的。
那可运维性是架构特征吗？可以认为是。为啥这么描述呢？因为它是一个比较泛化的概念，建议我们在进行架构设计的时候还是量化一下具体的指标，比如易部署性，可理解性以及可测试性等都是可运维性的一个表现，当我们拆分为具体的细化特征的时候，我们就有对应的工具手段来度量我们的特征，比如可测试性我们可以通过UT覆盖率以及可观测性指标等来衡量，而可理解性可以通过文档完整性以及代码可读性等来衡量，因此架构特征主要包含但不限于如下：
图片什么是架构决策
架构决策规定了构建系统应遵循的规则，换言之我们可以理解为它是架构设计过程制定的一种约束。什么意思呢？
在分层架构中，只有业务层和服务层可以访问数据库，限制表示层直接调用数据库。架构决策构成了系统的约束条件，并指导开发团队明确哪些操作是被允许的，哪些是不被允许的。如下图所示：
图片什么是设计原则
设计原则是一种指导方针，而不是绝对的硬性规则（提供解决问题的方向）。也可以理解为架构模式或者设计模式，架构是更高层次，采用架构模式来辅助我们更好地进行架构，比如在分层架构中我采用三层架构模式对系统进行拆分为表示层、控制层以及模型层；再比如我采用静态工厂创建设计模式来平替我们对象创建模式，这样一可以提升可读性，二是与构造方法不同，不需要每次调用时都创建一个对象，三是可以其可以返回任何子类型的对象，提升了灵活性。
再比如在微服务架构中，开发团队应利用服务之间的异步消息传递来提高性能。架构决策（规则/约束）永远无法涵盖服务之间通信的所有情况和选项，因此可以使用设计原则来为首选方法（在这种情况下是异步消息传递）提供指导，以便开发人员在特定情况下选择更合适的通信协议（如REST或gRPC）。如下：
图片总结
尽管我们软件架构复杂多变，但是仍然存在统一的要素，比如我们可以利用上述架构思维中包含的四个维度去思考我们的软件架构，这个时候就有了我们软件架构的第一法则，即：
Everything in software architecture is a trade-off. 即软件架构中的一切都是一种权衡取舍。 ——软件架构第一法则
对于软件架构师来说，没有什么是处于美好、纯粹的状态。每一个决策都必须考虑到许多相互矛盾的因素。如果一位架构师认为自己发现了某件不存在权衡取舍的事情，那么很可能只是他们还没有发现其中的权衡之处。
我们对软件架构的定义不仅仅局限于结构框架，还融入了各种原则、特性等等。架构的范畴比单纯的结构元素组合更为广泛，这体现在我们的软件架构第二法则中：
Why is more important than how. 即为什么做比怎么做更重要。 ——软件架构第二法则