前几个月交付了犍为县交通监控中心的分布式系统改造项目最近系统正式通过验收、全面投用。趁着还有点热乎劲把这次项目的完整思路、技术选型、部署过程和踩过的坑整理出来给正在做类似监控中心改造、或者打算从传统单机架构往分布式方向迁移的同行们一个参考。先说下项目背景犍为县原有的交通监控中心一直是传统的单机集中式部署——一台中心服务器承载了前端所有摄像头的视频接入、存储、转发卡口数据、违法数据、信号灯状态等业务系统也都跑在同一台物理设备上。过去车辆保有量没这么大、路网没那么密的时候问题不大但近几年前端点位逐年增加新增了不少违停抓拍、电子警察和流量检测设备中心服务器的CPU常年跑在80%以上存储盘的写入瓶颈越来越明显夜间高峰时段偶发视频卡顿和丢帧。更要命的是单机部署就意味着单点故障一旦设备宕机整个监控中心全部瘫痪别说调录像连实时预览都看不了。所以这次改造的核心目标很明确打破数据壁垒把原本耦合在单机上的业务拆开让整个监控中心具备横向扩展的能力同时提升系统的可用性和容错能力。下面按项目推进的顺序把设计和实施的关键内容逐一展开。1. 整体设计与方案选型为什么必须上分布式传统监控中心的问题本质上不是设备性能不够而是架构限制了扩展。单台服务器的CPU、内存、磁盘带宽都是物理上限前端点位增加到一定规模再怎么堆硬件也撑不住。我在这类项目上吃过亏早年有个项目就是不停给单机加内存、加硬盘最后加到顶配还是卡只能推倒重来。所以这次一开始就定了调子必须上分布式。1.1 核心需求拆解先搞清楚到底要解决什么问题做任何架构改造之前第一步都是梳理需求。犍为县这个项目的需求表面上看是“监控中心太卡了”但拆开来看其实是四个独立的问题视频接入压力大前端高清摄像头1080P起步部分点位是400万像素产生的实时视频流需要持续写入存储同时还要分发给大屏和控制台预览。这是一个高并发、高带宽的读写场景。业务数据耦合严重交通监控不只是看视频还包括卡口过车记录、违法抓拍图片、信号灯配时方案、设备运维状态等多类业务数据。这些数据访问模式各不相同有的需要频繁写入过车记录有的需要频繁查询违法图片取证混在一起互相干扰。单点故障风险高原有架构下任何核心部件损坏都可能导致整个系统不可用。对于交通监控这种7x24小时运行、不能中断的业务来说这是最不能接受的。扩容能力不足未来前端点位还会继续增加新的业务应用也会不断上线系统必须具备按需扩展的能力而不是每次扩容都大动干戈。这四个问题对应到技术层面需要的分别是流媒体负载均衡与集群存储、业务数据的分类解耦、故障自动切换、以及水平扩展能力。这恰好就是分布式系统最擅长解决的几类问题。1.2 架构选型从“大而全”到“小而专”选型阶段我对比了几个方向。一开始有厂家推荐直接上一台更高配置的小型机把CPU、内存翻倍再加个磁盘阵列。这个方案便宜省事但治标不治本——它只是延后了瓶颈出现的时间没有解决扩展性和可用性的根本问题。还有厂家推荐云化部署把所有业务都迁到云上。理论上可行但县域交通监控涉及大量的视频流媒体传输对带宽延迟要求极高把所有视频流都推到云端既不经济也不现实——前端点位到云机房的专线带宽成本可能比系统本身还贵。最终确定的方向是混合分布式架构中心侧自建分布式集群前端接入层和流媒体分发层做本地化部署业务数据层和业务应用层做集群化部署。这个方案的核心思路是“把鸡蛋分到多个篮子里”——每个业务组件独立部署、独立扩展、互相备份任何一个节点出问题都不影响整体。具体来说整体架构分成四层接入层负责前端摄像头的接入认证和码流接收部署多台接入服务器组成集群通过负载均衡把不同摄像头的视频流分发到不同的接入节点上。存储层采用分布式存储集群把录像数据切片后分散存储到多个存储节点上每个节点互为冗余。业务层卡口、违法、信号灯等业务系统分别独立部署各自使用独立的应用服务器和数据库实例互不干扰。展示层大屏、指挥台、Web客户端通过流媒体分发集群获取视频和业务数据不直接访问存储节点。这个架构的好处是每一层都可以独立扩展比如将来新增摄像头只需要增加接入节点和存储节点新增业务应用只需要划分独立的计算和存储资源。层与层之间通过标准接口通信耦合度大幅降低。1.3 几个关键选型的决策逻辑具体到技术组件选型有几个决策我想单独说一下因为这些选择直接决定了项目能不能落地。流媒体服务方案。这个是最核心的部分。传统NVR软件都是单机架构而我们要的是集群方案。我测试过开源的ZLMediaKit、SRS也评估过商业流媒体平台最后选了基于SRS做二次开发。原因很简单SRS对GB/T 28181协议的支持比较完善而交通监控行业前端设备基本都走GB28181国标接入省去了大量协议适配工作。另外SRS在弱网环境下的表现比较稳定符合县域网络环境参差不齐的实际情况。视频存储方案。监控行业传统的存储方式是NVR直存或CVR集中存储但这两种方式都是“一台设备管一堆盘”横向扩展能力有限。我采用的方式存储这块直接用分布式文件存储集群把视频切片均匀分布到多台存储服务器上。这里用到了一个监控行业不太常见的思路把视频当成海量小文件来处理而不是按照传统NVR的思路按照录像通道建固定目录。这样做的代价是录像回放的定位逻辑要从头实现但收益是存储利用率大幅提升扩容时只需要增加节点即可。数据库方案。卡口过车数据的特点是写入量大、按时间范围查询频繁、单条数据价值低但总量巨大。我选了关系型数据库存储结构化业务数据加上时序数据库存车流量统计和设备运行状态后者在写入吞吐和按时间聚合查询上的性能确实强很多。这个选型参照了物联网平台的做法事实证明在交通流量这类典型时序数据场景下效果立竿见影。2. 核心系统实现拆解分布式改造到底改了哪些东西方案定了之后落地阶段其实更像瘦身手术——原来的系统是“一坨”各种功能交错在一起牵一发动全身。分布式改造要做的就是把这些交错的功能剖开、切成模块、重新接线。2.1 接入层的负载均衡实现摄像头接入是第一个要解决的环节。原来所有摄像头的视频流都直接推给中心服务器中心服务器要同时完成收流、存储、转发的多重任务压力非常大。改造后我在接入层部署了多台接入网关前端设备通过GB28181协议注册到统一的SIP服务器上再由SIP服务器按照负载均衡策略把视频流请求分发到不同的接入网关。这里有一个细节要注意GB28181协议本身支持多级级联原本就能让设备注册到不同的SIP服务器上但实际项目里前端摄像头数量多、厂商杂逐个修改摄像头的注册地址工作量巨大。我在SIP服务器上做了虚拟IP对外仍然是一个注册地址内部通过负载均衡把不同设备的信令分发到不同的接入节点。这样前端设备完全不需要改动改造过程对业务几乎无感。接入网关内部还要解决一个视频流的转发效率问题。如果每路视频都经过“收流—重新编码—转推”的流程CPU开销会非常大。我们用的是一个比较成熟的技巧收到原始码流后不做转码直接做流式转发只在分发环节做协议转换比如把国标流转换为RTMP或HLS供网页端播放。这样接入网关的转发性能可以做到接近网卡线速单台设备支撑几百路视频流的转发不成问题。2.2 存储层的分布式文件系统选型与调优录像存储是整个系统里对可靠性要求最高的部分。我最初考虑的方案是直接用开源分布式文件系统但测试下来发现视频写入的特点是持续大带宽顺序写而开源系统普遍针对通用文件场景优化对视频流这种持续高吞吐写入的适配一般。最后我们决定采用商业监控厂商的云存储方案——这类方案本质上也是分布式架构但针对视频存储场景做了专门优化比如数据切片策略、故障域隔离机制、录像索引的分布管理等。具体部署时存储节点采用了纠删码而不是传统的多副本模式。举个例子如果是三副本三台存储节点存同样的数据三倍的存储成本换来安全冗余。如果是纠删码比如41模式数据和校验信息分布到5台节点上允许其中任意1台宕机而存储成本只有原来的1.25倍。监控录像数据量大用多副本存储意味着多出两倍的成本在县域项目里预算上很难接受。纠删码在成本和可靠性之间找到了一个平衡点。存储集群调优方面有两个参数很关键。一个是数据切片大小我测试了从4MB、8MB到32MB的切片大小对写入性能的影响最终设成了16MB——这个大小下顺序写入吞吐最稳定碎片最少。另一个是写入缓存策略因为视频流是持续写入的如果每次写入都立刻落盘磁盘IO会瓶颈我们把写缓存调到合理区间配合后端异步刷盘在应急断电时可能丢失的数据量控制在几秒内这对于交通视频监控的合规要求来说是可以接受的。2.3 业务数据的解耦与分布原来的业务系统是一个大单体应用卡口数据、违法数据、设备管理、用户权限全在一个数据库里。查询违法记录的时候如果恰好碰上卡口过车数据的写入高峰数据库锁竞争会很严重查询响应时间经常会超过10秒。改造后我把数据按照业务域拆分成独立的库每个库只负责自己的业务卡口库存过车记录核心字段是车牌号、过车时间、方向、速度等。这个库的写入压力最大做了按时间分区表按月分表。违法库存违法抓拍的图片索引和证据链信息图片文件本身存在分布式对象存储中库里只存访问路径。基础库存设备信息、点位信息、用户权限等基础数据数据量小但读写频繁。流量统计库存车流量、平均车速、道路饱和度等时序数据用专门存储。拆分之后各业务之间的IO干扰问题基本消失。卡口库写压力再大也不影响违法库的查询。业务应用的部署也跟着做了拆分原来是“一个大Tomcat跑所有服务”现在拆成了多个独立服务各自扩容、各自更新互不影响。2.4 高可用与故障切换机制分布式架构如果只有“分布”没有“高可用”那就是徒有其表。这个项目的可用性设计分三个层次接入层HA多台接入网关通过负载均衡设备对外统一提供IP负载均衡设备自身做双机热备。故障切换时间控制在秒级。存储层HA分布式存储本身就具备节点故障自动重建的能力。某个节点宕机后系统会自动在其他节点重建丢失的数据副本或校验数据整个过程不需要人工介入。业务层HA核心业务服务部署在多台服务器上通过心跳机制互相监控。如果主节点超过一定时间没有发送心跳备用节点自动接管。我在测试环境验证过故障切换时间可以控制在30秒以内应用层面用户几乎无感知。这里我想特别强调分布式的高可用不是“把软件装上就行”而是需要从网络设计、配置管理、监控告警多个层面配合才能实现的。比如网络层面要保证各个节点之间低延迟互通配置层面要把每个节点的配置管理好避免漂移运维层面要有完善的监控体系能在故障发生前预警、发生时告警、发生后快速定位。3. 部署落地阶段的关键细节与踩坑实录方案在图纸上画得再漂亮部署阶段才是真正见真章的时候。这个项目从进场到联调通过花了两个多月过程中遇到了一堆文档里查不到的问题这里挑几个典型的详细说说。3.1 第一步网络规划决定了分布式系统的生死分布式系统对比单机最大的变化就是各个节点之间需要频繁通信。原来所有数据都在一台机器内部流转现在变成了跨服务器传输。如果网络规划不合理整个系统即使架构再优秀也跑不起来。犍为这个项目的网络规划花了一周时间做调研和设计。前端点位分布在城区十几个路口和几条主干道大部分通过运营商专线汇聚到监控中心机房。机房内部按功能划分了三个网段管理网段用于设备管理和状态采集、存储网段用于视频流和存储数据的分发与写入、业务网段用于业务系统的数据交换。其中存储网段是2万兆网专门给视频写入用避免和业务流量互相抢占带宽。这个规划踩了一个坑分享一下最初存储节点和接入节点都接在同一台核心交换机上测试时发现视频写入速率不稳定经常出现瞬时降速。排查发现是交换机缓存不足在突发流量时出现了丢包。后来把存储网段单独划分出来接入节点和存储节点分别接到核心交换机的不同板卡上并把存储流量标记为高优先级队列问题才解决。3.2 部署步骤与关键配置参数整个部署过程按以下步骤推进每一步都有明确的验收标准基础设施准备机房机柜、供电、制冷确认服务器上架操作系统安装统一采用同一版本避免内核行为差异。基础组件部署部署分布式协调组件、消息队列、负载均衡组件验证各组件之间通信正常。存储集群初始化配置分布式存储集群初始化纠删码策略用压测工具验证写入性能达到预期我这里的验收标准是持续并发写入不低于每节点350MB/s。接入集群配置部署SIP服务和接入网关配置负载均衡策略逐个把前端摄像头从原平台迁移到新接入域下。业务系统迁移卡口、违法、信号灯等业务数据做全量导出按新库表结构导入业务应用切换到新环境。联调与试运行各系统之间做联动测试包括视频预览、录像回放、卡口查询、违法取证全流程走通试运行两周观察稳定性。这里挑几个关键参数和数据量级展开。卡口数据的迁移验证结果是两个月的过车记录共约1200万条全量迁移用了4个小时导入完成后做抽样比对数据完整率99.99%。违法图片共约15万张迁移过程中发现部分旧系统存储的图片文件名存在特殊字符在对象存储中兼容性有问题写了个脚本做了批量重命名和索引修正这也是旧系统迁数据常见的坑。视频录像方面因为录像的底层存储结构完全不同原有录像做了保留策略——保留旧系统90天内的录像作为过渡期查询使用超过90天的按归档策略清理新录像全部写入新存储集群。3.3 视频业务改造中最容易出问题的三个环节录像文件切片与索引。分布式存储和传统NVR的录像索引机制完全不一样。传统NVR在录像时按通道按时间段建立索引文件回放时直接按索引寻址。分布式存储下录像被切成了16MB的切片文件分散到多个节点上。我开发的回放组件做了两级索引第一级是时间索引记录某个时间段对应的切片文件位置第二级是切片索引记录切片文件在哪个存储节点上、偏移量是多少。这部分的坑在于一些老的上位机软件调回放时用的是文件路径方式不支持我们的两级索引接口最后在这类老软件上做了兼容层才解决。国标设备批量迁移。前端摄像头的迁移是整个部署过程中最容易造成业务中断的一环。我的策略是两组设备并行运行——接入新网关的摄像头正常录像存储到新存储还没迁移的摄像头仍然在旧平台运行通过平台侧做统一视图。每个路口在夜间低峰时段切换切换前先离线升级摄像头固件、确认支持国标协议然后在新平台预注册、取流测试无误后再正式切换。整个迁移过程中监控中心的大屏从未出现全部黑屏的情况。并发回放的性能保障。交通监控中心的典型使用场景是事故发生后多名民警同时查询多个时段的录像。如果回放请求全部落到同一个存储节点上那个节点的磁盘IO会瞬间被打满。我在回放调度上做了按时间范围分片拉取的逻辑把同一个时间段的录像从多个存储节点并行拉取然后按时间顺序拼接输出。实测8个用户同时回放4路高清视频每路延迟稳定在1秒以内体验和本地回放基本一致。3.4 试运行阶段的数据修复和调优试运行期间发现的主要问题是卡口数据的入库延迟波动较大。正常情况下过车数据从前端设备上传到入库应该在5秒以内但试运行第三天出现了部分数据延迟到30秒以上的情况。查下来是消息队列的消费端配置问题——消费者实例数少于分区数部分分区消息积压而且数据库写入做了批量提交积压后形成雪崩。解决办法是调整消费者并发度同时在数据库端把单条INSERT改为批次写入每次攒够100条或者等待1秒再批量写入一次。调整后入库延迟稳定在3秒左右高峰期也没有再出现积压。另外存储集群在连续运行一周后出现了性能缓慢下降的迹象。检查后发现是长时间大量小文件碎片导致存储节点内部的索引膨胀影响了寻址效率。后来配置了周期性的碎片整理任务在每天凌晨低峰期执行性能恢复稳定。4. 常见问题与日常运维排查手册系统上线不等于结束对用户来说日常运维才是真正开始。这部分我整理了一份排查手册相当于新系统运维团队的“避坑指南”。4.1 视频流中断排查的五个层级视频流中断是监控系统最常见的故障类型。新系统里的排查顺序是第一层前端设备状态。登录设备管理平台确认摄像头在线状态、信号强度、编码参数是否正常。很多视频中断其实是前端设备掉电或网络闪断导致的与中心侧无关。第二层接入网关负载。查看接入网关的CPU、内存、会话数指标是否超出当前节点的承载能力。如果有会话协商异常优先重启接入服务而不是重启整个服务器。第三层网络链路质量。用ping大包测试接入节点到存储节点、接入节点到客户端之间的丢包和延迟。视频流对丢包非常敏感1%的丢包就可能造成画面卡顿。第四层存储集群状态。查看存储节点的磁盘空间、IO延迟、节点健康状态。如果单节点磁盘IO长期高位录像写入就会出现落盘慢的问题。第五层流媒体分发服务。确认分发服务的并发连接数和带宽使用是否达到上限达到上限时新用户的预览请求会被排队表现为部分客户端长时间加载。4.2 分布式集群性能排查的三板斧集群出问题的时候先别急着看应用日志按顺序做三件事看每个节点的资源曲线。分布式集群的常见问题是“热点”——某个节点负载特别高其他节点比较空闲。用监控大屏把全部节点的CPU、内存、磁盘IO拉一个24小时的曲线一眼就能看出来是不是存在热点。热点通常意味着数据分布不均匀或者负载均衡策略失效。我遇到过存储集群里一个节点磁盘空间比其他节点多占了30%查下来是前期扩容时数据迁移策略没有覆盖老节点导致新数据全部写到了新增节点上。看节点间的网络流量。如果集群内部网络流量异常偏高通常是数据副本同步或者数据均衡任务在运行。运维时要留意这类后台任务的调度窗口尽量安排在业务低峰期。我见过一个运维同事在白天手动执行了数据均衡任务结果把核心交换机的带宽占满前端视频全部卡顿这个事故完全是可以避免的。看应用层监控指标。中间件的队列深度、数据库的慢查询数量、流媒体服务的并发连接数变化趋势这些指标能提前预警系统容量问题。比如消息队列的积压数持续上升就说明消费端的处理能力跟不上生产端需要提前扩容不要等数据堆积到影响业务才处理。4.3 常见问题速查表故障现象可能原因排查方法快速恢复手段个别摄像头画面不出前端设备离线或网络中断登录设备平台查看在线状态远程重启设备或联系现场人员排查线路多个摄像头同时不出画面接入网关节点故障或负载过高检查网关节点资源和使用率在负载均衡层面摘除异常节点流量自动切换录像回放卡顿存储节点IO饱和查看存储节点IO延迟增加回放并发配置或临时限制回放路数录像查询有缺失时间索引和切片索引不一致执行索引重建任务对缺失时间段重新执行索引校验卡口数据入库延迟大消息队列积压或数据库写入慢查看队列深度和数据库慢查询重启消费服务并调整批量写入参数存储空间增长异常快数据均衡任务未完成或备份策略异常检查数据均衡进度和备份任务日志暂停非关键任务优先保障业务存储写入4.4 运维中的两个心得第一个心得是分布式系统一定要有集中式的监控入口。管理节点分散在各个服务器上如果没有一个统一的监控视图各个服务状态割裂排查问题无异于大海捞针。我们部署了统一监控平台把所有节点的CPU、内存、磁盘、网络、服务状态、告警信息全部汇聚到一个大屏上值班人员可以一目了然看清整个系统运行情况。这个投入是值得的它能把故障平均定位时间从小时级缩短到分钟级。第二个心得是变更操作必须要有严格的流程。分布式系统节点多、依赖关系复杂一次看似简单的变更比如升级某个组件的版本、调整某个存储节点的配置都可能影响其他地方。我们的做法是所有变更操作列入变更单明确变更内容、影响范围、实施计划、回退方案经审核确认后才允许实施。这在实际运维中帮我们避免了好几次事故。5. 这个系统能干什么从监控中心到基层治理的延伸系统投用一段时间后回过头看这个项目的价值不只是把监控中心的性能提升了它对基层交通治理的实际支撑作用远超最初预期。5.1 数据打通后的直接业务价值最直观的变化是数据查询效率。过去民警要查一辆车的轨迹需要在多个系统里分别查询然后手工比对拼接效率很低。现在过车数据统一存储在卡口数据库中按车牌号建了索引输入车牌就可以直接拉出车辆在全县所有路口的过车时间列表和图片证据轨迹一目了然。这在交通事故追查、走失人员寻找等场景中非常实用。违法取证也方便了很多。过去手动导出违法图片要一条条找现在违法库和图片存储做了关联点一条违法记录就能直接调出对应时间的图片序列复核效率大幅提升。系统上线后做过一次统计违法信息录入的日均效率比旧系统提升了约三倍。视频存储的可靠性提升也很有价值。过去单机存储偶尔出现录像文件损坏重要的视频证据丢失甚至无法恢复。现在分布式存储具备冗余机制单个节点故障不会导致数据丢失录像完整率做到了99.9%以上。这对需要长期保存证据的交通执法场景非常关键。5.2 为未来扩展预留的能力系统的横向扩展能力意味着今后增加新业务场景时不用再重复建设底层。比如目前只是接入了交通监控的摄像头但未来如果要接入治安监控点、雪亮工程点位、乃至移动车载视频只需要在接入层和存储层增加节点资源即可业务平台不需要改动。同样新的数据应用比如流量态势分析、信号灯自适应优化可以直接建在业务层之上调取底层数据接口即可不用再造轮子。这一点对接下来的基层治理工作有实际意义。基层治理涉及的道路隐患排查、重大活动保障、交通组织优化等都需要多维度的数据支撑。现在系统已经有了比较扎实的数据底座后续的新应用等于是在一个坚实基础上盖楼比从零开始要顺利得多。目前已有一个新的交通态势分析应用在规划中就是基于该系统提供的历史数据积累做道路拥堵预测和信号配时辅助决策预期能进一步缓解城区交通压力。这个项目的落地也让我想明白了一个道理基础架构的改造短期内不一定能看到直接的经济回报但它决定了一个团队未来很长时间能做什么事。分布式系统把数据壁垒打破了把系统的边界撑开了后面想做创新时才会发现自己手里有一把好用的工具。比起一座座赶工期的“新烂尾楼”先把地基打得扎扎实实才是真正对业务负责的态度。6. 现场部署与迁移实操记录这一节把系统上线过程中的具体操作记录一下有正在做类似迁移项目的可以直接参考。6.1 前端点位迁移的实施细节前端点位迁移是整个项目里最需要耐心的一环因为牵涉大量硬件设备和不同品牌的协议兼容问题。我按以下流程逐路执行确保不中断业务迁移前一周向平台侧申请批量升级前端设备固件统一到支持标准国标协议的版本。迁移当天晚上9点后开始逐路操作。先在分布式平台的接入域新增对应设备的注册信息确保设备基本信息正确。用测试工具向设备发起实时预览请求确认视频流畅、编码参数正确、时间戳符合国标要求。验证通过后把设备从旧平台摘除再在新平台正式注册。同时修改存储策略让这路视频从当日起写入新存储集群。每迁移完一个路口的设备立即通知监控中心值班人员确认该路口画面正常显示。全部迁移完成后把旧平台的设备信息做归档保留只读查询权限一个月用于过渡期数据核对。当时用的测试工具主要验证一路视频流的三个关键指标建立会话时间、首帧延迟、持续丢包率。我给自己定的验收标准是会话建立时间不超过2秒首帧延迟不超过500毫秒丢包率为0对这个类别的验收标准设定高一点是值得的。因为前端设备型号杂、品牌多有些老设备一迁移就容易出现协议不兼容问题提前设定好验收标准能快速定位是哪一环节出了问题。前期宁可多花时间测试每一路也不要盲目加快进度。6.2 录像迁移与历史数据保留策略视频录像和历史业务数据都是重要资产迁移策略必须谨慎。我们制定了分阶段保留方案新系统的录像从设备迁移起全部写入分布式存储集群不保留旧NVR中的录像文件。旧系统的录像文件在原设备上保留90天与原有存储轮询周期一致这90天作为双轨期方便处理历史告警和纠纷。卡口业务数据做了全量迁移迁移完成后在旧库上保留只读备份防止新库出现数据问题时无法追溯。违法图片全量迁移到新对象存储迁移完成当天对图片做完整性校验逐张比对MD5值。这里特别提醒做数据迁移的同仁千万不要在迁移后立刻清除旧数据。我在多个项目里都遇到过迁移时没发现问题、几个月后旧数据被清了、才发现某个字段映射错了的情况。保留旧数据至少三个月成本低但能救命。6.3 试运行两周的观察清单系统正式上线后的前两周是最关键的观察期我列了一份清单让运维团队每天对照检查实时预览成功率是否在99.5%以上有没有偶发黑屏或画面卡顿。录像回放的请求成功率是否稳定高峰期并发回放有没有明显延迟。卡口数据入库延迟是否在5秒以内有没有出现积压。存储节点的磁盘空间增长是否符合预期有没有某个节点增长异常。各业务服务的响应时间是否稳定有没有出现内存泄漏或线程池耗尽。故障告警的准确率是否可靠有没有大量误报或漏报。过了两周之后运维团队对系统的脾气也摸熟了一些就不再需要这么密集的日检了转为常规周检和月度健康检查。这段试运行期还发现了一个有价值的现象部分老设备尤其在偏僻路段的在夜间低光照环境下视频流偶尔会出现编码花屏但系统自身不产生告警这说明前端设备的运维也要纳入常态化管理不能指望中心侧架构改造解决所有前端问题。7. 系统监控与容量管理分布式系统的日常必备功课分布式系统上线后日常的工作重心要放在监控和容量管理上。这一节分享我们沉淀下来的一些操作规范。7.1 监控指标的选择与告警阈值设置监控告警不是指标越多越好重点要看那些能反映系统健康的指标。我们这个系统日常重点盯五类指标每类都设了对应的告警阈值接入网关资源CPU使用率超过85%、内存使用率超过90%、在线连接数超过预估上限的80%时告警。存储节点磁盘空间剩余低于15%、磁盘IO队列深度超过阈值、节点心跳丢失时告警。数据库性能慢查询数量每分钟超过20条、单表扫描量异常增大、主从复制延迟超过5秒时告警。消息队列积压消息数超过1万条、消费速率持续低于生产速率50%时告警。业务链路视频流建立会话失败率超过2%、API接口平均响应时间超过3秒时告警。告警阈值不能一成不变要根据系统运行的真实数据做动态调整。比如系统刚上线时我们把磁盘告警阈值设成20%运行一段时间后发现录像数据增长速度比较稳定就调整成了15%这样既不会因为过早告警打扰运维也不会发现得太晚导致磁盘写满。7.2 容量管理需要提前做规划分布式系统一个很常见的风险是“容量失控”——随着数据积累存储空间和计算资源会被逐渐蚕食如果不在早期做好规划后期可能要付出很大的运维成本来清理和扩容。我们的做法是每季度做一次容量趋势评估关注几个关键指标录像存储的增长速率根据当月新增录像量推算出剩余磁盘空间的可支撑天数低于180天时列入扩容计划。监控行业的录像文件默认是滚动覆盖的但如果存储集群整体空间不足会导致录像保留周期缩短无法满足合规要求。卡口数据的增长量和归档策略过车数据量很大如果不做冷热分离几年后数据库会非常臃肿。我们的策略是超过6个月的明细数据转入冷存储明细查询的热数据只保留半年。这个代价是历史在线查询的时间范围缩短了但对日常的基层治理工作来说半年内的数据热查已经完全够用。业务系统峰值资源评估不同业务系统的访问高峰期不同比如早晚高峰时段卡口查询频繁节假日景区周边流量大时信号灯系统的运算压力增大。根据峰值评估扩充计算资源避免平时资源浪费、高峰时资源不足。7.3 周期性健康检查清单每月做一次健康检查可以提前发现很多隐患避免演变成故障。我们的健康检查清单包括存储集群所有节点的磁盘SMART状态检查提前发现物理磁盘寿命风险。有一个存储节点我选择在它真正宕机之前就主动更换了磁盘因为SMART报了一个潜在不稳定的扇区这种主动替换远比故障后更换来得安全。关键服务的配置变更备份完整性。因为分布式系统节点多配置管理容易出现漂移每个节点的配置文件和版本都要核对一遍。数据库表和索引的膨胀检查索引碎片率高的表需要做在线重建否则查询会越来越慢。负载均衡策略的有效性验证模拟摘除一个节点确认流量能自动切换到其他节点。时钟同步检查如果各节点之间的系统时间偏差超过阈值会导致日志定位困难、时间戳错乱。我们用NTP协议做全集群时间同步偏差控制在毫秒级。这些检查项看起来琐碎但恰恰是把系统出事概率降到最低的务实做法。经历过几次半夜被电话叫醒处理故障之后我对周期性健康检查的态度就是四个字严格执行。最后分享一点个人体会。分布式系统这件事不是说技术上用了多少新名词、部署了多少台服务器就完事真正的考验在于日常的每个细节——网络规划合不合理、监控配置完不完善、运维团队对这些节点有没有足够的掌控力。犍为这个项目从设计到上线走下来我最大的感悟是好的架构不是靠一次性的灵光乍现而是靠持续的验证、调整和打磨。如果这篇文章能给正在做类似系统的你提供一些参考那就值得了。