远程医疗音视频系统，这个方向我前前后后折腾了大半年，从最初的需求调研、技术调研，到中期原型验证、试运行，再到最后的多院区联调上线，踩过的坑比想象中多得多。今天就把整个技术选型和落地架构盘一盘，重点是解释清楚每一步为什么这么选，以及在真实医疗场景里哪些坑是文档里不会告诉你的。

先交代一下背景，这套系统主要服务的是多院区远程会诊、疑难病例讨论和术前交流等场景，核心诉求有三个：一是音视频通话质量必须稳定，因为医疗场景里一张影像片子、一个术野画面糊了，会直接影响判断；二是架构要能平滑扩展，因为院区会持续增加，在线人数有突发峰值；三是必须满足数据安全和合规要求，所有音视频流都要加密，操作日志要留痕。

先说结论，整套系统最终的技术栈大概是：WebRTC + SFU模式，媒体服务用的是开源的mediasoup，信令服务基于Node.js自研，搭配Kubernetes做容器编排，编码优先使用H.264，同时保留AV1能力预留，录制模块独立部署，数据面和控制面彻底分离。下面把每个环节具体拆开讲。

1. 整体定位与选型框架

1.1 先想清楚：远程医疗对音视频系统的真实要求

很多人一上来就盯着延迟、清晰度这些参数，但远程医疗场景和普通视频会议有一个本质区别：画面内容本身可能是诊断依据。会诊时专家要看的是患者的舌苔、创面、皮肤颜色，或者是病理切片、影像报告，这就要求色彩还原度要高、文字边缘要清晰，而且整个过程中不能出现马赛克、花屏这种不可逆的损伤。

另一个容易被忽略的点是，远程医疗的参与者往往是“非对称”的。发起端可能是基层医院的医生，用一台笔记本加一个普通摄像头，网络环境可能是共享的办公Wi-Fi；而专家端可能在省会三甲医院的专用会诊室里，用的是专业摄像头和专线网络。两端带宽、设备性能、网络稳定性差距悬殊，系统必须有能力做动态适配，而不是简单粗暴地统一成同一套参数。

还有一个管理层面的需求：每场会诊都需要可追溯。这就意味着系统不仅要实时通信，还要支持录制、回放、第三方旁听，以及把音视频流与HIS系统的预约单关联。这些需求叠加在一起，直接影响了底层架构的选型方向。

1.2 我采用的是“链路倒推法”来做选型决策

正式选型时，我给自己定了一个原则：不看厂商宣传册，不追热点，先画出完整的数据链路，再在每个环节上列出可选方案和硬性约束。

这条链路大概是：采集端（摄像头/桌面屏幕）→ 编码 → 上行传输 → 服务端分发 → 下行传输 → 解码 → 渲染显示 → 录制归档。

每一个环节我都会问三个问题：

• 这个环节最核心的目标是什么？比如采集端的核心是画面质量和延迟的平衡，传输端的核心是抗丢包和动态带宽适配。
• 有哪些技术方案可以达到这个目标？
• 在医疗场景的约束下，哪些方案是不能碰的？

基于这个思路，我淘汰了不少看起来很美的方案。比如有些低延迟方案依赖客户端插件或SDK内嵌，这会大幅增加终端适配工作量；有些方案在公网环境下表现很好，但完全没考虑内网隔离的需求；还有些方案录制功能是后置的，需要额外拉流，这在医疗场景根本不行，因为会诊过程中不能有额外的旁路链路干扰主链路。

1.3 关键技术约束：浏览器端优先，还是客户端优先？

远程医疗系统的终端形态决定了整个技术选型的走向。如果走WebRTC浏览器方案，优势是零安装、跨平台，医生在会诊室里打开浏览器就能接入；劣势是如果遇到Safari的部分版本，或者特定的国产浏览器内核，兼容性问题会让人想砸电脑。如果走原生客户端方案，稳定性和控制力更强，但开发和维护成本成倍上升，特别是还要考虑医护人员的操作习惯和学习成本。

我们在实际调研中发现，基层医院的很多医生用了大量老旧电脑，浏览器版本常年不更新，强行推原生客户端反而不现实。最终定下的原则是“WebRTC浏览器为主，原生客户端为辅”：日常会诊全部走浏览器，涉及专业设备接入、4K术野画面等特殊场景，再引导用户安装专用客户端。这个策略让选型范围一下子收敛了，服务端只需要聚焦在WebRTC生态即可。

