企业官网建设流程全解析

画架构图这件事，我见过两种极端。一种是三分钟出一张，几个方框一摆、几根箭头一连，看着挺像那么回事，但真拿去讨论问题时，谁都说不清那个"用户中心"到底是服务还是数据库；另一种是精益求精，光图例就定义了十几种颜色，评审时大家花了四十分钟争论箭头该不该带圆角。两种都跑偏了。架构图既不是随手涂鸦的示意图，也不是美术作品，它本质上是一次针对特定读者的信息压缩——把脑子里那套复杂的系统结构，压缩成一张能被目标读者在三分钟内抓住重点的图。

我真正开始理解这件事，是在一次线上故障复盘会上。当时大家对着监控和日志吵了两个小时，最后有位同事在白板上画了七个框、五条线，五分钟把请求链路和数据落点讲清楚了，所有人瞬间安静。那张图没有颜色、没有图标、方框画得歪歪扭扭，但它精确回答了"一次写请求到底经过哪些环节、在哪一步可能丢数据"这个问题。从那天起我就认定，评价一张架构图好坏的唯一标准，是它能不能一次性消除读者心里的疑问，而不是好不好看。

这篇内容围绕"实际场景架构图"展开：怎么判断当下该画哪一种图、骨架怎么搭、边界画在哪里、连线怎么标、容量参数怎么估、工具怎么选、评审现场会被问什么、怎么让图在三个月后还不至于变成历史遗迹。受众我按三类人准备——刚接手项目、需要把脑子里的系统倒出来对齐的新人；要写设计文档、被要求"附一张架构图"的中级开发；以及需要拿图去跟运维、数据、上下游团队谈判的负责人。文中所有场景都是脱敏重构后的虚构案例，参数是估算口径，你可以直接套公式换成自己的数。

1. 动笔之前先定坐标：这张图到底给谁看

我踩过最多次的坑，是打开绘图工具就开始摆方框。这个动作跟写代码不先想接口就直接敲 main 函数是一个性质。绘图工具一旦打开，人的注意力就会从"我要表达什么"滑向"这个框放左边还是右边"，最后图是画完了，但它回答的其实是一个没人问过的问题。

正确的顺序是先定坐标：这张图服务的是哪一次沟通，读者是谁，他看完之后要能做出什么判断。是让老板批准一笔预算，还是让隔壁团队确认接口能不能对齐，还是让自己三个月后接手时能快速回忆"这条链路为什么绕了一圈"。三次沟通对应三张完全不同的图，哪怕描述的是同一个系统。

1.1 三类读者，三种完全不同的颗粒度

决策类读者关心的是成本、风险、扩展余量和交付节奏。给他们看的图，方框数量要少，一个方框代表一个"可以独立估算成本和排期的单元"，图上的重点标注应该是"这里是瓶颈""这里依赖外部""这里是单点"。我一般会把这类图控制在 15 个方框以内，超了就说明颗粒度没收敛，需要往上抽象一层。

协作类读者是上下游团队、运维、数据、测试。他们关心的是接口在哪、谁调谁、协议是什么、超时多少、数据写到哪张表、失败怎么重试。这类图的方框数量可以到 30 个左右，但每一根连线都要带语义标注，否则协作方拿到的只是"看着挺复杂"的心理压力。

接手类读者是三个月后的自己，或者下一个维护这套系统的人。他们关心的是"为什么是这样而不是那样"。这类图最难画，因为它必须承载决策痕迹——为什么这里要加一层缓存、为什么这个服务不直接读库、为什么消息队列要做两个主题。我的做法是在图上用带编号的小标签打点，图下方配一段编号对应的说明，形成"图 + 注脚"的组合。

1.2 六种常见架构图的分工对照

很多人嘴里的"架构图"其实是个筐，什么都往里装。我习惯按"回答的问题"来分类，这样选型时不容易错位。

实际工作中最常见的错位，是把部署信息塞进应用架构图。一张图上同时出现"订单服务"和"三台 8 核 16G 的机器"，读者会瞬间失焦——他到底该关注逻辑拆分还是物理部署？我的一般做法是应用架构图和部署架构图分开画，用同一套服务名称做锚点，看图的人能在两张图之间建立映射，而不是在一张图上同时处理两个维度。

