整体架构总览：从分层到微服务，一张图看懂系统设计

很多朋友刚开始学架构时，第一个问题往往不是“某个框架怎么用”，而是这堆名词到底谁和谁有关系——微服务、DDD、六边形、事件驱动、服务网格、分布式事务，看着都认识，串不起来。我最近在整理一套架构方向的系列笔记，第一篇就是《整体架构总览》。这篇内容的核心价值，是把“架构”这个词从抽象落到具体：它由哪些层次组成，主流风格各自解决什么问题，常见行业的架构长什么样，以及怎么从零开始画出一张真正能被团队看懂的整体架构总览图。准备考系统架构设计师的同学、想从开发转架构的工程师、还有正被公司里那张谁也讲不清楚的技术架构图折磨的人，都值得把这篇当索引。

既然叫“总览”，就得先建立坐标系。没有这个坐标系，后面所有细节都容易漂。这篇不急着讲某个具体中间件，而是把整个架构版图摊开，让每个技术名词各归各位。等这个框架搭起来，你再去看分布式、DDD、AUTOSAR、AI算力集群，都能找到它们在全局中的位置。

1. 先搞清楚：整体架构总览到底在讲什么

1.1 为什么几乎所有架构课都把全景图放在第一章

你去一个陌生城市，不会先背每条街的名字，而是先打开地图，知道城市被几条主干道分成几块，河在哪儿，老城区在哪儿。软件系统架构也是一样。整体架构总览就是这张城市地图，它提供三个东西。

第一是坐标系。你听到“注册中心”“配置中心”“API网关”这些词，如果脑子里没有“这是微服务基础设施这一层的东西”的定位，听再多也记不住。总览能让你知道每个组件在哪个层次、服务谁、被谁依赖。

第二是边界感。系统不是一台机器，而是很多模块的协作。边界感指的是清楚系统的入口在哪里、内部有哪些逻辑分区、外部依赖有哪些、数据从哪里来到哪里去。没有边界感，做技术选型会只看单个工具好不好用，忽略它和上下游的兼容性。

第三是取舍锚点。架构是trade-off的艺术，没有绝对正确的架构，只有当前阶段最合适的架构。总览图把业务复杂度、团队规模、成本约束、扩展需求放在一张图里，你做决策时才有依据。没有锚点，就很容易跟风：看别人上微服务你也上，结果一个几十人的系统拆出几百个服务，运维成本直接爆掉。

1.2 一句人话理解架构：从盖房子到系统设计

给非科班的朋友打个比方。盖一个两层小楼，基本不需要设计院出全套结构图纸，凭经验就能干。但盖一百层的超高层，必须做完整的结构设计、风洞实验、承重计算，因为楼层越高、人越多、管线越复杂，任何一个局部的改动都可能影响整体稳定。

软件系统也是一个道理。一个教务管理系统、一个内部工具，用单体应用、几台服务器就能跑，这时候不需要复杂的微服务架构。但当你面对的是千万级日活、几十个团队同时开发、业务规则剧烈变化、故障影响面扩大到整条业务链时，就必须有一个整体的架构规划。

架构不是画出来的，是取舍出来的。这句话是我这些年最深的感受。所谓“架构”，本质上是回答一组问题：

• 系统分几层，谁依赖谁？
• 哪些逻辑必须放一起，哪些必须拆开？
• 数据怎么存储、怎么流转、谁来保障一致？
• 故障出现时，哪些部分能降级，哪些部分必须死扛？
• 团队规模和技术能力，撑得起这样的设计吗？

整体架构总览，就是把这些问题的答案浓缩成一张看得见的图。这张图的核心不是“长得好不好看”，而是“是否准确反映了系统的真实运行关系”。

1.3 这篇总览适合谁？能解决什么问题

第一类是备考系统架构设计师的人。这个考试上午题考概念，下午题考案例分析，论文题考整体设计能力。如果没有全局概念，光背“微服务、SOA、DDD”的定义是拿不到分的，你需要在纸上能画出结构、能讲清楚取舍理由。总览帮你把散落的知识点组装成可输出的系统图。

