企业官网建设流程全解析

1. 四类架构图到底在解决什么问题

画架构图这件事，我见过太多团队踩同一个坑：拿到需求就开始打开画图工具，框框线线一顿操作，画完自己看着挺满意，拿去评审被问一句“这个框代表什么”就卡壳了。问题不在画图技巧，在于画之前没想清楚这张图要回答什么问题。

软件架构图粗分下来就是四类——业务架构图、应用架构图、技术架构图、数据架构图。这个分类不是学院派硬凑出来的，它对应的是四个不同视角的提问者。业务方关心“系统支撑了哪些事”，研发负责人关心“系统拆成了哪些模块”，运维和基础架构团队关心“这些东西跑在什么上面”，数据团队关心“数据从哪来到哪去”。你拿一张应用架构图去给业务方汇报，对方只会觉得你在讲天书；反过来拿业务架构图去跟运维对部署方案，人家也接不住。

所以这四类图的本质是沟通工具，不是艺术品。判断一张架构图合不合格，标准只有一条：目标读者能不能在三十秒内找到自己关心的信息。我见过用纯文本框加箭头画出来的技术架构图，丑是真丑，但运维一眼就能看出哪台机器是单点；也见过配色精美、图标齐全的“架构图”，评审时没人说得清那条虚线到底代表同步调用还是异步消息。后者的问题就是画图的人把精力花在了视觉上，没花在语义上。

这四类图之间有严格的推导关系，不是并列的四张画。业务架构定边界，应用架构承接业务能力做拆分，技术架构为应用提供运行支撑，数据架构贯穿前三者描述信息的流转与沉淀。顺序反了就会出问题——先画技术架构再补业务架构，大概率画出一堆“为了用某个中间件而存在的服务”，业务价值说不清楚。我自己带项目时的习惯是：业务架构图没跟业务方对齐之前，应用架构图一个字都不画。

下面按四类图逐一拆解，每类图讲清楚三件事：画之前要准备什么、具体怎么画、画完怎么自查。中间会穿插一些我实际踩过的坑和团队里反复强调的规范，都是文档里不太会写但实操中特别要命的东西。

2. 业务架构图：先把“做什么”说清楚

2.1 画之前先做业务能力盘点

业务架构图最容易犯的毛病是画成组织架构图或者流程图的混合体。我见过一张图，左边一排部门名称，右边一排系统名称，中间用箭头连起来，画图的人管这叫业务架构。这东西既没说清业务能力怎么划分，也没说清系统支撑关系，纯粹是把通讯录和服务器清单拼在了一起。

正确的起手式是业务能力盘点。具体做法：找业务方开一次工作坊，拿一张大白纸，把“这个业务域里到底有哪些事要做”一条条列出来，列的时候只写动词加名词的能力项，比如“订单创建”“库存锁定”“对账结算”，不要写部门名也不要写系统名。列完之后做归并，把粒度拉齐——有的能力项细到“修改收货地址”，有的粗到“供应链管理”，这种粒度混杂的清单没法直接画图，得往上抽一层或者往下拆一层，让同一张图上的能力项大致在一个量级。

归并完之后按业务价值链排序。什么叫价值链？就是这些能力项按业务发生的先后顺序或者按对客户的价值贡献排布。以电商场景为例，从“商品管理”到“交易履约”到“售后服务”就是一条价值链。排完序你会发现有些能力项孤零零挂在旁边，跟主链条没有明显的前后关系，这些通常是支撑性能力，比如“风控”“客服”，画图时单独放一块区域。

这一步的产出是一张能力清单，还不是图。清单确认过业务方认可之后，再开始画。这个顺序不能省，我试过直接上手画图再拿去对，业务方会陷入“这个框应该放左边还是右边”的细节争论，而能力清单阶段大家讨论的是“这件事到底归不归我们管”，后者才是真正需要对齐的东西。

2.2 分层与分域的画法规范

