专栏链接：https://time.geekbang.org/column/intro/100006601

架构设计的目的

架构设计的主要目的是为了解决软件系统复杂度带来的问题。

复杂度来源：

高性能、高可用、可扩展性、低成本、安全、规模

高性能

软件系统中高性能带来的复杂度主要体现在两方面:

• 一方面是单台计算机内部为了高性能带来的复杂度

• 另一方面是多台计算机集群为了高性能带来的复杂度

集群的复杂度

通过大量机器来提升性能，并不仅仅是增加机器这么简单

让多台机器配合起来达到高性能的目的，是一个复杂的任务：

• 任务分配：
  • 指每台机器都可以处理完整的业务任务，不同的任务分配到不同的机器上执行。
  • 能够突破单台机器处理性能的瓶颈，通过增加更多的机器来满足业务的性能需求。
• 任务分解：
  • 业务越来越复杂，单台机器处理的性能会越来越低。
  • 为了能够继续提升性能，需要采取第二种方式：任务分解。
  • 简单的系统更加容易做到高性能。
  • 可以针对单个任务进行扩展。

高可用

定义：系统无中断地执行其功能的能力，代表系统的可用性程度

• 是进行系统设计的准则之一。

本质上都是通过冗余来实现高可用。

基本概念

系统与子系统

系统：

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

子系统：

• 子系统是由一群有关联的个体所组成的系统，通常是更大系统中的一部分。

系统和子系统的概念相对比较容易理解

• 比如微信是个系统，聊天、朋友圈、公众号就是它比较重要的三个子系统。

架构和框架

软件架构：

• 架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

软件框架：

• 框架通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范

  • 也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。

• 框架的功能类似于基础设施，与具体的软件应用无关，但是提供并实现最为基础的软件架构和体系。

• 软件开发者通常依据特定的框架实现更为复杂的商业运用和业务逻辑。

• 这样的软件应用可以在支持同一种框架的软件系统中运行。

• 简而言之，框架就是制定一套规范或者规则，大家在该规范或者规则下工作。

架构和框架的概念比较相似，且两者通常都有比较强的关联。

框架强调的是规范以及与之相对应实现的基础软件产品。

• 架构强调的是整体结构，各组件或者模块的相互关系，是系统的顶层设计。

比如，经常说采用Spring MVC框架进行开发，是基于MVC架构的。

• 前者指的是具体的软件产品，后者指的是系统的整体结构。

架构通常又可以分为功能架构和技术架构。

功能架构

功能架构是从系统功能的角度来描述系统的整体结构，类似于建筑中的建筑设计

• 所以建筑图就是从功能方面来描述一个建筑，如一楼商场及其布局，二楼餐饮及其布局等。

技术架构

技术架构是从技术的角度来描述系统的整体结构，类似建筑中的结构设计，如钢筋、承重梁及其相互关系。

如一个图书管理系统，功能架构图示意如下：

技术架构图示意如下：

模块和组件

软件模块：

软件模块是一套一致而互相有紧密关连的软件组织，包含了程序和数据结构两个部分。

• 是现代软件开发往往利用模块作合成的单位。

模块的接口表达了由该模块提供的功能和调用它时所需的元素。

• 模块是可能分开地被编写的单位，能允许广泛人员同时协作、编写及研究不同的模块。

软件组件：

软件组件为定义为自包含的、可编程的、可重用的、与语言无关的软件单元。

• 软件组件可以很容易被用于组装应用程序中。

其实模块和组件都是系统的组成部分，只不过它们是从不同的角度来拆分系统。

• 模块是从功能的角度来拆分，组件是从物理或者说实现的技术角度来拆分。

划分模块的主要目的是职责分离，划分组件的主要目的是单元复用。

以图书管理系统来说，读者信息管理、书籍信息管理这些都是模块。

• 缓存组件、搜索引擎等就是组件。

子系统是独立运行的，模块是子系统的逻辑组成部分。

• 模块在一定条件下，变成独立运行，就转化为子系统。

举一个例子，比如在某个大型的商业广场，如果厕所和商场一起，那么厕所就是商场的一个模块。

如果厕所与商场分离，是独立的公共厕所，那么厕所就算是商业广场的子系统。

4R架构

软件架构指软件系统的顶层（Rank）结构

• 它定义了系统由哪些角色（Role）组成，角色之间的关系（Relation）和运作规则（Rule）。

第一个R，Rank：

• 它是指软件架构是分层的，对应系统和子系统的分层关系。

通常情况下，只需要关注某一层的架构，最多展示相邻两层的架构，而不需要把每一层的架构全部糅杂在一起。

无论是架构设计还是画架构图，都应该采取自顶向下，逐步细化的方式。

第二个R，Role：

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

第三个R，Relation：

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

第四个R，Rule：

• 它是指软件系统角色之间如何协作来完成系统功能。
• 系统能力不是个体能力之和，而是产生了新的能力。
• 那么这个新能力具体如何完成的呢？具体哪些角色参与了这个新能力呢？
  • 这就是Rule所要表达的内容。
  • 在架构设计的时候，核心的业务场景都需要设计Rule。

在实际工作中，为了方便理解，Rank、Role和Relation是通过系统架构图来展示的。

而Rule是通过系统序列图（System Sequence Diagram）来展示的。

以微信为例，Rank的含义如下所示：

以一个简化的支付系统为例，支付系统架构图如下所示：

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

架构设计

架构图

4+1视图

4+1视图的核心理念是从不同的角度去剖析系统，看看系统的结构是什么样的

具体每个视图的含义是：

• 逻辑视图：

  • 从终端用户角度看系统提供给用户的功能，对应 UML的 class 和 state diagrams。

• 处理视图：

  • 从动态的角度看系统的处理过程，对应 UML 的 sequence 和 activity diagrams。

• 开发视图：

  • 从程序员角度看系统的逻辑组成，对应 UML 的 package diagrams。

• 物理视图：

  • 从系统工程师角度看系统的物理组成，对应 UML 的 deployment diagrams。

• 场景视图：

  • 从用户角度看系统需要实现的需求，对应 UML 的 use case diagrams。

系统序列图

部署架构图

系统架构图

业务架构图