如何进行架构管控

架构管控

技术管理者如何进行架构管控

技术管理者如何进行架构管控

为什么要做架构管控

tbd

保证设计的延续性

tbd

及时掌握架构变更信息

tbd

如何开展架构管控

使用C4架构图保证架构设计的一致性

一、C4架构图
C4架构图是近年兴起的一种架构图，用来弥合从传统瀑布开发模式转到敏捷开发模式的实践中，设计文档可能缺失的问题。具体而言，在瀑布开发模式中，详细设计文档是事无巨细的，要么耗费大量的时间和精力（并且在开发过程中更改的设计还要导致多次修订），要么都是按照一个模板克隆出来，沦为摆设物；而在敏捷开发模式中，对敏捷一词的（有意或无意）误读又会导致一部分项目欠缺设计文档，造成后期维护困难。此外，无论哪一种模式，不同公司、不同项目组的技术架构图又是基于各自的理解，缺乏统一的格式和图例。在此情形下，C4架构图应运而生，它旨在以简洁易懂的方式描述系统的技术架构，既不要懒婆娘的裹脚又长又臭，又要把事情说清楚。总的来说，它是简洁主义、明确主义、重点主义的产物。

概念
核心是4种图：

C1（Context）：上下文图或曰系统（System）图，用来描述整个系统的主要功能。通常是4级图中最简洁的一个。
C2（Containers）：容器图，每个独立部署的单元是一个容器。典型的如前端†、移动端、后端（每个微服务是一个容器）。DB、中间件也画在这一级。
C3（Components）：组件图或曰模块（Module）图，组件图不必具体到代码层级上的单个组件（如Spring的Controller、Service等），而是逻辑模块，即程序中的一个独立单元，无论是业务的（纵向的）还是非业务的（横向的）。
C4（Code）：代码图，主要表现为UML类图和实体-关系图。
† 严格来说，前后端分离的单页应用（SPA），前端（或移动端）应视为两个容器：一个是服务端容器（Http Server），负责存储SPA以便用户下载；一个是客户端容器，即下载到用户浏览器里的SPA。下面要介绍的画图工具自身的示例就是这样做的。

这4个层级是递进的，如同一个地图的局部不断放大，看到越来越多的细节。一个Context里有多个Container，一个Container里有多个Component。因此，理论上，各层级的图形个数呈金字塔状，每一层都穷举上一层中所有的直接下层元素；但在实践中，我们通常挑重点的画。

示例如下（“工单辅助平台”是一个待做的小型项目，用来辅助相关角色发ITSM工单，以申请资源，还能查看自己的系统申请了哪些资源）：

其中第一个图（C1）为系统整体功能图，包括交互者、接口系统，见较浅蓝色框图所示。第二个图为该框图的细化：分成了3个Container，用虚线圈出。第三个图则是第二个图虚线框中中间那个后端API的细化图，分成了4个模块，同样用虚线圈出。每一级中，都同时画出与本级有直接交互的人和其它系统/容器/模块，并且尽量具体到本级元素（例如C3图中，外部系统“ITSM”直接与“工单生成”模块相连，“云管平台”系统直接与“资源管理”模块相连；但另一些无法具体到模块的，如“SPA（前端）”和“数据库”会同时和所有模块打交道，就只能连接到虚线框了，全连接的话线会太乱）。

注意事项：

C4图对于框和线怎么画、文字怎么写，没有严格的规定，只有一些约定俗成。
交互线是单向的，不需要画请求/响应形式的双向线。
C1层（系统）不要画得太简单——比如只画一个框——而要画上用户以及与之有交互的系统；当然，SSO、主数据等通用外部系统可不画。
C2层（容器）还可画上用于系统间交换信息的工具，典型的如message broker（kafka等）；它不属于单独某个业务系统，只是纯技术组件；不适合出现在C1和C3。
从C2层开始要标注具体技术（如JSON、REST、Vue、Spring Boot等）；对于连接线，我们可统一为 [协议, 数据格式] 的方式，举例如下：
一般前后端调用或微服务间调用：[HTTP, JSON]、[HTTPS, JSON]
往Redis、Kafka等中间件存取对象（用不同Serializer时）：[TCP, JSON]、[TCP, STR]、[TCP, BIN]
往SQL数据库存取对象：[JDBC, BIN]
总之，知道上层协议的填具体协议，不知道的填TCP（或UDP）；知道格式的填具体格式，不知道的填BIN或者TEXT（byte[]或者ByteBuffer序列化器填BIN，String序列化器填STR或TEXT）。
C3层（组件）可以只拣C2层最主要的容器来画。像数据库和中间件当然不需要画。注意：上面的示例中，由于后端只有一个微服务，所以C3层只有一个图；假如有N个微服务，那么C3层应该有N个图。
C4层（代码）不需要画。
每个图要标注是哪一层的图，如“C1. 一厂一策系统图”，“C3. 工单系统模块图”等。
注意风格（颜色）统一，即使不用PlantUML（见下面“工具”一节），也要使用与其一致的色调和图例，如本次关注的元素用蓝色调，外部系统/人员用灰色调。
该模型缺少子系统（Sub-system）的概念：比如SED是一个大的System，一厂一策是其中一个业务单元，可能不止包含一个微服务，只好也当作System画。