业务架构图的标准画法是分层分域。横向按价值链分域，纵向按能力层级分层。通常分三层：业务域层、业务能力层、业务活动层。业务域层是最大的颗粒度，比如“交易域”“履约域”“用户域”；业务能力层是域下面的能力项，比如交易域下面的“下单”“支付”“退款”；业务活动层是可选的，只有需要向执行层讲清楚具体操作时才展开。

画的时候有个实用技巧：同一层级的框用同一种颜色和形状，跨层级的关系用带箭头的实线，同层级之间的协作关系用虚线。这个约定看起来是小事，但评审时能省大量解释成本。我团队里曾经有个项目，画图的人用红色框表示核心业务、蓝色框表示支撑业务，但图例里没写，评审时业务方以为红色代表有风险，闹了个乌龙。从那以后我们定了个死规矩：任何颜色和线型的含义必须写在图例里，图例放在图的右下角，字号不能小于正文。

分域的时候注意域之间的边界要跟组织权责对齐。这话听起来有点绕，说白了就是：如果一个业务域的能力项分散在三个部门手里，画图时要么拆成三个域，要么在图上标注清楚各部分的归属。不标注的后果是后续做应用架构拆分时，没人认领对应的系统建设责任。我见过一个供应链项目，业务架构图上“库存管理”画成了一整块，落到应用架构时发现库存的入库、出库、盘点分别归三个团队管，系统拆得稀碎，根子就在业务架构图没把权责边界画出来。

2.3 业务架构图的自查清单

画完业务架构图，拿下面这张表过一遍，有一项不满足就回去改：

这张表里最容易被忽略的是“读者适配”。业务架构图的读者是业务方和产品负责人，不是研发。图上出现“消息队列”“缓存穿透”这类词就是不合格。我见过一张业务架构图在“订单创建”能力下面标注了“依赖分布式事务保证一致性”，业务方当场问“分布式事务是哪个部门”，场面相当尴尬。技术细节留给技术架构图，业务架构图只讲业务语义。

3. 应用架构图：把业务能力翻译成系统模块

3.1 从业务能力到应用模块的映射方法

应用架构图的核心动作是映射：把业务架构图上的每一个能力项，映射到一个或多个应用模块上。映射关系有三种：一对一（一个能力对应一个模块）、一对多（一个能力拆到多个模块，通常是因为该能力内部有不同技术特征的部分）、多对一（多个能力收敛到一个模块，通常是共享服务）。

映射的时候拿一张对照表逐项过，不要凭记忆。表格长这样：

这张表是应用架构图的底稿，表填完图基本就出来了。填表过程中最容易暴露的问题是共享模块的归属。比如“统一认证服务”被五个业务域共用，画图时它应该放在哪？我的做法是单独拉一个“公共支撑层”放在图的底部或者侧边，跟业务应用层用不同底色区分。不这么做的后果是画图的人把它塞进某个业务域里，其他域的读者以为认证归那个域管，后续排期扯皮。

映射过程中还有一个高频争议点：一个业务能力到底该拆成几个模块。判断依据不是技术偏好，是变更频率和团队边界。如果“订单创建”和“订单查询”的变更节奏完全不同（前者跟促销规则强相关，后者跟报表需求强相关），那就拆成两个模块；如果由同一个团队维护且变更同步，合在一起也没问题。这个判断没有标准答案，但必须在图上体现出来，因为应用架构图的读者是研发负责人，他们看的就是模块划分合不合理。

3.2 分层画法与依赖关系表达

应用架构图的标准分层是：接入层、业务应用层、领域服务层、公共支撑层、外部集成层。接入层放网关、BFF（面向前端的后端）这类东西；业务应用层放各业务域的编排服务；领域服务层放可复用的领域能力；公共支撑层放认证、消息、配置这类横切能力；外部集成层放跟第三方系统对接的适配器。

层与层之间的依赖方向必须单向向下，这是硬约束。接入层调业务应用层，业务应用层调领域服务层，领域服务层调公共支撑层，不允许反向依赖。画图时用箭头明确标出调用方向，跨层调用（比如接入层直接调领域服务层）要用醒目线型标出来并注明原因，因为跨层调用往往是架构腐化的信号。