第二类是写了两三年代码、想往架构师方向走的开发者。你可能已经很熟悉某个框架了，Spring Cloud也好、Redis也好、消息队列也好，但不知道它们在全局里处于什么位置。只看树不见森林，是转架构前的最大障碍。总览能帮你把点状经验连成面。

第三类是正在主导或参与系统重构、却说不清楚当前系统全貌的人。公司里很多老系统没有架构文档，唯一参考是同事脑子里的记忆。这时候你需要一套从零梳理整体架构的方法，先把现状画出来，才有可能谈怎么改。

2. 架构的核心维度：先分四层，再谈风格

2.1 业务、数据、应用、技术四层架构，别混在一起画

我自己见过太多公司架构图，把“用户如何操作”“订单数据存哪里”“用的什么数据库”“部署在哪些机器上”全部画进一张图，结果谁也看不懂。根因是混淆了架构的不同维度。完整的架构视角至少包含四层。

业务架构描述企业的业务流程、角色分工和业务规则。比如电商里“用户下单”“商家发货”“平台对账”，这是业务流。它的产物是业务流程和需求清单，基本不涉及技术。

数据架构聚焦业务产生和依赖的数据，以及数据在系统间的流转关系。订单数据从哪个服务产生，同步到哪个分析平台，哪些数据是核心资产，怎么保证一致性，这是数据架构要回答的。很多系统崩在业务上，其实是数据模型没设计好。

应用架构是把业务流程落到具体模块和服务上。业务里“下单”这个动作，在应用架构里变成订单服务的某个接口；业务里的“库存扣减”，变成库存服务的一组逻辑。应用架构关注模块划分、接口定义、调用关系和部署单元。

技术架构是支撑应用落地的基础设施。数据库选MySQL还是PostgreSQL，缓存用Redis还是Memcached，消息队列用Kafka还是RabbitMQ，容器化用K8s还是裸机，监控用Prometheus还是Zabbix，都属于技术架构范畴。

四层的关系是逐层支撑的：业务定义需求，数据定义素材，应用定义逻辑，技术定义手段。一个正确的架构总览，应该先分区再填充，而不是一锅端。你在看任何架构图时，先问一句：这画的是业务、数据、应用还是技术？如果混着画，那这个图本身就值得重建。

2.2 从分层到微服务：架构风格的演化逻辑

架构风格不是被人凭空发明出来的，而是被问题逼出来的。最早的软件很简单，所有代码写在一起，就叫单体。后来代码太多，开始按功能分模块，再后来按层次分层：界面层、业务层、数据访问层。分层架构到现在也不过时，因为它解决了一个核心问题——让依赖关系有序。

再往后系统规模变大，不同模块的资源消耗和发布节奏差异很大。比如订单模块要频繁发版，用户模块相对稳定，把它们捆在同一个进程里，每次上线都要全量发布，风险大、频率低。于是出现了SOA（面向服务架构），把业务能力封装成粗粒度的服务，通过各种协议互相调用。SOA重在对企业级能力的复用，但往往太重，需要企业服务总线（ESB）做复杂路由，实施门槛高。

微服务可以看作SOA演进后的一个分支，但它更强调“按业务能力拆分为小而自治的服务”，每个服务独立部署、独立扩展、独立发布。拆得足够小，团队就能各自负责一块，不用等别人排期。代价是原来在一个进程内的函数调用变成了跨网络调用，分布式复杂性全部浮出水面。

从单体到分层再到微服务，演化的逻辑其实只有一句话：系统的复杂度超过单个部署单元能承载的极限，于是通过拆分来隔离变化和故障。但拆分不是免费的，后面会专门讲它的代价。

2.3 架构图里的“角色清单”：看到一张总览图先找这些

当你拿到一张整体架构总览图（不管是别人的还是自己的），不要急着看细节，先按角色清单去找要素。这是我多年练出来的习惯，基本能保证你不会漏掉关键部分。

顺序很重要。你先找到用户入口，然后顺着请求路径往右看，依次经过网关、应用、缓存、数据库；再看有没有消息队列拆出去的异步链路；最后看最底下的基础设施和旁边的监控运维。用这条路径走一遍，一张架构图的基本盘就能啃下来。

3. 主流架构风格全景：从单体到分布式再到智能体

