企业官网建设流程全解析

架构评审会上最尴尬的一幕，往往不是方案被否，而是投影仪打出一张图，底下有人问了一句"这个框是干什么的"，画图的人自己愣了三秒。我见过太多次这种场面：图里塞满了方块和箭头，配色讲究，线条笔直，看着挺专业，可真正要拿它做决策、做交接、做故障定位的时候，没人能用得上。问题不在画图工具，也不在审美，而在于画图之前没想清楚这张图要回答什么问题。

这篇内容聊的是实际场景下的架构图实例与详细说明，重点不在"怎么用某个软件画得好看"，而在"一张图怎么从零构思到能落地使用"。我会拿一个订单交易场景做完整拆解，把应用架构、部署架构、数据流转这几个视角分别摊开讲，中间穿插图元规范、工具取舍、评审清单和几个踩过的坑。适合正在写技术方案、做系统交接、准备架构评审的开发者、技术负责人和刚接手陌生系统的同学看。哪怕你之前只在纸上画过框框图，按这套思路走一遍，也能画出别人看得懂、用得上、三个月后自己还能认出来的图。

1. 架构图失效的三种典型现场

先把失败案例摆出来，比空谈原则有用。我整理过手上十几份被判定为"没起到作用"的架构图，问题高度集中在三类，而且这三类往往同时出现，互相放大。

1.1 一张图塞下所有组件：信息密度失控

最常见的做法是把数据库、缓存、消息队列、网关、几十个微服务、第三方接口全塞进一张画布，然后疯狂连线。这种图初看很震撼，细看全是问题：连线交叉成蜘蛛网，箭头方向分不清谁调谁，同一个服务在图里出现两次（因为要凑连线），有些组件被画在空白处没有归属层。

我印象很深的一次，某团队交付了一份系统全景图，画布大约两米宽，缩放比例降到 30% 才能看全。图上节点数量我数了一下，八十多个。评审时有人提了个非常朴素的问题："线上出故障时，我从哪里开始看这张图？"没人答得上来。这张图的信息量是够了，但没有阅读路径，它对任何一个具体问题都不构成答案。

判断一张图是否信息密度失控，有个很直接的标准：如果不能在 10 秒内指出"请求从哪进来、经过哪几层、数据落在哪"，那就是失控了。治理办法也简单，按照读者关心的问题把图拆开，一张图只服务一个问题。拆完之后单张图的节点数建议控制在 15 到 25 个之间，超过 30 个就该考虑分图了。

1.2 没有视角切换：用部署图回答业务问题

第二类问题更隐蔽：图画得挺清楚，但视角错位。典型表现是拿一张机房部署图去讲业务能力划分，或者拿一张业务流程去讲网络分区。听众在脑子里做视角转换，转着转着就跟丢了。

举个具体例子。某项目要做一次大促容量评估，会上放的是一张应用架构图，服务拆分、依赖关系画得很细，但没有画实例数量、没有画数据库主从、没有画缓存集群规模。结论是"我们的服务拆分很合理"，可容量问题根本没被回答。第二次会议换成部署视图，标了每层集群的节点数和规格，问题立刻暴露：某个核心服务的实例数只有两个，且两个实例部署在同一个可用区。

这就是视角的价值。业务视角回答"系统提供什么能力"，应用视角回答"能力被拆成哪些服务、怎么互相调用"，部署视角回答"这些东西跑在哪里、资源怎么分"，数据视角回答"数据从哪来到哪去、存在哪"。四个视角对应四种读者、四类决策，混在一起就都讲不清楚。

1.3 图例和命名各自为政：看图像破译密码

第三类问题看起来是小事，实际沟通成本最高。同一个系统里，有人用圆角矩形表示服务，有人用直角矩形；有人用虚线表示异步调用，有人用虚线表示"预留未实现"；服务命名一会儿是中文业务名，一会儿是英文模块名，一会儿是缩写。

我接手过一个交接项目，前同事留下的架构图里有个叫OMS-Core的方块，图例里没写。我花了大半天才确认它对应的是订单主流程服务，而不是订单管理系统本身。这种成本是隐性的，但在人员流动频繁的团队里会不断累积。

解决方式不复杂：每张图必须带图例，图例里至少写清形状含义、连线含义、颜色含义。命名统一走一套规则，要么全用业务语义名，要么全用服务标识，不要混。这个投入大概十分钟，省下的是后面每个人的半小时。

