企业官网建设流程全解析

简介：这份PPT资料围绕平台架构图与产品架构图展开，面向产品经理、架构师及项目汇报人员，用于梳理平台规划、项目进展与阶段性成果，也可作为数字化综合运营平台方案设计的参考底稿。压缩包仅含1个pptx文件，大小约1.22MB，共收录15张平台架构图与产品架构图，以图示化方式呈现项目计划、截止当前完成工作与当前状态，以及平台架构规划等内容。图中涉及业务应用层、业务中控平台、数据中台、技术中台、混合云与运维监控等模块，并覆盖智慧城市、物流运输、物资采购等场景，便于读者快速理解分层结构、能力支撑与业务中心之间的关系。已有165人学习，适合需要制作架构汇报材料、梳理产品蓝图或补充方案表达的产品与技术人员参考。

1. 从一次评审被问住说起：平台架构图到底该画给谁看

投影亮起来的那一刻，屏幕上是一张塞满了业务场景、中间件、机房和专线的框图。评审的人看了三秒，问了一句：这张到底是产品架构图还是技术架构图。画图的人愣了一下，因为他自己也没想清楚。接下来半小时全花在解释图例上，方案本身反而没人问。

这套 15 张的平台架构图和产品架构图，解决的就是这件事——把「一张图讲完所有事」拆成一套分工明确的图，立项汇报、架构评审、开发交接、答辩各拿各的那张。它覆盖从资源层、平台层、数据中台到业务引擎、业务应用、用户接入的完整分层，也覆盖物流、供应链金融、物资采购、智慧车站几条业务线。适合正在写平台类毕设、做课程设计、或者要给甲方出一份完整平台方案的人直接拿去改。PPT 形态意味着它得经得起投影，也经得起别人放大到 200% 逐字看。

2. 五层横向骨架加两条纵向支撑：先把分层定死再动笔

所有平台类架构图出问题，八成不是画得丑，是分层没定死就开始摆方块。摆到一半发现订单中心不知道该放哪一层，于是硬塞进平台层；再过一会儿发现监控大屏既像应用又像工具，干脆单独飘在右上角。到最后图能看，但没人能顺着它讲出一条完整链路。

我一般会先把分层写成一张文字清单，确认每一层「只装什么、绝不装什么」，再去 PPT 里画。

2.1 从资源层到接入层的六段横向切分

按这套方案的原始规划，横向从上到下走六段：

这张表的价值在于「不装什么」那一列。画图时一旦有方块找不到位置，先回头看它是不是越界了，而不是新开一层。见过太多方案在中间临时加一个「支撑层」，结果支撑层里既有消息队列又有客服系统，两层语义彻底混掉。

资源层和平台层的界线，最容易被含糊处理。容器编排、虚拟机、对象存储属于平台层的能力封装，机房、物理服务器、专线属于资源层。混合云场景下，公有云、私有云、专线这三样要画在资源层，而「混合云业务支撑平台」这种统一纳管的东西画在平台层。分清楚这一点，后面讲部署架构的时候才不用重画。

2.2 两条纵向：安全防护和运维监控为什么必须贯穿到底

横向分层解决「东西在哪」，纵向解决「谁在兜底」。这套方案里纵向有两条：

安全防护从下往上依次是物理安全、网络安全、主机安全、数据安全、应用安全、终端安全，外面再包一圈威胁情报、认证授权、云密码服务、源码加密。运维监控则是资产管理、配置管理、流程管理、备份管理、可用性管理，加上状态监控、容量监控、性能监控、操作监控、应用监控五路监控，最后汇到监控大屏和可视化交互。

这两条为什么不能画成单独一页？因为它们不是某一层的功能，是横切的约束。一旦画成独立模块，评审就会问「安全是第几层」，这个问题本身就说明图画错了。正确画法是画成贯穿所有层的两条竖带，宽度不必大，位置固定在左侧和右侧，让读者的视线从上往下扫的时候始终能看见它们的存在。

有一点要提醒：纵向带里的条目不要写成产品名。写「主机安全」「数据安全」是能力域，写具体产品名就变成了采购清单，图和方案的性质都变了。

2.3 数据中台单独拎出来：数据湖加主题库的两级组织

数据中台在这套图里占的分量比一般方案重，因为它承接了「用大数据支撑运营辅助决策」这条主线。组织结构是两级：底下是数据湖，装用户信息、运单数据、在途数据这类原始和多形态数据；上面是按业务主题切分的库，包括在途数据库、智能调度库、签收信息库、结算信息库、运单数据库、合同数据库、费用数据库、物流状态库、调度计划库、库存数据库、企业信息库。

两级之间靠接口服务打通，对外暴露的是运输数据服务、仓储数据服务、计费数据服务这类封装好的数据服务，而不是直接暴露库表。这条设计在答辩时是加分项，因为它回答了「数据怎么被业务用起来」这个必问问题。如果只画一排数据库，评委会默认你只是把 ER 图换了个壳。

