架构到底是指什么？

在技术领域，“架构”一词极为普遍。新入职的技术人员会接受有关整个系统架构的培训，参与架构设计的评审过程，探索如MySQL、Hadoop这样的开源系统架构，以及分析大型企业如微信、淘宝的架构方案。

尽管架构这一术语被频繁使用，对于它的深层含义，很多人可能难以给出精确的定义。例如，架构与框架之间是什么关系、它们之间存在什么差异？Linux、MySQL和JVM都具有自己的架构，同样，基于Java开发、使用MySQL进行数据存储、在Linux系统上运行的业务系统也有其架构，我们应该重点关注哪一个架构呢？当谈论到微信的架构，是指微信整体的架构，还是指其登录或支付系统的架构？

为了准确回答关于“架构”的几个关键问题，必须先澄清一些经常混淆的概念，这些概念包括系统与子系统、模块与组件、以及框架与架构之间的区别和联系。下面，我们将探讨这些概念，尤其是系统与子系统的定义，以及它们在实际中的应用。

系统与子系统的理解

从维基百科的定义出发，我们可以提炼出关于“系统”的三个核心要素：

关联性：系统由相互关联的元素组成，这些元素单独存在时不构成系统。例如，发动机与PC单独放置时不形成系统，但发动机、底盘、轮胎和车架结合起来就构成了一辆汽车。

规则性：系统内的元素根据特定规则运作，而不是随意行动。这些规则定义了元素之间的分工与协作。比如在汽车中，发动机生成动力，通过变速器和传动轴将动力传递给轮胎，从而推动汽车前进。

能力性：系统的能力是全新的，不仅仅是构成它的元素能力的总和。比如汽车能够承载重物并前进，但是其单个组成部分，如发动机或轮胎，却不具备这种能力。

子系统的定义与系统的定义相同，但观察的角度不同。一个系统可以是另一个更大系统的子系统。这个概念有助于我们更好地理解复杂系统的层次结构。

以微信为例进行分析：

微信是一个包含聊天、登录、支付、朋友圈等多个子系统的综合系统。

朋友圈自身可以视为一个系统，它下面又包含动态发布、评论、点赞等子系统。

评论系统可能进一步包括防刷、审核、发布、存储等子系统。

在这种分析框架下，系统可以被看作是由相关联元素组成的整体，这些元素根据一定的规则协同工作，实现单个元素无法单独完成的功能。而子系统则是构成更大系统一部分的系统，通常也由相互关联的元素组成，但在更大的系统框架内发挥作用。

在更细的层面上，如评论审核子系统，它可能不再包含业务意义上的子系统，而是由多个模块或组件构成，这些模块或组件在另一个维度上也被视为系统，如MySQL、Redis等存储系统，尽管它们不直接构成业务子系统。

模块和组件

在日常工作中，技术人员经常讨论模块和组件，但这两个概念容易被混淆。原因在于模块和组件的定义较为抽象，难以明确区分。尽管如此，理解这两者之间的区别对于系统设计至关重要。

根据维基百科的定义，模块和组件都是系统构建的基本单元，但它们从不同维度对系统进行拆分。如果我们从逻辑角度对系统进行划分，得到的就是“模块”。模块的分割侧重于实现职责的分离，目的是让系统的每一部分都有明确的职责。而从物理角度拆分系统时，我们得到的是“组件”。组件的划分旨在实现单元的复用性，强调的是组件的独立性和可替换性。

在中文中，“组件”的英文“component”也可以翻译为“零件”，这个词从物理含义上更易于理解。零件是具体的、物理存在的单元，它们是独立的且可以被替换的。

以构建一个简单的网站系统——学生信息管理系统为例。从逻辑角度划分，这个系统可以分为几个模块，比如“登录注册模块”、“个人信息模块”、“个人成绩模块”。这样的划分侧重于系统内部的逻辑功能分区。从物理角度划分，系统可以被拆分为几个组件，如Nginx、Web服务器、MySQL等。这种划分关注于系统的物理结构，即系统的不同部分是如何在物理层面上相互独立并可能被复用的。

总的来说，模块是逻辑上的划分，强调功能和职责的分离；而组件则是物理上的划分，关注于实现的独立性和可复用性。理解这一区别有助于更合理地设计和构建系统。

框架和架构

架与架构这两个概念在技术领域中经常被提及，且两者之间存在密切关联，这在实际应用中有时会导致一些混淆。通过参考维基百科上关于框架与架构的定义，可以对两者进行区分，并理解它们的不同之处。

框架（Framework）和架构（Architecture）的关键差异可概括如下：

框架定义为组件规范：框架提供了一种或多种开发规范，例如MVC（模型-视图-控制器），此外还有MVP（模型-视图-演示者）、MVVM（模型-视图-视图模型）、J2EE等。这些都是规定了如何组织代码或组件的方法。

框架作为提供基础功能的产品：以Spring MVC为例，它不仅遵循MVC规范，还提供了一系列基础功能，如注解系统（@Controller等）、Spring Security、Spring JPA等，这些功能帮助开发者更便捷地实现应用功能。

从定义来看，框架更多关注于为软件开发提供规范和工具的“基础设施”，而架构则关注于软件的“结构”设计，涉及到软件各部分的组织方式以及这些部分间的关系。

尽管定义上有明确的区分，实际工作中的语言使用却更加灵活。例如，“我们的系统采用MVC架构”、“我们需要将Android应用重构为MVP架构”、“我们的系统基于SSH（Struts-Spring-Hibernate）框架开发”等说法，在实践中都是可接受的。这些表述的混用并不一定是错误的，反而反映了架构与框架在实际应用中的紧密联系。

导致这种现象的根本原因在于，架构定义中的“基础结构”概念并没有严格限定分解的角度或维度。这意味着，根据不同的角度或需求，同一个系统可以被描述为采用了某种特定的“架构”或是建立在某个“框架”之上。比如之前提到的“学生信息管理系统”例子，既可以讨论其使用的技术框架，也可以从架构设计的角度来分析它。

重新定义架构

参考维基百科的定义，我将架构重新定义为：软件架构指软件系统的顶层结构。这个定义看似很简单，但包含的信息很丰富，基本上把系统、子系统、模块、组件、架构等概念都串起来了，我来详细解释一下。首先，“系统是一群关联个体组成”，这些“个体”可以是“子系统”“模块”“组件”等；架构需要明确系统包含哪些“个体”。

其次，系统中的个体需要“根据某种规则”运作，架构需要明确个体运作和协作的规则。

从重新定义架构业务逻辑的角度分解，“学生管理系统”的