2. 落笔前先定读者：四类架构图的分工

拆图之前得先知道有哪些图可拆。我把实际工作中用到的架构图归成四类，每类的读者、回答的问题、必备元素都不一样。这个分类不是学术定义，纯粹是按"谁看、看什么"来切的，实操性更强。

2.1 业务架构图：讲清能力边界与上下游

业务架构图的读者是产品、运营、业务方和技术负责人。它要回答的问题是：这个系统承担哪些业务能力，和外部系统之间的边界在哪，谁给我数据，我把数据给谁。

这类图里不该出现数据库、缓存、中间件这些技术组件，出现就是越界。节点应该是业务域或者业务能力，比如"订单履约""库存管理""结算对账""风控审核"。连线表示业务上的数据流转或者依赖方向，箭头上要写清楚流转的是什么，比如"订单状态变更事件""结算明细"。

我通常会在业务架构图上额外标两种信息，一个是能力的新旧状态（已有、在建、规划中），用不同的边框样式区分；另一个是跨团队边界，用一条粗虚线把不同负责团队隔开。后者的价值在跨部门项目里非常明显，一眼就能看出哪些环节需要协调。

2.2 应用架构图：讲清服务拆分与调用关系

应用架构图的读者是开发、测试、架构评审人员。它要回答：系统被拆成哪些服务或模块，它们之间怎么调用，同步还是异步，依赖方向是什么。

这张图是所有图里最容易画崩的，因为大家习惯把所有东西都往上堆。我的建议是严格分层，一般分四层：接入层（网关、负载均衡、BFF）、应用层（面向场景的编排服务）、领域层（核心业务能力服务）、基础设施层（中间件、存储）。层与层之间只允许上层依赖下层，同层之间如果要调用，必须显式画出并标注原因，因为同层横向调用往往是耦合的信号。

连线类型必须区分。同步调用用实线加实心箭头，异步消息用虚线加开放箭头，批量定时任务用点划线。这个区分不是形式主义，排查问题时它能直接告诉你"这个链路的失败会不会阻塞上游"。我曾经靠一条虚线的标注定位到一个隐藏的耦合点：两个服务本来是异步解耦的，后来有人改成了同步调用但没更新图，故障时上游被拖垮，按图排查时走了不少弯路。

2.3 部署架构图：讲清网络分区与资源分布

部署架构图的读者是运维、SRE、负责容量和稳定性的同学。它要回答：服务跑在哪些环境，跨几个可用区，每层集群的规模和规格，网络分区和访问策略是什么。

这张图必须带数字。节点上写清楚实例数量、规格、存储容量，集群要标明是主从还是多副本。区域划分要画出来，比如接入区、应用区、数据区，区域之间的访问策略要标注（允许哪些端口、走内网还是专线）。

有个细节容易被忽略：不要把逻辑部署和物理部署混在一张图。逻辑部署图讲的是"应用集群、数据库主从、缓存集群"这种抽象形态，物理部署图讲的是"具体机房、机柜、网段"。前者用于方案评审，后者用于运维操作，混在一起两边都不好用。实际场景中，方案阶段画逻辑部署图就够了，上线前再补物理部署图。

2.4 数据流图与时序图：讲清一次请求的完整旅程

业务、应用、部署三张图都是"静态"的，缺一张能讲清"一次请求怎么走完"的动态图。数据流图或者时序图补的就是这块。

数据流图适合讲批处理、数据同步、报表链路这类场景，重点是数据在哪些存储之间流动、经过哪些加工环节、时效性要求是什么。时序图适合讲一次交互的完整调用链，重点是参与方、调用顺序、同步异步、异常分支。

这两类图我最看重的是异常路径的标注。大部分图只画成功路径，但排查问题时异常路径才是关键。比如下单链路，库存扣减失败怎么办、支付超时怎么办、消息重复消费怎么处理，这些在图上标出来，图的实用价值立刻上一个台阶。具体的画法可以简化，用一条带叉的分支线加一行文字说明即可，不需要画完整的异常流程。

3. 订单场景实例：一套图从需求到成稿

理论说完了，拿一个具体场景走一遍。为了讲清楚，我虚构一个交易系统的改造项目（下文简称"模拟项目 T"），业务是订单创建到履约完成的全链路。这个场景足够典型，大部分互联网系统都能套用。

3.1 划定边界：这次到底画哪一段