1.3 落笔前的四个自问

这四个问题我每次画图前都会在草稿上写一遍，三十秒能写完，能省掉后面一小时的返工。

第一个问题：**这张图要回答的那一个问题是什么？**只能是一个。如果一句话说不清，说明你其实想画两张图。

第二个问题：**读者看完之后会做什么动作？**批准预算、改接口定义、加一台机器、还是仅仅"知道了"。动作不同，图上要突出的东西完全不同。

第三个问题：**边界画到哪一层？**外部系统画不画进去？画的话只画到网关还是画到对方的核心服务？我一般只画到"我方的调用出口 + 对方的一个代表方块"，再往里画就超出了我的知识边界，容易画错还误导人。

第四个问题：**这张图三个月后谁维护？**如果答案是"没人"，那它就不该进正式文档，只配待在白板照片里。正式文档里的图必须有人负责更新，否则它就从资产变成了负债——比没有图更糟，因为它会误导后来者。

2. 骨架拆解：分层、边界与连线

定完坐标，接下来是骨架。骨架决定了图的"可读性下限"——骨架错了，后面再怎么美化都救不回来。我见过太多图，方框画得很精致，但因为分层混乱，读者需要自己脑补"这个组件属于哪一层"，认知成本极高。

2.1 分层不是套模板，而是切责任

分层这个词被讲烂了，很多人以为分层就是"接入层、应用层、数据层"三行摆好。但真正有价值的不是层的名字，而是每一层承担的责任边界。判断分层是否合理，我有个很土的办法：指着任意一个方框问"它出了问题，谁负责？"，如果答案清晰且不跨层，说明分层成立。

一个实操性更强的分层思路，是按"变更频率"来切。最上层（接入、路由）变更最少，一年动不了几次；中间层（业务逻辑）变更最频繁，一周可能上线三次；最下层（存储、基础设施）变更频率居中，跟着容量走。把这个频率差异在图上体现出来，读者立刻能理解为什么中间那一层要拆细、上下两层要收拢。

这里有个常见误区：中间件层按产品画。比如把"缓存"画成一个框，里面写三个产品名。这样画的问题是，读者不知道业务代码到底调的是哪一个、什么场景用哪个。我建议按用途画：读缓存、会话存储、分布式锁，各自一个框，框里再标注具体用了什么。这样读者关心的是"为什么需要这三种能力"，而不是"为什么用了三个产品"，思考层级完全不同。

2.2 边界画在三种地方：部署、数据、团队

图上的边界线是最容易被忽略、但信息密度最高的元素。我一般会画三种边界。

部署边界用虚线框圈起来，一个框代表"一台机器 / 一个容器 / 一个可用区"，具体用哪种取决于图的用途。圈部署边界最大的价值，是让人一眼看出"哪些东西会一起挂"。如果订单服务和库存服务被圈在同一个框里，读者马上会问：那它们是不是同时不可用？这个问题问出来，容灾设计就被摆到台面上了。

数据边界用实线框圈，一个框代表"一个写权限的所有者"。系统里最危险的事情是多个服务同时写同一份数据，这几乎必然导致状态不一致。数据边界画清楚，等于把"谁能写"这件事公开化。我通常会在数据边界框外面标注"只读消费方"，把读写关系明确区分开。

团队边界用不同底色或者不同线型区分，一个框代表一个团队的负责范围。这个边界在跨团队协作的图上尤其重要，因为它是"出问题找谁"的直接依据。我自己画的图里，团队边界一般用右上角的小标签表示，比如"归属 A 组"，不占用图面中央的视觉资源。

注意：边界线不要太多。一张图上超过四条边界线，读者就开始数不清了。边界的作用是划分，不是装饰，画之前先问自己"这条线如果不画，读者会误解什么"，答不上来就别画。

2.3 连线承载的信息比方块多

