外币兑换1. 项目背景与需求拆解：一所学校为何要全面上云
在线课堂和智慧校园这两个词，过去几年在教育行业已经被说烂了，但真正落到架构层面去推动整体升级的学校，其实并不多。大部分学校的现状是：在线课堂是临时采购的一套视频平台，智慧校园是若干年前建设的一卡通、门禁、OA、教务管理系统，彼此独立、互不相通。所以当学校提出“从在线课堂到智慧校园的整体架构升级”时，我们要解决的其实不是某一个系统的替换，而是一整套从基础设施到业务平台再到终端接入的体系重构。
上云这件事，很多学校的信息中心老师第一反应是“把服务器搬到云上”，但这只是最表层的理解。真正的上云，核心在于架构治理：哪些系统可以容器化、哪些系统必须保留物理机、哪些数据要留在本地、哪些能力可以走公有云弹性资源，这些问题是会上云和不会上云的分水岭。从在线课堂到智慧校园，业务跨度大、用户群体复杂（学生、教师、行政人员、家长），设备种类更是五花八门（教室大屏、门禁闸机、录播主机、学生终端），这套组合对架构提出的要求远比普通企业信息化要高。
以我们团队实际推进的这个项目为例，学校背景是华东地区一个多校区办学的高校，校本部加两个分校区，师生总数接近两万人。原有系统大概有四十多个，其中超过一半是各院系和职能部门自己采购的独立系统，数据孤岛严重，账号体系也各不相同。在线课堂系统是疫情后紧急上线的，用的是公有云SaaS产品，虽然解决了当时“能上课”的问题，但根本无法和学校自己的教务系统、学工系统对接，成绩数据、考勤数据、选课数据全是断的。
这次全面上云，目标很明确：第一，把在线课堂的底层能力掌握在自己手里，做到高峰期可弹性扩展；第二，用一张跨校区的专网把所有智慧教室、录播设备、门禁终端统一接入，基于VXLAN技术实现大二层打通；第三，把分散的业务系统通过数据中台和统一身份认证串起来，形成真正的智慧校园底座。这三个目标分别对应了计算资源层、网络接入层、数据业务层，正好构成一个完整的上云架构升级路径。
如果你所在的学校或教育信息化企业也正处于类似阶段，这篇文章里我讲的架构决策、设备选型思路、配置参数和踩过的坑，大概率都能直接用上。我尽量把每一个关键节点为什么这么做、换一种方案会有什么问题讲清楚，而不是泛泛去谈概念。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 整体架构设计：混合云底座与分层解耦的决策过程
2.1 为什么不能全部推到公有云
最开始讨论方案时，有一派意见非常明确：既然叫“上云实践”，那就把所有系统全部搬到公有云，数据中心机房直接退租，既省电费又省运维人力。这个想法听起来很美，但实际一算账就站不住脚。
首先是数据合规和数据主权问题。高校的师生信息、成绩数据、科研数据，很多都有明确的属地化管理要求，全部放在公有云上，一旦出现合规审查，学校很难自证清白。其次是成本结构问题。智慧校园的物联网设备——门禁控制器、教室中控、能耗采集器——产生的数据是持续不断的小包高频流量，这类流量如果全部经过公网传输到公有云再返回控制指令，时延上看不到问题，但带宽成本和消息队列的吞吐压力会非常高。更别说教室里的录播主机、视频会议终端，需要的是低延迟、高带宽的内网通道，公网路径在晚自习高峰时段根本无法保证质量。
所以最终我们采用了混合云架构：核心业务系统、师生数据、物联网控制链路放在学校私有云（超融合平台）上，在线课堂的WebRTC流媒体服务、突发性的大规模直播转码、大数据分析这类弹性需求明显的计算任务放在公有云上，私有云和公有云之间通过专线打通，同时保留一条加密的备份通道。这个决策的核心理念是“按需分配”：稳定且敏感的业务留在本地，突发且计算密集的业务借力云端。
2.2 分层架构：从微服务到容器化的逐步演进
上云不是把原来的单体应用原封不动搬进虚拟机就完事了，那叫“迁移”，不叫“架构升级”。真正要做的，是借着这次机会把系统切分到合理的粒度。
我们确定了“五层架构”模型：接入层、应用层、服务层、数据层、基础设施层。接入层负责统一入口和认证，所有业务系统（除了必须独立部署的工业级设备网管）都通过统一API网关对外提供服务；应用层是各类业务应用，按照领域拆分成微服务，比如教学管理域、学生工作域、后勤保障域、办公协同域；服务层沉淀公共能力，包括统一身份认证（OAuth2 + CAS）、消息推送、文件存储、流程引擎、数据同步组件；数据层做了逻辑分库，核心业务库和数据分析库隔离，分析库通过CDC（变更数据捕获）实时同步业务数据；基础设施层就是混合云底座。
这里有一个关键选择值得展开说：微服务拆分到什么粒度。很多团队容易走极端，要么拆得太碎（一个登录功能拆三个服务），要么干脆不拆（还是单体，只是加了个注册中心）。我们的原则很简单——按业务变更频率和团队边界拆。比如教学管理域和后勤报修域，变更节奏完全不同，肯定拆开；而用户服务和认证服务虽然理论上可以拆，但实际操作中耦合度太高，强行拆只会增加一次调用开销和分布式事务的复杂度。最终我们拆出了36个微服务，这个数量对于两万人的学校规模来说不算多，但每个服务都能独立部署、独立扩缩容，已经达到了上云的核心目的。
容器化方面，我们统一用Kubernetes管理私有云上的应用运行环境，开发环境、测试环境、生产环境完全一致，配置用GitOps方式管理，环境差异只体现在values文件里。这个决策在后期割接中帮了大忙，因为大批系统分批切换时，环境一致性直接决定了排错成本。
2.3 高可用设计：校园业务一样不能接受长时间宕机
教育行业有个特点，平时看起来IT系统可有可无，但一到选课、考试报名、成绩发布这些节点，系统压力是突然暴增的，而且是不可预测的。选课系统过去每年崩一次，已经成了学生吐槽的固定节目。
这次架构升级，我们对高可用做了三层设计。第一层是基础设施冗余：私有云的存储和计算节点全部采用多副本，关键数据库用主从加半同步复制，RPO（恢复点目标）控制在5分钟以内。第二层是应用层面：所有微服务至少双实例部署，并配置了优雅停机、健康检查和自动重启。第三层是流量治理：在API网关上配置了限流和熔断，选课高峰期针对不同接口设置不同的令牌桶速率，防止某个异常调用拖垮整个网关。
这个部分我要特别强调一个容易被忽略的点——高可用不只是技术问题，更是预案问题。我们专门做了两次“选课高峰模拟演练”，第一次演练直接暴露出了数据库连接池参数配置不合理的问题，连接池默认最大值只有50，而选课接口并发峰值预估会达到300以上。如果没有演练，真到选课那天，即便底层再稳定，应用层也会被连接池拒绝服务打垮。上云之后看似弹性资源无限，但应用自己得有能力把流量接住，这个能力必须提前通过压测验证。
3. 在线课堂核心链路改造：从直播卡顿到稳定承载万人并发
3.1 在线课堂的技术底座选择与改造方向
原来的在线课堂用的是公有云SaaS，老师发起直播、学生进入直播间、录制回放，这些功能都有，但问题也明显：一是无法和学校教务系统的课表打通，每节课都要手动创建直播间，效率极低；二是高峰期质量不稳定，一个直播间超过200人就明显卡顿，原因在于SaaS厂商对套餐有限流；三是数据都在别人手里，课堂互动数据、出勤数据无法回流到学校的数据库做分析。
我们这次改造的关键点，是把在线课堂从“外部SaaS”变成“自建平台 + 云端弹性资源”的模式。核心是自研了基于WebRTC的互动课堂服务，部署在学校私有云上，承担日常的普通班课（单人授课、几十人互动）；当遇到公开课、大型讲座这类高并发场景时，自动把转码和分发任务弹性扩展到公有云的媒体服务集群上。简单说，就是日常流量自己扛，突发流量借云端。
为什么选WebRTC而不选传统的RTMP加HLS方案？因为在线课堂的核心场景是双向互动，老师要看到学生画面、学生要举手发言，RTMP协议在推流端很成熟，但延迟高（起重叠3到5秒），不适合互动教学；HLS延迟更大，基本只能做单向直播。WebRTC基于UDP，通过SRTP加密传输，在优质网络下端到端延迟可以控制在200毫秒以内，这才是“课堂”而不是“电视直播”该有的体验。
3.2 媒体链路设计：SFU架构与混合云调度
在流媒体架构选型上，我们对比了MCU和SFU两种方案。MCU会在服务器端做多路画面的合成，所有参与者只看到合成后的一路画面，服务器压力大但客户端压力小，适合人数极少的精品课；SFU则是在服务器端做转发，每一路流独立传输，客户端自行合成画面，扩展性好、服务器资源消耗相对可控，更适合大班课和公开课。我们最终选择了SFU架构，并且对视频编码做了SVC（可伸缩视频编码）分层，弱网用户自动订阅低分辨率层，网络好的用户订阅高清层，这样在跨校区网络环境不统一的情况下，能尽量保证每个端到端的体验。
混合云调度是另外一个难点。WebRTC服务如果全部放在公有云上，学生接入公网没问题，但教室里那些智慧大屏和录播主机很多只有内网IP，走公网绕一圈延迟不可控。所以我们做了两级媒体节点：校内媒体节点负责内网终端接入，云端媒体节点负责外网学生接入，两个节点之间通过专线做级联转发。调度逻辑不算复杂——客户端先请求一个信令服务，信令服务根据IP段和网络延迟动态返回最优的媒体节点地址，内网IP直接分配到校内节点，公网IP分配到云端节点或公网专线接入点。
这里要提醒一点，混合云调度最怕的就是“网络路径来回绕”。我们初期测试时就发现了一个问题：某个教室内的学生终端分配的居然是云端节点，原因在于那个教室的网络出口做了NAT，信令服务识别到的是公网IP。最后通过给校园网出口加了一个网段标记头字段，信令服务优先匹配这个标记，才彻底解决。如果你也要做类似的混合调度，务必在信令协议里设计网络标识字段，别完全依赖IP识别。
3.3 微服务化的在线课堂：不只是视频流
在线课堂不只是视频流，它还包含课堂管理、互动答题、白板、聊天、录制等一系列功能。我们把这些能力拆成了独立的微服务，视频信令服务只负责建连和媒体节点分配，业务逻辑全部交给对应的领域服务。这种拆分带来的直接好处是，选课高峰和直播高峰是不同的流量模型，各自可以独立扩缩容，不会互相干扰。
对扩容策略，我们采用了Kubernetes的HPA（Horizontal Pod Autoscaler）配合自定义指标。默认的HPA指标是CPU和内存，但对于WebRTC信令这类IO密集型服务，CPU往往不是瓶颈，并发连接数和消息队列堆积量才是。我们在服务里暴露了Prometheus指标，包括当前信令连接数、入会请求排队耗时、消息队列积压数，然后让HPA基于这些业务指标扩缩容。实测下来，一个大班课500人并发入场时，信令服务能在2分钟内从3个Pod扩容到10个Pod，入场高峰期单Pod连接数稳定控制在2000以内。
录制功能的实现上，我们没有走传统的“服务器端直接录屏”路线，因为转码资源的消耗太大。我们的方案是每个参与者的上行流都会在SFU侧做一份旁路拷贝，旁路流直接以原始编码格式写入分布式对象存储，等直播结束后再异步触发转码任务，把各路的原始流合成一个标准MP4文件。这个设计把最耗算力的转码操作挪到了云端空闲时段，用低成本的计算资源池去跑，录制成本降低了大概七成。如果你们也有录制需求，强烈建议别在直播过程中实时转码，那是对资源最大的浪费。
4. 跨校区智慧教室专网：VXLAN网络架构与设备部署实践
4.1 为什么不用VLAN而要上VXLAN
跨校区的智慧教室专网是整个项目里最硬核的部分，也是热度最高的话题点。三个校区之间要部署几百间智慧教室，每间教室里至少有智慧大屏、录播主机、IP广播、环境控制终端四类设备，加一起超过两千个IP终端需要统一接入管理。
如果是在单校区，传统VLAN方案就够用了。但跨校区场景下，传统VLAN有两个致命问题：VLAN ID上限是4094，看似够用，实际上划分到每个校区、每个楼层、每个业务类型后很快就捉襟见肘；更致命的是，VLAN的二层广播域无法跨越三层网络。校区之间的骨干链路是三层路由，而智慧教室的终端设备之间需要二层互通——最典型的就是录播主机需要通过二层组播发现摄像头，某些老旧的教学终端甚至依赖固定IP和二层广播做设备发现，跨三层就用不了。
VXLAN（Virtual Extensible Network）作为主流的Overlay网络技术，正好解决这个问题。简单来说，VXLAN把二层以太网帧封装进UDP报文里（UDP目的端口4789），通过网络IP网络传输，在三层物理网络上构建出虚拟二层网络。VXLAN的VNI（VXLAN Network Identifier）有24位，可以划分1600万个隔离网络，以后不管加多少个业务域都足够用。更重要的是，终端设备感知不到VXLAN的存在，它们看到的仍然是传统的二层网络，所有广播、组播、未知单播都由VXLAN网关和头端复制机制处理。
4.2 整体网络拓扑与设备选型
我们最终确定的网络架构是Spine-Leaf（脊叶）结构，这也是VXLAN场景下的标准拓扑。两个核心数据中心各部署一对Spine交换机，三个校区分别部署Leaf交换机，所有Leaf（包括跨校区的）都与Spine建立BGP EVPN邻居关系，Underlay使用OSPF或者静态路由保证物理连通性，Overlay通过BGP EVPN动态同步MAC地址和VNI路由信息。
设备选型上，这里给出我们实际使用的配置参考，不写具体品牌，只说明规格要求：
- Spine交换机：建议选择支持64K以上VNI、支持BGP EVPN的框式或高规格盒式设备，双向转发能力不能低于4.8Tbps，包转发率不低于2000Mpps。跨校区骨干带宽建议至少双10G链路，最好预留40G升级空间。
- Leaf交换机：支持VXLAN的盒式交换机即可，要求支持BGP EVPN、IPv4/IPv6 VXLAN网关功能，端口数以满足教室接入为准。我们一间教室预留了4个接入端口，所以Leaf普遍选用48口千兆+4万兆上行的型号。
- 接入侧：教室内的智慧大屏、录播主机直接接入面板交换机或墙面AP的以太网口，不需要每个教室放一台接入交换机，用瘦AP加有线混合模式控制成本。
组播方面，因为BGP EVPN支持头端复制（Head-end Replication），我们在Spine上关闭了PIM组播，直接采用头端复制模式处理广播和组播流量。这样做的好处是不需要维护复杂的组播路由协议，坏处是广播流量大的场景下Spine压力会明显增加。实测下来，一间教室四类终端产生的广播流量非常有限，头端复制完全扛得住，但如果你的智慧教室里有大量基于组播的录播协议，建议提前压测再决定是否启用PIM。
4.3 VXLAN配置的关键参数与细节
VXLAN的配置细节决定了整个专网的质量，我把几个关键参数单独拎出来讲，这些都是踩过坑之后总结出来的。
**第一，MTU调整必须提前做。**VXLAN封装会在原始以太网帧上增加50字节左右的额外开销（外层UDP头8字节、外层IP头20字节、外层MAC头14字节、VXLAN头8字节）。如果物理链路的MTU还是默认的1500，那么传输1500字节的原始帧就会导致分片，分片带来的问题是延迟增加和乱序丢包。我们的做法是：Underlay物理链路和核心链路全部调整MTU为1600，终端接入端口保持1500不动，终端发出的1500字节帧到Leaf后由Leaf完成VXLAN封装和正确处理，不让分片发生。这个设置前期必须全网统一核查，不然丢包问题会在出问题时特别隐蔽，表现为“偶尔卡顿、延迟抖动、视频花屏”。
**第二，BGP EVPN的RT/RD规划。**BGP EVPN通过VNI与VRF（虚拟路由转发实例）的映射来实现租户隔离，每个业务域分配独立的VNI和VRF。我们的规划是：智慧教学网VNI 10001、安防监控网VNI 10002、设备管理网VNI 10003、办公访客网VNI 10004，每个VNI对应独立的Route Target，防止跨域路由泄漏。RD（Route Distinguisher）的规划也要按照“校区号:业务号”的格式统一，比如10:10001代表校本部智慧教学网，20:10001代表分校区A的智慧教学网，这样在做排障时只要看RD就能知道路由源点。
**第三，网关部署模式决定了南北向流量的路径。**VXLAN网关分为二层网关和三层网关。我们的方案是在每个校区Leaf上同时部署二层网关和分布式三层网关，终端跨VXLAN互访时，流量在Leaf本地完成三层终结，不需要绕行核心数据中心。这个设计对跨校区访问延迟的优化非常明显，比如校本部到分校区A访问教务系统，路径是终端到Leaf到Spine到远端Leaf再到服务器，全程走的是骨干专线的极短路径。如果网关集中部署在核心，所有跨校区流量都要先回到核心再转发出去，延迟会增加毫秒级，但更重要的是Spine压力成倍增加。
4.4 校区互联链路与服务质量管理
跨校区骨干选择的链路是点到点专线，三家运营商分别提供一条，做了链路聚合与故障自动切换。这里有一个容易踩的坑，就是专线质量的波动。教育行业晚自习时间是流量高峰期，跨校区录播传输会大量占用带宽，而运营商专线的突发拥塞可能持续十几秒，直接表现为视频卡顿。
解决思路是给关键流量打上DSCP（差分服务代码点）标记，在网络设备上配置QoS队列。我们把实时音视频流的DSCP值设为EF（加速转发），录播文件传输设为AF41，普通数据流量设为BE。Spine和Leaf的出接口分别配置严格优先队列和加权公平队列，保证视频流量即使在链路拥塞时也能获得优先转发。实测在晚自习高峰叠加校区间视频会议的场景下，视频流端到端延迟稳定在80ms以内，丢包率控制在0.1%以下，这是一个可以接受的教学体验水平。
对网络质量要求更高的场景，还可以考虑Overlay QoS映射，把应用层的优先级传递到Underlay的DSCP字段。不过这一步涉及跨设备字段映射，我们在实施中因为运营商专线设备不支持自定义规则而自动降级处理，这属于资源限制下的妥协方案，如果你的专线设备可控，建议做完整映射。
5. 智慧校园数据与统一平台：从烟囱系统到数据中台
5.1 数据孤岛是智慧校园最大的敌人
网络层打通后，上层业务系统依然是一盘散沙。原本四十多个独立系统各有各的数据库，有些是Oracle，有些是MySQL，甚至还有几个是SQL Server；账号体系也是各搞各的，学生在一个系统里改密码不会同步到另一个系统。数据孤岛带来的直接后果是“一卡通”系统没法做到与教务系统实时联动，教室门禁、宿舍门禁、图书馆系统的数据延迟高达一天。
这一轮的智慧校园平台建设，核心是建立三个底座：统一身份认证底座、数据中台底座、消息与集成总线底座。统一身份认证解决“你是谁”的问题，数据中台解决“你的数据在哪”的问题，消息与集成总线解决“系统之间如何通信”的问题。三个底座搭好之后，新系统上线不需要再讨论账号怎么办、数据从哪来，直接接入底座就行，这是一种明显的“架构红利”。
5.2 统一身份认证与OAuth2/CAS混合模式
统一身份认证方案选择的复杂度比想象中高。学校环境里既有传统的Web业务系统（比如OA、教务），又有移动端App（今日校园类应用），还有第三方平台（比如图书馆数据库商提供的校外访问系统）。这些系统的认证协议各不相同，有的是CAS，有的只支持LDAP对接，有的支持SAML/MD。
我们最终采用了一个开放平台思路：自建统一认证中心，同时支持OAuth2.0、CAS、LDAP和SAML四种协议。用户在主身份源（人事系统或学工系统）完成认证后，认证中心签发一次票据，各业务系统根据票据换取本系统的会话。对老系统改造的原则是：能对接协议的尽量对接协议，不具备改造条件的（比如老旧的设备网管系统），通过LDAP代理方式做只读认证，不把密码托管到第三方。
这个方案实施中最容易出问题的地方是会话同步和登出逻辑。OAuth2的access token有有效期，CAS的ticket是一次性票据，混合模式下用户在一处登出后，其他系统的会话未必能同步失效。我们在认证中心做了全局会话管理，统一维护用户的SSO会话状态，并向前端各业务系统定期推送会话状态变更事件。建议你们在规划时就把“单点登出”作为验收指标写进需求文档里，不然后期填坑的难度远超预期。
5.3 数据中台的“攒数据”三步法
数据中台的建设不容易大而全地铺开，我们采用的是“三步走”策略。
第一步，盘点主数据。把人员、组织、教室资源、课程、设备资产这五类主数据定义清楚，确定唯一的可信数据源。比如人员的可信源是人事系统，教室资源的可信源是教务排课系统，设备资产的可信源是资产管理系统。这一步的价值在于明确了数据的源头，后续做数据同步时不用争论哪个系统说了算。
第二步，建设CDC数据同步通道。我们在源数据库上配置了Debezium这类CDC工具，把业务库的binlog变化实时捕获到Kafka消息队列，再由数据同步服务消费并写入数据中台的分析库。业务高峰时，这种实时同步链路的积压监控非常重要，一定要给Kafka消费者的Lag指标设置告警。有一次我们发现某条同步链路Lag超过30分钟，排查原因是源库在大批量导入历史数据时binlog文件格式变化，导致解析器临时抛异常，这类问题在CDC方案中经常会遇到，多盯监控、做好重试机制就对了。
第三步，提供统一数据服务API。数据中台不只是存储，更重要是对上层应用提供标准化的数据访问接口。我们在中台上封装了“学生综合信息查询”“教师工作量统计”“教室使用率分析”等二十多个API，业务系统不再需要直连数据库查询，统一走API网关调用。这个模式的好处是，一旦源系统切换或者数据结构调整，只要中台侧保证接口兼容，下游业务系统完全不受影响。
6. 部署实施与问题排查：分阶段割接路上的真实教训
6.1 分批割接策略：不能一把梭
智慧校园项目的实施难度在于，涉及在线教学、门禁考勤、设备控制等核心业务，一旦失败直接影响学校的日常运转。我们采取了分四批割接的策略，原则是“先难后易，先外后内，预留充足回退窗口”。
第一批割接是新建系统，包括统一身份认证、API网关、数据中台的搭建，不涉及存量系统切换，风险最低。第二批割接是基础设施网络VXLAN专网的搭建，把跨校区的智慧教室设备逐步迁移到新专网，此时老网络还保留着，可以随时切换回退。第三批割接是核心业务系统迁移，先把教务、学工这些对稳定性要求高的系统切换到新平台。第四批才是在线课堂和智慧校园应用的全面上线。
每批割接都选了寒暑假或小长假进行，并且制定了详细的回退预案。比如VXLAN专网割接时，我们的回退方案是保留防火墙上的静态路由并重新启用VLAN接口，一旦VXLAN隧道出现大规模异常，15分钟内可以把流量切回老网络。
6.2 割接过程中的几个典型故障
割接过程中遇到的技术问题很多，挑几个典型的分享。
**第一个是VXLAN的ARP广播风暴问题。**跨校区VXLAN打通之后，我们发现部分楼层网络在高峰时段出现MAC表项震荡，持续了一段时间后个别Leaf设备CPU占用飙高。排查思路：先查Underlay的组播和广播报文量，确认头端复制模式下Spine转发的广播报文量确实异常增大；再查到底是哪个终端在频繁发送ARP请求，用抓包工具发现是某一批老旧录播主机在启动时发送了每秒上百次的ARP探测，而这个探测在VXLAN网络中会被头端复制模式放大传输到所有关联Leaf。最终解决方法是，在Leaf接入端口上开启DHCP Snooping和动态ARP检测，对异常ARP报文直接丢弃。这类问题在传统VLAN网络里通常不会形成系统性影响，但在VXLAN环境下因为二层广播域跨越了多个校区，必须用该方式收口。
**第二个是云上在线课堂服务与校内用户之间的跨网质量差。**公有云节点在国内某地，而学校在另一个区域，学生接入时有部分走的是公网路径，高峰期跨网延迟能达到200ms以上。排查后发现是WebRTC信令流程正常，但媒体流的网络路径选了最差的一条。我们的解决方法是接入多个公有云地域的媒体节点，并在信令服务中增加基于延迟探测的节点选择逻辑，在建立媒体连接前对候选节点做一次主动探测，选延迟最低的节点。效果显著，客户端报告的卡顿率下降了六成。
**第三个是数据库主从切换引发的重复数据。**在割接数据同步服务时，我们有一个订单类业务的同步脚本在数据库主从发生切换后，出现了部分数据重复写入的目标库。原因是CDC工具在读取binlog时，由于主从切换导致一部分事务被读取了两次，而同步逻辑没有做幂等。这类问题属于“基础设施高可用带来的新问题”，因为上云之后我们设置了更完善的数据库主从切换策略，切换本身是好事，但同步应用没有为此做准备。最后的修复方式是在同步写入链路中加了一步基于主键去重的逻辑，同时给同步任务增加了自动重启和断点续传的能力。
6.3 巡检与长效运维机制
网络和平台全部上线后，长效运维又是一个新的课题。我们搭建了基于Prometheus和Grafana的监控告警体系，覆盖三层：基础设施层监控（服务器CPU、内存、磁盘、网络带宽）、平台与中间件层（K8s状态、Kafka消费Lag、数据库慢查询）、业务应用层（在线课堂的并发数、平均延迟、会话成功率、门禁设备在线率）。
给运维同事的建议是，告警阈值不能拍脑袋定。比如在线课堂的会话成功率，初期我们设成低于90%告警，结果发现日常就是在88%到92%之间波动，告警频率太高，逐渐就成了背景噪音。后来花了两个星期收集基线数据，把告警阈值调整为“低于85%或连续5分钟低于90%”才达到合理的告警灵敏度和可用性。教育类应用有明显的峰谷特征：白天上课都是高峰，晚间只有夜自修和在线答疑，周末和寒暑假基本空闲。不同时段的基线和告警阈值必须分开设置，否则运维同学很快会被无关告警淹没。
最后再分享一个非常实用的小技巧，跨校区的网络设备巡检，强烈建议开通自动化配置备份和配置对比功能。学校团队的人力有限，不能指望每个校区都有专职网络工程师。我们给所有Switch配置了每天凌晨自动备份配置的功能，并设置MD5比对，只要配置有变化就推送到运维群。有一次分校区新来的驻场工程师在调设备时误删了一个VXLAN的VNI配置，系统配置变化告警发出来的同时，运维平台上的上一版配置已经在等待他确认回滚了。这类自动化兜底机制，对一个队伍精简的学校信息中心来说，价值不亚于任何一套昂贵的网管软件。
这个项目从启动到全量上线，整整用了一年时间，期间通宵割接的次数马上两位数了。但回头看整个上云架构升级的路，最庆幸的就是一开始没有盲目追求“全部公有云”或“纯微服务”，而是踏踏实实地从业务痛点出发做架构取舍。现在学校各个系统的数据开始真正流动起来了，在线课堂和教室设备也不再是两张皮。这个项目里学到的经验和踩过的坑，希望能给正在考虑类似升级的同行们提供一些参考。