动手前第一个动作不是打开画图工具，是确定边界。模拟项目 T 的改造范围是"订单创建与支付确认"，那架构图就聚焦这一段。上游的商品详情、下游的仓储发货、财务结算，都只画成一个外部系统方框，不展开内部结构。

边界划定的作用是控制图的范围，避免无限膨胀。实际操作中我一般会在图的一角画一个淡淡的矩形框，把本次改造范围内的节点框起来，旁边写一句"改造范围"。这个动作看起来很土，但对评审非常有效，听众的注意力会自然聚焦。

另一个要说清楚的是不在范围内的东西。比如这次不改动风控，那图上就把风控画成外部依赖并标注"本期不变更"。明确说"不改什么"，比说"改什么"更能降低沟通成本，因为大家最担心的往往是你动了不该动的地方。

3.2 应用架构分层与依赖方向

应用架构图按四层来画，下面是模拟项目 T 的分层说明，我把它整理成表格，实际画图时每一层对应一行横向的节点组。

这张表画成图之后，节点数大约 20 个，在可控范围内。依赖方向从上往下，唯一的横向依赖是"下单编排服务"和"支付确认服务"之间通过消息队列做状态同步，用虚线标注，箭头上写"订单支付完成事件"。

有几个具体的设计取舍值得说明。为什么把支付适配单独拆一层？因为对接的支付渠道不止一个，且渠道侧的接口规范和超时特性差异大，拆出来之后，渠道变更不会影响订单主流程，也方便单独做重试和降级。为什么优惠计算是独立服务而不是订单服务里的一个模块？因为优惠规则变更频率高，且计算过程需要读取多个数据源，放在订单服务里会让主流程变得不稳定，拆出来后可以独立做缓存和限流。

这些取舍都要在图上用一句话注释出来。图不是只给结论，还要传递理由，否则下次评审时同样的争论会再来一遍。

3.3 部署视图：可用区、集群与网络分区

部署架构图承接应用架构图，把逻辑节点映射到物理资源上。模拟项目 T 的部署视图分三个区。

接入区包含负载均衡和网关集群，网关集群按最小三节点部署，跨两个可用区分布，前面挂一个负载均衡做流量分发。应用区包含编排服务集群和领域服务集群，每类服务最小三实例，强制跨可用区打散。数据区包含数据库主从集群、缓存集群、消息队列集群，数据库采用一主两从，主从分布在不同可用区，缓存集群采用多分片多副本。

部署图上有一个地方我特别建议标出来：故障域。用浅色底纹把每个可用区圈出来，一眼就能看出"某个区整体挂掉会损失多少实例"。模拟项目 T 第一版方案里，订单服务三个实例全在同一个可用区，图上画出来之后，讨论省了半小时，直接改。

另外，分区之间的访问策略要标在连线上，比如"应用区到数据区走内网，仅开放指定端口"。这类信息运维同学最关心，写在图上比写在文档正文里更容易被看到。

3.4 关键链路时序与数据落点

静态图讲完，用一张时序说明把下单主链路串起来。参与方依次是：客户端、网关、下单编排服务、订单服务、库存服务、优惠计算服务、支付适配服务、消息队列、通知服务。

正常路径是：客户端发起下单请求，网关做鉴权和限流后转发到编排服务，编排服务调用优惠计算拿到最终价格，调用库存服务做预占，调用订单服务创建订单并置为待支付状态，返回订单号和支付参数给客户端。用户完成支付后，支付渠道回调支付适配服务，适配服务校验签名并发出支付成功事件到消息队列，订单服务和库存服务各自消费这个事件，前者推进订单状态，后者把预占转为实扣，最后通知服务发送结果消息。

异常路径至少要在图上标出三条。库存预占成功但订单创建失败：编排服务发起库存释放，释放动作走补偿重试，最多三次，超过则落异常单据由人工处理。支付成功事件重复投递：订单服务和库存服务都做幂等，以订单号加事件类型作为幂等键。支付回调超时：支付适配服务定时主动查询支付状态，做状态对齐。

这些异常路径不需要画成完整的流程图，在时序图旁边用带叉的短线加一行文字说明就够了。判断标准是：新人拿着这张图能不能自己回答"库存占到一半系统挂了会怎样"。能回答，图就是合格的。

4. 图元、连线与命名的硬规范

图画得好不好看是次要的，可读性和一致性才是关键。这一节讲的是团队内部应该固定下来的规范，投入不大，收益长期。