主题库的命名建议统一成「XX库」而不是「XX表」，颗粒度停在库这一级。图上一旦出现表名，说明你在画数据模型，那属于另一张图（数据架构图），不该混进总体架构里。

3. 15 张图怎么排：一套图的读者分工与依赖顺序

单张图画得再好，凑成一套也容易散。散的原因是每张图都在回答同一个模糊的问题——「这个平台长什么样」。读者不同，需要的答案完全不同：决策层想知道业务闭环，架构组想知道技术边界，开发和运维想知道自己那部分落在哪。

3.1 三类读者，三种详略

决策层只看两件事：这套系统服务谁、钱和数据从哪流到哪。给他们看的是业务架构图和产品架构图，方块数量控制在 30 个以内，每个方块后面跟一句人话注释。

架构评审组看的是边界和取舍：为什么数据中台独立、为什么引擎层不并入应用层、混合云怎么纳管。给他们看技术架构图和部署架构图，允许密集，但每条连线必须有语义。

开发与运维看的是落位：我负责的模块在哪一层、依赖谁、上线时挂在哪个环境。给他们看功能架构图和部署架构图的分区版本。

同一份内容给三类人看，最省事的做法不是做三套图，而是做一套图配三种讲法。这套 15 张图的组织方式就是「一张总图 + 若干专题图」，总图谁都能看，专题图按需展开。

3.2 从总图到分图的编号与依赖

15 张图按依赖顺序编号，前面的图定了口径，后面的图不许改口径：

D01 到 D08 是「一套底座」，D09 到 D14 是「六条业务线」，D15 收口。这个顺序的好处是，讲的时候可以随时停在任意一张，前后都能自洽；坏处是前期必须把 D01 的分层和命名彻底定死，否则后面 14 张全是返工。我见过最惨的一种情况是 D09 画完才发现 D01 里没有「开放平台」这个方块，于是回头补，补完 D03 的对齐全乱了。

3.3 每张图必须带的三样东西

标题栏。左上角固定写三行：图名、版本号、日期。版本号别写「最终版」「最终版2」，写 v1.0、v1.2 这种。答辩现场被问到「这是最新的吗」，能直接指版本号回答。

口径注释。右下角小字写清楚这张图的边界，比如「本图仅表达逻辑分层，部署拓扑见 D06」。这一行字能省掉一半的追问。

图例。颜色代表什么、实线虚线分别代表什么、箭头指向谁。图例不需要好看，需要的是每张图都用同一套。D03 里蓝色是平台层，D09 里蓝色就不能变成业务应用层，否则读者跨图阅读时会产生错乱。

4. 图上的元素规范化：命名、连线与一份可校验的结构描述

图画到第 8 张的时候，人会开始疲劳，命名开始飘。前面叫「订单管理中心」，后面叫「订单中心」，再后面变成「订单服务」。单看每张图都没问题，摊在一份 PPT 里就是事故。

4.1 模块命名的三段式

我的做法是给所有方块定一个三段式：能力域 + 对象 + 形态。

• 能力域：订单、运力、仓储、结算、风控、监控、安全
• 对象：中心、引擎、平台、服务、库、网关
• 形态：管理中心、调度引擎、数据服务

比如「订单管理中心」「智能调度引擎」「计费数据服务」「在途数据库」。这样命名之后，读者看名字就知道它大概在哪一层——带「中心」的基本在应用层，带「引擎」的在引擎层，带「服务」的多半是数据或接口层，带「库」的在数据中台。

对应的，有几类命名要禁用：不加「综合」「智能」「统一」这类前缀除非确有多个同类被合并；不写英文缩写除非全篇统一（写 Dubbo 就全写 Dubbo，不要一半写 RPC 框架）；不在方块里写版本号。

4.2 连线的四种语义

连线是架构图里信息密度最高的部分，也是最容易糊掉的部分。这套方案里只允许四种：

• call：同步调用，实线箭头，可标协议（RESTful、Dubbo、RPC）
• data：数据流向，虚线箭头，标数据形态（流水、状态、指标）
• deploy：部署归属，点线，从应用指向它所在的运行环境
• depend：弱依赖，无箭头实线，用于「需要但不同步调」的关系

规则定死之后有个直接好处：不许出现双向箭头。两个模块互相调用就画两条平行线，或者画一条call加一条data，绝不用一个双向箭头糊过去。双向箭头在评审时几乎必被追问「到底是请求还是回调」，答不上来就变成减分项。

跨层连线也要限制。业务应用层不能直接连到资源层，中间必须经过平台层或数据中台。这条约束在图上是能看出来的，一旦有人偷偷拉了一条直连，说明要么分层错了，要么这个模块被放错了层。