3.1 单体、分层与模块化：小系统的正确选择

很多初学者听到“微服务”就兴奋，觉得单体架构是落后代表。这是典型的被热词带偏。单体最大的优点是简单：一个应用、一份代码、一套部署流程，开发调试都很直接。对早期项目、内部工具、团队人数很少的系统来说，单体是成本最低、交付最快的方案，没有之一。

单体并不意味着可以胡写。一个优秀的单体项目应该有清晰的分层和模块边界，比如严格遵循Controller→Service→DAO的结构，业务逻辑不许绕过服务层直接操作数据库。这种结构如果保持干净，后续拆分成微服务的成本其实非常低，因为模块边界已经划好了。

分层架构有经典的三层：表现层、业务层、数据层。在实际项目中还可以增加防腐层（Adapter），让你在调用外部系统时隔离变化。比如支付接口换了供应商，你只要改防腐层的适配代码，业务层完全不受影响。

选择单体不是终点，而是起点。我见过不少系统，业务规模上去了、团队从5人涨到50人，却在同一个代码仓库里互相踩脚，发布权限被滥用、每次上线都要全量回归。这时候再谈拆分，就不是“要不要拆”的问题，而是“怎么拆”的问题。但如果一开始就把模块之间的接口契约、数据归属定义清楚，拆分过程会顺畅很多。

3.2 分布式与微服务：规模变大后的必答题

当系统拆成多个服务，分布式的问题就来了：服务之间怎么找到对方？配置怎么统一管理？调用链路上出故障了怎么定位？这些不是框架能自动解决的事，而是架构设计必须补的配套。所以一个完整的微服务总览图，很少只有业务服务本身，旁边一定跟着一整套基础设施。

注册发现是基础。服务启动时把自己注册到注册中心（Nacos、Consul、Eureka），消费者通过注册中心拿到提供者地址。网关负责统一入口、鉴权和流量控制，避免每个服务暴露一堆外部接口。配置中心解决多环境配置漂移问题，最好做到配置变更不重启。链路追踪（SkyWalking、Zipkin）用于把一次跨多个服务的请求串成一条完整链路，否则分布式排查会让工程师崩溃。

分布式事务是微服务架构里的经典难题。最好不要强拆一个跨库事务到多个服务，而是先重新审视业务，让一个服务管理一个业务闭环，必要时允许最终一致性。事务消息、本地消息表、Seata这类AT/TCC模式都是常见解。以电商下单为例，你不可能让“扣库存”和“下订单”在同一个本地事务里完成，通常的做法是订单状态先置为“待支付”，通过事务消息驱动库存预留，后续再对账校正。

分布式定时任务也是很容易踩坑的地方。Spring里拿@Scheduled写个定时任务很简单，但服务一旦多实例部署，定时任务就会重复执行。这种“一锁了之”的问题需要统一调度平台解决，常见方案有xxl-job、ElasticJob 和 Quartz集群模式。调度平台负责分配任务给具体实例执行，并保证同一个任务同一时刻只有一个实例在跑，而不是每个服务自己各写一套调度逻辑。

3.3 六边形、整洁架构与DDD：让业务规则站在C位

微服务解决的是“物理拆分”的问题，DDD（领域驱动设计）解决的是“逻辑边界”的问题。在实际系统里最常见的毛病是：业务逻辑被技术细节包围，每个方法里先判断数据库连接、再处理JSON序列化、最后才弹出一段业务规则，久而久之，业务规则和技术实现完全纠缠在一起。六边形架构和整洁架构，都是把“业务内核”从“技术适配”中剥出来的设计思路。

六边形架构也叫端口-适配器架构。最里面是领域模型，承载业务规则；向外是一圈端口（接口定义），比如仓库接口、消息发送接口、鉴权接口；最外面是适配器，也就是具体技术实现，比如JPA的Repository、Kafka的Producer。核心领域不依赖任何外部技术，反过来外部技术都去实现端口。这样好处很明显：换数据库、换消息队列不会影响核心业务逻辑，业务代码可以直接做单元测试，不需要启动Spring容器。