2. 传输层与媒体服务架构选型

2.1 WebRTC为什么是远程医疗的底线，而不是选择题

先说结论，要做远程医疗音视频，WebRTC不是一个“可选项”，而是“必选项”。核心原因是它解决了音视频实时传输中最难的两个问题：一是NAT穿透，医疗场景里客户端分布在各种复杂的网络环境里，有些在医院内网，有些在运营商大内网里，没有ICE框架的话，光打通P2P链路就够团队喝一壶的；二是端到端加密，WebRTC的SRTP协议栈强制加密，这几乎是医疗数据合规的最低门槛。

WebRTC体系里自带的一套东西，比如自适应码率、丢包重传、抖动缓冲，都是标准能力。你当然可以用纯RTMP或者SRT自建一套，但那就意味着从传输到播放全链路都要自己造轮子，而且RTMP的TCP传输机制在弱网下的表现远不如WebRTC的UDP加FEC（前向纠错）机制来得从容。

不过这里要特别提醒一下：WebRTC的“实时”是相对的，它默认的端到端延迟通常在300到500毫秒之间，这个区间对远程会诊来说完全够用。但如果你去做“远程手术指导”这种极致场景，还要求毫秒级操控，那纯WebRTC也是不够的，得叠加专线和更底层的协议优化，这属于另一个维度的问题了。

2.2 SFU模式才是医疗场景的正解，MCU和P2P都不适合

WebRTC的组网方式其实就三种：P2P单连、MCU集中转发、SFU选择性转发。很多人一开始会纠结选哪个，但放到远程医疗的具体场景里，答案是唯一的，就是SFU。

P2P模式的问题很直接：多人会诊时每路端到端要建立网格状的连接，上行带宽消耗是几何级增长的。假设5个人开会，每个人的客户端要同时上传4路视频流，这还没算屏幕共享，基层医院那点上行带宽根本扛不住。

MCU模式的思路是服务端把所有人的画面混合成一路再下发，听起来很省带宽，但服务端需要做转码、混流，计算开销极大。通常一台MCU服务器同时支撑10路720P会话就顶天了，而且混合后的画面分辨率、帧率会受限，专家想看某个细节时根本放不大，这在医疗场景是不可接受的。

SFU的做法是服务端只做转发，不碰流内容，每个接收端订阅自己需要的流层。这样一来，上行带宽压力被分摊到每个发送端，服务端只消耗下行带宽和少量信令开销，横向扩展也容易。而且SFU天然支持SVC（可分层编码）和Simulcast（多流并发），订阅端可以根据自己的网络情况选择高质量或低质量流，这套机制完美匹配了“专家端好网络看好画质、基层端弱网保连通”的诉求。

2.3 媒体服务选型对比：mediasoup、LiveKit、Janus，我为什么选了mediasoup

选SFU引擎时，我在mediasoup、LiveKit和Janus之间纠结了接近两周，最后选定了mediasoup，但另外两个也都有各自的适用场景。

先看Janus，老牌项目，功能很全，插件体系设计得不错，文档也算丰富。但它的架构相对偏重，很多功能用不到却必须带着跑，二次开发的学习曲线很陡。我们团队里刚上手的人看了一周源码还是畏手畏脚，这对于快速迭代的项目来说是个阻碍。

再看LiveKit，这两年热度很高，走的是“全家桶”路线，服务端、客户端SDK、录制、直播全包，部署起来确实方便，开发效率极高。我一度差点选它，后来发现两个痛点：一是它的服务端依赖Redis做信令协调，这对Kubernetes集群部署来说多了一个需要运维的组件，出问题的概率也增加了一分；二是LiveKit对自定义协议扩展的约束比较强，我们想要在信令层做深度定制的空间相对有限。

最后说mediasoup，核心优势有四个：首先是纯Node.js实现，和我们的信令服务同构，团队可以用一套语言体系搞定所有服务端逻辑，降低了维护成本；其次是它自身不关心信令格式，只负责媒体层的传输和转发，给了我们极大的上层设计自由度，我们可以在信令层随意扩展业务逻辑，比如预约校验、权限控制、断线重连；再其次是它的性能表现优秀，单台8核16G的服务器可以比较轻松地支撑30到50路并发音视频流转发，在远程医疗的量级下完全够用；最后是它内建了完善的实时统计API，我们可以拿到每一路流的丢包率、往返时间、码率等指标，这对后面的监控和问题排查太重要了。唯一需要适应的，是mediasoup对使用者的要求比较高，你必须真正理解WebRTC的语义才能用得顺手，但这对于做技术选型的人来说反而是好事，核心能力掌握在自己手里。