新手画图，方框里写满字，连线光秃秃一根。老手反过来，方框里只写名字，连线上堆满信息。因为方块回答的是"有什么"，连线回答的是"怎么发生关系"，而后者才是架构的核心。

我自己有一套固定的连线约定，用了好几年没改过。

标注格式我建议统一成"协议 + 关键参数"，比如HTTP / 800ms / 重试 2 次。这种写法看着啰嗦，但在故障排查时价值极高——你不需要翻文档，看图就知道某条链路超时设了多少，是不是设得太长导致线程堆积。

还有一个细节：箭头方向别乱。数据流向和调用流向有时是相反的，比如消息队列，生产者箭头指向队列，消费者箭头从队列指出，但数据实际是从生产者最终到消费者。我在图上会统一约定"箭头一律表示控制流/调用流的发起方向"，数据流向在图的边角用小字说明，避免两套语义打架。

3. 三个场景的完整实例拆解

抽象讲完，落到具体。下面三个场景是脱敏重构过的虚构案例，覆盖了单体、微服务、数据链路三种典型形态。每个场景我都按"图长什么样 → 为什么这么画 → 关键参数怎么估 → 图上必须标什么"来拆。

3.1 场景一：中小规模内容站点的单体架构

先看一个日活五万左右的内容站点。这类系统的特点是读远多于写，读写比大概在 20:1 到 50:1 之间，业务逻辑不复杂但流量有明显峰值。图长这样：

[客户端] | v [CDN] ----回源----> [反向代理 / 负载入口] | v [应用服务副本 x2] (无状态) | | 读请求 | | 写请求 v v [缓存集群] [数据库主从] | | | 未命中----->| |---> [对象存储] | [定时归档任务]

这张图的骨架其实是三层：入口、无状态应用、有状态存储。为什么应用层必须无状态——因为只有无状态才能横向加副本，才能做到挂一台不影响整体。这条原则我在图上会直接标注"无状态，可水平扩展"，让读者一眼看到设计约束。

关键点在缓存和数据的关系上。图上我特意画了"未命中"这条从缓存指向数据库的线，因为这是这类系统里最容易出问题的地方：缓存击穿的时候，所有流量瞬间打到数据库，数据库扛不住，整个站点雪崩。图上有这条线，讨论时就会自然引出"缓存未命中的兜底策略"，比如空值缓存、热点数据的互斥重建。

容量参数估算这块，我把常算的几个列出来，公式你可以直接套。

日活 5 万，人均每天 40 次接口请求，日请求量约 200 万。峰值系数按 8 倍算（内容站点有明显的早晚高峰），峰值 QPS 约2000000 / 86400 × 8 ≈ 185。单副本 4 核应用在常规业务下能扛 300~500 QPS，取保守值 300，两副本可以扛 600，相对 185 的峰值有两倍以上余量，够用。如果要考虑单副本故障，两副本降到一副本时扛 300，仍然高于峰值，这个设计就是安全的。

缓存容量按二八原则估：热点数据占 20% 支撑 80% 的访问。数据总量假设 30GB，缓存 6~8GB 就能覆盖主要热点，考虑到缓存本身的元数据开销和副本，实际申请 12GB 左右比较稳。这个数字要写在图旁边，不然运维问你"缓存要多大"时你还是得现算。

提示：这张图上有一个很多人会漏掉的元素——归档任务。它不算在线链路的一部分，但它决定了主库的数据量增长速度。主库表超过千万级行之后，索引效率、备份耗时、DDL 风险都会明显上升。把归档画进图里，等于提前把"数据生命周期"这件事摆上桌面。

3.2 场景二：跨端订单系统的服务拆分

第二个场景复杂一些：一套同时服务多个端的订单系统，涉及下单、库存扣减、支付对接、对账。业务量不算大，但一致性要求高，任何一个环节出错都是真金白银。图的结构如下：

