FAQ

Q：什么是架构？

A：架构就是对系统中的实体及实体间的关系的抽象描述。

Q：为什么要设计架构？

A：鲁迅说过：“那些精妙的方案之所以落不了地，是因为没有在设计上兼容人类的愚蠢。没有共识，不成方圆。不把人类的愚蠢拉到同一水平线上，蠢蛋们只会争论不休，最终屁事都干不成。”

Q：…… 那要怎么描述？

A：画架构图。

Q：为什么是画架构图？不能是其它的？

A：其它的其实也有，像写文档之类的，但是写文档这种方式不够直观，描述起来也很难，因为不能保证每个架构师都有深厚的文学功底、语言表达能力。而架构图是一种视觉呈现，其最终是以图像的形式完成输出，大部分人类对于图像的记忆、理解能力强于文字等（可能是人类用眼睛认识世界的时间已经久到无法考证了，而文字的出现才短短几千年吧 (:з」∠)）。

Q：怎么画好架构图？

A：↓↓↓↓↓

架构图分类

以下为 4 + 1 分类（还有其它的，本文不讲）。

场景视图

场景视图用于描述系统参与者与功能用例之间的关系，反映系统的最终需求和交互设计，通常由用例图表示。

逻辑视图

逻辑视图用于描述系统功能拆解后的组件关系、约束、边界；反映系统整体组成和构建过程；通常由 UML 的组件图和类图表示。

物理视图

物理视图用于描述系统与硬件的映射关系，反映出系统如何部署到机器节点上，用于指导系统部署的实施过程。

处理流程视图

处理流程视图用于描述系统组件间的通信时序、数据输入输出，反映的是系统的功能流程与数据流程，通常由书序图和流程图表示。

流程图不止是在技术领域用的多，在其它领域一样应用广泛。

开发视图

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

如何做好架构图

好架构图的标准：

• 明确受众
• 明确需要传达的信息

评价架构图做的好不好的点在于：受众有没有准确的接收到架构图作者想要传达的信息。

一个好的架构图是不需要解释的，它应该是自描述的，并且要具备一致性和足够的准确性，能够与代码相呼应。

成功不是一蹴而就的，不可能一上来就做出一份无瑕疵的图，上面的引用内容为终极标准，做图时尽量往上靠就行，不能因为过分强求而浪费过多时间。

如果一个图形表达不清楚，可以适当增加多个图。

前提

需要了解架构图中，多种常用图形、线条、箭头的意思。

方法

在学习架构图设计中，不难发现，我们所接触的架构图（即使是系统相似度 90% 以上的系统架构图）几乎很难能得出一种做图套路，因为每个架构师对系统的抽象层次是不一样的。所以每个架构设计新手都容易迷失在架构图海洋里。

C4-Model

官网
InfoQ

• C4 模型由一系列分层的架构组成
• C4 图的层次结构提供了不同的抽象级别（每种级别都与不同的受众有关）
  • 上下文（Context）
  • 容器（Container）
  • 组件（Component）
  • 代码（Code）
• C4 模型中没有预设任何特定的符号
  • 建议
    • 让每个元素都有名称、元素类型（人、系统、组件、容器）、技术选型（如果有的话）以及一些描述性文字
    • 为图标提供图例（显而易见的图例也需要，有助于消除歧义）；理想情况下，图例应该在每个细节上保持一致
      • 颜色
      • 形状
      • 首字母缩写
      • 线条样式
      • 边框
      • 尺寸
    • 为图例提供标题（描述图的类型和范围，如：网上银行系统的系统上下文图表）

上下文（Context）

上下文反映了正在构建的系统，以及系统与用户及其它软件系统之间的关系。

• 上图中，银行用户（Personal Banking Customer）使用互联网银行系统（Internet Banking System）（待构建：蓝色）查看银行账户信息等功能
• 互联网银行系统使用使用银行现有的大型银行系统（Mainframe Banking System）（已存在：灰色）来操作
• 互联网银行系统使用以后现有的邮件系统（E-mail System）（已存在：灰色）来给用户发送邮件

容器（Container）

容器图是将系统放大，显示组成改软件系统的容器（此容器非彼容器，指：应用程序、数据存储、微服务等）。技术决策、选型也是这个图中需要重点关注的部分。

• 上图中互联网银行系统（虚线框内）由五个容器组成
  • 服务器端 Web 应用（Web Application）
    • Java/Spring MVC Web 应用程序
      • 提供静态内容（包括单页应用的）
  • 客户端单页面应用（Single-Page Application）
    • Angular 程序
      • 提供所有网上银行功能（通过 API 服务）
  • 移动应用（Mobile Application）
    • Xamarin 跨平台移动应用
      • 提供部分网上银行功能（通过 API 服务）
  • 服务端 API 接口应用（API Application）
    • Java/Spring MVC 应用程序
      • 从数据库获得信息（用户信息）
      • 通过 XML/HTTPS 与现有大型银行系统通信（银行账户、交易信息）
      • 通过 SMTP 与邮件系统通信
      • 提供 JSON/HTTPS API
  • 数据库（Database）
    • 存储用户信息

组件（Component）

组件图将单个容器放大，以显示其中的组件。这些组件映射到代码中的真实抽象。

• 上图中由两个 Spring MVC Rest 控制器提供接口（JSON/HTTPS）服务
• 控制分别使用其它组件访问数据库和现有的大型银行系统

代码（Code）

代码图（有必要的话；通常情况下不建议创建这么细的图；部分 IDE 可以直接从代码中生成）放大组件，以显示该组件的实现方式。这种图由很多类组成，实现细节直接反映了代码。

C4-Model 使用（OSX + VSCode）

安装

Command: brew install graphviz

VSCode（Command + P）: ext install plantuml

Command: git clone http://github.com/RicardoNiepel/C4-PlantUML

使用

1. 创建 PlantUML 文件
2. 根据语法编写（使用 C4-Model 参考上文 git 仓库 Readme）
3. VSCode -> 代码窗口右键 -> Preview Current Diagram

C4-Model 扩展三图

System Landscape diagram（系统格局图）

本质上还是 Context 图，只不过站的角度更高一点。不局限于某个系统。

Dynamic diagram（动态图）

核心四图都属于静态图。动态图用于表达动态关系。可以存在于任何层级里面。本质上类似于时序图等。

Deployment diagram（部署图）

基本存在于 Container 层。用于表达容器部署在什么地方、什么操作系统上，部署了多少实例等信息。

参考

程序员必备技能：如何画好架构图？

用于软件架构的 C4 模型