4.3 用一份结构化描述统一 15 张图的口径

15 张图纯手工对齐不现实。我的做法是先用一份 YAML 把每张图的节点和连线描述出来，再拿脚本做一致性检查，检查通过之后才动手排版。这样改一次分层，能一次性找出所有受影响的图。

# diagrams/D03-tech-architecture.yaml diagram: id: "D03" title: "平台技术架构图" version: "v1.2" layer_model: "six-layer" # 与 D01 共用同一套分层口径 nodes: - id: "L5-order-center" name: "订单管理中心" layer: "L5" # L1资源 L2平台 L3数据 L4引擎 L5应用 L6接入 type: "application" - id: "L4-schedule-engine" name: "智能调度引擎" layer: "L4" type: "engine" - id: "L2-mq" name: "消息队列" layer: "L2" type: "middleware" edges: - from: "L5-order-center" to: "L4-schedule-engine" kind: "call" # call / data / deploy / depend protocol: "RESTful" - from: "L4-schedule-engine" to: "L3-in-transit-db" kind: "data" payload: "调度计划"

节点里的layer字段是唯一权威的分层来源，PPT 上的颜色和上下位置都由它推出来，不靠手工摆。type决定方块形状：application 用矩形、engine 用圆角矩形、middleware 用深色块。

校验脚本负责抓三类问题：层的取值越界、连线端点悬空、节点孤立。

# tools/check_diagram.py import sys import yaml from pathlib import Path LAYERS = {"L1", "L2", "L3", "L4", "L5", "L6"} EDGE_KINDS = {"call", "data", "deploy", "depend"} # 允许的跨层连线：应用->引擎/数据、引擎->数据/平台、数据->平台、平台->资源 ALLOWED = { ("L5", "L4"), ("L5", "L3"), ("L4", "L3"), ("L4", "L2"), ("L3", "L2"), ("L2", "L1"), ("L6", "L5"), ("L5", "L2"), } def check(path: str) -> list[str]: doc = yaml.safe_load(Path(path).read_text(encoding="utf-8"))["diagram"] errs: list[str] = [] layer_of = {n["id"]: n["layer"] for n in doc["nodes"]} for n in doc["nodes"]: if n["layer"] not in LAYERS: errs.append(f'{doc["id"]} 节点 {n["id"]} 的 layer 越界：{n["layer"]}') for e in doc["edges"]: if e["kind"] not in EDGE_KINDS: errs.append(f'{doc["id"]} 连线 {e["from"]}->{e["to"]} 语义非法：{e["kind"]}') if e["from"] not in layer_of or e["to"] not in layer_of: errs.append(f'{doc["id"]} 悬空连线 {e["from"]} -> {e["to"]}') continue pair = (layer_of[e["from"]], layer_of[e["to"]]) if pair not in ALLOWED: errs.append(f'{doc["id"]} 违规跨层 {e["from"]}({pair[0]}) -> {e["to"]}({pair[1]})') linked = {e["from"] for e in doc["edges"]} | {e["to"] for e in doc["edges"]} for n in doc["nodes"]: if n["id"] not in linked: errs.append(f'{doc["id"]} 孤立节点 {n["id"]}，检查是否漏连或该删') return errs if __name__ == "__main__": total = [] for f in sorted(Path("diagrams").glob("*.yaml")): total.extend(check(str(f))) print("\n".join(total) if total else "全部通过") sys.exit(1 if total else 0)

脚本里ALLOWED这个集合是关键参数，它把「哪些层之间允许有连线」写成了硬约束。实际用的时候按方案调整：如果方案里允许接入层直连数据中台（比如小程序直读指标），就往里加一条("L6", "L3")，但加之前要想清楚这是设计还是将就。

失败时看什么：报「违规跨层」多半是模块放错了层，先回去改layer而不是放宽ALLOWED；报「孤立节点」通常是画图时漏了一条线，也可能是这个模块本来就该删；报「悬空连线」是改了节点 id 没同步改连线，属于纯手误。

提示：这份 YAML 不必给别人看，它是给你自己对齐口径用的。但答辩时被问「你这 15 张图口径怎么保证一致」，能拿出来讲，说服力比口头保证强得多。

5. 避坑：五处最容易在答辩现场被打断的地方

5.1 图上的模块名和系统里对不上

现象：评委会指着图问「这个客户服务中心，和你们需求文档里的客服管理是一个东西吗」。一问就卡住。

原因：图是画图的人按自己理解命名的，需求文档是另一个人写的，中间没有对齐环节。这类问题在小团队里几乎是必然，因为没人负责口径。

解决：画图前先把需求文档里的模块名导出一份清单，图上的方块名必须从清单里挑，不允许自创。确实需要抽象合并的，在图例里写一行「客户服务中心 = 客服管理 + 工单 + 回访」。这一行字能挡掉后续所有追问。