[多端客户端] | v [统一接入网关] (鉴权 / 限流 / 路由 / 幂等键提取) | +-------> [订单服务] ---写---> [订单库] | | | | 同步 | | 发事件 | v v | [库存服务] [消息队列] | | | | v +--> [通知服务] | [库存库] | | +--> [对账任务] --> [对账结果库] | +-------> [支付对接层] ---> [外部支付渠道] ^ | 异步回调 +---- (回调入口独立，绕过网关限流)

这张图上有几个必须标出来的点，缺一个就会在评审时被追问。

第一是幂等键的位置。我在网关那一层标注了"幂等键提取"，因为跨端场景下用户可能重复点击、客户端可能重试、网关可能超时重发，同一笔下单请求到达订单服务时可能有多次。幂等控制放在最靠前的位置，能挡掉绝大部分重复流量，剩下的在订单服务内部用唯一业务键兜底。

第二是支付回调的独立入口。这点特别重要：外部渠道的回调如果走正常网关，会受限流和鉴权策略影响，回调失败就意味着订单状态永远停在"支付中"。图上把它单独拉一条线出来，写明"独立入口，不做业务限流，只做来源校验"，看图的运维同事立刻就知道这条路径不能套用通用策略。

第三是一致性的实现方式。订单写库和库存扣减之间，图上用的是同步调用 + 事件补偿的组合，而不是分布式事务。这么画的原因要写清楚：分布式事务在跨服务场景下锁持有时间长、失败恢复复杂，对这类业务量来说性价比不高；改用"本地事务 + 事件表 + 定时补偿"，代价是短暂的不一致窗口，但换来了可用性和可运维性。

图下方的注脚我一般会写一段状态机的关键节点，因为订单系统的复杂度 90% 集中在状态流转上：

待支付 --支付成功--> 已支付 --发货--> 已发货 --签收--> 已完成 | | | +--超时取消--> 已取消 +--退款--> 退款中 --> 已退款 | +--异常--> 待人工处理 (禁止自动流转)

把状态机画在架构图旁边，是我从一次事故里学到的。那次事故的原因是一个边界状态没有被覆盖，订单卡在"退款中"三天，用户投诉、财务对不平。后来我们规定，凡是涉及资金状态的系统，架构图必须配一张状态机，且状态机上的每一条边都要能对应到代码里的一个分支。

容量估算上，订单系统的瓶颈通常不在 QPS 而在存储增长和索引效率。假设日均订单 3 万单，单条订单主表记录按 1KB 算（含索引开销约 1.5KB），日增 45MB，一年约 16GB。这个量级单表完全扛得住，不需要分库分表——很多团队在这个量级就上分片，纯属给自己找麻烦。什么时候需要拆？我的一般判断线是单表超过 2000 万行、或者单表写入成为瓶颈、或者备份窗口超过可接受范围，三者出现任一才考虑。

3.3 场景三：离线数据链路的批处理架构

第三个场景是数据侧的，很多后端同学画架构图时容易忽略这类系统，但实际工作中它出现的频率很高——埋点采集、日志分析、经营报表，本质都是同一条链路。图如下：

[业务系统] --埋点/日志--> [采集代理] | v [消息队列] (削峰 / 缓冲) | v [原始层存储] (只追加, 不修改) | 清洗 / 去重 / 补全 | v [明细层存储] (按天分区) | 聚合 / 关联维表 | v [汇总层存储] (按主题建模) | | v v [报表服务] [数据接口]

这张图最值得说的是分层存储的设计意图。原始层只追加不修改，这一点必须画出来并标注，因为它是整条链路的"可重放"基础——上游逻辑改了、清洗规则出 bug 了，都能从原始层重跑，不需要让业务系统重新埋点。没有这一层，任何一次加工逻辑的变更都会变成不可逆的数据损失。

明细层按天分区，是为了控制单次扫描的数据量。假设日增原始日志 200GB，压缩比按 5:1 算（文本日志的常规压缩水平），压缩后 40GB/天。保留 180 天，原始层占用约40 × 180 = 7200GB ≈ 7.2TB。如果存储做了三副本，物理占用约 21.6TB。这个数字要提前算出来写进图旁边的容量说明，否则半年后存储告警时没人认账。