依赖关系的表达有个细节很多人不注意：同步调用和异步消息要用不同线型。同步用实线箭头，异步用虚线箭头，消息中间件在图上用一个独立的框表示，所有走异步的箭头都指向这个框再指出去。这个画法比在箭头上写“MQ”清楚得多，评审时一眼就能看出哪些链路是强耦合的。我经历过一次线上故障复盘，就是因为架构图上把一条异步链路画成了同步实线，排查时按同步超时去查，方向完全错了。

3.3 应用架构图的常见翻车点

第一个翻车点是画成部署图。应用架构图描述的是逻辑模块划分，不是物理部署。图上出现“两台服务器”“容器集群”这类信息就是越界了，那是技术架构图的事。逻辑模块和物理部署分开画的好处是：模块划分相对稳定，部署方案随基础设施变化频繁，混在一起画会导致每次扩容都要改架构图，改着改着图就跟实际对不上了。

第二个翻车点是模块命名用技术词。比如把模块叫“Kafka消费者服务”“Redis缓存层”，这是把技术选型写进了逻辑架构。正确的命名是“订单事件处理服务”“商品详情缓存服务”，技术选型在技术架构图里体现。命名用业务语义的好处是，业务方也能看懂应用架构图的大致轮廓，跨角色沟通成本低很多。

第三个翻车点是不标接口协议。模块之间的调用是 HTTP 还是 RPC，是同步还是异步，这些信息在应用架构图上至少要有个大致标注。不标的话，后续做技术方案评审时每个调用关系都要重新确认一遍。我的习惯是在关键调用链路上用小字标注协议类型，非关键链路省略，保持图面清爽。

4. 技术架构图：说清楚东西跑在哪、怎么跑

4.1 技术架构图的三个必备视角

技术架构图跟应用架构图最容易混淆，区别在于：应用架构图回答“系统由哪些逻辑模块组成”，技术架构图回答“这些模块部署在什么环境、依赖什么中间件、网络怎么走”。一张合格的技术架构图至少包含三个视角的信息：部署拓扑、中间件依赖、网络分区。

部署拓扑画清楚每个应用模块部署在什么环境（生产、预发、测试）、多少个实例、有没有多可用区分布。中间件依赖画清楚每个模块依赖哪些数据库、缓存、消息队列、对象存储，以及依赖的方式（直连、通过代理、通过连接池）。网络分区画清楚哪些模块在同一个网段、跨网段调用走什么通道、对外暴露的入口在哪。

这三个视角可以画在一张图上，也可以拆成三张。我的建议是：对外汇报用一张整合图，内部技术评审拆成三张。整合图信息密度低但易读，拆开的图信息完整但需要讲解。团队内部做容量规划或者故障演练时，看的一定是拆开的那三张。

4.2 部署拓扑的画法与参数标注

部署拓扑的骨架是环境分层加可用区分布。从上到下依次画：接入层（负载均衡、网关）、应用层（各业务模块的实例组）、数据层（数据库主从、缓存集群、消息集群）、基础设施层（计算资源、存储资源、网络资源）。

每个模块的实例组旁边标注关键参数：实例数量、规格（CPU/内存）、部署方式（容器/虚拟机/物理机）。这些参数不是拍脑袋写的，要有容量测算依据。举个实际的测算例子：某订单服务峰值 QPS 是 800，单实例压测下来稳定承载 200 QPS，考虑 1.5 倍冗余系数，实例数 = 800 / 200 × 1.5 = 6，取整部署 6 个实例，分布在两个可用区各 3 个。这个计算过程要写在技术方案文档里，架构图上只标结果（6 实例，2 可用区）。评审时如果有人质疑实例数，翻方案文档就能对上，不用重新算。

可用区分布有个硬规矩：任何有状态服务的主节点和从节点不能放在同一个可用区。画图时用不同的背景色块表示可用区，一眼就能看出分布是否合理。我见过一张图，数据库主库和从库画在同一个色块里，评审时被基础架构团队直接打回，因为那个可用区一旦故障，主从一起挂，等于没做高可用。

