整体架构总览实战指南：四视图、C4模型与架构决策记录

作为一个做了十几年系统设计和研发的老兵我越来越觉得架构这个词被过度神化了。不少团队把架构设计等同于画几张漂亮的拓扑图或者开会时在白板上画几个框、几条线然后拍照发到群里就算完事。结果呢图是图代码是代码业务是业务各说各话。等到系统出问题要排查、新人要上手、新需求要评估影响范围时那份架构图根本派不上用场。归根结底缺的不是图是一份真正能承上启下的整体架构总览。03-01-架构篇-整体架构总览这个标题看起来简单但它其实是一个很关键的项目节点。它不是在写代码而是在为整个系统勾勒一张全局地图。这张地图决定了后续所有模块设计、接口定义、技术选型、资源配置的走向。这篇内容我会从实战视角出发把整体架构总览这件事彻底拆开讲清楚它到底应该包含什么、怎么落地、怎么用以及我在实操中踩过的坑和总结出来的经验。1. 一份架构总览到底在回答什么问题1.1 架构不是画盒子是给系统的寻宝图很多初学者以为架构就是一堆方框和箭头其实这是最大的误解。方框和箭头只是最终呈现出来的结果架构设计的核心是决策。整体架构总览要解决的本质上是一组关键问题这个系统到底包含哪些核心组成部分这些部分之间的边界在哪里谁依赖谁数据从哪里产生流经哪些环节最终落到哪里系统运行在什么样的基础设施之上依赖哪些外部服务如果某个部分出现问题影响范围有多大未来如果要扩展应该在哪个层面动手你可以把架构总览想象成一张寻宝图。没有它你只知道自己站在一个房间里手里可能还有某个房间的详细设计图但你不知道整个建筑有几层、楼梯在哪、哪些门是死路。做架构总览的目的就是把全局地图画清楚让团队里所有人都能建立一致的认知。我见过太多系统业务逻辑写得没问题模块划分也算清晰但整体就是缺乏一个统一的架构视角。结果就是A模块的开发不知道B模块依赖哪些接口前端不知道后端哪个服务真正持有数据运维不知道某个新服务应该部署在哪层。这些问题在项目早期可能不明显一旦到了系统联调、压测、故障排查阶段全部会爆发出来。1.2 总览、概览、详细设计三者的分工整体架构总览不是详细设计。它和概要设计、详细设计之间有明确的分工很多人混在一起导致文档臃肿又没人看。架构总览本文主角面向团队所有人包括开发、测试、运维、产品甚至新入职的同事。它回答的是系统长什么样颗粒度到子系统、核心模块、关键服务即可不需要深入到类级别。概要设计面向开发人员回答模块怎么拆、接口怎么定义、数据怎么存储颗粒度到模块、接口、表结构。详细设计面向具体开发任务的执行者回答这个类怎么写、这个方法怎么实现、这个流程怎么跑通颗粒度到类、方法、时序。三者之间是逐层递进的。总览是地基之上的框架框架定好了概要设计和详细设计才有依据。很多项目跳过了总览直接做详细设计结果每个模块内部都设计得很完美拼在一起却互相矛盾。这不是执行力的问题是缺少了最上层那个统一坐标系。2. 整体架构总览的核心构成四视图一主线2.1 业务视图先回答系统在为什么而活做架构总览的第一步一定不是画技术图而是先梳理业务视图。业务视图回答的是系统服务的核心业务是什么有哪些关键业务域用户角色有哪些核心业务流程长什么样举个例子一个电商系统业务域至少包括商品、订单、用户、支付、库存、营销。每个业务域内部有自己的核心流程比如订单要经历创建、支付、发货、收货、完成这些状态流转。整体架构总览中的业务视图不是把每个流程都画出来而是把业务域的边界、核心流转路径、业务与技术模块的对应关系呈现出来。我在实际项目中有一个很深的体会业务视图是整个架构总览的指南针。如果业务视图是错的后面所有技术视图都会跟着错。比如如果把用户和用户营销混在一个业务域里后续做用户服务拆分时就会纠结会员积分到底应该归用户中心还是归营销中心。这种边界问题必须在总览层面就明确不能在代码层面再争论。业务视图也不只是画给产品经理看的。开发人员同样需要业务视图来理解我写的这段代码到底支撑了业务的哪个环节。没有业务视角的技术人员写出来的代码往往是功能正确但难以演进的。2.2 应用视图模块边界与调用关系应用视图是整体架构总览中最热闹的部分它描述了系统由哪些应用或模块组成、谁调用谁、通信方式是什么。在单体架构时代应用视图通常表现为分层结构展示层、业务层、数据访问层。在微服务时代应用视图变成了一张服务调用网。画应用视图时最容易犯的毛病是把图画成满天星。每发现一个服务就画一个节点每有一条调用就画一条线最后整张图密不透风完全没法看。解决的办法是分层展示或者按业务域分组展示。我的习惯是第一层先画出网关、接入层、服务群、数据存储、外部依赖这几大类第二层再按业务域画出每个域内部的服务与应用。这样整体架构总览始终保持从高处俯瞰的视角不会陷入细节。应用视图里必须包含通信方式的说明。是HTTP调用、RPC调用还是消息队列异步通知这个信息如果缺失后续做性能优化、链路追踪、故障隔离时都会非常被动。另外调用方向必须清晰谁依赖谁、谁不能反向依赖谁这是架构治理的基础。2.3 数据视图数据如何流动数据视图是整体架构总览中最容易被人忽略、但价值最高的部分。它回答的是系统里的核心数据有哪些谁拥有数据的唯一权威来源数据如何在各个系统之间流动哪些数据需要强一致哪些可以最终一致我举一个常见的例子用户下单后订单系统扣减库存同时需要通知物流系统创建运单再通知财务系统生成账单。如果没有数据视图每个系统可能都认为自己存了一份数据就代表数据归自己管。结果就是用户改了收货地址订单系统更新了但物流系统还是旧的订单取消后库存还回去了但财务系统已经生成了账单。这些问题的根源是数据所有权和流转路径不清晰。在整体架构总览中数据视图可以用一张核心数据流转图来呈现。注意这里不需要画每张表的字段只需要把核心实体订单、支付单、库存流水、运单以及它们在系统间的流转路径画出来。同时要标注每个实体的数据权威源比如订单状态的权威源是订单服务、支付金额的权威源是支付服务。这个标注非常重要它直接决定了跨系统数据不一致时以谁为准。2.4 技术视图技术选型与基础设施技术视图是大家在聊架构时最先想到的部分它涵盖技术栈、基础设施、中间件、部署环境等内容。在整体架构总览层面技术视图不需要穷举所有技术点而是要把关键的技术决策和选型理由讲清楚。比如你选用了MySQL作为核心业务数据库那么在总览里应该说明为什么不用PostgreSQL是因为团队熟悉度、生态成熟度还是因为历史原因你引入Redis是用作缓存还是存储它的数据丢失容忍度是怎样的这些问题如果不在总览层面回答清楚后续每个项目组成员都会按自己的理解去使用这些组件早晚会出问题。技术视图还包括部署环境的描述。在总览里至少需要画出应用部署在哪里、中间件部署在哪里、数据存储放在哪层、网络如何分区。对很多团队来说这直接决定了后面做容器化改造、上云迁移、混合云部署时的具体方案。毫不夸张地说一份好的技术视图就是一张运维作战地图。3. 如何把架构总览落地成可维护的文档3.1 用C4模型分层建模前面讲了架构总览要包含四类核心内容但光有内容还不够还得有清晰的表达方法。我强烈推荐使用C4模型来组织整体架构总览的呈现方式。C4模型把架构分成四个抽象层级Context系统上下文系统与外部用户、外部系统的关系一页纸说清楚系统在生态中的位置。Container容器可独立部署运行的进程或存储单元比如Web应用、后台任务、数据库、消息队列。Component组件容器内部的模块、服务、组件颗粒度到可以对应到代码层面的模块。Code代码类级别的设计这部分属于详细设计范畴一般不在总览里展开。使用C4模型最大的好处是它强制你分层思考。很多人画架构图时习惯把所有东西塞进一张图有了C4模型你就知道系统上下文图是给管理层看的容器图是给开发和运维看的组件图是给某个模块开发者看的。每张图都有明确的读者和用途不会再信息过载。我在实操中一般会这样落地先画一张系统上下文图然后在总览文档里放1到2张容器图按业务域拆分画出组件图。这样一份整体架构总览就有了立体感而不是一张面条图。3.2 用Archimate描述架构元素之间的关系C4模型适合表达技术和应用架构但如果你要做更加企业级的架构总览ArchiMate是一个非常值得掌握的标准。它与C4的一个关键区别是ArchiMate不只关注技术视图它把业务架构、应用架构、技术架构、数据架构放在一张图上并且用标准化的元素和关系来描述它们之间的协作。什么是ArchiMate你可以把它理解为一套架构建模的语言规范。它定义了业务对象业务服务应用组件技术节点数据对象等元素以及元素之间的触发访问实现关联等关系。用ArchiMate表达出来的架构总览比随手画的Visio图要严谨得多因为它有明确的语义约束。比如你想表达销售订单业务服务由订单管理应用组件实现订单管理应用组件运行在Kubernetes集群上同时访问MySQL数据库中的订单数据表用ArchiMate就是一套标准化的连接关系。这套标准的好处是不会出现这个箭头到底表示数据流还是调用流这种歧义。当然我不建议所有团队都直接上ArchiMate它有一定的学习成本。但如果你的项目规模足够大或者要和外部团队、客户反复沟通架构ArchiMate绝对是值得投入的工具。3.3 架构决策记录ADR与规范约束整体架构总览不仅要有图和流程还要有决策上下文。很多团队总览文档里只写我们用了微服务架构用了消息队列但没有记录为什么微服务为什么用RocketMQ而不用Kafka结果半年后参与决策的人离职了新来的架构师看到现有架构百思不得其解为什么要拆得这么细当时是怎么想的ADRArchitecture Decision Record就是用来解决这个问题的。每个ADR只记录一个关键架构决策格式可以非常简单背景当前面临的问题是什么决策我们决定怎么做理由为什么是这个方案而不是那个方案后果这个决策带来了哪些正面和负面影响在整体架构总览里把关键决策对应的ADR编号引用进来比如1.2节应用视图中的服务拆分方案参考ADR-003。这样架构总览就不再是一个静态的快照而是一个有历史、有背景、可以演进的生命体。新加入的工程师看到总览时不仅能知道系统长什么样还能知道为什么长成这样这对团队知识传承的价值是巨大的。4. 常见架构风格与总览视角的适配4.1 单体与分层架构简单不等于落后聊架构总览绕不开单体与微服务的比较。我必须说明一个观点单体架构不是贬义词微服务也不等同于先进。整体架构总览的价值不在于你用了什么风格而在于你的总览是否如实、清晰、完整地描述了系统。单体架构的总体视图通常很简单一个应用、一个数据库、几个模块。这种架构下的总览重点不在服务划分而在于模块边界的定义和依赖方向的管控。我见过不少单体项目代码不分层模块之间互相直接调用service直接操作别人的表最后技术上明明没有微服务却在代码层面形成了分布式泥球。这种架构的总览图会非常难看因为根本画不出清晰的边界。分层架构是单体时代最经典的总览视角。展示层、业务层、数据访问层每一层只依赖下一层不跨层调用。到现在我依然觉得很多中小型项目使用分层架构是性价比最高的选择。它不需要引入复杂的服务治理不需要处理分布式事务调试和部署都很直接。做整体架构总览时千万不要为了画得复杂而把简单的系统强行复杂化那是对团队的折磨。4.2 分布式与微服务架构总览的复杂度陡增当系统进入分布式架构整体架构总览的复杂度会明显上升。微服务不是把单体拆成几个小服务就完事了在做出这个选择之前你得要在总览层面回答一系列问题服务如何注册与发现服务间通信是同步还是异步分布式事务怎么处理链路追踪怎么做如何做服务容错限流、熔断、降级数据一致性怎么保证每个服务独立的数据库还是共享数据库这些问题每一条都会直接影响整体架构总览的内容。比如服务间通信如果全走同步HTTP调用总览里就是一个同步调用网如果引入消息队列做异步削峰那总览里就要画出消息主题的拓扑以及每个主题的消费者是谁。我的一点建议是在做微服务架构的总览时不要试图把每个服务都单独画一个框那样图会非常拥挤。更好的做法是把服务的分组画出来比如订单域服务组用户域服务组然后在分组的框内标注有哪些服务。另外一定要画出基础设施层比如注册中心、配置中心、网关、日志中心、监控平台。这些看似不是业务服务但它们是微服务架构得以运转的底座缺了它们服务数量越多越混乱。4.3 DDD与六边形架构从业务边界出发的另一种总览方式在这几年的架构圈里DDD和六边形架构能见度一直很高。DDD的核心思想是架构不应该从技术分层出发而应该从业务领域出发。整体架构总览如果采用DDD的视角首先要呈现的不是服务和技术组件而是领域划分。一个典型的DDD架构总览会包含核心域、支撑域和通用域。订单、支付这类是核心域评价、优惠券可能是支撑域用户、权限这类是通用域。这种划分对技术决策有直接影响核心域值得投入最强的技术力量和最高的架构质量通用域可以引入现成的开源方案或第三方服务。六边形架构端口适配器架构则是从组件内部视角出发的架构风格。它把业务逻辑放在内核位置把外部依赖数据库、消息队列、Web接口当作可插拔的适配器。在整体架构总览里如果某些核心模块使用了六边形架构我会单独画出该模块的结构图展示哪些端口对外暴露、哪些适配器在依赖外部资源。这种图的价值在于它让团队清楚看到业务内核和外部依赖之间有一层隔离不至于在重构数据库时把业务逻辑也搅得一团乱。4.4 领域特定架构举例从车载到AI算力集群整体架构总览不只在互联网后端里存在。打开视野会发现各种领域都有自己特有的架构总览方式。在智能驾驶和车载电子架构中常能听到基于规则智驾架构、RCP、ZCU、SOC这类术语。这类系统的架构总览关注的是域控制器划分、功能安全等级、传感器数据的链路路径、执行器的控制下发流程。它们的技术方案与互联网后台很不一样但核心思路相同明确边界、明确依赖、明确数据流。在AI基础设施领域算力集群的架构总览则更侧重GPU集群拓扑、存储访问路径、分布式训练框架的并行策略DP、TP、PP、DPA。这些内容看起来离传统后端很远但本质上也是架构总览要解决的核心问题计算、存储、网络、调度如何协同。包括最近很火的Agent架构、LLMAPI架构、MoonCake架构、MoE架构它们整体架构总览的呈现方式各有特色但底层逻辑依然是业务链路、模块边界、数据流、基础设施这四个维度。掌握了一套通用的架构总览方法你就能相对从容地进入任何一个新领域。5. 实操经验从总览到落地的避坑指南5.1 架构总览与代码不一致怎么办这是几乎所有团队都会遇到的问题总览图画的是一套代码实现是另一套。原因很多元有可能是迭代过程中架构漂移了而没人更新文档也有可能是当初画图的人一厢情愿根本没有落实到代码评审里。我踩过几次坑之后给自己定了一条规矩架构总览不是一次性交付物而是和代码同步演化的活文档。具体做法是每次迭代排期时多问一句这个需求会不会影响架构总览的某个视图。如果会就必须在本次迭代内更新文档不允许攒到最后统一补。建立架构守护机制比如代码评审时邀请架构角色参与检查有没有破坏分层依赖、有没有绕过服务边界有没有违反ADR记录中的决策。定期做一次架构总览与实际代码的映射检查比如按模块核对服务数量、依赖关系、数据存储归属。如果你发现总览与代码已经严重不一致先不要急着画新图。第一步是考古找出从哪一个时点开始失真的是因为某个临时方案长期遗留还是因为一个捷径直改了数据表。把原因理清楚再动手更新否则你只是在画一张新的、仍然不符合事实的图。5.2 谁有权改架构图整体架构总览必须有一个明确的负责人通常叫架构负责人或者技术Owner。这个人不一定是职位最高的但一定是掌握全局视野、了解业务和技术两边上下文的人。我在实际工作中强烈建议建立架构总览变更记录。任何人发现问题有权利提出变更建议但真正动图、动总览文档的人只有架构负责人。原因很简单架构总览是全局性的修改某个模块的边界会影响到上下游多个团队的依赖。如果人人都能改最后一定是一堆互相矛盾的历史遗留。这个负责人还有一项重要职责做架构评审。我不是说要搞一个冗长的评审委员会而是至少在每个迭代的关键节点找相关技术骨干过一遍总览确认没有出现失控的蔓延。尤其是当团队规模变大之后架构总览文档就像一部宪法修订必须走流程不能随随便便改动。5.3 让新人15分钟读懂架构总览的技巧最后分享一个我觉得特别实用的经验一份好的架构总览应该做到让一个刚加入团队的技术新人在15分钟内建立起对系统的整体认知。这听起来容易做起来很难。我的做法是采用电梯讲解思路来组织总览内容。先从一页纸的系统上下文开始让新人知道我们的系统在生态中的位置、有哪些外部依赖、核心用户是谁。然后进入容器视图页面用几句话说清楚我们有几个应用、存储上用了什么、消息队列负责什么。最后再让新人带着好奇心去翻各业务域的组件图而不是强迫他一口气看完整个文档。还有一个技巧不要只有静态图。在总览文档中加入一个典型请求路径章节选一个最核心的业务流程从头到尾走一遍用户请求到达网关经过鉴权落到订单服务订单服务向商品服务查询库存扣减库存后发送消息再由异步任务生成本地数据存储。通过这样一个场景串联起来的架构讲述逻辑比单纯贴图有效得多。新人跟着这条路径走一遍比看十张架构图都更能理解系统的脉络。我在实际使用中还发现整体架构总览其实是一份流动的资产。它不只在项目启动时需要更在整个系统的生命周期里持续产生价值。新需求评估时翻翻总览知道改动会落在哪个模块故障排查时对照总览能快速缩小故障域线上复盘时追溯总览变更记录能还原决策现场。如果方法用对了你会发现架构总览不是给别人交差的文档而是你在一个系统里积累经验和持续演进的最佳载体。