2.4 信令服务为什么必须自研，以及如何设计

媒体层用开源组件，信令层我坚持自研，这算是一个比较反直觉的决定。市面上有很多现成的信令方案，但远程医疗场景有几个特殊需求是通用方案覆盖不了的。

第一是业务耦合。信令里必须携带预约单号、参与人角色、会诊类型这些医疗业务数据，比如“申请端”和“专家端”的权限就不一样，申请人能看到的操作按钮和专家能看到的完全不同。通用信令服务很难理解这些业务语义。

第二是异常状态机。医疗会诊不允许“静默失败”，如果某个参与者掉线，系统必须在几秒内把状态同步给所有人，并且在参与者重新上线后能自动恢复，整套逻辑是复杂的有限状态机，需要和业务层做深度绑定。

我自己写信令服务时，最核心的设计是：把信令消息分为两类，一类是“控制信令”，比如房间创建、加入、离开、媒体验证，这类消息必须可靠有序，走WebSocket；另一类是“媒体信令”，比如ICE候选、SDP协商，这类消息可以走相同通道但允许乱序，我们直接复用了WebSocket的有序性，只是在业务逻辑上做了幂等处理。

另外要注意的是，信令服务和媒体服务完全分离部署，信令服务无状态，可以随意横向扩缩容；媒体服务有状态，但通过mediasoup的worker进程模型配合Kubernetes的Pod调度，也能做到节点级别的水平扩展。这套设计让系统在用户量翻倍时，只需加Pod、加节点，而不会出现单点瓶颈。

3. 编码、弱网与多端适配的实战取舍

3.1 编码标准怎么选：H.264是地基，AV1是储备

编码格式的选型直接影响画质、带宽占用和终端兼容性，我在这一层花了最多的时间做交叉验证，最终的结论很简单但过程并不简单。

首选H.264，这是一个看似保守但极其务实的决定。远程医疗场景里，终端类型太杂了，Windows老电脑、MacBook、Android平板、iPhone，甚至还有一部分国产医疗设备内置的浏览器。H.264的硬件解码支持是最广的，几乎所有设备的GPU和浏览器都能硬解，这样可以极大地降低CPU占用，延长老旧设备的使用寿命。

VP8和VP9虽然也有一部分终端支持，但总体兼容性还是比H.264差一些，特别是某些移动端浏览器对VP9的支持是时好时坏，会直接影响会诊体验，所以我没有把VP8/VP9作为主编码。

AV1和H.266这类新一代编码的压缩率确实诱人，在同等画质下可以比H.264节省30%到50%的带宽。但现在的硬件编码器还不普及，纯软件编码对CPU的消耗又太高，所以在医疗这种不能冒风险的场景里，AV1目前只作为“储备方案”留着。我在代码里预留了编码参数的接口，等到终端硬编覆盖率足够高之后再考虑切换。

3.2 弱网环境下的“保连通优先”策略

医疗场景的网络状况比企业办公网复杂得多。基层卫生院的出口带宽可能只有10M到20M，而且楼上做心电图、楼下做B超的时候，网络会突然波动。所以我在做弱网策略时，定的原则是“连通性大于画质”。画面可以模糊，但声音不能断，视频不能黑屏，因为会诊过程中一旦画面卡死，医生的节奏就全打断了。

落地到具体执行，我会用这几个手段组合使用。一是启用Simulcast，让发送端同时生成高、中、低三路不同分辨率的视频流，接收端根据自身网络情况动态选择订阅哪一路，这是SFU架构下最优雅的降级方案；二是调整拥塞控制参数，WebRTC默认的GCC算法比较保守，我基于mediasoup的控制通道做了优化，让接收端的REMB反馈更加频繁，这样网络恢复后可以更快地提升码率；三是开启动态分辨率适配，通过监听音频包到达情况来判断链路质量，发现连续丢包时就主动把视频分辨率从720P降到360P，这个策略实测下来效果显著。

