系统：泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能独立完成的工作能力的群体，关键词：

关联：系统是由一群有关联的个体组成的，没有关联的个体堆在一起不能成为一个系统。例如，把一个发动机和一台 PC 放在一起不能称之为一个系统，把发动机、底盘、轮胎、车架组合起来才能成为一台汽车。

规则：系统内的个体需要按照指定的规则运作，而不是单个个个体各自为政。规则规定了系统内个体分工和协作的方式。例如，汽车发动机负责产生动力，然后通过变速器和传动轴, 将动力输出到车轮上，从而驱动汽车前进。

能力：系统能力与个体能力有本质的差别，系统能力不是是个体能力之和，而是产生了新的能力。例如，汽车能够载重前进，而发动机、变速器、传动轴、车轮本身都不具备这样的能力。

子系统：也是由一群关联的个体组成的系统，多半是在更大的系统中的一部分。

都是系统的组成部分，从不同角度拆分系统而已。模块是逻辑单元，组件是物理单元。

模块就是从逻辑上将系统分解， 即分而治之， 将复杂问题简单化。模块的粒度可大可小， 可以是系统，几个子系统、某个服务、函数、类，方法、 功能块等等。划分模块的主要目的是职责分离。

组件可以包括应用服务、数据库、网络、物理机、还可以包括 MQ、容器、Nginx 等技术组件。划分组件的主要目的的是单元复用。"组件"的英文单词 Component，对应中文的"零件"一词，"零件"更容易理解一些。"零件"是一个物理的概念, 并且具备"独立且可替换"的特点。现在越来越多的 UI 设计使用组件化化和模块化。

框架通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范, 也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。

框架是组件实现的规范，例如：MVC、MVP、MVVM 等，是提供基础功能的产品，例如开源框架：Ruby on Rails、Spring、Laravel、Django 等，这是可以拿来直接使用或者在此基础上二次开发。再例如,SpringMVC 是 MVC 的开发框架，除了满足 MVC 的规范,Spring 提供了很多基础功能来帮助我们实现功能，包括注解(@Controller 等)、Spring Security、SpringJPA 等很多基础功能。

框架是规范，架构是结构：框架和架构的区别还是比较明显的，框架关注的是"规范", 架构关注的是"结构"：框架的英文是 Framework ，例如，SpringMVC 是"Web MVC Framework"；

架构的英文是 Architecture，例如，Linux 操作系统的架构。

在 TOGAF9 是这么定义：一个系统基本的构件(子系统, 模块, 组件)，体现在它的各个构件、构件间的相互关系、构件与环境间的关系，以及对系统设计和演进进行治理的原则中。两种含义：

一个系统的形式化描述，或指导系统实现的构件级的详细计划；

一组构件的结构、构件间的相互关系、以及对这些构件的设计和随时间演进的过程进行治理的一些原则和指导策略。

架构从字面意思上，是源于古代的建筑术语。把架构拆分成两个字“架”和“构”。“架”就是“加”和“木”的结合，把木头加起来、连接起来就是架。“构”就是结构的意思。所以，“架构”就是把“木“按照一定的结构连接起来。

总结一下架构的组成 = 要素 + 结构 + 连接，将系统要素按照特定结构进行连接交互。我在这重新定义架构(见仁见智，自己独立思考)：软件架构指软件系统顶层结构设计。架构是经过系统性地思考, 权衡利弊之后在现有资源约束下的最合理决策, 最终明确的系统骨架: 包括子系统, 模块, 组件. 以及他们之间协作关系, 约束规范, 指导原则. 并由它来指导系统各方面的设计和指导团队中的每个人思想层面上的一致。

涉及四方面：

1、系统性思考的合理决策：比如技术选型、解决实施方案(包括执行目标计划)、成本评估、性价比评估等等。

2、结构：明确的系统骨架（结构）：明确系统有哪些构件组成。

3、连接：系统协作关系：各个组成部分如何协作来实现业务请求。

4、规范：约束规范和指导原则：保证系统有序，高效、稳定运行，包括规范、原则、流程等内容。

在 EA 架构领域，有两种常见架构方法 RUP 和 TOGAF

1995 年，Philippe Kruchten 在《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文，引起了业界的极大关注，并最终被 RUP 采纳。即 RUP4+1 架构方法。该方法主要采用用例驱动，在软件生命周期的各个阶段对软件进行建模,从不同视角对系统进行解读，从而形成统一软件过程架构描述。该方法的不同架构视图承载不同的架构设计决策，支持不同的目标和用途。

逻辑视图：用于描述系统软件功能拆解后的组件关系,组件约束和边界,反映系统整体组成与系统如何构建的过程。关注功能和逻辑层。

