从零开始学架构——架构是啥子？

序言

架构这个词在这几年的开发过程中听过很多次，对它也有个大致的印象，比如我们设计的微服务架构把各个模块拆分开解耦，每一个模块都是独立的子系统，相同交互使用dubbo进行通信交互，有管理模块、交易模块、支付模块、评价模块、营销模块、优惠券模块等，各个模块组成的整体的App应用。但这都是别人已经设计好的架构，架构设计的思维方式和写代码有很大差异，我作为架构新手需要学习一点架构设计流程。所以从0开始学习入门。

目录

从5个大方向了解架构设计流程：

1. 架构基础：阐述架构相关概念以及架构本质；提炼三个架构设计原则；详细描述架构设计的标准流程和步骤；
2. 高性能架构模式：将介绍高性能数据库集群读写分离、分库分表两种方案，NoSQL方案的典型特征和应用场景，缓存的架构设计三大要点；介绍PPC、TPC、Reactor、Proactor模型提升性能，以及负载均衡的分类与架构、算法与优缺点。
3. 高可用架构模式：将介绍CAP原理的理解和应用、FMEA分析方法；从主备、主从、主主、集群、分区详解常见的高可用存储架构；给出如何设计高可用计算架构；使用异地多活方案保障业务高可用的技巧和步骤。
4. 可扩展架构模式：将概述可扩展模式及其基础思想，详解分层架构、SOA架构、微服务及微内核架构。
5. 架构实战：将理论与案例结合，在实战中落地专栏传递的架构原则、架构流程和架构模式。

架构是什么？

要理解架构是什么，先得把三组容易混淆的概念梳理清楚：
1）系统与子系统
2）模块与组件
3）框架与架构

系统与子系统

维基百科定义的“系统”：

系统泛指由一群有关连的个体组成，根据预先编排好的规则工作，能完成个别元件不能单独完成的工作的群体。

系统的三个素点

• 关联：必须是有关联的个体放一起才能成为系统。
• 规则：每个个体有各自的分工和协作方式，按照一定的规则运行。
• 能力：系统不是个体能力之和，而是产生新的能力。

“子系统”的定义：

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

模块与组件

软件模块在维基百科上的定义：

软件模块（Module）是一套一致而互相有紧密关连的软件组织。它包含了程序和数据结构两个部分。现代软件开发往往利用模块作为合成的单位。模块的接口表达了由该模块提供的功能和调用它时所需的元素。模块是可能分开地被编写的单位，能允许广泛人员同时协作、编写及研究不同的模块。

软件组件的定义：

软件组件（Component）定义为自包含的、可编程的、可重用的、与语言无关的软件单元，软件组件可以很容易被用于组装应用程序中。

模块和组件都是系统的组成部分，只是从不同的角度拆分系统而已。从业务逻辑的角度来拆分系统后，得到的单元就是模块。而从物理部署的角度来拆分系统后，得到的单元就是组件。划分模块的主要目的是职责分离；划分组件的主要目的是单元复用。

其实，组件的的英文Compoent也可以翻译成中文的“零件”，零件是一个物理概念，并且具备“独立可替换”的特点。

框架与架构

框架是和架构比较相似的概念，且两者有较强的关系，所以在实际工作中，这两个概念可以容易分不清。
先来看维基百科的定义：

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

其中的关键部分说的是框架是组件规范，而架构关注的是建筑结构，定义如下，

软件架构（Software Architecture）是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构会包括软件组件、组件之间的关系，组件特性以及组件间关系的特性。软件架构可以和建筑物的架构相比拟。软件架构是构建计算机软件，开发系统以及计划进行的基础，可以列出开发团队需要完成的任务。

框架和架构可能经常会有一些似是而非的说法，比如基于Spring MVC框架开发或者标准的MVC架构，两种说法都对，只是采用了不同的角度或维度来分解系统。以《学生管理系统》为例，
从业务逻辑的角度分解，学生管理系统的架构是：

从物理部署的角度分解，学生管理系统的架构师：

从开发规范的角度分解，学生管理系统是：

4R架构

参考维基百科的定义，软件系统架构可以定义为4R架构：软件架构指软件系统的顶层（Rank）结构，它定义了系统由哪些角色（Role）组成，角色之间的关系（Relation）和运作规则（Rule）。

Rank指软件架构是分层的，对应“系统”和“子系统”的分层关系。通常情况下，我们只需要关注某一层的架构，最多展示相邻两层的架构，而不需要把每一层的架构全部揉杂在一起。无论是架构设计还是画架构图，都应该采取自顶向下，逐步细化的方式。以微信为例，

Role指软件系统包含哪些角色，每个角色都会负责系统的一部分功能。架构设计最重要的工作之一就是将系统拆分为多个角色。最常见的微服务拆分其实就是将整体复杂的业务系统按照业务领域的方式，拆分为多个微服务，每个微服务就是系统的一个角色。有本比较火的书就叫《领域驱动设计》。

Relation指软件系统的角色之间的关系，对应到架构图中其实就是连接线，角色之间的关系不能乱连，任何关系最后都需要代码来实现，包括连接方式（HTTP、TCP、UDP和串口等）、数据协议（JSON、XML和二进制）以及具体的接口等。

Rule指软件系统角色之间如何协作来完成系统功能。前面解读系统时提到过——系统能力不是个体能力之和，而是产生了新的能力。Rule所要表达的就是如何产生这个新能力，哪些角色参与了这个新能力。Rule时通过系统序列图（System Sequence Diagram）来展示的。
以简化的支付系统为例，支付系统的架构图如下，

扫码支持的核心场景的系统序列图如下所示：

参考引用

该系列文章引用自极客时间《从 0 开始学架构》课程，参考链接：https://time.geekbang.org/column/intro/100006601