企业官网建设流程全解析

前几个月交付了犍为县交通监控中心的分布式系统改造项目，最近系统正式通过验收、全面投用。趁着还有点热乎劲，把这次项目的完整思路、技术选型、部署过程和踩过的坑整理出来，给正在做类似监控中心改造、或者打算从传统单机架构往分布式方向迁移的同行们一个参考。

先说下项目背景，犍为县原有的交通监控中心一直是传统的单机集中式部署——一台中心服务器承载了前端所有摄像头的视频接入、存储、转发，卡口数据、违法数据、信号灯状态等业务系统也都跑在同一台物理设备上。过去车辆保有量没这么大、路网没那么密的时候问题不大，但近几年前端点位逐年增加，新增了不少违停抓拍、电子警察和流量检测设备，中心服务器的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 存储层的分布式文件系统选型与调优

录像存储是整个系统里对可靠性要求最高的部分。我最初考虑的方案是直接用开源分布式文件系统，但测试下来发现，视频写入的特点是持续大带宽顺序写，而开源系统普遍针对通用文件场景优化，对视频流这种持续高吞吐写入的适配一般。最后我们决定采用商业监控厂商的云存储方案——这类方案本质上也是分布式架构，但针对视频存储场景做了专门优化，比如数据切片策略、故障域隔离机制、录像索引的分布管理等。

具体部署时，存储节点采用了纠删码而不是传统的多副本模式。举个例子：如果是三副本，三台存储节点存同样的数据，三倍的存储成本换来安全冗余。如果是纠删码，比如4+1模式，数据和校验信息分布到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 部署步骤与关键配置参数

整个部署过程按以下步骤推进，每一步都有明确的验收标准：

1. 基础设施准备：机房机柜、供电、制冷确认，服务器上架，操作系统安装（统一采用同一版本，避免内核行为差异）。
2. 基础组件部署：部署分布式协调组件、消息队列、负载均衡组件，验证各组件之间通信正常。
3. 存储集群初始化：配置分布式存储集群，初始化纠删码策略，用压测工具验证写入性能达到预期（我这里的验收标准是持续并发写入不低于每节点350MB/s）。
4. 接入集群配置：部署SIP服务和接入网关，配置负载均衡策略，逐个把前端摄像头从原平台迁移到新接入域下。
5. 业务系统迁移：卡口、违法、信号灯等业务数据做全量导出，按新库表结构导入，业务应用切换到新环境。
6. 联调与试运行：各系统之间做联动测试，包括视频预览、录像回放、卡口查询、违法取证全流程走通，试运行两周观察稳定性。

这里挑几个关键参数和数据量级展开。卡口数据的迁移验证结果是：两个月的过车记录共约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 常见问题速查表

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协议做全集群时间同步，偏差控制在毫秒级。

这些检查项看起来琐碎，但恰恰是把系统出事概率降到最低的务实做法。经历过几次半夜被电话叫醒处理故障之后，我对周期性健康检查的态度就是四个字：严格执行。

最后分享一点个人体会。分布式系统这件事，不是说技术上用了多少新名词、部署了多少台服务器就完事，真正的考验在于日常的每个细节——网络规划合不合理、监控配置完不完善、运维团队对这些节点有没有足够的掌控力。犍为这个项目从设计到上线走下来，我最大的感悟是：好的架构不是靠一次性的灵光乍现，而是靠持续的验证、调整和打磨。如果这篇文章能给正在做类似系统的你提供一些参考，那就值得了。