4.1 形状语义表：让每个框都有固定含义

形状的含义必须固定，不能一张图一个样。我常用的映射关系是这样的：

这套映射不唯一，团队里定一套统一用就行。关键是必须写进图例，且图例放在图的固定角落（我习惯放右下角），每次位置一致，看多了就形成肌肉记忆。

有个小技巧：如果一张图里同类节点超过八个，在图例之外再加一个"分组框"，用浅灰底色把同类节点框在一起，框的左上角写组名。这样即便节点多，阅读时也是分块处理的，认知负担小很多。

4.2 连线的方向、虚实与标注

连线的规矩比形状更重要，因为它承载的是关系信息。基本规则三条。

第一，方向统一表示依赖方向，也就是"谁调用谁"或者"谁依赖谁"，不表示数据流向。这条容易搞混，约定死之后就不乱了。如果确实需要表达数据流向，用另一张数据流图。

第二，虚实表示同步异步。实线加实心箭头是同步调用，虚线加开放箭头是异步消息，点划线表示定时任务。这个区分在排查故障时价值极高，一眼就能看出哪些链路会阻塞。

第三，关键连线必须标注。标注内容包括协议、数据内容、频率。比如"HTTP/JSON，订单创建请求，同步""消息队列，支付成功事件，异步"。全标会很挤，我的做法是只标跨层和跨分区的连线，同层内部的连线不标。

连线交叉是绕不开的问题，控制手段是布局时按调用方向纵向排布，让大部分连线保持同向。实在交叉的，用跳线（弧线跨过）而不是直接穿过。如果一张图里交叉超过十处，说明节点排布有问题，考虑拆图。

4.3 命名与版本：图也要能追溯

命名规则定两条就够了：节点名统一使用一种语言和一种粒度。要么全用中文业务名（订单服务、库存服务），要么全用英文服务标识（order-service、stock-service），不要混着来。层级上，同一个图里的节点名保持同一抽象层级，不要一个叫"订单服务"，旁边一个叫"优惠券满减计算模块"。

图必须带版本和日期，格式建议放在标题下方的一行小字里，比如"模拟项目 T 应用架构图 v1.2 / 2024-06 / 变更：增加支付适配服务"。变更说明这一条很关键，它让看图的人知道这次改了什么，不用每次都从头看一遍。

图源文件的管理同样重要。可编辑文件（绘图工具的原文件或者代码化描述文件）必须进版本库，和文档放在一起。只存导出图片的做法一定会出问题，后面想改一个字都改不动，最后只能重画。

5. 工具选型与协作流程

工具这块没有绝对优劣，只有场景匹配。我把实际用过的三类工具按适用场景列一下，都是通用类型，不绑定具体品牌。

5.1 手绘、代码生成、专业绘图三类工具的取舍

拖拽式绘图工具适合一次性交付、对视觉要求高的场合，比如方案汇报、对外材料。优点是排版自由、样式可控，缺点是修改成本高，节点一多容易失控，多人协作时冲突难处理。

代码化描述工具适合需要频繁变更、需要进版本库的图。用文本描述节点和连线，渲染出图，改起来快，diff 清晰，多人协作天然友好。缺点是布局由工具自动决定，复杂图的排版不一定理想，需要花时间调整。

白板类工具适合早期讨论、快速对齐。随手画几个框，边聊边改，效率最高。缺点是画完不能直接用，需要有人整理成正式版本。

我的实际做法是三段式：讨论阶段用白板，定稿后转成代码化描述存进版本库，对外汇报时再导出成图片贴进材料。三者的源文件都保留，白板截图也留一份，方便回溯当时讨论了什么。

需要提醒一点，不要为了工具而工具。我见过团队花两周搭建一套自动生成架构图的流水线，结果图的维护还是靠人，自动化的部分只覆盖了目录结构，收益有限。图的准确性取决于人是否持续维护，工具只影响维护成本。

5.2 评审会上的提问清单

架构图评审最容易变成"看着挺好"的过场。为了让评审有抓手，我整理了一份提问清单，评审前发给参与人，会上按清单过。

这八个问题过一遍，大部分图的硬伤都能暴露出来。清单的价值在于把"感觉不对"变成"具体哪一项不符合"，讨论效率完全不同。

5.3 让图跟代码一起变更的机制