DDD则给出了更完整的实践方法。战略设计阶段，你要和业务专家一起做事件风暴，梳理业务流程中的关键事件，圈出限界上下文，并明确每个上下文之间的合作关系，这是服务拆分的依据。战术设计阶段，在限界上下文内部定义实体、值对象、聚合根和领域服务，把复杂的业务规则写进领域模型，而不是散落在Service层。

很多人误以为用了DDD就等于架构先进。其实DDD只是给了你一套组织和建模的思路，关键在于你能不能在项目中找到真正复杂的业务内核。如果系统本质上就是一个简单的增删改查，套DDD只会增加概念负担，并不会提升交付速度。

3.4 事件驱动、云原生与Serverless：现代架构的加速度

事件驱动架构的核心是用事件来触发行为。订单创建成功后，系统发布一个“订单已创建”事件，下游积分服务、短信服务、搜索引擎各自异步消费。这让服务之间彻底解耦：上游不用关心下游是谁，下游挂了也不影响主流程。Kafka、RocketMQ、RabbitMQ是常用载体。

使用事件驱动的代价是，系统的数据一致性变成最终一致，并且排查问题时不能只盯着一条调用链，还得追踪事件流。在架构总览里，事件流和同步调用流应该用不同颜色画出来，否则图上全是箭头，谁也分不清哪些是强依赖、哪些是异步通知。

云原生这个词这两年被说烂，但核心内容其实很稳定：容器化、微服务、声明式API、服务网格和DevOps。以Kubernetes为底座，应用以容器镜像为交付物，具备弹性伸缩、自愈和滚动发布能力。服务网格（Istio、Linkerd）则把流量治理下沉到Sidecar，让业务代码不必关心熔断、超时、重试等逻辑。

Serverless进一步把“运维”两个字从开发者脑海里抹去。你只需要写函数，平台负责实例调度、弹性伸缩和计费。最适合Serverless的是突发性强、间歇式调用的场景，比如定时批量任务、Webhook处理、图片缩略图处理。对核心交易链路，用Serverless需要谨慎评估冷启动延迟和长连接支持。

3.5 Transformer、MoE与Agent：AI系统的架构总览

架构这个词并不局限于企业后端。最近几年AI系统成为热点，热搜里反复出现Transformer架构、MoE架构、Agent架构，也值得放进总览视野。

Transformer最初是一种模型骨架，解决序列建模中的长距离依赖问题。但要落地一个AI产品，只谈Transformer远远不够，还需要围绕它搭一套工程架构：数据管道负责采集清洗样本，训练集群负责跑模型，模型仓库管理版本，推理服务负责在线响应，再叠加反馈回环做模型迭代。所以AI产品画架构图时，从来不只有模型框图，而是包含数据、训练、推理、监控、评估的完整流水线。

MoE（混合专家）是当前大模型扩展算力的热门结构。它把一个大模型拆成多个“专家”子网络，由路由模块根据输入决定激活哪些专家。这种架构的收益在训练阶段和推理阶段都很明显：不需要每来一个token就让全部参数都计算一遍。缺点是对显存带宽和通信调度要求很高，基础设施架构要专门配合。

Agent架构则像传统系统里的“编排层”。大模型在这里充当大脑，它做规划，调用外部工具（搜索、代码解释器、数据库接口），并利用外部记忆库补足上下文。整套Agent系统的架构通常包含模型服务、工具注册中心、记忆存储、任务编排和可观测链路。对看过大量后端架构的人来说，Agent的很多问题其实不新鲜，依然是调度、状态、容错和扩展性的组合。

4. 几张真实的行业架构总览图

4.1 互联网应用架构：一套高并发系统的标准画法

互联网后端架构是大家最熟悉、也最常被拿来当学习样本的。一张标准的高并发互联网架构总览图，从入口到落地大概是这样。

流量先经过DNS解析和CDN，静态资源就近返回，动态请求到达全局负载均衡（SLB/云负载）。然后进网关层，网关负责统一的鉴权、限流、灰度路由。再往下是业务服务，按用户、订单、支付、商品等领域拆分。服务之间通过HTTP/RPC调用，注册中心负责服务发现，配置中心负责动态配置。