明细层的数据量通常比原始层小，因为清洗过程会丢掉无效记录、只保留需要的字段。经验值大概压到原始层的 30%~50%，按 40% 算，180 天约 2.9TB，三副本 8.7TB。汇总层按主题建模，量级通常只有明细层的 1%~5%，可以忽略不计。

注意：这张图上最容易出错的地方，是没标注"清洗任务的调度依赖"。明细层的加工必须等原始层当天的数据全部就绪才能开始，这个依赖关系在图上如果只是一根箭头，很容易被理解成"实时流"。我一般会在箭头旁标注"T+1 调度，依赖上游分区就绪校验"，把批处理的时间语义固定下来。

4. 工具选型与落地流程

图画得好不好，工具只占两成，但对长期维护来说，工具选错会持续消耗团队精力。我按使用场景分了几类。

4.1 按场景选工具，别追求一套通吃

我自己的组合是这样的：白板阶段用任何顺手的工具，怎么快怎么来；设计文档阶段用带图形库的工具，保证风格一致；正式纳入文档、需要长期维护的架构图，一律用文本描述 + 渲染的方式。原因很实在：二进制图片文件在版本库里没法 diff，谁改了什么完全看不出来，两个人同时改还会冲突。文本化的图，改动就是几行文本的差异，评审时能直接看到"这次新增了一个服务"，价值极大。

4.2 文本化描述：让架构图进版本库

文本化绘图的核心思路是：用一段结构化文本描述"有哪些节点、怎么分组、谁连谁"，再由渲染器生成图片。具体用哪种描述语言不重要，重要的是它得支持三件事——分组嵌套、连线带标签、输出矢量图。

下面是我常用的一种描述结构，用 YAML 风格的伪代码示意，你可以换成任何支持的工具语法：

groups: - name: 接入层 nodes: - id: gateway label: 统一网关 note: 鉴权/限流/幂等键提取 - name: 应用层 nodes: - id: order label: 订单服务 note: 无状态 x2 - id: stock label: 库存服务 note: 无状态 x2 - name: 数据层 nodes: - id: orderdb label: 订单库 note: 主从, 日增约45MB links: - from: gateway to: order type: sync label: HTTP / 800ms / 重试2次 - from: order to: stock type: sync label: RPC / 300ms / 幂等键=订单号 - from: order to: orderdb type: sync label: 写, 本地事务

这套写法最大的好处是信息密度可控。图面只放 label，note 和连线参数以文字形式存在，渲染时可以折叠显示。评审时打开源文件，所有参数一目了然，不需要放大图片去猜。

实际操作中我发现两个坑要提前避开。一个是布局失控，文本化工具自动排版，节点一多就容易连线交叉，这时候需要手动指定分组顺序，而不是任由它算。另一个是过度参数化，有人把每个节点的 CPU、内存、镜像版本全写进去，结果文件变成了一本流水账。我的原则是：图里只放"影响理解结构"的信息，资源配置单独维护在清单文件里，需要时用链接关联，不塞进图。

4.3 评审与更新机制：让图活下来

图最大的敌人不是画得丑，是过期。我见过太多团队，架构图停留在两年前的版本，新人看了之后按图去排查问题，结果发现图上的服务早就下线了。

我的做法是给图绑定三个机制。

**第一，图跟着变更走。**凡是涉及新增服务、拆分服务、更换中间件、调整部署拓扑的变更，变更单里必须包含"架构图是否更新"这一项，勾"否"要写理由。这一条听着官僚，但确实有效——它把画图从"有空再说"变成了流程的一部分。

**第二，图有明确责任人。**每张正式文档里的架构图，都要标注维护人。责任人不需要每次都改，但要负责判断"这次变更需不需要改图"。

**第三，每季度做一次"图-实现"对齐。**具体做法很简单：拉出线上的服务清单和部署清单，跟图上一一对照，多出来的、少掉的、名字对不上的，全部列出来修正。这个动作一次半小时，能挡掉绝大部分的图漂移。

提示：给图加一个"最后核对日期"的角标，比任何规范都管用。任何人看到半年前的日期，自然会多问一句"这个还准吗"。