5.2 分层画成了功能清单的横条堆叠

现象：图很整齐，一行一行排得满满当当，每行十几个方块，但读者看完记不住任何东西。评委的评语通常是「信息量很大，但重点不突出」。

原因：把「分层」理解成了「分行」。分层的前提是层与层之间有明确的服务关系——上层调用下层，下层不感知上层。如果只是把功能按类别横向排开，那不是分层，是分类列表。

解决：每一层只放 4 到 8 个方块，超出的合并成「其他」。合并之后如果发现某一层只剩一个方块，说明这一层没必要独立，并到相邻层去。这套方案里引擎层之所以独立，是因为它下面被数据中台托着、上面被应用层调着，服务关系明确；如果只是因为「有几个分析功能不好归类」，就不该单开一层。

5.3 箭头方向反了、双向箭头泛滥

现象：数据流向箭头从数据库指向应用，看起来像是数据库在主动推数据。或者满图双向箭头，看着很热闹，讲不清谁调谁。

原因：画的时候想的是「这两个模块有关系」，而不是「关系朝哪个方向」。关系是有方向的，偷懒画成双向，信息就丢了。

解决：动手前先确定这张图的主语。D03 技术架构图的主语是调用方，箭头从调用方指向被调方；D05 数据架构图的主语是数据，箭头从数据源指向消费方。同一份 PPT 里不同图的主语可以不同，但每张图内部必须统一，并在图例里写明「箭头表示调用方向」或「箭头表示数据流向」。

5.4 一页塞进三层信息，答辩翻不到重点

现象：一张图上同时有业务模块、技术组件、机房分区，投影出来字小到看不清，讲到第三分钟自己都找不到鼠标指的地方。

原因：怕信息不全，什么都不敢删。实际上删掉的东西可以在下一页单独展开，塞在一页反而谁都记不住。

解决：一张图只讲一件事。D01 讲能力构成，D06 讲部署位置，两张图里同一个模块名可以重复出现，这不算冗余，这叫互相索引。答辩时的标准动作是「先放总图讲 30 秒，再切专题图讲 2 分钟，最后回到总图收口」，页码要对得上。

5.5 PPT 里的文本框错位、字体丢失、导出变形

现象：在自己电脑上对齐得很好，拷到答辩现场的机器上，方块整体右移，箭头和方块脱开，字体变成默认宋体。

原因：用了系统里不一定有的字体，或者用了组合形状但没组合完全，再或者导出 PDF 时选了压缩图片。

解决：全篇统一用思源黑体或微软雅黑这类通用字体，字号只用三档（标题 20、模块名 12、注释 9）。所有方块和连线在做完后统一「组合」，避免误拖。交付前必须做一次 PDF 导出检查，导出后逐页看箭头是否还对得上。这套 15 张图我建议额外留一份 PNG 备份，现场 PPT 打不开时能直接插图应急。

6. 验收与答辩：拿一张总图串起三句话

这套图做完，怎么判断它算不算合格？我给的标准很土：随便抽一张，遮住图名，让别人看 20 秒，能说出「这是什么平台、分几层、我该看哪块」，就算过。

答辩现场更实用的技巧是「一张总图 + 三句话」。总图固定是 D01，讲的时候不逐块念，只讲三句：

第一句说清服务谁——「这套平台服务需求方、承运方、仓储方和运营方四类角色，入口分别是 Web、APP、服务终端和开放平台」。这句话把用户接入层和业务应用层的存在理由交代了。

第二句说清靠什么撑——「底下是混合云资源池和平台层能力，中间是数据中台把在途、调度、结算这些主题数据沉淀下来，上面是六个业务引擎对外输出分析和调度能力」。这句话把 L1 到 L4 一口气带过，不用逐个方块讲。

第三句说清怎么转起来——「订单从需求发布进来到交易撮合、运输执行、签收结算，全程状态回流到数据中台，再喂给运营管控中心出指标」。这句话讲的是业务闭环，也是评委最爱追问的地方。

三句话讲完大约 90 秒，剩下的时间留给提问。提问环节有个自查表可以提前过一遍：

有一点我得说清楚：D15 那张实施路线图，很多人会画成一条漂亮的甘特条，从头到尾一路绿到底。这种图在答辩现场是负分，因为没人相信一个平台能全部做完。诚实标注当前状态——哪些模块已经联调、哪些只有设计、哪些还在排期——反而显得可信。这套原始方案开头就写了「截止目前完成的工作，当前的状态」，这个意识是对的。

从那以后我每次交架构图，都会强制走一遍「遮住图名 20 秒」的自查，再让一个不参与画图的人复述三句话。他复述不出来的地方，就是图上真正含糊的地方，跟我自己觉得画得多细没关系。希望这套东西帮到你。

本文还有配套的精品资源，点击获取