4.3 中间件依赖与网络链路的表达

中间件依赖用依赖矩阵表配合架构图表达最清楚。矩阵表的行是应用模块，列是中间件类型，交叉格填依赖方式。比如：

这张表比在图上画一堆连线清楚得多，而且可以直接拿去做故障影响分析——某个中间件挂了，查表就知道哪些模块受影响。架构图上只需要把中间件集群画出来，用连线连到对应的模块组，细节查表。

网络链路要标清楚跨分区调用的通道类型。同网段调用、跨网段调用、公网入口，这三种在图上用不同线型区分。公网入口必须单独画出来并标注防护措施（比如经过哪层网关），这是安全评审的必查项。我参与过的一次架构评审，图上所有调用都是同一种实线，评审专家问“哪些链路暴露在公网”，画图的人说不清楚，评审直接中止要求补充。

4.4 技术架构图的评审要点

技术架构图画完，内部评审时重点看四件事。单点风险：有没有哪个模块只有一个实例、哪个中间件只有单节点。容量匹配：实例数跟标注的 QPS 是否对得上，数据库规格跟数据量增长是否匹配。故障隔离：一个模块出问题会不会拖垮整条链路，有没有熔断降级设计在图上体现。环境一致性：生产环境和预发环境的拓扑差异是否在图上标注，差异过大的地方往往是线上问题的来源。

这四项里最容易被放过的是环境一致性。很多团队的生产架构图画得很漂亮，但预发环境是另一套拓扑，图上不标差异，结果预发验证通过的变更上了生产出问题。我的做法是在技术架构图旁边附一张环境差异对照表，列清楚生产、预发、测试三套环境在实例数、中间件规格、网络策略上的差异，评审时逐项确认。

5. 数据架构图：追踪信息的来龙去脉

5.1 数据架构图的两条主线

数据架构图有两条主线：数据流和数据模型。数据流描述数据从产生到消费的完整路径，数据模型描述核心实体的结构和关系。两条线通常画两张图，混在一张图上信息密度太高，没人看得清。

数据流图的画法是从数据源头开始，沿着业务链路画到数据消费端。以交易场景为例：用户下单产生订单数据，订单数据写入订单库，同时发出订单事件，事件被履约系统消费生成履约单，被数据平台消费进入数仓，数仓加工后供报表和风控使用。这条链路上每个节点标注数据形态（原始数据、加工后数据、聚合数据）和更新频率（实时、准实时、T+1）。

数据模型图就是 ER 图，但架构级别的 ER 图只画核心实体和主要关系，不画全部字段。核心实体的判断标准是：被三个以上模块引用的实体、承载核心业务状态的实体、有强一致性要求的实体。订单、用户、商品这类肯定是核心实体，一些配置表、日志表就不用在架构级 ER 图上出现。

5.2 数据流转的关键节点标注

数据流图上有几个节点必须重点标注，这些是数据一致性和合规审查的关注点。数据产生点：数据在哪个模块、什么时机产生，是用户操作触发还是定时任务触发。数据落地点：数据写入了哪些存储，主存储是哪个，有没有冗余副本。数据加工点：数据在哪些环节被转换、聚合、清洗，加工逻辑归哪个模块负责。数据出口：数据被哪些外部系统消费，出口有没有脱敏和权限控制。

这几个节点标注清楚之后，数据血缘就自然出来了。后续做数据问题排查时，顺着图就能定位是哪个环节出的问题。我经历过一次报表数据对不上的问题，靠数据流图十分钟定位到是某个加工环节的时区处理有误，没有这张图的话，光确认数据链路就要花半天。

数据出口的标注还有个实际作用：合规审查。哪些数据流出了系统边界、流给了谁、有没有脱敏，这些信息在图上标清楚，安全合规评审时直接看图说话，不用临时翻文档。标注方式是在出口连线上加一个小标签，写明“脱敏后输出”或“原始数据输出（需授权）”。

