如何进行架构管控

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

为什么要做架构管控

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画。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。