但要注意的是，弱网策略不能一味求稳，因为过度压缩会导致画面细节丢失。比如会诊看皮肤病变时，如果分辨率降得太低，红色斑块的边界就完全看不清了。所以我给分辨率降级设了“底线”：最高保底的清晰度是360P，低于这个就不再降级，宁可卡顿也不能让画面失去诊断价值。这个“临床底线”是我和一线医生反复交流后定的，比任何技术参数都重要。

3.3 多端适配清单：从浏览器兼容到硬件兼容

多端适配是整个项目里最繁琐的部分，因为医疗系统不可能强制所有用户统一用某一种设备。这里我列一份实际的适配检查和参数项，供后来者参考。

先看浏览器矩阵。Chrome和Edge是主力，功能最全，问题最少。Firefox在部分Linux终端上还是要测一下，它在WebRTC的实现上有一些边界情况。Safari最头疼，特别是屏幕共享功能，老版本Safari不支持getDisplayMedia的部分参数，需要做降级处理；音视频播放的autoplay策略也和Chrome不同，需要额外处理。

再看操作系统。Windows 7虽然微软早已停止更新，但基层医院还有不少存量电脑在跑，这些机器上的Chrome版本一般比较老，WebRTC的API支持不完整，我建议在代码里做版本检测，低于某版本时给出升级提示。macOS相对省心，但要注意摄像头权限弹窗的逻辑，有些医生点了“拒绝”就再也找不到入口了。Android和iOS的移动端走WebRTC的话，比较关键的是硬件编码能力差异，部分中低端手机硬编H.264会出现绿屏，需要做能力降级。

最后是外设兼容，这个往往最容易被忽视。医疗场景里有大量USB视频采集卡、高清摄像头、会议全向麦克风，它们对WebRTC的适配程度参差不齐。我们遇到过一款很常见的采集卡，在Windows下暴露出来的分辨率和帧率组合不符合标准，导致WebRTC协商失败。解决办法是在采集阶段做能力枚举，对不支持的格式做转换，而不是直接报错。

3.4 屏幕共享与录制归档：两个不可妥协的细节

远程医疗中屏幕共享的优先级极高，因为需要共享的内容太关键了，比如影像系统的读片界面、病理切片软件的实时画面。屏幕共享和摄像头视频流在技术上的核心差异是：屏幕内容的每帧数据量大、变化频率低，更看重文字清晰度而不是流畅度。

我在配置屏幕共享时，会强制把编码profile设置为High，码率上限放宽到4Mbps，并且关闭Simulcast的自动降级，目的很简单：保证共享的影像报告边缘锐利、文字可读。这里踩过的坑是，如果不做限制，某些浏览器在共享屏幕时会默认开启码率自适应，遇到网络抖动后会突然把码率降得很低，导致文字糊成一团，医生根本没法看。

录制方面，我直接把录制当成一个独立的“特殊参会者”来设计。录制节点以SFU客户端身份加入房间，订阅所有参与者发布的高清流，然后通过服务端混流或单流录制的方式写入存储。这样做的好处是录制不干扰正常参会者的转发链路，哪怕录制挂了也不影响看诊。归档格式我选的MP4，兼容性最好，但要注意录制文件的时长轮转和索引策略，医疗场景的录像可能长达几小时，一个文件切分成多段再统一索引，后续回放和导出会更方便。

4. 服务端落地架构与安全合规细节

4.1 服务端组件全景：控制面、媒体面、数据面彻底分离

整套服务端的架构，我把它整理成三个平面：控制面、媒体面、数据面。它们互相独立部署，但在逻辑上协同完成一次完整的会诊。

控制面是信令服务和业务后台，负责预约管理、房间创建、参与者鉴权、通话状态机管理。这是一组无状态服务，通常跑3到5个Pod在前面挂负载均衡就够了。这个平面最大的压力在于会诊开始和结束时的突发信令风暴，比如一个30人的授课式会诊同时入会时，信令QPS会瞬间冲高，无状态部署配合水平扩展能轻松扛住。

媒体面就是跑mediasoup的节点池。每个节点的上限我用并发数而不是CPU使用率来控制，比如单节点最大同时服务50路音视频流转发，超过阈值就拒绝新房间的调度，而不是硬扛。每个媒体Pod内部，我启动了多个mediasoup worker进程，每个worker绑定独立的CPU核心，避免进程间互相抢占调度资源。这个部署细节对性能影响很大，很多人以为一个mediasoup进程就够用了，实际上在多核机器上不显式绑核的话，UDP包的处理时延会有明显抖动。

