架构，貌似对我们来说并不陌生，因为工作中时不时会提到架构，如今市面上也有各种XXX架构师的职位。
更多时候我们还会调侃架构师只是一群画图做PPT的人…但，我们真的理解什么是架构吗？
确实有必要梳理下概念，有个整体的认识，以便更好的深耕细分领域，共勉！
什么是架构
架构这个词起源于建筑，是一个比较宽泛的概念，业内也未有标准的定义。
架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。– 摘自百度百科
软件架构（Software Architecture）是一系列相关的抽象模式，从本质上来看，属于一种系统草图。
几个概念
软件架构中几个有关系而又相似的概念。
架构 与 设计
所有架构都是设计，但并非所有设计都是架构。架构反映了使一个系统成型的重要设计决策，而重要性则通过改变的成本来衡量。
从本质上讲，重要决策即架构，其他的都是设计。重要决策包括：
- 系统的形态，eg. 客户端-服务器、基于Web、原生移动客户端、分布式、异步等等。
- 软件系统的结构，eg. 组件、层、交互等等。
- 技术选择，eg. 编程语言、部署平台等等。
- 框架选择，eg. Web MVC框架、持久层/ORM框架等等。
- 设计方法/模式选择，eg. 针对性能、可伸缩性、可用性等的方法。
架构是软件的整体结构设计。
系统 和 子系统
系统是由相互作用相互依赖的若干组成部分结合而成的，具有特定功能的有机整体，而且这个有机整体又是它从属的更大系统的组成部分。– 摘自百度百科
系统是一个可以独立存在的完整实体，由一组完成特定任务的功能组成。
系统和子系统的概念是相对的，当作为另一个系统的一部分时，系统就成为一个子系统。
比如电商系统有支付系统、订单系统、用户系统等等子系统。
模块 和 组件
模块和组件都是系统的组成部分，只是从不同的角度拆分系统：
- 从逻辑层面，系统可拆分为各个模块，如 登录注册模块、权限管理模块等；划分模块是为了职责分离。
- 从物理层面，系统可拆分为各个组件，如 Web服务器、数据库、缓存中间件等；划分组件是为了单元复用。
另，模块和系统一般情况下没有本质区别，但是不能独立工作的模块一般不称之为系统。
框架 和 架构
软件框架（Software Framework），通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。– 摘自百度百科
框架是组件规范，eg. MVC、MVP、MVVM等开发规范；框架是提供基础功能的产品，eg. 国际化、日志记录等等。
框架关注的是“规范”，架构关注的是“结构”。
但很多时候，并没有完全界定，或者说框架是架构的具体实施。
架构的分类
按关注角度划分
- 逻辑架构
软件系统中元件之间的关系，如用户界面，数据库，外部系统接口，商业逻辑元件等。 - 物理架构
软件元件是怎样放到硬件上的。关注基础设施，如应用服务器、代理服务器、存储服务器、报表服务器、WEB服务器、网络分流器等。 - 系统架构
系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。
构架由许多不同的构架视图来表示，这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。
4+1 视图模型 是比较典型的架构视图集，最早由 Philippe Kruchten 提出，最终被 RUP 采纳，现已成为架构设计的结构标准。
“4+1”视图 从5个不同的视角来描述软件体系结构，包括：
- 逻辑视图（Logical View）
主要支持功能需求，使用面向对象进行分解。可以用UML的 类图、组件图、E-R图 来绘制。DDD领域驱动设计 属于面向对象的分解方法。 - 处理视图（Process View）
描述软件内各组件之间的通信时序，数据的输入输出，反映系统的功能流程与数据流程，通常用 时序图 和 流程图 来表示。
同时考虑非功能性需求，比如三高（高性能、高并发、高可用），并指导如何把逻辑视图的抽象融入到处理视图中，比如哪个线程来控制对象的实际执行。 - 开发视图（Development View）
关注软件开发环境下实际模块的组织。软件打包成小的程序块（程序库或子系统），子系统可以组织成分层结构，每一层为上一层提供良好定义的接口。
开发视图用模块和子系统来表达，展示输入输出关系。参考 C4模型 和 整洁架构（The Clean Architecture）。 - 物理视图（Physical View）
主要描述软件到硬件的映射。在UML中通常被称为 部署图。
通常需要针对不同的阶段（开发、测试、生产等）或不同的客户（PC端、移动端等）使用不同的物理配置，因此需要高度灵活以及对程序本身产生最小影响的运行平台，云计算和Docker之类的PaaS能够满足这样的要求。 - 场景（Scenarios）
四个视图中的元素通过场景进行无缝协同工作，场景可以 用例图、活动图 等UML图来表示。
每个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容。
TOGAF架构域
TOGAF，全称 The Open Group Architecture Framework（开放组体系结构框架），由国际标准权威组织 The Open Group 制定，是用于开发企业架构（Enterprise Architecture，简称 EA）的一套方法和工具。
最新版 TOGAF 9.2 于2018年4月发布（1995年开发、2009年推出TOGAF 9、2012年6月实施TOGAF 9.1），包括：架构开发方法（ADM）、架构能力框架、架构指引和技术、架构内容框架、企业连续系列和工具等一系列组件。其中，ADM是核心内容，详细介绍了构建企业架构所需要执行的各个步骤。
TOGAF的架构内容框架中定义了4个架构域：
- 业务架构（Business Architecture）
业务架构定义了业务策略、治理、组织和关键业务过程。它是企业架构的核心内容，承接了企业的战略，直接决定了企业战略的实现能力，是其他架构领域工作的前提条件。 - 数据架构（Data Architecture）
数据架构描述了企业的逻辑物理数据资产和数据管理资源的结构。 - 应用架构（Application Architecture）
应用架构为要部署的单个应用系统、它们之间的交互和它们与组织的核心业务流程之间的关系提供蓝图。应用架构和数据架构一起合称为信息系统架构。 - 技术架构（Technology Architecture）
技术架构描述了需要支持业务、数据和应用服务的部署的逻辑软硬件能力，包括IT基础设施、中间件、网络、通信、流程、标准等。
更多介绍内容可以参看《TOGAF概述及认证》。
常见的软件架构
O‘Reilly 出版的免费电子书《Software Architecture Patterns》（2015年2月出版，2017年6月第3次修订）介绍了5种常见的软件架构：
分层架构（Layered Architecture）
分层架构是最常见的软件架构。一般分4层：
- 表现层（Presentation）：用户界面，负责视觉和用户互动。
- 业务层（Business）：实现业务逻辑。
- 持久层（Persistence）：提供数据，SQL语句就放在这一层。
- 数据库（Database）：保存数据。
MVC的View层对应表现层、Dao层对应持久层、Controller层对应业务层，有时候一些MVC框架会根据需要在Dao和Controller之间加一层Service层，主要为简化和复用业务逻辑。
事件驱动架构（Event-Driven Architecture）
事件驱动架构是通过事件进行通信的软件架构，主要包含4部分：
- 事件队列（event queue）：接收事件的入口。
- 分发器（event mediator）：将不同的事件分发到不同的业务逻辑单元。
- 事件通道（event channel）：分发器与处理器之间的联系渠道。
- 事件处理器（event processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操作。
实现事件驱动架构最简单、直观的方式就是使用消息。
严格来讲，事件和消息不是一个概念：消息代表非直接交互时简短的信息，而事件往往代表状态的显著变化。
但，实际中，一个消息往往同时包含了事件和数据，eg. 订单创建成功后，系统发出消息，包含下单成功事件和订单ID等数据。
所以，消息中间件经常被用于事件驱动的架构实现。
微核架构（Microkernel Architecture）
微核架构，又称插件架构，指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。
内核通常只包含系统运行的最小功能。插件间彼此独立、较少通信，避免出现互相依赖的问题。
微核架构的最佳示例是Eclipse IDE：核心是一个编辑器，而只有在添加了各种插件之后，才成为一个高度可定制的、实用的产品。
微服务架构（Microservices Architecture）
微服务是一种分布式系统解决方案，主要围绕业务，领域建模。
微服务的特点是 - 小，专注做好一件事 & 自治性（松耦合、API通信）。
即，每一个服务就是一个独立的部署单元，这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST、SOAP）联系。
基于空间的架构（Space-Based Architecture）
基于空间的架构，也称 云架构，主要解决扩展性和并发的问题，是最容易扩展的架构。
业务处理能力封装成一个个处理单元，按访问量增减，以此来解决伸缩性问题。
高扩展性是通过去除中心数据库的限制，并使用 数据网格 来替代。
云架构有两个主要的模块：处理单元（Processing Unit） 和 虚拟化中间件（Virtualized Middleware）。
典型的处理单元包括应用模块、内存中数据（In-Memory Data）、为应用失败时准备的异步数据持久化模块 和 数据复制引擎（Data-Replication Engine，使得虚拟化中间件可以将处理单元修改的数据复制到其他活动的处理单元）。
虚拟化中间件本质上是架构的控制器，它管理请求、会话、数据复制、分布式的请求处理和处理单元的部署，包含4个架构组件：
- 通信网格（Messaging Grid）
管理用户请求和会话信息，当一个请求进来以后，决定分配给哪一个处理单元。 - 数据网格（Data Grid）
与各个处理单元的数据复制引擎交互，低延时（通常为微秒级）、异步并行的将数据复制到每一个处理单元（即 数据同步），以保障每个处理单元都有相同的内存中数据。 - 处理网格（Processing Grid）
可选，如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元，充当处理单元见数据传递的媒介。 - 部署管理器（Deployment Manager）
负责处理单元的动态启动和关闭，监控负载和响应时间，根据负载大小自动伸缩处理单元实例，是实现可变伸缩性需求的关键。
常见的架构模式
架构模式是一个通用的、可重用的解决方案，用于解决在给定上下文的软件体系结构中经常出现的问题。架构模式与软件设计模式类似，但具有更广泛的范围。– 摘自维基百科
- 分层模式
抽象是计算机科学中最为重要的概念之一。计算机系统提供不同层次的抽象表示，来隐藏实际实现的复杂性：
指令集是对CPU的抽象，文件是对I/O设备的抽象，虚拟内存是对程序存储器的抽象，进程是对一个正在运行的程序的抽象，而虚拟机是对整个计算机的抽象，包括操作系统、处理器和程序。– 《深入理解计算机系统》
分层是抽象的一种，通过层次把复杂的、可能变化的东西隔离开来，只能上下访问不能跨层访问，每一层都为下一层提供更高层次的服务。
比如，信息系统一般可划分为表示层（UI层）、应用层（服务层）、业务逻辑层（领域层）、数据访问层（持久化层）。
- 客户端-服务端模式
即，C/S（Client/Server）架构，桌面应用程序时期尤为盛行，随着互联网的兴起，B/S（Browser/Server）架构大行其道，但本质上是轻客户端的C/S架构。 - 主从设备模式
基于分而治之的思想，将任务分解为若干个语义等同的子任务，主设备分派子任务给各从设备，并整合各子任务处理结果。
在分布式系统中尤为常见，如分布式计算（eg. MapReduce）、分布式文件系统（eg. HDFS）等等。 - 管道-过滤器模式
管道-过滤器模式的体系结构是面向数据流的软件体系结构，最典型的应用是在编译系统。
一个普通的编译系统包括词法分析器、语法分析器、语义分析与中间代码生成器、优化器、目标代码生成器等一系列对源程序进行处理的过程。
可以将编译系统看作一系列过滤器的连接体，按照管道-过滤器的体系结构进行设计。
此模式类似于GoF设计模式中的责任链模式。 - 代理模式
用于构造具有解耦组件的分布式系统。
代理组件负责协调服务之前的通信：服务器向代理发布功能（服务和特征），客户端向代理请求服务，然后代理将客户端重定向到合适的服务。
eg. 微服务架构中，客户端请求网关（API Gateway），网关去注册中心查询服务地址，把请求转发给具体服务，即，网关+注册中心起到了反向代理的作用。
此模式类似于GoF设计模式中的代理模式。 - 点对点模式
即，P2P（Peer to Peer），单个组件被称为对等点。
对等点既可以作为客户端，从其他对等点请求服务；也可以作为服务器，为其他对等点提供服务。
P2P在下载（eg. BT）、区块链、分布式存储（eg. IPFS）等都有广泛应用。 - 事件总线模式
事件总线模式是一种广泛运用于Android开发的软件架构模式，包括4个主要组件：事件源、事件监听器、通道和事件总线。
事件源将产生的消息发送到事件总线的特定通道，监听器会事先订阅事件总线的不同的通道以区分消息的响应，然后当消息被发送到事件总线的特定通道时，对应的监听器会监听到消息，并执行在程序中与之绑定的响应函数。
此模式类似于GoF设计模式中的观察者模式。 - 模型-视图-控制器模式
即，MVC（Model-View-Controller）模式，主要用在Web应用程序的软件体系结构，比如Web框架等。 - 黑板模式
黑板模式是观察者模式的一个扩展，允许多个生产者/消费者共存，可以理解为消息的广播，主要解决生产者/消费者之间的耦合问题。
核心是消息存储，即黑板，它存储所有消息，并可以随时被读取。消费者只需要关注特定消息，不处理与自己无关的消息，这通常通过过滤器来实现。
黑板模式就好像多位不同的专家在同一块黑板上交流思想，每个专家都可以获得别的专家写在黑板上的信息，同时也可以用自己的分析去更新黑板上的信息，从而影响其它专家。
主要解决可分解成多个子问题，但每个子问题都属于不同的专业领域的问题，如视觉识别、图像识别、语音识别和监视等。
常见有两种实现方式：- 数据库作为黑板：生产者更新数据，不同的消费者共享数据库中的信息。
- 消息队列作为黑板：通过订阅-发布模型实现，即，消息主动推送给消费者。
- 解释器模式
类比GoF设计模式中的解释器模式。
所谓解释器模式，即，给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。
主要用于一些需要解释执行的场景，比如SQL语句，解释器分析SQL语句的文法，识别想要查找的数据元素并把它提取出来。
架构的演进
架构的核心价值在于能结合当下设计出最佳的体系结构，所以需要架构的演化以支撑不断变化的业务。
以服务端为例，基本是从 单体 到 分布式，最终上云。
若为分层架构，则每一层都可以进行横向或纵向的扩展。
常见的技术思路和演化过程可以参考这篇文章。
几个问题
MVC、MVP 和 MVVM 有什么区别？
- MVC，Model（模型）-View（视图）-Controller（控制器）
我们目前用的大部分Web框架都是MVC模式。
Model层，有时候包含DAO和ORM，再在这之上构建模型对象，eg. Java的Bean。
Controller层，有时候为了逻辑复用会分离出Service层。
View层，大多用模板引擎来渲染生成最终的HTML，但随着前端的发展及多终端述求，慢慢的从后端分离出去了，eg. 前后端分离结构。
虽说MVC中的View和Model可以交互，但一般不建议这样做，否则会增加代码耦合。 - MVP，Model（模型）-View（视图）-Presenter（表示器）
不同于MVC，MVP中的View不能直接访问Model，而是通过Presenter来调用。
Presenter负责接收View的输入并调用Model进行展示逻辑处理再反馈给View进行渲染，可以类比MVC中的Controller。
MVP模式在Android开发中运用的较多。 - MVVM，Model-View-ViewModel
ViewModel是Model和View的双向数据绑定，随着前端的发展，MVVM框架逐步盛行，eg. AngularJS、Vue.js等。
顺便提一下，Angular是通过指定事件触发脏检测实现双向绑定；
Vue是通过数据劫持（主要通过Object.defineProperty监听属性变化触发更新视图）与发布订阅相结合的方式实现双向绑定。
DAO、ORM、ActiveRecord 有什么区别？
DAO（Data Access Object，数据访问对象），抽象的数据访问接口，为不同的数据库提供统一的API。
ORM（Object-Relational Mapping，对象关系映射），把数据库里的数据映射为对象，用面向对象的方式访问数据库；
有些称 持久化框架，提供更多能力，如缓存处理、事务管理等，eg. Java中的MyBatis。
ActiveRecord（活动记录）是一种领域模型模式，兼具ORM能力。
SOA 和 微服务架构有什么区别？
SOA，全称 Service-Oriented Architecture，即 面向服务架构，服务间通过网络调用。
传统的SOA，如ESB（Enterprise Service Bus，企业服务总线）；微服务架构是SOA的升级。
ESB和微服务都是SOA的具体实现，但ESB注重服务聚合，微服务注重服务拆分。
什么是数据网格？与 RDBMS 和 NoSQL 有什么区别？
数据网格，又称 In-Memory Data Grid，IMDG，一般放在数据库之前，Web应用访问IMDG而不是数据库。
IMDG中的数据是一种可切分数据格式的领域对象模型，并且异步批量持久化到数据库。
一般使用ORM框架将IMDG中对象数据和RDBMS进行映射，eg. Hibernate、OpenJPA。
数据网格采用内存作为主要存储，意在低延迟，而NoSQL一般为分布式持久化存储，意在解决吞吐量。
正向代理 和 反向代理
正向反向指的是代理对象不同：
- 正向代理指客户端通过代理访问服务器，意在隐藏真实的请求客户端，FQ软件实际就是一个正向代理。
- 反向代理指服务器通过代理对外提供服务，意在隐藏真实的服务端，Nginx就是性能非常好的反向代理服务器，用来做负载均衡。
云计算跟 TOGAF 是什么关系？
云计算大致分为三类：IaaS（Infrastructure as a Service，基础设施即服务）、PaaS（Platform as a Service，平台即服务）、SaaS（Software as a Service，软件即服务）。
其中，IaaS可以对应到TOGAF的技术架构部分，即用IaaS作为企业的技术架构。
同样，PaaS对应IT架构（包括应用、数据、技术架构），企业可以在PaaS平台上快速、高质量的开发和实施企业级应用。
SaaS在业务架构层面为企业提供完整的软件或系统（eg. ERP、CRM等等），即无需关心IT架构，直接进行业务建模。
架构师的职业素养
美团技术团队的博客里有一篇文章提到了架构师能力模型：
总归来说，基于底层技术能力，逐步掌控提升技术领导力和项目/团队统筹管理能力。
- 编程能力
编程能力是技术人的基本功，本质上是把业务需求转换成机器语言。常见的如精通面向对象、设计模式等。 - 调试能力
调试是为了保障高质量的交付，良好的调试能力是高效编程的前提，如今可以借助于各种IDE里集成的调试工具来简化。 - 编译部署能力
运行环境的搭建及相关配置的调优，得益于CI/CD之类的工具，编译部署的工作简化了许多，但还是需要了解每个环节。 - 性能优化能力
为了提升体验，需要不断调优系统性能，各种性能指标的优化考核着综合技术能力，甚至于很多时候需要结合业务做权衡取舍。 - 在线运维能力
本质上是为了预防及快速解决线上故障，通常涉及监控、告警、快速恢复等，考验着技术细节、业务场景、处理规范等，需要通过大量实践来提升。 - 业务架构能力
架构是为了保障系统具备良好的伸缩以适应快速变化的市场需求，所以，了解业务、洞悉真实述求是架构的前提。
把抽象需求转换为可行的架构实施是架构师走向卓越的核心。 - 项目管理能力
通过运用完整的项目管理体系来保障项目实施，这是对事的全局掌控。
项目管理涵盖了较多的软实力要求，比如计划制定、过程推进、沟通协同、高效会议、风险把控、难点攻关等等。
具体到如敏捷开发（研发管理）、SMART原则（目标制定）、六顶思考帽（高效会议）等等。 - 团队管理能力
团队管理的一个核心是规划能力，包括项目规划和人员规划。
项目规划是为了制定符合多方利益的行动目标，以阶段性项目做推进。
所以，有的是自上而下拆解的项目，以符合公司的整体战略；有的是从自下而上制定的项目，以完善自身体系或补充上层目标。
人员规划本质是团队的能力配比，涵盖了人员培养、KPI/OKR、团队氛围（人员关系优化、技术分享…）等等。
另，今天看到一篇微信推文，“有商业意识的技术人，才有未来！”，技术或许能一条道走到黑，但或许有商业意识才能有更高格局！
参考资料
架构到底是指什么，https://zhuanlan.zhihu.com/p/57141837
软件架构的4+1视角模型简介，https://www.jdon.com/artichect/4+1view-architecture.html
软件架构入门，http://www.ruanyifeng.com/blog/2016/09/software-architecture.html
《软件架构模式》，https://www.codingsky.com/books/architecture-pattern/
数据网格，https://www.jdon.com/artichect/scalable9.html
软件架构漫谈：业务架构、应用架构与云基础架构
10种常见的软件架构模式，https://www.cnblogs.com/IcanFixIt/p/7518146.html
写给工程师的十条精进原则
服务端高并发分布式架构演进之路