数据层再细分：缓存层用Redis扛读流量，数据库用MySQL配主从复制和读写分离，消息队列承担最终一致性和削峰。如果需要搜索引擎，会引入Elasticsearch；要是还做推荐、报表，则有实时计算Flink、离线计算Spark和数据仓库。

以抖音这类短视频系统为例，总览图里还会多出两条特殊链路。一条是上传链路：用户上传视频后，经转码、抽帧、审核、封面生成，然后写入对象存储和CDN；一条是分发链路：推荐系统需要实时读取用户特征，从海量内容库召回候选集，再排序后推给用户。这两条链路与常规用户服务并行，是抖音架构图中最核心的组成部分。

画这类图时一定要区分同步调用链和异步处理链。同步链是用户能感知的强依赖，必须保证低延迟和高可用；异步链允许延迟，可以长时间后台运行。我把这种区分当秘籍，总览图上两类箭头一旦混在一起，看起来全网都有依赖，实际上很多只是消息通知，根本不构成强耦合。

4.2 物联网三层架构：从终端、网络到云端的经典模型

物联网虽然行业分散，但架构总览出奇统一，基本都落在三层架构或扩展出来的四层架构上。三层分别是感知层、网络层、应用层。

感知层是终端设备，包括各类传感器、摄像头、PLC控制器、智能电表。这些设备能力参差不齐，有的能跑完整的操作系统，有的只有一个单片机跑裸机程序。感知层设备通过不同通信协议（MQTT、CoAP、Modbus、HTTP）接入网络层。

网络层负责传输和接入，核心是物联网网关和接入平台。网关的作用不光是透传数据，还包括协议转换、设备认证、边缘计算。很多AI图像类应用，摄像头采集后并不需要把每一帧都传云端，在边缘端完成人脸检测，只上传结构化结果，既省带宽又降低延迟。

应用层是物联网的价值出口。IoT平台一般包含三块：设备管理（连接状态、生命周期、固件OTA）、数据管理（规则引擎、时序数据库、告警）、业务应用（数字孪生、运维大屏、智能联动）。以智能家居为例，用户在App上关灯，这个请求进入云端的规则引擎，规则引擎再下发指令到家庭网关，网关转发给设备，整个过程就是一次典型的三层协作。各类工业监控系统也类似，只是把智能家居App换成了MES看板。

4.3 嵌入式与汽车电子架构：STM32、AUTOSAR与算法系统

嵌入式和汽车电子领域的“架构总览”跟互联网是两套语言，但层次逻辑高度一致。以经典的STM32单片机为例，系统架构简单说就是内核、总线矩阵和外围设备三部分。Cortex-M内核通过总线连接到Flash、RAM以及各类外设（GPIO、UART、I2C、DMA），整个系统运行在裸机或RTOS之上。学习STM32架构，本质是搞清“CPU怎么通过总线调度外设资源”，这和数据中心里“CPU怎么通过总线下发指令到存储”是同构的。

汽车电子领域，AUTOSAR是一个绕不开的标准。它的分层总览已经写进了标准文档里：最上面是应用层（SWC，软件组件），中间是运行时环境（RTE），下面是基础软件层（BSW），再往下是微控制器抽象层（MCAL）。RTE的存在让应用组件之间的通信独立于具体硬件，上层不知道自己是跑在哪个芯片上。这个思想跟互联网里的“依赖倒置”完全一致，只是汽车行业对功能安全要求极高，相关标准更严苛。

还有一套常见的车控架构是基于RCP（快速控制原型）的ZCU（区域控制器）方案。RCP的思路是把算法模型在PC上跑通，再目标部署到实车控制器。ZCU则是整车电子电气架构演进后出现的“区域汇流站”，代替过去几十个分散的ECU，把同一物理区域的传感器、执行器就近接入。

另外提一个最近频繁出现在课程设计里的例子：基于MATLAB OOP架构的多算法融合数字图像处理系统。这类系统的好玩之处在于，它证明了算法型项目同样需要架构总览。整体上分为：图像采集与预处理模块、算法库（每个算法封装成独立的OOP类）、融合调度层（按规则组合多种算法结果）和结果可视化模块。用MATLAB的OOP能力，把不同滤波算法、边缘检测算法抽象出统一接口，再用一个调度器根据图像场景选用不同方法，这套设计其实就是策略模式在MATLAB里的落地，对毕设和课设来说是很典型的“小而完整”的架构样板。