数据面是录制、截图、事件日志和监控数据的存储层。录制产生的媒体文件先写本地临时目录，再由上传组件归档到对象存储；实时事件日志走消息队列，异步写入查询服务。把数据面彻底分离出来，是为了避免I/O密集型任务拖累媒体转发。

4.2 Kubernetes部署的取舍与网络模型

整套系统跑在Kubernetes上，但媒体服务在K8s里的网络部署和普通Web服务完全不同，这是整个架构中最容易出现线上事故的地方。

WebRTC的媒体流走的是UDP，而且端口范围是动态协商的，所以Kubernetes的Service负载均衡模型在这里行不通。我不能用ClusterIP这种虚拟IP做媒体流负载，因为UDP流经过NAT或负载均衡会破坏ICE的连通性。我的做法是：信令服务走标准的K8s Ingress暴露，媒体服务则使用DaemonSet模式部署，每个节点上跑一个媒体Pod，并且用hostNetwork直接暴露物理网络端口，再由上层F5或自建的UDP网关做四层转发。

这里要特别说一下，大部分K8s发行版默认的Service转发模式对UDP并发流的性能是不太友好的，尤其是会话数暴涨时，kube-proxy的iptables规则更新会成为瓶颈。直接采用hostNetwork之后，媒体节点就变成了纯物理网络模型，延迟明显下降，而且排查网络问题时也更直接。

4.3 媒体调度算法的核心：先做容量检查，再做路由决策

当用户发起会诊时，后台会调用调度模块来完成一次媒体分发决策。很多人以为调度就是把用户随机扔到一个可用的节点上，但医疗场景对调度有两点额外要求：一是同一次会诊的所有参与者尽可能调度到同一个机房或同一网络区域，这样可以降低跨地域的链路抖动和成本；二是要预留“突发房间”的容量，不能把节点全部塞满，否则紧急会诊时没有资源可分配。

我的调度算法分了三个步骤。第一步是容量检查，查询各媒体节点的CPU、内存、网络利用率和当前并发数，过滤掉负载过高的节点；第二步是亲和性检查，如果当前会诊的主持人已经在某个节点上，优先把新参与者调度到同节点；第三步是延迟估算，基于参与者IP的归属地，选择最近区域的媒体节点接入。这套算法跑下来，绝大多数情况下参与者从点击“入会”到画面出现，时间控制在2秒以内。

4.4 安全与合规：加密、鉴权、录制的“红线”

医疗数据的安全合规不是纸面条款，是必须落到每一行代码里的硬要求。我在这套系统里做了三层防护。

第一层是通信加密。WebRTC自身的SRTP加密是默认开启的，但要注意的是信令通道的加密同样重要，如果信令被截获，攻击者可以伪造加入房间请求。所以信令WebSocket全部走WSS，并且使用双向TLS认证，服务端和客户端都持有证书。

第二层是业务鉴权。每次加入房间的请求都要携带一次性Ticket，Ticket由后台接口签发，绑定预约单号和有效时间。媒体服务在收到入会请求后，会先验证Ticket的有效性，再创建对应的媒体传输，而不是让客户端直接裸连。

第三层是录制管理。录制的文件在静态存储时必须加密，播放时需要单独的授权Token，且下载操作要留审计日志。回放系统也不能直接把MP4文件地址暴露给前端，而是通过后端鉴权后的流媒体地址去获取。

注意：涉及医疗场景时，最好让法律和隐私团队提前介入，把数据留存期限、访问权限、跨境传输限制这几条红线尽早定下来，后期再改的成本非常高。

5. 常见问题与排查技巧实录

5.1 “看不见画面”类问题的排查路径

会诊场景最常见的故障是“对方能听到声音，但看不到画面”，我把这类问题的排查路径总结成了一套固定流程，方便一线运维直接照做。

第一步看SFU侧统计。通过mediasoup自带的stats接口，查看发送方和接收方各自的丢包率、Bitrate、可用带宽。如果发送方bitrate为0，问题大概率出在编码侧或摄像头采集；如果发送方bitrate正常但接收方bitrate为0，问题出在下行链路或订阅逻辑。