5. 常见问题与排查技巧实录

图的问题基本集中在两类：画的时候想岔了，和维护的时候懒得管。下面这些是我在实际工作中反复遇到的。

5.1 图与实现脱节的四种典型症状

**症状一：图上有，线上没有。**最典型的是画图时把"计划要做的"和"已经有的"混在一起画。这个问题危害极大，因为读者会基于错误的前提做判断。解决办法是给未落地的部分加明确的视觉区分，比如虚线框 + "规划中"标签，并且图例里必须说明。

**症状二：线上有，图上没有。**通常是临时加的应急组件，比如某次故障时紧急加的限流网关、临时起的数据同步任务。这类组件往往没人维护、没人监控，是最容易出事的部分。它们出现在"线上有图上没有"的清单里，本身就是个风险信号。

**症状三：连线语义错。**比如实际是异步消息，图上画成了同步调用。这种错最隐蔽，因为方框都对，只有箭头错了，但它是致命的——同步和异步在故障传播上的表现完全相反。同步调用会把下游的延迟直接传导到上游，异步则表现为积压。排障时按错误的语义去推，方向会完全跑偏。

**症状四：层级错位。**把数据库画在应用层，或者把网关画在数据层。这种错通常发生在多人协作画的图上，每个人心里的分层标准不一样。

我处理这四类问题的统一办法是对照三个清单：服务清单（有哪些应用）、部署清单（跑在哪些节点）、依赖清单（谁调谁）。三个清单跟图逐项比对，差异就是图的错误。这三个清单大多数团队都有，只是没人想到拿它们去校验图。

5.2 评审现场最容易被问倒的问题清单

我整理了一份"架构图评审高频追问"，每次评审前自己先过一遍，能挡掉八成尴尬。

这张表里我最看重第一行和最后一行。"挂了影响什么"验证的是可用性设计的完整性，"谁维护"验证的是组织层面的可持续性。很多技术上讲得通的架构，最后死在"没人负责"上。

5.3 常见问题速查表

6. 几个不上台面但很管用的细节

最后聊几个零碎但真省事的习惯，都是踩坑之后攒下来的。

**给图加编号体系。**我习惯用S-01表示服务、D-01表示数据存储、L-01表示链路，图上只显示名字，编号放在角落。好处是讨论时可以直接说"L-03 那条链路超时多少"，不用描述"从左往右第三根箭头"。开会时这个效率提升非常明显。

**先画异常路径，再画正常路径。**大部分人画图是从正常流程开始的，画完就收工。我的习惯反过来：先把所有可能失败的环节标出来——超时、重试、降级、补偿、人工介入，然后再把正常路径连起来。这样画出来的图天然带着容灾视角，评审时被问"这里挂了怎么办"的概率大幅下降。

**别在图上写缩写。**团队内部约定俗成的缩写，对外部读者就是天书。我见过一张图上有七个不同的缩写，讨论前十分钟全花在解释名词上。宁可名字长一点，也别用只有三个人懂的缩写。

**给重要连线标颜色，但只用两种。**一种是正常链路，一种是异常/补偿链路。三种以上颜色，读者的注意力就被分散了。

**图的尺寸控制在一屏内。**超过一屏的图，读者需要滚动，滚动就意味着失去整体感。如果内容真的装不下，拆成主图和子图，主图只画到"模块"级别，子图展开细节。这个原则我坚持了很多年，效果比任何排版技巧都好。

我个人在实际操作中的体会是，架构图的价值从来不在于它被画出来的那一刻，而在于画的过程中你被迫回答的那些问题。很多设计缺陷，是在你把方框摆上去、准备连线的那几秒钟里暴露出来的——"这两个服务怎么通信？""这份数据谁写？""这里挂了会怎样？"——这些问题在写代码时会被各种细节淹没，只有在画图这种高度抽象的动作里才会浮出水面。所以我现在带新人，第一件事不是让他读代码，而是让他画一张当前系统的架构图，画完再对照实际实现找差异。这个方法比任何文档都管用，因为差异本身就是最好的学习材料。