图最大的敌人不是画得丑，是画完就烂。三个月后代码改了三轮，图还停在第一版，这时候图不仅没用，还有害，因为它会误导人。

让图保持新鲜，靠自觉不行，得靠机制。我实践下来有效的做法有三条。

第一条，把图纳入变更流程。凡是涉及服务拆分、依赖关系、部署形态变更的需求，验收清单里加一条"架构图已更新"。这条写进模板，比口头强调管用得多。

第二条，图与代码放在同一个仓库。改代码和改图在同一个提交里，评审时一起看。代码化描述工具在这件事上有天然优势，图片格式做不到。

第三条，定期做图与实际的比对。我一般每个季度挑核心系统过一遍，方法很土：拿图对着监控面板和部署清单逐项核对，把不一致的地方标出来修正。这个过程大概半天，能发现不少已经悄悄变化但没人提的地方。

判断一张图是否已经开始腐烂，有几个早期信号：图上出现"临时""待定"之类的标注超过三个月没变；某个节点在图上有但查不到对应的部署；连线上的协议标注和实际抓包不一致；新人看完图还是要问一堆问题。出现任意一条，就该安排一次核对了。

6. 几个容易被忽略的细节

前面讲的是主干，这一节补几处实操中的细节，都是踩过坑之后才意识到的。

6.1 颜色与视觉层级的克制用法

配色是最容易过度发挥的地方。见过不少图用七八种颜色区分节点，结果看图的人得反复对照图例，反而更慢。

我的建议是颜色只用三档语义：主色表示核心链路节点，灰色表示辅助或非核心节点，浅色表示外部依赖或规划中。三种足够覆盖绝大多数场景。如果需要强调某条链路，用加粗连线而不是换颜色。

底色可以用来表达区域，但要用非常淡的色调，且不超过三个区域。区域太多，底色的区分度会下降，视觉上变成一团色块。文字和图例始终用深色，保证对比度，投影时不至于看不清。

另外一个细节是字号层级。图标题最大，分区名次之，节点名再次，连线标注最小。四级足够了，字号差保持明显，比如 20、16、13、10。这个层级定下来之后，整张图的阅读顺序会自然形成。

6.2 复杂图的拆分策略

节点数超过三十，单张图就很难看清了。这时的处理方式不是缩小字号硬塞，而是拆。拆分方式有三种，按场景选。

按视角拆是最常用的，也就是前面讲的业务、应用、部署、数据四张图。每张图解决一个问题，读者按需取用。

按链路拆适合核心流程特别长的系统。比如把下单链路、履约链路、售后链路分别画一张，每张图只画这条链路经过的节点。缺点是节点会重复出现，需要在图上标注"完整结构见总图"。

按层次拆适合分层特别明确的系统。总图只画层与层的关系，每层的细节单独出一张图。这种方式的好处是总图非常清爽，缺点是读者要来回翻。

实际项目中我一般组合使用：先出一张总览图，控制在 20 个节点以内，只画主要层次和核心链路；然后针对每条核心链路各出一张详图；部署单独一张。这样一个系统大概四到六张图，覆盖完整又不冗余。

6.3 对外交付时的脱敏处理

架构图经常要对外提供，比如给合作方、给审计、给新入职同学做培训材料。这时候必须做脱敏，而且要在导出前做，不要指望事后检查。

需要脱敏的内容包括：内网网段和具体 IP、真实的域名和端口、第三方服务商的标识、具体的实例数量和规格（这个视情况）、以及内部的服务代号。处理方式是把具体值替换成占位描述，比如"内网地址""外部接口""集群规模 N"。

有个细节容易漏：导出图片的元数据。有些绘图工具会把文件路径、作者信息、甚至图层的隐藏文字写进导出文件。交付前用工具检查一遍，或者干脆走截图后重新保存的流程，能规避这类问题。

另外，对外版本和对内版本建议分开维护。对内版本保留完整信息用于运维，对外版本只保留结构和逻辑关系。两个版本同源，不要各画一遍，否则一定会不同步。

最后分享一个我自己一直在用的习惯：每画完一张图，隔一天再看一遍，假装自己是个完全不了解这个系统的人，从图的左上角开始读，看能不能顺畅地读下去、每个框能不能看懂、每条线能不能说清含义。这个"隔夜自检"能发现大概一半的问题，比当场反复检查有效得多。图画出来是给人看的，自己先当一次读者，是最省成本的验证方式。