初探说明：
最近极客时间推出一个性价比很高的架构课程“从零开始学架构”，我抱着试一试学习的态度付钱了。于是就有了这个“从零开始学架构”的系列文章。
下面开始表演真正的技术吧。
干货开始
首先要明白 “架构”到底是什么鬼？
架构和框架是什么关系？有什么区别？
Linux 有架构，MySQL 有架构，JVM 也有架构，使用 Java 开发、MySQL 存储、跑在 Linux 上的业务系统也有架构，应该关注哪个架构呢？
微信有架构，微信的登录系统也有架构，微信的支付系统也有架构，当我们谈微信架构时，到底是在谈什么架构？
要解决以上几个问题，可以从如下几个具体概念的联系和区分入手：
系统与子系统、模块与组件、框架与架构。
一、 系统与子系统
维基百科定义的“系统”。
系统泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。它的意思是“总体”“整体”或“联盟”。
关联：系统是由一群有关联的个体组成的，没有关联的个体堆在一起不能成为一个系统。例如，把一个发动机和一台 PC 放在一起不能称之为一个系统，把发动机、底盘、轮胎、车架组合起来才能成为一台汽车。
规则：系统内的个体需要按照指定的规则运作，而不是单个个体各自为政。规则规定了系统内个体分工和协作的方式。例如，汽车发动机负责产生动力，然后通过变速器和传动轴，将动力输出到车轮上，从而驱动汽车前进。
能力：系统能力与个体能力有本质的差别，系统能力不是个体能力之和，而是产生了新的能力。例如，汽车能够载重前进，而发动机、变速器、传动轴、车轮本身都不具备这样的能力。
维基百科定义的“子系统”
子系统也是由一群有关联的个体所组成的系统，多半会是更大系统中的一部分。
其实子系统的定义和系统定义是一样的，只是观察的角度有差异，一个系统可能是另外一个更大系统的子系统。
然后我们以 微信 为例来做一个分析：
微信本身是一个系统，包含聊天、登录、支付、朋友圈等子系统。
朋友圈这个系统又包括动态、评论、点赞等子系统。
评论这个系统可能又包括防刷子系统、审核子系统、发布子系统、存储子系统。
评论审核子系统不再包含业务意义上的子系统，而是包括各个模块或者组件，这些模块或者组件本身也是另外一个维度上的系统。例如，MySQL、Redis 等是存储系统，但不是业务子系统。
二、 模块与组件
模块和组件两个概念在实际工作中很容易混淆，我们经常能够听到类似这样的说法：
1.MySQL 模块主要负责存储数据，而 ElasticSearch 模块主要负责数据搜索。
2.我们有安全加密组件、有审核组件。
3.App 的下载模块使用了第三方的组件。
造成这种现象的主要原因是，模块与组件的定义并不好理解，也不能很好地进行区分。
维基百科上 “模块” 的定义
软件模块（Module）是一套一致而互相有紧密关连的软件组织。它分别包含了程序和数据结构两部分。现代软件开发往往利用模块作为合成的单位。模块的接口表达了由该模块提供的功能和调用它时所需的元素。模块是可能分开被编写的单位。这使它们可再用和允许人员同时协作、编写及研究不同的模块。
维基百科上 “组件” 的定义
软件组件定义为自包含的、可编程的、可重用的、与语言无关的软件单元，软件组件可以很容易被用于组装应用程序中。
看上面两个概念还是一头雾水；根本原因在于：
模块和组件都是系统的组成部分，只是从不同的角度拆分系统而已。
1. 逻辑角度来拆分系统，得到的单元就是“模块”；(划分模块的主要目的是职责分离)
2. 物理的角度来拆分系统后，得到的单元就是“组件”。(划分组件的主要目的是单元复用)
其实，“组件” 的英文 component 也可翻译成中文的“零件”一词，“零件”更容易理解一些，“零件”是一个物理的概念，并且具备“独立且可替换”的特点。
举例说明（一个学生信息管理系统）：
这个系统从 逻辑 的角度来拆分，可以分为“登录注册模块”“个人信息模块”“个人成绩模块”；
从 物理 的角度来拆分，可以拆分为 Nginx、Web 服务器、MySQL。
三、框架与架构
框架定义：
软件框架（Software framework）通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。
提炼一下其中关键部分：
1.框架是组件规范：例如，MVC 就是一种最常见的开发规范，类似的还有 MVP、MVVM、J2EE 等框架。
2.框架提供基础功能的产品：例如：node.js中express框架是提供的 mvc 框架，满足了 MVC 规范;
Spring MVC 是 MVC 的开发框架，除了满足 MVC 的规范，Spring 提供了很多基础功能来帮助我们实现功能，包括注解（@Controller 等）、Spring Security、Spring JPA 等很多基础功能。架构定义：
软件架构指软件系统的“基础结构”，创造这些基础结构的准则，以及对这些结构的描述。
总的来说就是：
框架关注的是“规范”，架构关注的是“结构”
框架的英文是 Framework，架构的英文是 Architecture。Spring MVC 的英文文档标题就是“Web MVC framework”。
express 的英文文档标题 Node.js web application framework
虽然如此，在实际工作中我们却经常碰到一些似是而非的说法。例如，“我们的系统是 MVC 架构”“我们需要将 android app 重构为 MVP 架构”“我们的系统基于 SSH 框架开发”“我们是 SSH 的架构”“XX 系统是基于 Spring MVC 框架开发，标准的 MVC 架构”……
究竟什么说法是对的，什么说法是错的呢？
其实这些说法都是对的，造成这种现象的根本原因隐藏于架构的定义中，关键就是“基础结构”这个概念并没有明确说是从什么角度来分解的。采用不同的角度或者维度，可以将系统划分为不同的结构，其实我在“模块与组件”中的“学生管理系统”示例已经包含了这点。
“学生管理系统”示例：
从业务逻辑的角度分解，“学生管理系统”的架构是：
从物理部署的角度分解，“学生管理系统”的架构是：
从开发规范的角度分解，“学生管理系统”可以采用标准的 MVC 框架来开发，因此架构又变成了 MVC 架构：
这些“架构”，都是“学生管理系统”正确的架构，只是从不同的角度来分解而已，这也是 IBM 的 RUP 将软件架构视图分为著名的“4+1 视图”的原因。
关于 IBM 的 RUP 将软件架构视图分为著名的“4+1 视图” 这里挖一坑下次再填吧！
重新定义架构
“软件架构指软件系统的顶层结构”
这个定义看似很简单，但包含的信息很丰富，基本上把系统、子系统、模块、组件、架构等概念都串起来了，我来详细解释一下。
1.首先，“系统是一群关联个体组成”，这些“个体”可以是“子系统”“模块”“组件”等；架构需要明确系统包含哪些“个体”。
2.其次，系统中的个体需要“根据某种规则”运作，架构需要明确个体运作和协作的规则。
3.维基百科定义的架构用到了“基础结构”这个说法，我们改为“顶层结构”，可以更好地区分系统和子系统，避免将系统架构和子系统架构混淆在一起导致架构层次混乱。
小结：
梳理了与架构有关的几个容易混淆的概念，包括系统与子系统、模块与组件、框架与架构，解释了架构的定义
架构是顶层设计；框架是面向编程或配置的半成品；组件是从技术维度上的复用；模块是从业务维度上职责的划分；系统是相互协同可运行的实体。
系统与子系统：系统是由一系列有关联，按特定规则组成的个体，并且产生新的能力，而系统与子系统则是观察的交角度不同
模块与组件：模块是从逻辑角度去看待，而组件是从物理角度去看待
框架与架构：框架是规范也是约束，可以理解为封闭性的话题，定义好，让别人如何去使用，而架构是一种结构，是一种开放性的话题，如何去设计组织架构，如何让架构更具有拓展性，减少沟通错误成本