简介这份PPT资料围绕平台架构图与产品架构图展开面向产品经理、架构师及项目汇报人员用于梳理平台规划、项目进展与阶段性成果也可作为数字化综合运营平台方案设计的参考底稿。压缩包仅含1个pptx文件大小约1.22MB共收录15张平台架构图与产品架构图以图示化方式呈现项目计划、截止当前完成工作与当前状态以及平台架构规划等内容。图中涉及业务应用层、业务中控平台、数据中台、技术中台、混合云与运维监控等模块并覆盖智慧城市、物流运输、物资采购等场景便于读者快速理解分层结构、能力支撑与业务中心之间的关系。已有165人学习适合需要制作架构汇报材料、梳理产品蓝图或补充方案表达的产品与技术人员参考。1. 从一次评审被问住说起平台架构图到底该画给谁看投影亮起来的那一刻屏幕上是一张塞满了业务场景、中间件、机房和专线的框图。评审的人看了三秒问了一句这张到底是产品架构图还是技术架构图。画图的人愣了一下因为他自己也没想清楚。接下来半小时全花在解释图例上方案本身反而没人问。这套 15 张的平台架构图和产品架构图解决的就是这件事——把「一张图讲完所有事」拆成一套分工明确的图立项汇报、架构评审、开发交接、答辩各拿各的那张。它覆盖从资源层、平台层、数据中台到业务引擎、业务应用、用户接入的完整分层也覆盖物流、供应链金融、物资采购、智慧车站几条业务线。适合正在写平台类毕设、做课程设计、或者要给甲方出一份完整平台方案的人直接拿去改。PPT 形态意味着它得经得起投影也经得起别人放大到 200% 逐字看。2. 五层横向骨架加两条纵向支撑先把分层定死再动笔所有平台类架构图出问题八成不是画得丑是分层没定死就开始摆方块。摆到一半发现订单中心不知道该放哪一层于是硬塞进平台层再过一会儿发现监控大屏既像应用又像工具干脆单独飘在右上角。到最后图能看但没人能顺着它讲出一条完整链路。我一般会先把分层写成一张文字清单确认每一层「只装什么、绝不装什么」再去 PPT 里画。2.1 从资源层到接入层的六段横向切分按这套方案的原始规划横向从上到下走六段层级装什么不装什么用户接入层Web 端、移动 APP、小程序、呼叫中心、服务终端、开放平台任何业务逻辑业务应用层订单管理中心、资源服务中心、业务服务中心、运营管控中心、客户服务中心中间件、数据库业务引擎层多维实时分析引擎、商业智能分析引擎、机器深度学习平台、实时音视频通讯平台、大数据交互可视化引擎、智能推荐引擎具体业务单据数据中台数据湖、各类主题库、接口服务运输 API、仓储 API、订单 API计算与存储的物理资源平台层容器与容器编排、虚拟机、块/文件/对象存储、集成引擎、负载均衡、软件定义网络、大数据组件、物联网管理、人工智能能力业务系统名称资源层计算资源、存储资源、网络资源、操作系统、数据库、机房与专线任何软件功能名这张表的价值在于「不装什么」那一列。画图时一旦有方块找不到位置先回头看它是不是越界了而不是新开一层。见过太多方案在中间临时加一个「支撑层」结果支撑层里既有消息队列又有客服系统两层语义彻底混掉。资源层和平台层的界线最容易被含糊处理。容器编排、虚拟机、对象存储属于平台层的能力封装机房、物理服务器、专线属于资源层。混合云场景下公有云、私有云、专线这三样要画在资源层而「混合云业务支撑平台」这种统一纳管的东西画在平台层。分清楚这一点后面讲部署架构的时候才不用重画。2.2 两条纵向安全防护和运维监控为什么必须贯穿到底横向分层解决「东西在哪」纵向解决「谁在兜底」。这套方案里纵向有两条安全防护从下往上依次是物理安全、网络安全、主机安全、数据安全、应用安全、终端安全外面再包一圈威胁情报、认证授权、云密码服务、源码加密。运维监控则是资产管理、配置管理、流程管理、备份管理、可用性管理加上状态监控、容量监控、性能监控、操作监控、应用监控五路监控最后汇到监控大屏和可视化交互。这两条为什么不能画成单独一页因为它们不是某一层的功能是横切的约束。一旦画成独立模块评审就会问「安全是第几层」这个问题本身就说明图画错了。正确画法是画成贯穿所有层的两条竖带宽度不必大位置固定在左侧和右侧让读者的视线从上往下扫的时候始终能看见它们的存在。有一点要提醒纵向带里的条目不要写成产品名。写「主机安全」「数据安全」是能力域写具体产品名就变成了采购清单图和方案的性质都变了。2.3 数据中台单独拎出来数据湖加主题库的两级组织数据中台在这套图里占的分量比一般方案重因为它承接了「用大数据支撑运营辅助决策」这条主线。组织结构是两级底下是数据湖装用户信息、运单数据、在途数据这类原始和多形态数据上面是按业务主题切分的库包括在途数据库、智能调度库、签收信息库、结算信息库、运单数据库、合同数据库、费用数据库、物流状态库、调度计划库、库存数据库、企业信息库。两级之间靠接口服务打通对外暴露的是运输数据服务、仓储数据服务、计费数据服务这类封装好的数据服务而不是直接暴露库表。这条设计在答辩时是加分项因为它回答了「数据怎么被业务用起来」这个必问问题。如果只画一排数据库评委会默认你只是把 ER 图换了个壳。主题库的命名建议统一成「XX库」而不是「XX表」颗粒度停在库这一级。图上一旦出现表名说明你在画数据模型那属于另一张图数据架构图不该混进总体架构里。3. 15 张图怎么排一套图的读者分工与依赖顺序单张图画得再好凑成一套也容易散。散的原因是每张图都在回答同一个模糊的问题——「这个平台长什么样」。读者不同需要的答案完全不同决策层想知道业务闭环架构组想知道技术边界开发和运维想知道自己那部分落在哪。3.1 三类读者三种详略决策层只看两件事这套系统服务谁、钱和数据从哪流到哪。给他们看的是业务架构图和产品架构图方块数量控制在 30 个以内每个方块后面跟一句人话注释。架构评审组看的是边界和取舍为什么数据中台独立、为什么引擎层不并入应用层、混合云怎么纳管。给他们看技术架构图和部署架构图允许密集但每条连线必须有语义。开发与运维看的是落位我负责的模块在哪一层、依赖谁、上线时挂在哪个环境。给他们看功能架构图和部署架构图的分区版本。同一份内容给三类人看最省事的做法不是做三套图而是做一套图配三种讲法。这套 15 张图的组织方式就是「一张总图 若干专题图」总图谁都能看专题图按需展开。3.2 从总图到分图的编号与依赖15 张图按依赖顺序编号前面的图定了口径后面的图不许改口径图号图名主要读者回答的问题D01平台总体产品架构图决策层平台由哪几块能力组成D02平台功能架构图业务方一共有哪些功能模块D03平台技术架构图架构组技术栈与分层怎么落D04平台业务架构图决策层商流、资金流、信息流、物流怎么走D05平台数据架构图数据组数据湖与主题库怎么组织D06平台部署架构图运维公有云、私有云、机房怎么摆D07安全防护体系图安全组七类安全能力覆盖到哪D08运维监控体系图运维五路监控与统一运维怎么接D09物流平台产品架构图业务线订单、运力、仓储、结算怎么串D10供应链金融平台产品架构图业务线贷前贷中贷后与风控怎么排D11物资采购平台产品架构图业务线招投标、采购协同、供应商怎么管D12智慧车站平台产品架构图业务线应急指挥、站场服务、旅客服务怎么合D13行业云平台架构图架构组多平台如何共用一套云底座D14综合运营管控中心架构图管理层指标、报表、大屏怎么汇D15实施路线与当前状态图全体已完成什么、下一步做什么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、RPCdata数据流向虚线箭头标数据形态流水、状态、指标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(encodingutf-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 秒剩下的时间留给提问。提问环节有个自查表可以提前过一遍常被问到该翻到哪张图一句话答法数据从哪来到哪去D05数据湖沉淀原始数据主题库按业务切分通过数据服务对外混合云怎么管D06资源层分公有云、私有云、专线平台层统一纳管安全做到什么程度D07七类安全能力横向覆盖威胁情报和认证授权贯穿和已有系统怎么对接D09/D11通过开放平台的 API 网关内部系统走专线接入现在做到哪一步了D15已完成部分标绿进行中标黄未启动标灰有一点我得说清楚D15 那张实施路线图很多人会画成一条漂亮的甘特条从头到尾一路绿到底。这种图在答辩现场是负分因为没人相信一个平台能全部做完。诚实标注当前状态——哪些模块已经联调、哪些只有设计、哪些还在排期——反而显得可信。这套原始方案开头就写了「截止目前完成的工作当前的状态」这个意识是对的。从那以后我每次交架构图都会强制走一遍「遮住图名 20 秒」的自查再让一个不参与画图的人复述三句话。他复述不出来的地方就是图上真正含糊的地方跟我自己觉得画得多细没关系。希望这套东西帮到你。本文还有配套的精品资源点击获取