1. 部署视图概述：什么是部署视图、为什么需要部署视图、部署视图在嵌入式开发中的角色
各位做嵌入式的朋友，咱们今天聊一个很实在的话题——部署视图。
你可能听过这个词，也可能在架构文档里见过。但说实话，我见过太多团队把部署视图画成一张“盒子加箭头”的示意图，然后就扔一边不管了。这其实挺可惜的。
部署视图，说白了就是回答三个问题：你的软件跑在什么硬件上？它们之间怎么连？运行时怎么分工？
嗯，就这么简单。但越简单的东西，越容易被忽视。
1.1 什么是部署视图
先给个定义。部署视图是描述软件制品在硬件节点上的物理分布，以及节点之间的通信关系的一种架构视图。
我习惯把它理解成“软件的地图”。你想想看，做嵌入式开发，最终代码是要烧到芯片里、跑在板子上的。没有这张地图，你怎么知道哪个模块该放在哪个处理器上？
举个例子。一个典型的车载T-Box系统：
- 主控芯片跑Linux，负责网络协议栈和远程通信
- MCU跑RTOS，负责CAN总线收发和车辆控制
- 安全芯片跑专用固件，负责加密认证
这三个芯片之间通过SPI或UART通信。这就是一个典型的部署视图。
核心要点：部署视图不是画给项目经理看的，是画给开发者和测试人员看的。它要能指导你“代码该放哪、接口该怎么连、资源该怎么分”。
1.2 为什么需要部署视图
我刚开始做嵌入式那会儿，也觉得自己心里有数就行。直到有一次翻车了。
那是个物联网网关项目。我们团队把协议栈和业务逻辑都放在主控芯片上，结果上线后发现内存不够用。查了半天才发现——有个加密模块本来应该放在安全芯片上，结果因为部署视图没画清楚，大家默认都往主控上堆。
从那以后，我定了个规矩：任何嵌入式项目，必须先画部署视图，再写代码。
部署视图的价值，我总结了几点：
| 价值点 | 说明 | 我踩过的坑 |
|---|---|---|
| 明确分工 | 每个模块该放哪个芯片，一目了然 | 模块放错位置，导致性能瓶颈 |
| 接口清晰 | 芯片间用什么协议通信，提前约定好 | SPI和I2C混用，调试到崩溃 |
| 资源规划 | 内存、Flash、算力按节点分配 | 主控Flash爆了，MCU还剩一半 |
| 风险识别 | 单点故障、带宽瓶颈一眼看出 | 两个高频率模块共用一条低速总线 |
| 团队协作 | 不同模块的开发者知道依赖关系 | 两个团队同时改同一个接口 |
避坑指南：我曾经见过一个团队，部署视图画了，但画的是“理想版”——所有节点都连在一起，所有通信都顺畅。结果实际硬件连不上，因为有个节点用的电平是3.3V，另一个是5V。部署视图一定要反映真实硬件拓扑，别画“概念图”。
1.3 部署视图在嵌入式开发中的角色
嵌入式开发和纯软件开发的区别在哪？
纯软件开发，部署视图可能就是个“应用服务器-数据库服务器”的简单图。但嵌入式不一样。嵌入式系统里，硬件资源是有限的，通信是实时的，可靠性要求是极高的。
部署视图在嵌入式开发中，扮演着三个关键角色：
角色一：架构落地的“施工图”
你画了架构图，分了模块，定了接口。但怎么落地？部署视图就是那个“施工图”。它告诉你：
- 这个模块是跑在Cortex-A上，还是Cortex-M上？
- 它和另一个模块是通过共享内存通信，还是通过消息队列？
- 它的日志是输出到串口，还是通过网络上传？
没有部署视图，架构就是空中楼阁。
角色二：性能分析的“基准线”
我记得有个项目，客户说系统响应慢。我们拿着部署视图一看，发现问题了——有个传感器数据采集模块和图像处理模块放在同一个MCU上。MCU既要轮询传感器，又要做图像压缩，CPU占用率直接飙到90%。
后来我们把图像处理模块挪到另一个带DSP的芯片上，响应时间从200ms降到了30ms。这就是部署视图的价值——一眼看出性能瓶颈在哪。
角色三：团队协作的“契约”
嵌入式项目通常涉及多个团队：硬件团队、底层驱动团队、应用开发团队、测试团队。部署视图就是大家共同遵守的“契约”。
硬件团队按部署视图设计电路板，驱动团队按部署视图开发BSP，应用团队按部署视图写业务逻辑。大家各司其职，互不干扰。
我的习惯：每次项目启动会，我都会把部署视图打印出来贴在白板上。谁改动了模块部署位置，必须更新视图并通知所有人。这招帮我避免了很多“我以为你改了”的尴尬。
1.4 部署视图的核心要素
说了这么多，部署视图到底该画什么？我总结了一个“4+1”要素模型：
- 节点（Node）：物理硬件设备，比如MCU、MPU、FPGA、传感器
- 制品（Artifact）：部署到节点上的软件单元，比如可执行文件、库、配置文件
- 通信路径（Communication Path）：节点之间的连接方式，比如SPI、I2C、CAN、以太网
- 部署规格（Deployment Specification）：每个节点的资源约束，比如内存大小、Flash容量、CPU频率
- +1 运行时约束（Runtime Constraint）：实时性要求、功耗限制、安全等级
下面这张图，是我常用的部署视图框架：
1.5 什么时候该画部署视图
不是所有项目都需要一开始就画部署视图。我一般按这个节奏来：
- 项目启动阶段：画一个粗粒度的，确定主芯片和关键外设
- 架构设计阶段：细化到每个模块的部署位置和通信方式
- 硬件选型阶段：根据部署视图评估资源是否够用
- 开发过程中：每次有模块迁移或接口变更，同步更新
- 系统集成阶段：用部署视图做集成测试的参考依据
一句话总结：部署视图不是画完就完事的文档，它是贯穿整个嵌入式开发周期的“活地图”。你越早画、越勤更新，后面踩的坑就越少。
好了，这一章就聊到这。记住我说的——下次项目启动，先别急着写代码，把部署视图画出来。你会发现，很多问题在画图的时候就暴露了，而不是等到联调时才手忙脚乱。