一、架构是什么
在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。在不同的书籍上, 不同的作者, 对于架构的定义也不统一, 角度不同, 定义不同。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前，我们先讨论架构的概念定义, 因为概念是人认识这个世界的基础和用来沟通的手段，如果对架构概念理解不一样，那沟通起来自然不顺畅。
Linux 有架构，MySQL 有架构，JVM 也有架构，使用 Java 开发、MySQL 存储、跑在 Linux 上的业务系统也有架构，应该关注哪一个？想要清楚以上问题需要梳理几个有关系又相似的概念：系统与子系统、模块与组建、框架与架构。
1.1 系统与子系统
1.1.1 系统
泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能独立完成的工作能力的群体。
关键词：关联、规则、能力
1.1.1.1 关联
系统是由一群有关联的个体组成的，没有关联的个体堆在一起不能成为一个系统。例如，把一个发动机和一台 PC 放在一起不能称之为一个系统，把发动机、底盘、轮胎、车架组合起来才能成为一台汽车。
1.1.1.2 规则
系统内的个体需要按照指定的规则运作，而不是单个个体各自为政。规则规定了系统内个体分工和协作的方式。例如，汽车发动机负责产生动力，然后通过变速器和传动轴, 将动力输出到车轮上，从而驱动汽车前进。
1.1.1.3 能力
系统能力与个体能力有本质的差别，系统能力不是是个体能力之和，而是产生了新的能力。例如，汽车能够载重前进，而发动机、变速器、传动轴、车轮本身都不具备这样的能力。
1.1.2 子系统
也是由一群关联的个体组成的系统，多半是在更大的系统中的一部分。
1.2 模块与组件
都是系统的组成部分，从不同角度拆分系统而已。模块是逻辑单元，组件是物理单元。
1.2.1 模块
模块就是从逻辑上将系统分解， 即分而治之， 将复杂问题简单化。模块的粒度可大可小， 可以是系统，几个子系统、某个服务，函数， 类，方法、 功能块等等。划分模块的主要目的是职责分离。
1.2.2 组件
组件可以包括应用服务、数据库、网络、物理机、还可以包括 MQ、容器、Nginx 等技术组件。划分组件的主要目的的是单元复用。"组件"的英文单词 Component，对应中文的"零件"一词，"零件"更容易理解一些。"零件"是一个物理的概念, 并且具备"独立且可替换"的特点。
1.3 框架与架构
1.3.1 框架
框架通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范, 也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。
框架是组件实现的规范，例如：MVC、MVP、MVVM 等，是提供基础功能的产品，例如开源框架：Ruby on Rails、Spring、Laravel、Django 等，这是可以拿来直接使用或者在此基础上二次开发。再例如,SpringMVC 是 MVC 的开发框架，除了满足 MVC 的规范,Spring 提供了很多基础功能来帮助我们实现功能，包括注解(@Controller 等)、Spring Security、SpringJPA 等很多基础功能。
1.3.2 架构
1.3.2.1 架构定义
在 TOGAF9 是这么定义：一个系统基本的构件(子系统, 模块, 组件)，体现在它的各个构件、构件间的相互关系、构件与环境间的关系，以及对系统设计和演进进行治理的原则中。两种含义：
* 一个系统的形式化描述，或指导系统实现的构件级的详细计划；
* 一组构件的结构、构件间的相互关系、以及对这些构件的设计和随时间演进的过程进行治理的一些原则和指导策略。
架构从字面意思上，是源于古代的建筑术语。把架构拆分成两个字“架”和“构”。“架”就是“加”和“木”的结合，把木头加起来、连接起来就是架。“构”就是结构的意思。所以，“架构”就是把“木“按照一定的结构连接起来。
1.3.2.2 架构组成
1.3.2.2.1 要素
对应到软件架构，“木”代表构件(要素)，“结构”代表架构的产物：
木就是系统中的要素，我们将他们称之为架构构件(要素)。架构要素可以是**子系统、模块、应用服务、组件**。
1.3.2.2.2 结构
**结构**，是架构的产物。不同的软件系统会有不同的结构，这些结构是为解决不同场景而设计的。
1.3.2.2.3 连接
**连接**，通过定义架构元素之间的接口和交互关系、集成机制，实现架构元素之间的连接。连接可以是分布式调用、进程间调用、组件之间的交互关系等。
1.3.2.3 总结
总结一下架构的组成 = 要素 + 结构 + 连接，将系统要素按照特定结构进行连接交互。
1.3.2.4 我对架构的理解
我在这重新定义架构(见仁见智，自己独立思考)：软件架构指软件系统顶层结构设计。架构是经过系统性地思考，权衡利弊之后在现有资源约束下的最合理决策，最终明确的系统骨架：包括子系统，模块， 组件。 以及他们之间协作关系，约束规范， 指导原则. 并由它来指导系统各方面的设计和指导团队中的每个人思想层面上的一致。
1.3.2.4.1 系统性思考的合理决策
比如技术选型、解决实施方案(包括执行目标计划)、成本评估、性价比评估等等。
1.3.2.4.2 结构
明确的系统骨架（结构）：明确系统有哪些构件组成。
1.3.2.4.3 连接
系统协作关系：各个组成部分如何协作来实现业务请求。
1.3.2.4.4 规范
约束规范和指导原则：保证系统有序，高效、稳定运行，包括规范、原则、流程等内容。
二、架构设计的目的
2.1 无架构设计带来的问题
如果没有架构设计，说明你的系统不够复杂。随着业务的增长，系统由单体应用渐进演化为分布式和微服务化。系统整体的复杂性越来越高，技术团队可能从一个团队变成多个专业化团队。假如没有架构设计，系统定会是一个无序失控的状态。
2.1.1 应用服务的边界不是很清晰
到底该怎么拆分没有一个明确的原则，研发人员为了所谓微服务化而拆分，而不是从当前业务考虑。导致系统无序的状态，开发效率低。
2.1.2 应用服务层次不清晰，系统耦合严重
导致服务依赖出现网状依赖结构，牵一发动全身，后续修改和扩展困难。
2.1.3 系统应用服务跟踪问题
由于微服务化后，系统逻辑复杂，服务出现问题后，你很难快速的定位问题和修复。比如之前我们踩过不少坑，我们使用 dubbo 服务化，系统一旦出现问题，一推人手忙脚乱。
2.1.4 系统服务监控问题
由于研发人员基本没有服务监控意识，都是出现问题后再想办法如何添加服务监控接口。
2.1.5 技术体系失控问题
不同的开发团队使用不同的技术栈或者组件，造成公司内部的技术架构失控。甚至研发人员为追求时髦新潮技术，拿应用项目来试验新技术。
2.2 架构设计的作用
架构设计的目的是为了解决系统复杂性带来的问题，其本质就是对系统进行有序化地重构以致符合当前业务的发展，并可以快速扩展。
2.2.1 系统性思考的合理决策
2.2.2 明确的系统骨架
2.2.3 系统协作关系
2.2.4 约束规范和指导原则
2.3 架构设计的目的
架构的本质是管理和解决系统的复杂性，提高效率。
2.3.1 管理复杂性
对系统进行有序化重构，不断减少系统的“熵”，使系统不断进化，改善软件质量为目的的内在结构性变化
2.3.2 提高效率
对系统进行有序化重构，以符合当前业务的发展，并可以快速扩展。
2.4 架构设计的前提条件
无论是何种变化，架构师通过理解业务，全局把控，权衡业务需求和技术实现，选择合适技术，解决关键问题、指导研发落地实施，促进业务发展，提高效率。那什么样的系统要考虑做架构设计? 技术不会平白无故的出和自驱动发展起来，而架构的发展和需求是基于业务的驱动。
