上个月接了个活客户园区里散着三十多台海康的枪机、球机还有两台带云台的立杆设备。需求听起来很朴素做一个内部的管理台能在网页上看到实时画面能按时间段把录像调出来下载顺便把设备在线状态、告警输入口的状态汇总成一张总览表。听起来就是个调接口的活真上手才发现海康威视接口这块的水深程度和文档的零散程度足够写一篇复盘了。这篇文章就是我把整个过程拆开揉碎的记录包含 ISAPI、SDK、RTSP 三条路线的取舍认证踩的坑取流地址的拼接规则以及上线之后遇到的一堆奇奇怪怪的问题。如果你也在做摄像头对接、视频平台集成、或者只是想把一台设备的数据接进自己的系统这篇东西可以直接抄作业如果你完全是新手也不用慌我会把每个参数为什么这么填都讲清楚。1. 先把路线定下来三条对接路线怎么选1.1 需求还原客户说的接一下到底是什么很多人一听到对接海康威视接口脑子里第一反应就是调个 API 拿数据。但摄像头这类设备和普通的业务系统完全不是一个物种它是长在网线另一头的硬件有自己的操作系统、自己的时钟、自己的编码芯片还有一堆只在设备内部生效的配置。所以第一步永远不是写代码而是把需求翻译成技术动作。我拿到手的原始需求大概是这么几条第一网页上要能同时看 4 路实时画面支持切换到第 5 到第 36 路第二指定时间区间内能检索录像并下载成 MP4第三设备离线要告警第四要能远程抓一张当前画面存证。这四条拆开看其实对应了三种完全不同的技术手段实时预览走的是流媒体RTSP 或 SDK 取流录像检索和下载走的是内容管理接口ISAPI 的 ContentMgmt 系列设备状态和抓图走的是系统管理接口ISAPI 的 System 系列而离线告警本质上是一个心跳监测问题跟接口本身关系不大。把这四条拆开之后选型就清楚了不是选一条路走到底而是每条需求配最合适的工具。这一点是我踩了坑之后才想明白的一开始我试图全部用 SDK 解决结果实时预览很稳录像下载却因为回调模型写得别扭折腾了两天。1.2 三条路线的真实对比为了让你少走弯路我把这三条路线在真实项目里的表现列成表这些都是我实测出来的结论不是抄文档的对比维度ISAPIHTTP 接口设备网络 SDKRTSP / 流媒体协议接入难度低会用 HTTP 就能上手中高涉及动态库和回调低但播放器侧要处理跨语言支持极好任何语言都行一般官方主推 C/C#好交给播放器实时预览不擅长最擅长支持软解硬解擅长标准协议录像检索下载最擅长支持但接口偏底层不支持设备配置读写支持返回 XML支持结构体形式不支持部署依赖无需要随程序分发动态库无长期维护成本低高版本升级易冲突低看完这张表我的结论是这样的设备配置、状态查询、抓图、录像检索与下载全部走 ISAPI实时预览走 RTSP交给前端播放器或者后端的流媒体网关处理只有当你需要做画面叠加、本地录像、智能分析回调这些深度功能时才去碰 SDK。这个组合的好处是你的核心业务代码里几乎没有对某个动态库的硬依赖将来换品牌或者设备固件升级改动的面很小。至于 GB28181 那条路我也评估过它的优势是跨品牌统一适合接入几十上百路并且需要上级平台级联的场景。但这个客户只有三十来路、也没有级联需求上 GB28181 相当于为了搬家买一辆卡车收益不划算。选型这件事永远要按实际规模来不要被标准化三个字冲昏头。1.3 一个被我提前预判到的坑在动手之前我列了一份可能出问题的清单事后回看命中率大概七成。排在第一位的不是代码问题而是固件版本差异。同一个型号的设备出厂批次不同固件版本可能差好几个大版本而海康的接口在不同固件上是有行为差异的比如某些老固件的摘要认证实现不完整某些新固件默认关闭了部分接口还有些设备的 XML 返回结构体字段增删过。所以我给自己定了条规矩先写一个探测脚本把所有设备的型号、固件版本、序列号、支持的能力集全部拉回来做成一张表再决定代码怎么写兼容分支。这个动作花了我大概两个小时但后面省下来的调试时间至少是它的五倍。下面第二章就讲这一步具体怎么做。2. 对接前的准备工作把设备底细摸清楚2.1 设备身份三件套IP、端口、账号摄像头接进网络之后你要拿到三样东西才能开始IP 地址、服务端口、可用的账号密码。IP 一般由施工方规划好通常是同网段内顺序分配比如 192.168.10.64 往后排。端口这块海康设备默认的 HTTP 服务端口是 80服务端口是 8000RTSP 是 554。如果你看到设备后面还挂了一台录像机那录像机也会有自己的一套端口。账号这块有个细节要特别提醒绝对不要用 admin 账号去跑你的业务程序。正确做法是在设备上新建一个专用账号只赋予它需要的权限——预览、回放、日志查询这几项就够了参数配置、用户管理、固件升级这些一律不给。理由很直接你的程序代码里会硬编码或者存一份凭据一旦泄露损失范围必须被限制在能看画面这个级别而不是能改设备配置。设备侧还有一个经常被忽略的点校时。录像检索是按时间区间查的如果设备的系统时间和你的服务器时间差了几分钟你查出来的录像片段就会错位甚至查不到。我在项目里加了一个每天凌晨自动校时的任务让所有设备和业务服务器统一指向同一个时间源这个改动几乎零成本但避免了一类很恶心的偶发查不到录像的问题。2.2 设备端必须打开的几个开关拿到账号之后登录设备的 Web 管理界面有几项设置必须先确认。第一项是Web 服务与接口服务是否启用有些交付给客户的设备被集成商做过加固把 Web 端口关掉了这种情况你得先让现场开通。第二项是码流参数实时预览和录像下载用到的都是编码流如果主码流配了过高的分辨率加过高帧率带宽和 CPU 都会吃不消我通常会要求现场把主码流配成 1080P、25 帧、H.264辅码流配成 720P 或 480P、15 帧前端小窗口用辅码流放大再看主码流。第三项是网络传输协议的选择。海康设备支持几种传输模式实测下来在局域网内部署选低延迟的传输方式画面几乎没有延迟但如果设备挂在 4G 链路上就必须切换到对丢包更宽容的传输方式否则画面会频繁花屏。这个参数在设备的网络配置里有对应选项不同版本叫法不太一样看到传输协议或者流传输模式之类的字眼就对了。这里插一句很多人做这个项目时会被浏览器打不开摄像头画面卡住其实大部分情况不是网络问题而是浏览器缺少对应插件或者设备固件太老、只支持旧的插件体系。我一般的处理方式是把实时预览完全从设备自带的 Web 页面上剥离出来前端自己用标准播放器组件去拉流这样就不依赖任何设备侧插件了用户体验也统一。相关问题是第五章的重点这里先记一笔。2.3 开发环境与依赖准备如果你决定用 SDK那就要提前把库文件的事情理清楚。以 Linux 为例SDK 包里通常包含一个核心动态库、一组编码相关的辅助库、还有头文件。部署的时候有两个坑一是动态库搜索路径程序启动时如果找不到库会直接报加载失败解决办法是在启动脚本里设置库搜索路径环境变量或者干脆把库文件放到系统默认的库目录下并刷新缓存二是库的位数必须和你的运行时一致32 位程序配 64 位库报错信息会非常隐晦。如果走 ISAPI 的话依赖就简单多了选一个 HTTP 客户端库就行。我用 Python 做探测脚本用requests库生产服务用 Java 的话HttpClient或者OkHttp都能处理摘要认证用 Node.js 的话要注意自带的请求库对摘要认证支持得不够完整需要额外处理。总的来说ISAPI 这条路线在依赖管理上几乎零负担这也是我推荐它作为主力的原因之一。3. 核心接口细节认证、调用与取流3.1 摘要认证第一道关卡ISAPI 用的是 HTTP 摘要认证这个机制跟普通的账号密码放在请求头里完全不是一回事。它的流程是这样的你第一次请求时服务器返回 401并在响应头里带上一串随机数、领域标识等信息你拿着这串随机数加上自己的用户名、密码、请求方法和路径经过两层哈希运算拼出一个认证头再发一次请求。这个设计的好处是密码不会在网络上明文传输坏处是实现起来比普通认证麻烦。用 Python 的requests库的话直接用内置的认证方式就能搞定它帮你自动完成挑战-应答的全过程import requests from requests.auth import HTTPDigestAuth BASE http://192.168.10.64 AUTH HTTPDigestAuth(integration_user, 你的密码) def get_device_info(): url f{BASE}/ISAPI/System/deviceInfo resp requests.get(url, authAUTH, timeout5) # 401 说明账号密码或权限有问题其他非 200 也要留意 resp.raise_for_status() return resp.text但如果你用 Java 的原生HttpURLConnection就必须自己实现这套挑战-应答逻辑我当时写了大概八十行才跑通。所以我的建议是能用成熟的 HTTP 客户端就用别自己造轮子。这里有三个实测坑要记牢。第一部分老固件对摘要认证的实现不完整会出现认证头算出来但服务器不认的情况这种时候只能升级固件或者改用其他通道。第二字符编码问题如果你的密码里有特殊字符某些客户端库在计算哈希时用的编码方式不一致会导致认证失败最简单的规避方式是密码里只用字母和数字。第三认证的随机数是有时效的长连接复用的时候要注意刷新我见过有人把第一次认证的头部缓存下来反复用跑几分钟就开始大面积 401。3.2 常用 ISAPI 接口清单下面这些接口是我这个项目里真正用到的路径都是设备上的相对路径拼上http://设备IP就能访问。你可以把这张表当成自己的速查卡接口路径方法用途备注/ISAPI/System/deviceInfoGET设备型号、序列号、固件版本探测脚本第一步/ISAPI/System/statusGET设备当前状态部分型号不支持/ISAPI/Streaming/channelsGET码流通道列表拿通道号用/ISAPI/Streaming/channels/101/picturePUT抓图返回 JPEG 二进制/ISAPI/ContentMgmt/searchPOST录像检索请求体是 XML/ISAPI/ContentMgmt/downloadPOST录像下载需要先检索拿到标识/ISAPI/System/IO/inputsGET告警输入口状态门磁、红外等/ISAPI/System/timeGET/PUT设备时间读取与设置校时用抓图这个接口值得单独说一下因为它的行为跟直觉不太一样它是一个 PUT 请求请求体里要放一段描述用什么格式抓图的 XML返回的是二进制图像数据。如果你用 POST 去请求会直接报方法不允许。我第一次调的时候愣了半天以为是自己拼错了路径。录像检索的请求体结构长这样核心是时间区间和最大返回条数?xml version1.0 encodingutf-8? CMSearchDescription searchID8b1f2c3d-0001-4a5b-9c7e-000000000001/searchID trackList trackID101/trackID /trackList timeSpanList timeSpan startTime2024-06-11T08:00:00Z/startTime endTime2024-06-11T09:00:00Z/endTime /timeSpan /timeSpanList maxResults40/maxResults searchResultPostion0/searchResultPostion /CMSearchDescription注意两个地方searchID必须是标准 UUID 格式自己随便拼一个字符串服务器会拒绝时间格式用的是带Z后缀的 UTC 时间如果你的设备设置的是本地时区这里传 UTC 会差几个小时这个坑我后面还会细说。3.3 取流地址的拼接规则RTSP 取流地址的拼接是这类项目里最口诀化的知识点记住规则基本就不会错。格式是这样的rtsp://用户名:密码设备IP:554/Streaming/Channels/通道号通道号的编码规则是三位数第一位是通道序号后两位是码流类型。比如101表示第 1 通道的主码流102表示第 1 通道的子码流201表示第 2 通道的主码流202是第 2 通道的子码流。所以一个 8 路录像机主码流地址的通道号依次是 101、201、301……一直到 801。这个规则我一开始记混过把第二通道的子码流写成了 202 之外的东西结果取流一直失败。# 第 1 通道主码流 rtsp://integration_user:密码192.168.10.64:554/Streaming/Channels/101 # 第 1 通道子码流 rtsp://integration_user:密码192.168.10.64:554/Streaming/Channels/102这里有个实际经验前端同时预览 4 路以上时一律走子码流。主码流虽然清晰但四路 1080P 主码流对浏览器的解码压力非常大实测在普通办公电脑上 CPU 占用会飙到七八成风扇呼呼转。用子码流之后占用降到两成左右用户点开某个画面看细节时再单独切主码流这套策略运行了几个月用户反馈很好。3.4 SDK 独有的价值在哪虽然我把主力放在 ISAPI 上但 SDK 也不是完全没用。它有几个 ISAPI 替代不了的能力一是本地录像到文件可以在你的服务器上把流直接落成文件不依赖设备存储二是画面叠加和智能事件回调设备侧识别出的人、车等事件可以通过回调主动推给你而不是你去轮询三是对弱网环境的容错更好SDK 内部有自己的重连和缓冲机制。用 C# 接 SDK 的话核心调用顺序是初始化、登录、开启重连、注册回调。写起来大概是这样// 初始化全局只需要一次 CHCNetSDK.NET_DVR_Init(); CHCNetSDK.NET_DVR_SetConnectTime(2000, 1); CHCNetSDK.NET_DVR_SetReconnect(10000, true); // 登录设备 CHCNetSDK.NET_DVR_USER_LOGIN_INFO loginInfo new CHCNetSDK.NET_DVR_USER_LOGIN_INFO(); loginInfo.sDeviceAddress 192.168.10.64; loginInfo.wPort 8000; loginInfo.sUserName integration_user; loginInfo.sPassword 你的密码; CHCNetSDK.NET_DVR_DEVICEINFO_V40 deviceInfo new CHCNetSDK.NET_DVR_DEVICEINFO_V40(); int userId CHCNetSDK.NET_DVR_Login_V40(ref loginInfo, ref deviceInfo); if (userId 0) { // 一定要把错误码打出来光说登录失败没法排查 Console.WriteLine(登录失败错误码 CHCNetSDK.NET_DVR_GetLastError()); }这段代码里我特意留了一行错误码输出这是血的教训SDK 的接口几乎都是返回一个整数句柄失败就返回 -1具体原因必须靠错误码查表。我遇到过一次登录一直失败错误码指向的是网络超时最后发现是设备的服务端口被防火墙拦了跟账号密码一点关系都没有。4. 一次完整的实操过程记录4.1 第一步批量探活与信息采集正式写业务代码之前我先写了一个探测脚本把所有设备的身份信息拉一遍。这个脚本的逻辑很朴素读一个 IP 列表文件对每一个 IP 并发地请求设备信息接口把结果写进一张 CSV。import csv from concurrent.futures import ThreadPoolExecutor import requests from requests.auth import HTTPDigestAuth USER, PWD integration_user, 你的密码 def probe(ip): auth HTTPDigestAuth(USER, PWD) try: r requests.get(fhttp://{ip}/ISAPI/System/deviceInfo, authauth, timeout4) if r.status_code 200: text r.text model text.split(model)[1].split(/model)[0] serial text.split(serialNumber)[1].split(/serialNumber)[0] firmware text.split(firmwareVersion)[1].split(/firmwareVersion)[0] return ip, model, serial, firmware, 在线 except Exception as e: return ip, , , , f异常:{type(e).__name__} return ip, , , , 离线或认证失败 if __name__ __main__: ips [f192.168.10.{i} for i in range(64, 100)] with ThreadPoolExecutor(max_workers16) as pool: rows list(pool.map(probe, ips)) with open(devices.csv, w, newline, encodingutf-8) as f: writer csv.writer(f) writer.writerow([ip, model, serial, firmware, status]) writer.writerows(rows)跑完这一遍我拿到了一张表立刻就发现了问题三十多台设备里固件版本居然横跨了四个大版本其中有两台老设备的型号比较特殊返回的 XML 结构里字段名都和别的不一样。如果我没有先做这一步直接写业务代码那这两台设备会在上线之后突然报错排查起来会非常痛苦。提示并发数不要开太大摄像头这类设备的处理能力有限同时打十几个请求已经接近极限了再往上很容易出现超时误判。4.2 第二步把设备信息接口封装成统一服务拿到设备清单之后我开始写正式的服务层。这一层的设计目标是把所有设备的差异屏蔽在内部对外只暴露一组统一的语义化方法。具体做法是定义一个接口然后针对不同固件版本写不同的实现通过工厂模式根据设备版本选择合适的实现类。public interface CameraGateway { DeviceInfo getDeviceInfo(String ip); byte[] captureSnapshot(String ip, int channel); ListRecordSegment searchRecords(String ip, int channel, Instant start, Instant end); String buildRtspUrl(String ip, int channel, boolean mainStream); }这么设计的理由很简单摄像头对接这类项目最大的成本不是第一版开发而是后续的设备增补和固件升级。你今天写死一套逻辑明年客户换一批新固件设备你就要回来改一堆散落各处的代码。抽象一层出来新增一种设备只需要加一个实现类其他代码一行不动。这里还有一个非常关键的工程实践接口幂等性。设备状态查询、抓图这类操作是纯粹的读操作天然幂等随便重试但像设置设备时间下发配置这种写操作绝对不能盲目重试因为设备侧可能已经执行成功了只是响应包在路上丢了你再发一次可能造成状态冲突。我的处理方式是给所有写操作生成一个唯一的请求标识跟着请求一起发过去服务层记录已完成的操作标识重复的直接返回上次结果。4.3 第三步录像检索与下载的完整链路录像下载是两条请求串起来的先检索拿到一个播放地址标识再用这个标识去下载。检索那一步我踩的第一个坑是时间格式。前面说过请求体里用的是 UTC 时间而设备在配置界面里显示的通常是本地时间。我第一版代码直接把本地时间当 UTC 传进去结果查出来的录像整体偏移了八个小时客户看到报表时间对不上差点以为系统有 bug。处理方式是这样的所有对外展示的时间统一用业务系统所在时区所有发给设备的时间在出口处做一次时区转换在入口处再转回来。这个转换只在一个地方做其他地方一律不碰避免出现有的地方转了有的地方没转的混乱局面。第二个坑是分页。录像检索一次最多返回若干条如果时间跨度大、录像段很多需要带上偏移量翻页查询。我一开始没做分页以为一次就返回全部结果查一整天的录像只拿到最前面的几十条后面的全丢了。翻页逻辑要注意的是最后一页返回的条数通常小于最大条数可以据此判断结束但更稳妥的做法是持续翻页直到返回空结果。下载那一步请求体里要带上下载地址标识返回的是流式数据。这里的关键是不要把整个录像读进内存再写文件动辄几百兆的数据会把服务打爆正确做法是边读边写def download_segment(ip, playback_uri, out_path): body f?xml version1.0 encodingutf-8? downloadRequest playbackURI{playback_uri}/playbackURI /downloadRequest with requests.post(fhttp://{ip}/ISAPI/ContentMgmt/download, databody.encode(utf-8), headers{Content-Type: application/xml}, authHTTPDigestAuth(USER, PWD), streamTrue, timeout(5, 120)) as resp: resp.raise_for_status() with open(out_path, wb) as f: for chunk in resp.iter_content(chunk_size1024 * 256): if chunk: f.write(chunk)streamTrue加上分块写入这两个细节是下载大文件时必须做的。我第一版没加本地测试的时候小片段没问题一到生产环境下载半小时的录像服务内存直接飙到几个 G被监控告警抓了个正着。4.4 第四步实时预览与断线重连实时预览我没有用 SDK而是让前端直接用标准播放器组件去拉 RTSP 流中间经过一个流媒体网关转换。这样就绕开了浏览器插件的问题——用户不需要装任何东西打开网页就能看。预览这块最重要的事情是断线重连。摄像头不是永远在线的交换机会重启网线会被老鼠咬4G 链路的信号也会波动。我的做法是在流媒体网关侧监听流的健康状态一旦判定中断就在退避策略下自动重新拉流前端侧也是同样的逻辑播放器检测到流断开后先等待一小段时间再重连重试间隔逐步拉长避免在设备真的离线时疯狂重连把设备打挂。退避策略我用的是一秒、两秒、四秒、八秒这样的指数增长上限设在三十秒左右。别小看这个上限我见过有的实现是固定一秒重试设备离线的那个晚上日志被重连请求刷了几百万行磁盘直接写满。5. 常见问题与排查实录5.1 认证失败与 401 的排查顺序401 是最常见的问题排查要按顺序来不要瞎猜。第一步确认账号密码是否正确尤其是密码里有没有特殊字符第二步确认这个账号在设备上有对应权限新建的账号如果没勾选权限认证会通过但后续接口返回权限不足第三步确认设备侧是否开启了摘要认证之外的其他限制第四步确认请求方法是不是对的有些接口必须用 PUT 或 POST。还有一个隐蔽的情况设备的时间和服务器时间偏差过大时摘要认证的随机数校验可能失败。这个现象很迷惑人因为表现和密码错误几乎一样。所以我在排查清单里把校时放在了很靠前的位置。5.2 浏览器打不开画面怎么办这个问题我遇到的次数最多处理起来也最套路化。如果是在设备自带的 Web 页面上看不了画面大概率是浏览器缺少设备所需的插件或者插件版本和新版浏览器不兼容。我的建议是不要在设备自带页面上纠结直接用标准协议拉流到自己的播放器里这条路更干净也更可控。如果是在自己的系统里打不开就按这个顺序查先确认 RTSP 地址在命令行能拉通再确认流媒体网关拿到了流再确认前端播放器的地址和协议参数正确。逐段隔离五分钟能定位。5.3 画面卡顿、花屏与时间戳错乱画质类问题的成因比较分散我整理了几个典型场景。局域网内卡顿通常是码流参数太高或者交换机带宽被打满可以先降辅码流分辨率验证跨网络卡顿多半是丢包切换到对丢包更宽容的传输方式一般能缓解花屏但网络正常要怀疑解码器兼容性试试换个编码格式时间戳和实际时间对不上回去查设备校时。还有一种很特别的情况画面有明显的周期性卡顿每隔几秒顿一下。这种十有八九是网络里存在环路或者广播风暴找网络组的人查交换机通常能发现一个接错口的设备。5.4 夜间画面效果不理想的排查思路有客户反馈过摄像头在夜间切换到全彩模式后对移动物体的响应不够灵敏。这个问题看着像接口问题其实是图像参数问题跟你的对接代码一点关系都没有。我一般从三个方向排查一是环境照度是否足够全彩模式对光线有最低要求照度不够时画面噪点会暴增算法自然判不准二是图像参数是否合理增益、快门、宽动态这几项设置会直接影响夜间表现可以试着调一下三是设备侧的移动侦测灵敏度设置是否过低这个在事件配置里能改。遇到这类问题我的态度一贯是先把是不是设备本身的能力边界搞清楚再去怀疑代码。很多对接项目背的黑锅其实是硬件配置没调到合适状态。5.5 问题速查表现象最可能的原因处理动作请求返回 401账号权限、密码字符、时间偏差依次排查优先校时抓图接口报方法不允许混淆了请求方法确认使用 PUT检索结果时间整体偏移UTC 与本地时区混用出口统一转换只返回部分录像未做分页按偏移量翻页拉取下载大文件时服务内存暴涨未使用流式写入分块读取并落盘预览几秒后断开重连策略缺失或码流过高加退避重连改走辅码流设备离线告警不触发心跳判定的阈值设置不当连续多次失败才判离线部分设备接口报错固件版本差异按版本分支处理6. 上线前的稳定性与安全加固6.1 超时、重试与幂等这三件事我见过太多对接项目在测试环境跑得好好的一上生产就各种卡死。根因往往就是超时和重试没设计好。我的基线配置是这样的连接超时设五秒读取超时针对不同接口分别设置查询类设十秒下载类设两分钟以上重试只针对网络类错误和 5xx 错误4xx 一律不重试因为重试也不会成功重试次数控制在三次以内间隔用指数退避。幂等这一块前面提过写操作的标识去重这里补充一个更通用的做法把设备的每一次状态变更都记录成一条带时间戳的日志这样即使发生了重复下发你也能从日志里还原出实际发生了多少次而不是两眼一抹黑。6.2 账号权限与固件管理安全加固这件事最重要的不是加密算法而是最小权限。业务账号只给它需要的几项权限管理账号牢牢握在运维手里业务代码里绝对不出现管理账号。此外定期梳理设备固件版本把长期不更新的设备单独列出来评估这是很多项目上线之后就忘掉的一件事。网络层面我建议把摄像头划分到独立的网段只允许业务服务器访问它的服务端口其余流量一律阻断。这一步做好等于给整个系统加了一道物理隔离收益远大于成本。6.3 接口压力测试怎么做压力测试这块很多人不知道从哪下手我的做法是先定义清楚测什么。对摄像头对接来说需要压的不是每秒多少次请求而是并发预览路数和并发检索请求数这两个指标。因为设备侧的并发处理能力非常有限普通枪机同时应付十几路取流就已经很吃力了。工具上HTTP 接口部分我用的是一套脚本化的压测工具配置好并发数和持续时间观察响应时间和错误率流媒体部分没法直接压我采用的是逐路递增的方式从 4 路开始加每次加 4 路观察设备 CPU 占用和画面延迟找到性能拐点。实测下来这批设备在 12 路子码流并发取流的时候延迟开始明显上升所以我把前端默认的并发预览数控制在了 8 路以内。注意压力测试一定要在业务低峰期做而且要提前跟现场打招呼。我在一次压测中把录像机的服务打满导致客户的实时监控画面卡了十几分钟虽然事后解释清楚了但这个教训我记了很久。压测的观测指标我列了几个必须看的请求成功率、平均响应时间、百分之九十五分位响应时间、设备侧 CPU 与内存占用、网络出口带宽占用。前两个指标好看不代表没问题真正决定体验的是分位响应时间和设备资源占用这两个一旦恶化说明已经接近容量上限了。我个人在这个项目里最大的体会是摄像头对接这类活代码只占三成工作量剩下的七成都在摸清设备的脾气。先把设备清单摸透、把参数调对、把边界情况想清楚代码反而写得很快。另外一个小建议如果你也要做类似的集成第一版一定要把日志打全包括每一次请求的地址、耗时、返回码这些东西在出问题的时候就是救命稻草事后补日志的成本远高于一开始就写。