5.3 数据架构图与前三张图的联动

数据架构图不是孤立存在的，它跟前面三张图有明确的对应关系。数据产生点对应应用架构图上的模块，数据落地点对应技术架构图上的存储组件，数据流转路径对应业务架构图上的业务链路。画数据架构图时如果发现某个数据找不到产生它的应用模块，说明应用架构图有遗漏；如果某个存储组件在技术架构图上没画，说明技术架构图不完整。

这种联动检查是架构评审的高效手段。我习惯在评审时拿四张图对照着看，任何一张图上的元素在其他图上找不到对应，就要追问原因。常见的情况是数据架构图上画了一个“数据同步服务”，但应用架构图上没有这个模块，追问下去发现是画图的人把某个中间件的同步功能当成了一个独立服务，实际上它只是配置项。这种不一致在评审阶段发现是好事，上线后才发现就是故障隐患。

6. 四类图的协同与版本管理

6.1 画图顺序与评审节奏

四类图的绘制顺序建议是：业务架构图 → 应用架构图 → 技术架构图 → 数据架构图。每张图画完单独评审一次，评审通过再画下一张。不要四张一起画完再评审，那样评审意见会互相纠缠，改起来牵一发动全身。

评审的参与者也不同。业务架构图评审必须有业务方在场，应用架构图评审以研发负责人为主，技术架构图评审要有运维和基础架构团队参与，数据架构图评审要有数据团队和安全合规角色参与。每场评审控制在九十分钟以内，超过这个时长注意力就散了，宁可分两次。

评审通过的标志是签字确认或者邮件确认，不是口头说“可以”。我吃过口头确认的亏：业务架构图评审时业务方说“大致没问题”，画图的人就当通过了，结果应用架构拆完之后业务方说“这个能力我们其实不负责”，返工重来。从那以后我们要求每张图评审后发确认邮件，列清楚评审结论和遗留问题，有据可查。

6.2 版本管理与变更同步

架构图必须纳入版本管理，跟代码一样对待。每次变更记录三样东西：改了什么、为什么改、谁批准的。变更原因要写具体，不能写“优化调整”，要写“新增预售业务，交易域增加预售能力项，订单服务拆出预售订单模块”。

四张图之间的变更要同步。业务架构图改了能力项，应用架构图的映射表要跟着改；应用架构图拆了模块，技术架构图的部署拓扑要跟着改；技术架构图换了存储组件，数据架构图的落地点要跟着改。不同步的后果是图跟实际脱节，脱节三次之后团队就再也不看架构图了，图变成摆设。

我的做法是给四张图建一个统一的变更记录表，每次变更在表里登记，标注影响到的其他图，变更完成后逐项确认同步。这个表不用很复杂，一个共享表格就够，关键是养成习惯。

6.3 画图工具的选择建议

工具选择上，我的建议是代码化画图优先。所谓代码化，就是用文本描述生成图，比如用 PlantUML、Mermaid 这类工具写文本渲染成图。好处是版本管理方便（文本可以 diff）、修改成本低（改几行文本而不是拖拽半天）、风格统一（模板控制样式）。缺点是学习成本，但一个团队里只要有一个人会写，其他人改文本参数就行。

可视化拖拽工具适合对外汇报的场景，因为样式调整灵活。但要注意：拖拽工具画出来的图，源文件要跟图一起存档，不然下次修改时找不到源文件只能重画。我见过团队用在线工具画图，账号到期后图全丢了，只剩导出的图片，改一个字都要重画整张。

不管用什么工具，输出格式统一用SVG 或 PNG 加源文件。SVG 放大不失真，适合放进文档；PNG 兼容性好，适合发消息。源文件必须跟图一起进版本库，这是硬要求。

7. 实操中反复踩到的坑与应对

7.1 图面信息过载的减法技巧

新手画架构图最常见的毛病是什么都想画上去。一张应用架构图上塞了三十多个模块、上百条连线，画的人觉得信息完整，看的人直接放弃。架构图的目的是沟通，不是存档，存档有详细设计文档。