4.4 数据与算力基础设施架构：MySQL、虚拟化与AI集群

数据架构的技术底座通常从数据库开始。MySQL在热搜里反复出现，因为它本身就是一套经典的“分而治之”架构。最外层是连接层（连接管理、鉴权、线程处理），往里是服务层（SQL解析、优化、缓存），再往下是存储引擎层（InnoDB、MyISAM），最后是操作系统和文件系统。常见的MySQL主从复制，本质是让写流量走主库、读流量走从库，把性能和可用性分离。更进一步的分库分表，则是把数据按业务或哈希拆到多台机器上，解决单节点容量和压力问题。

服务器虚拟化是云时代基础设施的另一张总览图。以KVM为例，宿主机通过Linux内核模块创建虚拟机，再由libvirt库和daemon统一管理，这就是所谓的libvirt-daemon-kvm架构。上面可以再叠加OpenStack或K8s来提供资源调度。对运维和平台团队来说，这条链路就像一条“流水线”：物理机→虚拟化层→资源池→业务集群。物理机的CPU架构（x86或ARM）决定了虚拟机的指令集基线，部署时得关注镜像与架构的匹配。

AI算力集群的架构总览这两年也频繁出现在企业方案里。底层是GPU服务器和高速网络（RoCE或InfiniBand），中间是并行文件系统（Lustre、GPFS），上层是调度系统（Slurm、Kubernetes），再往上才是PyTorch、DeepSpeed这类训练框架。整套集群设计要解决三个核心问题：数据喂得快不够快、GPU之间通信带宽够不够、故障时能不能快速恢复。很多人只关注模型效果，忽略了集群架构，结果训练一跑起来就卡在I/O瓶颈上。

5. 从零梳理一张整体架构总览图的实操方法

5.1 四步走：找边界、理流程、列依赖、定分层

很多人拿到一个老系统，第一反应就是去看代码。代码当然要看，但不应该是第一步。我自己的方法是四步走。

第一步，找边界。明确这个系统服务谁、不服务谁，外部有哪些系统，哪些数据是要接收的，哪些能力是向外输出的。把系统画成一个盒子，盒子外就是环境边界。

第二步，理流程。画出用户或事件的核心流程。电商看下单流程，物联网看物联数据上行和指令下行流程，AI系统看训练和推理流程。流程图上标出每一步对应的系统模块，这时候模块清单就出来了。

第三步，列依赖。把流程中涉及的中间件、数据库、外部系统列出来。对每个依赖标注：强依赖还是弱依赖？同步还是异步？数据是单向流动还是双向同步？这样自然分出了关键路径。

第四步，定分层。按入口层、应用层、数据层、基础设施层把模块归位。此时不要追求完美，先画出来，哪怕有些组件不知道放哪，也找个“待定区”放着。之后再通过几次迭代修正。

画完草图，还要做一遍减法。把那些不影响主链路的监控告警、后台管理功能收进一个独立模块，不要让它们抢主线。总览图的价值在于让你30秒内抓住系统主干，而不是30分钟还找不到核心流程。

5.2 画图与写文档：C4模型和Archimate的实际用法

架构图不是画给自己看的，是为了沟通。不同沟通对象关注不同层级，这也是我在实践中特别推崇C4模型的原因。C4模型把系统分为四层：Context（系统上下文）、Container（容器）、Component（组件）、Code（代码）。

Context图适合面向业务方和老板，只画系统的大边界和外部依赖，让他们知道你的系统在整个企业里处在什么位置。Container图面向开发团队，画出一个系统内部的“可独立部署单元”，比如Web应用、APP、数据库、消息队列，这基本就是技术总览图。Component图面向同一个容器内的开发人员，画容器内部模块划分。Code图层面太低，通常只在讲某个关键算法时使用。