第二步看协商结果。用chrome://webrtc-internals查看SDP协商，确认双方是否选定了H.264 profile，以及分辨率是否和预期一致。实战中遇到过Safari浏览器发起会话时默认选用了VP8，而Windows端的接收方不支持VP8导致黑屏，最后通过在服务端统一指定编解码优先级解决。

第三步看防火墙和网络策略。有些医院内网会封锁UDP端口或限制UDP流量，这会让WebRTC媒体流无法穿透，而信令走TCP反而正常，形成“能入会但没画面”的诡异现象。遇到这种情况，可以直接在客户端尝试切换为TCP-only模式（WebRTC支持这种降级），验证是不是UDP被封了。

5.2 高并发场景下媒体节点CPU飙升的元凶

系统试运行第三周，遇到过一次比较严重的线上问题：某场大型远程授课会诊有120人参与，连续运行40分钟后，媒体节点的CPU使用率从25%一路飙升到98%，整场会诊的画面开始明显卡顿。

一开始我怀疑是并发数超过了节点承载能力，但查监控发现并发数远低于预估上限。后来逐项排查才发现，罪魁祸首是部分参与者长时间静音后，WebRTC的音频DTX（不连续传输）机制没有正常工作，导致这些空闲流持续以全速率编码传输，把CPU和带宽白白吃掉了。解决办法是在信令层面增加“静音感知”策略，检测到参与者音轨连续30秒能量为0时，主动对音频流做静音替代处理，只传极小的舒适噪音包，确认效果后CPU占用直接回落了40%。

5.3 录制文件时间轴错乱的坑：混合流与多通道时间戳

录制模块上线后，我们收到过几次关于“回放时间轴不对”的反馈，具体表现是：部分参与者画面突然快进或跳跃。排查发现，原因出在录制节点从SFU拉取的各参与者视频流使用了不同的时间基准，而混流器直接按照客户端时间戳去做对齐，导致出现时间轴错乱。

这个问题折腾了比较久，最后解决的方案是在录制节点单独做一次“时间戳归一化”：以服务器的系统时基为准，把各参与者流的时间戳统一映射到录制时间轴上，而不是直接使用客户端发来的原始时间戳。另外一个经验是，录制节点最好只订阅视频流和主音频流，不要订阅冗余的屏幕共享辅流，否则混流时画面轨迹会变得更复杂。

5.4 主备切换与断线重连的细节坑

医疗会诊对可用性的要求高，所以我把断线重连也当成了核心功能来打磨。第一次做的是“用户在Wi-Fi和4G之间切换”的场景，发现WebRTC的ICE连接会断开但又在几秒后自动恢复，这时候业务层的UI往往还停留在“连接中”的状态，容易把医生搞懵。后来我在信令层增加了ICE连接状态变化的主动上报，让前端能实时感知“重连中”和“已恢复”，体验提升明显。

另一个容易忽略的问题是媒体服务节点重启时，原节点上的房间状态会丢失。我当时的做法是：媒体节点在启动时从注册中心拉取当前应该存在的房间列表，如果发现之前有房间没解散，就自动重建房间并通知控制面把参与者重新拉回来。这套主备恢复逻辑在测试环境可能看不出价值，但在真实故障演练时，能少挨很多骂。

6. 几条我觉得值得你带走的实战心得

整套系统从选型到上线，我最大的体会是：技术选型的核心不在于选最酷、最新的东西，而在于能不能覆盖场景里最脏、最累的那些边缘情况。比如H.264看起来不够新潮，但它就是能在老掉牙的电脑上流畅解码，这种“下限”在医疗场景里价值千金。

第二点心得是关于“监控体系”的。很多人把大量精力花在开发功能上，却在监控上做得非常简陋。远程医疗的线上问题往往只在某些特定网络环境、特定终端上暴露，没有全面的端到端链路监控，排查问题就像大海捞针。我最后把客户端的WebRTC统计上报、服务端信令日志、SFU媒体统计这三层数据打通，接了Grafana看板，才算是真正对线上状态有了掌控。

最后分享一个小技巧：给关键技术决策写“决策记录”，把当时为什么这么选、有哪些备选方案、最终考虑了哪些因素，都写清楚。这个文档初期看起来是成本，但半年后回头看，价值极大，尤其是团队新人接手时，可以直接通过这份文档快速理解架构的来龙去脉，不至于对着代码猜动机。

远程医疗音视频系统这条路走下来，确实没有捷径，但每一步都值得踩实。