减法技巧有三条。按读者裁剪：给业务方看的图只保留业务域和核心能力，模块级细节删掉；给研发看的图保留模块和关键依赖，部署细节删掉。按问题裁剪：这次评审要解决什么问题，只画跟这个问题相关的元素。评审模块拆分合理性，就重点画模块边界和依赖，中间件细节可以省略。按层级折叠：把稳定的、不需要讨论的部分折叠成一个框，展开只画有争议的部分。

我自己的习惯是每张图先画完整版，然后问自己“删掉哪个框读者会看不懂”，删不掉的保留，删得掉的删掉。通常完整版能删掉三成到五成的元素，图反而更清楚。

7.2 跨团队评审时的表达策略

跨团队评审架构图，最大的挑战是术语不对齐。同一个词在不同团队含义不同，比如“服务”这个词，业务团队理解成“服务内容”，研发团队理解成“服务进程”，运维团队理解成“服务实例”。评审时各说各话，讨论半天发现说的不是一回事。

应对策略是开场先对齐术语表。把图上出现的关键术语列出来，每个术语给一句话定义，评审开始前花五分钟过一遍。这个动作看起来多余，实际能省掉大量无效争论。术语表不用很正式，图旁边放一个小方框列出来就行。

另一个策略是用场景串讲代替逐框讲解。不要从左上角第一个框开始讲，而是挑一条典型业务链路，从入口讲到出口，沿途经过的框顺带解释。听众跟着场景走，理解成本低很多。讲完一条链路，再补充其他链路的差异点。这个方法我用了很多次，评审效率明显高于逐框讲解。

7.3 架构图与代码脱节的预防

架构图画完就锁进文档库，半年后跟代码对不上，这是普遍现象。预防办法是把架构图纳入研发流程。具体做法：重大需求的技术方案里必须包含受影响的架构图变更，代码评审时如果发现实现跟架构图不一致，要么改代码要么改图，不允许放着不管。

另一个办法是定期做架构图与代码的对账。每个季度花半天时间，拿应用架构图的模块清单跟代码仓库的服务清单对一遍，多出来的模块补进图里，图上画了但代码里没有的模块删掉或者标注“规划中”。这个对账动作很枯燥，但能保证架构图始终是可信的参考，而不是历史遗迹。

数据架构图的对账可以跟数据字典维护合并做，技术架构图的对账可以跟资源清单核对合并做。把对账动作挂到已有的例行工作上，比单独发起一个“架构图更新专项”可持续得多。

8. 从一张图到一套图的落地建议

如果团队之前没有系统的架构图，不要一上来就四张图画全套。我的建议是从应用架构图切入，因为它是研发团队日常沟通用得最多的一张图，画出来立刻能用上。应用架构图画完，往上补业务架构图（跟业务方对齐），往下补技术架构图（跟运维对齐），最后补数据架构图（跟数据团队对齐）。

每张图的第一版不求完整，求能用。应用架构图第一版哪怕只画了核心五个模块，只要模块边界和依赖关系是准的，就比一张画了三十个模块但关系混乱的图有价值。后续随着业务演进逐步补充，图跟着业务长，而不是一次画完然后束之高阁。

画图的人选也有讲究。架构图最好由实际负责系统设计的研发负责人来画，不要交给不熟悉系统的同学代笔。代笔的图往往形似神不似，框画对了但关系画错了，评审时经不起追问。如果负责人时间紧，可以口述加白板草图，由其他人整理成正式图，但整理完必须由负责人逐项确认。

最后说一个我自己的体会：架构图的价值不在于画得多漂亮，在于画的过程中逼着团队把模糊的地方想清楚。很多设计问题是在画图时暴露的——画到某个模块发现它依赖了不该依赖的东西，画到某条数据流发现源头找不到。这些问题在画图阶段发现，改起来只是改几根线；等到代码写完再发现，改起来就是伤筋动骨。所以别把画架构图当成文档任务，把它当成设计评审的一部分，画图的过程本身就是设计。