如果企业级架构建模需要更规范，可以用Archimate。Archimate定义了一整套元模型，包括业务层（组织结构、业务流程、业务对象）、应用层（应用服务、应用组件）、技术层（节点、系统软件、基础设施服务）以及元素之间的关系。举个例子：某个支付能力的架构中，业务层的“完成支付”流程由应用层的“支付应用服务”实现，而“支付应用服务”又运行在技术层的“应用服务器”节点上。Archimate的价值是让你把“业务—应用—技术”三层元素之间的关系显式化，避免张口闭口都是“系统”。

但我的建议是，普通团队先用C4加ADR就够用了，别急着上Introduce全套Archimate。只有架构规模达到企业级、需要跨部门沟通时，再引入Archimate 这类制式语言，否则流程改造成本会大于沟通收益。

5.3 用ADR记录决策：让架构总览不只是“一张好看的图”

总览图画完，很多人就放进Wiki吃灰了，等半年后一改，大家发现图和代码已经对不上。要想让架构总览长期有效，必须把“为什么这么设计”记录下来。这就是ADR（Architecture Decision Record，架构决策记录）。

一份ADR通常包含三段：背景（发生了什么问题，有什么约束）、决策（我们决定怎么干），后果（这样干的收益和代价是什么）。它不需要长篇大论，一个决策写半页就够了。比如“订单服务独立成模块”，背景是订单改动频繁、团队多人协作，决策是拆独立服务，后果是引入分布式一致性成本，但发布频率得到释放。

维护总览图的另一个教训是：架构图要有“负责人”。每张总览图由架构组或相关技术负责人认领，每次迭代评审时过一遍，确保图跟着系统一起演进。否则再好的总览也是废纸。

6. 常见问题与避坑经验

6.1 架构图越画越复杂，问题出在哪

我见过不少团队，架构图画得比作战地图还大，但没人能指出主链路是哪条。问题通常出在两点：把哪一层都想放一张图，以及把部署细节和逻辑结构混在一起。

破解方法是分层画图、每层不超过20个节点。一个面向总体汇报的架构图，最多体现到容器层，别把每个组件里面的类都画出来。物理部署和逻辑结构分离：逻辑视图描述模块分组和依赖方向，物理视图描述服务实例副本、机房容灾和网络分区。这两类信息混在一起是架构图变乱的最高频原因。

6.2 业务方和老板看不懂架构图

如果你给业务方讲架构一上来就抛“RPC”“注册中心”，他们看不懂很正常。记住沟通场景：给业务方讲系统上下文，讲“用户在App下单后，请求经过了几道最关键的环节”，而不是“Gateway的路由规则怎么配置”。用业务语言复述技术方案，才是架构师的基本功。

给上级汇报时，突出价值而不是复杂度。一张图上只保留与当前目标相关的部分。比如目标是稳定性，就突出容灾、降级、限流；目标是扩展性，就突出模块边界和扩展点设计。架构图不是知识竞赛试卷，而是决策辅助工具。

6.3 拿旧架构硬套新技术，架构迷信要不得

热词热度越高，越要冷静。微服务火的时候，有人把单体拆成十来个服务，结果连开发环境的部署都要等十分钟；DDD火的时候，有人把所有Service改成聚合根，反而把简单业务绕晕；Serverless火的时候，有人硬把长连接应用塞进函数计算，最后冷启动次数比调用次数还多。

架构选型的正确打开方式是看痛点。如果当前痛点在于“多个团队协作冲突、发布互相影响”，微服务的拆分对你真的有价值。如果当前痛点是“业务逻辑复杂多变、难以维护”，DDD的建模思路会帮到你。如果痛点只有“并发有点高”，那先做缓存、异步化、数据库优化，远比重构架构见效快、成本低。

我把这些年遇到的典型架构问题整理成一张速查表，方便大家自查：

我在实际踩坑中还有一个很管用的心得：架构总览图不是越细越好，而是越“对”越好。所谓对，就是图能准确回答四类问题——系统为谁服务、内部怎么分工、关键数据怎么流动、故障时谁先降级。只要围绕这四个问题去画，你的总览就算完成了使命。后续再针对其中任意一个点深挖，都能找到具体的架构知识去支撑。这也是我把“整体架构总览”放在整个系列最前面的理由：它是所有后续讨论的底图，值得多花时间打磨。