开发视图：描述系统的模块划分和组成,以及细化到内部包的组成设计,服务于开发人员,反映系统开发实施过程。

物理视图：描述软件如何映射到硬件，反映系统在分布方面的设计，系统的组件是如何部署到一组可计算机器节点上,用于指导软件系统的部署实施过程。

处理流程视图：用于描述系统软件组件之间的通信时序,数据的输入输出,反映系统的功能流程与数据流程,通常由时序图和流程图表示。关注进程、线程、对象等运行时概念以及相关的并发、同步、通信等问题。

运用 4+1 视图方法：针对不同需求进行架构设计。

业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另一方面影响技术选型。熟悉业务，形成业务架构，根据业务架构，做出相应的应用架构，最后技术架构落地实施。

基础的产品框架脱胎于业务流程，但相比业务流程，更加注重产品功能的枚举、功能模块之间的分界。

当我们打开一个系统，我们会看到一个精美的页面，一些丰富的信息、导航。这些东西会引导我们去使用这个系统。这些东西就是这个系统的组成部分，就是这个系统的功能模块。产品架构，就是将这些不同用途的功能模块围绕特定的业务目标进行分类整合。

功能模块是用户能够完成一个操作的最小粒度的完整功能。比如一个展示可购买商品的列表页、一个修改用户密码的功能。在功能模块设计过程中，需要确保用户能通过一个功能模块完整的完成一项工作，而不是半个工作。

产品架构中，功能模块是根据其相互之间的关系来组织的。一个产品中不同的功能模块之间的关系分直接关系和间接关系。只有直接关系的功能模块才会被组织到一起，形成一个子系统。那些存在间接关系的模块，会在不同的层级通过直接关系的模块产生联系。

当具有直接关系的功能模块组合成一个子系统后，解决相同问题域的子系统就形成一个功能层级。功能层级按照接近用户实操的距离程度进行从上到下，或者从左至右的划分，这就形成了产品架构的分层。

应用架构是要说明产品架构分哪些应用系统，应用系统间是如何集成的。这就是应用架构和应用集成架构。应用架构在产品架构的基础上考虑两个事情：第一、考虑的是子系统间的关系。第二、考虑将可复用的组件或模块进行下沉，沉淀到平台层，为业务组件提供统一的支撑。类似：

数据架构指导数据库的设计. 不仅仅要考虑开发中涉及到的数据库，实体模型，也要考虑物理架构中数据存储的设计。

系统代码架构主要为开发人员提供切实可行的指导，如果代码架构设计不足，就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控。

代码架构主要定义内容：

一、代码单元:

1、配置设计 

2、框架、类库。

二、代码单元组织：

1、编码规范，编码的惯例 

2、项目模块划分 

3、顶层文件结构设计，比如 mvc 设计

4、依赖关系

应用架构本身只关心需要哪些应用系统，哪些平台来满足业务目标的需求，而不会关心在整个构建过程中你需要使用哪些技术。技术架构是应接应用架构的技术需求，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间的关系描述清楚。

技术架构：确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm 等），这些运行组件之间的关系，以及部署到硬件的策略。技术架构还要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这也是架构设计工作中最为困难的工作。

系统级，即整个系统内各部分的关系以及如何治理：分层。

应用级，即单个应用的整体架构，及其与系统内单个应用的关系等。

模块级，即应用内部的模块架构，如代码的模块化、数据和状态的管理等。

代码级，即从代码级别保障架构实施

业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构需要适配业务架构，并随着业务架构不断进化，同时应用架构依托技术架构最终落地。

1、《大型网站技术架构：核心原理与案例分析》

这是比较早，比较系统介绍大型网站技术架构的书，通俗易懂又充满智慧，即便你之前完全没接触过网站开发，通读前几章，也能快速获取到常见的网站技术架构及其应用场景。非常赞。

2、《亿级流量网站架构核心技术》

相比《大型网站技术架构》的高屋建瓴，开涛的这本《亿级流量网站架构核心技术》则落实到细节，网站架构中常见的各种技术，比如缓存、队列、线程池、代理……，统统都讲到了，而且配有核心代码。甚至连 Nginx 的配置都有！

如果你想在实现大流量网站时找参考技术和代码，这本书最合适啦。

3、《架构即未来》

这是一本“神书”啦，超越具体技术层面，着重剖析架构问题的根源，帮助我们弄清楚应该以何种方式管理、领导、组织和配置团队。

4、《分布式服务架构：原理、设计与实战》

这本书全面介绍了分布式服务架构的原理与设计，并结合作者在实施微服务架构过程中的实践经验，总结了保障线上服务健康、可靠的最佳方案，是一本架构级、实战型的重量级著作。