对于技术人员来说，“架构”是一个再常见不过的词了。咱们会对新员工培训整个零碎的架构，加入架构设计评审，学习业界开源零碎（例如，MySQL、Hadoop）的架构，钻研大公司的架构实现（例如，微信架构、淘宝架构）……尽管“架构”这个词常见，但如果深究一下“架构”到底指什么，大部分人兴许并不一定可能精确地答复。例如：架构和框架是什么关系？有什么区别？Linux 有架构，MySQL 有架构，JVM 也有架构，应用 Java 开发、MySQL 存储、跑在 Linux 上的业务零碎也有架构，应该关注哪个架构呢？微信有架构，微信的登录零碎也有架构，微信的领取零碎也有架构，当咱们谈微信架构时，到底是在谈什么架构？要想精确地答复这几个问题，关键在于梳理几个有关系而又类似的概念，包含：零碎与子系统、模块与组件、框架与架构。
零碎与子系统
咱们先来看维基百科定义的“零碎”。零碎泛指由一群有关联的个体组成，依据某种规定运作，能实现个别元件不能独自实现的工作的群体。它的意思是“总体”“整体”或“联盟”。我来提炼一下外面的要害内容：
关联：零碎是由一群有关联的个体组成的，没有关联的个体堆在一起不能成为一个零碎。例如，把一个发动机和一台 PC 放在一起不能称之为一个零碎，把发动机、底盘、轮胎、车架组合起来能力成为一台汽车。
规定：零碎内的个体须要依照指定的规定运作，而不是单个个体各自为政。规定规定了零碎内个体分工和合作的形式。例如，汽车发动机负责产生能源，而后通过变速器和传动轴，将能源输入到车轮上，从而驱动汽车后退。
能力：零碎能力与个体能力有实质的差异，零碎能力不是个体能力之和，而是产生了新的能力。例如，汽车可能载重后退，而发动机、变速器、传动轴、车轮自身都不具备这样的能力。
咱们再来看子系统的定义。子系统也是由一群有关联的个体所组成的零碎，多半会是更大零碎中的一部分。
其实子系统的定义和零碎定义是一样的，只是察看的角度有差别，一个零碎可能是另外一个更大零碎的子系统。
依照这个定义，零碎和子系统比拟容易了解。咱们以微信为例来做一个剖析。微信自身是一个零碎，蕴含聊天、登录、领取、朋友圈等子系统。朋友圈这个零碎又包含动静、评论、点赞等子系统。评论这个零碎可能又包含防刷子零碎、审核子系统、公布子系统、存储子系统。评论审核子系统不再蕴含业务意义上的子系统，而是包含各个模块或者组件，这些模块或者组件自身也是另外一个维度上的零碎。例如，MySQL、Redis 等是存储系统，但不是业务子系统。
模块与组件
模块和组件两个概念在理论工作中很容易混同，咱们常常可能听到相似这样的说法：MySQL 模块次要负责存储数据，而 ElasticSearch 模块次要负责数据搜寻。咱们有平安加密组件、有审核组件。App 的下载模块应用了第三方的组件。造成这种景象的次要起因是，模块与组件的定义并不好了解，也不能很好地进行辨别。咱们来看看这两者在维基百科上的定义。
软件模块（Module）是一套统一而相互有严密关连的软件组织。它别离蕴含了程序和数据结构两局部。古代软件开发往往利用模块作为合成的单位。模块的接口表白了由该模块提供的性能和调用它时所需的元素。模块是可能离开被编写的单位。这使它们可再用和容许人员同时合作、编写及钻研不同的模块。软件组件定义为自蕴含的、可编程的、可重用的、与语言无关的软件单元，软件组件能够很容易被用于组装应用程序中。
可能你看完这两个定义后一头雾水，还是不晓得这两者有什么区别。造成这种景象的根本原因是，模块和组件都是零碎的组成部分，只是从不同的角度拆分零碎而已。
从逻辑的角度来拆分零碎后，失去的单元就是“模块”；从物理的角度来拆分零碎后，失去的单元就是“组件”。划分模块的次要目标是职责拆散；划分组件的次要目标是单元复用。其实，“组件”的英文 component 也可翻译成中文的“整机”一词，“整机”更容易了解一些，“整机”是一个物理的概念，并且具备“独立且可替换”的特点。
我以一个最简略的网站零碎来为例。假如咱们要做一个学生信息管理系统，这个零碎从逻辑的角度来拆分，能够分为“登录注册模块”“个人信息模块”“集体问题模块”；从物理的角度来拆分，能够拆分为 Nginx、Web 服务器、MySQL。
框架与架构
框架是和架构比拟类似的概念，且两者有较强的关联关系，所以在理论工作中，这两个概念有时咱们容易分不清楚。参考维基百科上框架与架构的定义，我来解释两者的区别。
软件框架（Software framework）通常指的是为了实现某个业界规范或实现特定根本工作的软件组件标准，也指为了实现某个软件组件标准时，提供标准所要求之根底性能的软件产品。我来提炼一下其中要害局部：
框架是组件标准：例如，MVC 就是一种最常见的开发标准，相似的还有 MVP、MVVM、J2EE 等框架。框架提供根底性能的产品：例如，Spring MVC 是 MVC 的开发框架，除了满足 MVC 的标准，Spring 提供了很多根底性能来帮忙咱们实现性能，包含注解（@Controller 等）、Spring Security、Spring JPA 等很多根底性能。
软件架构指软件系统的“根底构造”，发明这些根底构造的准则，以及对这些构造的形容。单纯从定义的角度来看，框架和架构的区别还是比拟显著的，框架关注的是“标准”，架构关注的是“构造”。框架的英文是 Framework，架构的英文是 Architecture。Spring MVC 的英文文档题目就是“Web MVC framework”。尽管如此，在理论工作中咱们却常常碰到一些似是而非的说法。例如，“咱们的零碎是 MVC 架构”“咱们须要将 android app 重构为 MVP 架构”“咱们的零碎基于 SSH 框架开发”“咱们是 SSH 的架构”“XX 零碎是基于 Spring MVC 框架开发，规范的 MVC 架构”……到底什么说法是对的，什么说法是错的呢？
其实这些说法都是对的，造成这种景象的根本原因暗藏于架构的定义中，要害就是“根底构造”这个概念并没有明确说是从什么角度来合成的。采纳不同的角度或者维度，能够将零碎划分为不同的构造，其实我在“模块与组件”中的“学生管理系统”示例曾经蕴含了这点。从业务逻辑的角度合成，“学生管理系统”的架构是：
从物理部署的角度合成，“学生管理系统”的架构是：
从开发标准的角度合成，“学生管理系统”能够采纳规范的 MVC 框架来开发，因而架构又变成了 MVC 架构
这些“架构”，都是“学生管理系统”正确的架构，只是从不同的角度来合成而已，这也是 IBM 的 RUP 将软件架构视图分为驰名的“4+1 视图”的起因。
从新定义架构
参考维基百科的定义，我将架构从新定义为：软件架构指软件系统的顶层构造。
这个定义看似很简略，但蕴含的信息很丰盛，基本上把零碎、子系统、模块、组件、架构等概念都串起来了，我来具体解释一下。
首先，“零碎是一群关联个体组成”，这些“个体”能够是“子系统”“模块”“组件”等；架构须要明确零碎蕴含哪些“个体”。
其次，零碎中的个体须要“依据某种规定”运作，架构须要明确个体运作和合作的规定。
第三，维基百科定义的架构用到了“根底构造”这个说法，我改为“顶层构造”，能够更好地区分系统和子系统，防止将零碎架构和子系统架构混同在一起导致架构档次凌乱。