先把业务域拆开，再决定技术怎么选
一套能长期运营的在线教育系统开发方案，至少得覆盖五块：内容生产、教学交互、训练评估、商业变现、学员生命周期。内容生产管录播课的上传、转码、加密和分发；教学交互管直播推流、连麦、白板和即时通讯；训练评估管题库、组卷、考试和评分；商业变现管订单、支付、优惠券和分销分润；学员生命周期则从注册、试听、购买一路延伸到完课和续费。五块之间通过API网关解耦，直播流量暴涨时可以单独扩容信令服务器和媒体节点，不必连带支付链路一起承受压力。这五块里，支付和分销最容易在项目中期被客户追加需求，因为教育场景的促销玩法比客户最初设想的要复杂得多——我们在柬埔寨和菲律宾的客户里，超过一半在开发中途改过分润规则。
技术选型上，后台用微服务架构配合Kubernetes做容器编排。MySQL承载订单和学员信息这类事务型数据，Elasticsearch负责课程检索，Redis处理分布式Session、积分排名和高并发抢购时的库存扣减。前端如果要覆盖iOS、Android和Web，React Native或Flutter可以一套代码多端复用。直播互动优先走WebRTC网关，再旁路转推到CDN做大规模观看分发，小班互动和大班直播共用一套底层。柬埔寨本地运营商线路质量参差不齐，Smart和Metfone的4G网络下WebRTC互动延迟通常能控制在几百毫秒量级，但跨到老挝或缅甸的本地网络时，丢包率会明显上升，延迟表现波动较大。我们在菲律宾和越南的项目里遇到过类似情况，最终都是在客户端做自适应码率切换和弱网重连逻辑，而不是指望运营商网络稳定。具体做法是在客户端埋点采集RTT和丢包率，超过阈值自动降档码率，同时把重连退避时间按网络类型区分——WiFi下用固定间隔重试，蜂窝网络下用指数退避，避免频繁重连把用户的流量和电量耗尽。
在金边这12年，团队28人，每年交付约100个项目，小项目几天就能上线，大项目通常控制在两个月左右。客户分布在柬埔寨、菲律宾、越南、老挝、泰国、印尼、马来西亚，不同国家的支付习惯和网络基建差异很大。菲律宾的GCash和越南的MoMo在用户端普及率很高，但商户侧对接文档和技术支持水平参差不齐；柬埔寨本地支付生态更分散，Wing和ABA Pay各占一块，很多客户手里拿到的通道资源质量差别很大。技术方案必须把这些本地因素考虑进去，而不是拿一套通用架构硬套。主攻的行业里，电商、娱乐、金融/交易、地产、物流这几类系统的底层模块和教育场景的重合度比一般人想象得高，尤其是订单、支付、分销、消息推送这几块，改造成本远低于从零开发。
录播、直播和班级进度怎么做才不踩坑
录播课表面上看是视频播放，背后要处理好几件事。视频切片转码用HLS或CMAF实现自适应码率，配合AES-128或DRM防止盗链下载。存储层用对象存储，设好生命周期策略，把低频访问的冷数据自动沉降到归档存储。播放端要做打点事件和心跳上报，才能准确记录学员学习时长，断点续播也得靠这些数据支撑。柬埔寨本地带宽成本比国内高不少，冷热分层策略在运营半年以上、课程量积累到几千节之后，对存储费用的控制效果会体现出来。【此处待填：具体的存储成本对比数据或客户实际节省比例】
直播模块最头疼的是状态同步和信令风暴。IM长连接用Protobuf序列化减小传输体积，信令服务器做哈希一致性路由，让同一间教室的学员落在同一台服务器上。白板多人同时涂鸦时用OT算法或CRDT解决冲突，避免互相覆盖。回放功能要把聊天弹幕和PPT翻页事件按时间轴对齐，学员拖进度条时能还原课堂任意时刻的状态。这套直播架构我们在娱乐和电商类项目里反复打磨过，教育场景的互动需求本质上和它们是相通的。一个容易忽略的细节是信令服务器的心跳间隔设置——柬埔寨部分地区的网络在晚高峰时段会出现间歇性断流，心跳间隔设得太短会把服务器打爆，设得太长又会导致断线检测滞后。我们的做法是按客户端网络类型动态调整，WiFi下心跳间隔【此处待填：具体数值】，蜂窝网络下放宽到【此处待填：具体数值】。
班级模型不用搞得过于复杂，三种模式基本够用：
- 固定班：学员统一入班，按固定课表解锁课程，适合考证辅导这类有明确时间节点的场景。
- 滚动班：随时可以插班，课程按学员个体时间轴解锁，适合兴趣类长期课。
- 自由组班：学员自主选课形成虚拟班，没有强约束进度，适合技能点播库。
学习进度用事件溯源架构，把完课、作业提交、测评通过存成不可变事件流，再投影出进度百分比和学分明细。后期规则变了，重放事件流就能重新计算历史进度，不用改老数据。事件溯源在东南亚客户的系统里落地时有一个实际问题：客户的技术团队往往不熟悉这种范式，后期维护会依赖我们。所以如果客户明确表示要自己接手运维，我们会退一步用传统的状态字段加流水表方案，牺牲一些灵活性换可维护性。
题库考试与证书：能自动化的尽量自动化
题库不是把题目堆进去就完事。每道题需要挂知识点ID、难度系数、区分度、题源年份和使用次数这些标签，题干和选项用JSON存储，支持富文本和LaTeX公式。组卷用遗传算法，以知识点覆盖率和难度分布曲线为目标函数。主观题接入NLP语义相似度评分，把明显异常的分数段筛出来给教师复核。这套组卷和自动评分逻辑我们在金融交易类系统的资格认证模块里跑过，题目量级在几万道规模下，组卷响应时间对用户端基本无感知。这里说的"无感知"是在题目预加载到缓存的前提下，冷启动第一次组卷还是会有一个可感知的等待，所以上线前要做预热。
在线考试防作弊是刚需。前端摄像头随机抓拍配合人脸比对，切屏行为触发记录和警告，超过阈值自动交卷。考试结束后成绩和证书自动绑定，证书用模板引擎动态渲染SVG再转成防伪PDF，区块链存证哈希值，扫码就能校验真伪。这套证书链路在东南亚客户里接受度不错，尤其是需要向雇主或机构证明学习成果的场景。菲律宾和印尼的客户对证书防伪验证的需求更强烈，因为当地伪造培训证明的情况比较普遍。有一个实操细节：柬埔寨本地的手机摄像头像素差异很大，低端机抓拍出来的人脸比对通过率偏低，所以阈值不能设得太死，否则正常学员会被误判。
支付、分销和会员：先把异常场景想清楚
支付链路用订单状态机管理待支付、支付中、已支付、全额退款、部分退款这些状态流转。对接多家支付渠道时，适配器模式可以屏蔽不同网关之间的差异，统一对账文件下载和差异预警。秒杀课程场景下，用Redis Lua脚本原子化扣减预置库存，抢到名额才允许进入下单环节，避免超卖和数据库行锁瓶颈。
支付异常处理策略：
| 异常场景 | 处理机制 |
|---|---|
| 支付回调丢失 | 定时轮询渠道查询接口，每5分钟主动同步一次支付状态 |
| 渠道流水与本地金额不一致 | 差异挂载至差错处理表，人工调账或自动冲正 |
| 支付成功但库存扣减失败 | 插入延迟队列，异步重试扣减，终局失败则自动退款 |
分销体系基于多层树形关系计算分润，每层配置差异化佣金比例，订单完成后触发结算，生成不可篡改的分润账单。优惠券用模板模式定义满减、折扣、兑换券等类型，限制叠加规则和适用课程范围。会员权益中台化，把专享价、免费课程、双倍积分统一为权益码，由权益服务鉴权发放。分销和会员这两块我们在电商类系统里做了很多年，部分成品系统有几十家客户在运营使用，教育场景的分润逻辑可以大量复用。电商类系统有成品，开箱即用，交付快，如果教育项目里订单、支付、分销这些模块和成品重合度高，基于成品改造能明显缩短交付周期。
支付通道本身由客户提供资源，我们负责对接，不提供支付通道。这一点在项目启动前就要明确。柬埔寨本地支付生态分散，不同客户手里的通道资源差别很大，对接前必须把渠道文档和测试环境确认清楚。菲律宾客户拿到的GCash商户资质和越南客户拿到的MoMo商户资质在接口版本上可能有差异，提前确认能省掉后期大量返工。判断通道质量有几个实操标准：沙箱环境是否完整、回调是否有签名校验、对账文件是否支持按天拉取、退款接口是同步返回结果还是异步通知。这四点里任何一点缺失，后期对账和客诉处理都会很麻烦。
开发周期、运维和合作方式
一个功能完备的在线教育系统开发项目，MVP版本（核心课程播放与支付）通常需要6到8周，完整版本（加入题库、直播互动与分销）再增加12到14周，高可用压测与安全渗透3到4周，上线后预留4周灰度发布和功能微调。团队最小配置需要产品经理、架构师、前端、后端、测试和运维。我们团队28人，同时并行多个项目是常态，单个教育项目的资源投入根据功能清单动态调配。
运维上全链路压测和熔断降级是必做的。直播高峰流量靠CPU使用率和连接数双重指标触发自动扩缩容，数据库读写分离，核心库每日增量备份并定期做灾备恢复演练。日志用ELK统一收集，设置明确报警阈值，比如支付转化率骤降、直播流卡顿率超出5%等。TG上我们做到分钟级响应，配合AI运维做第一轮告警筛查，人工再跟进处理。AI运维主要负责把告警按业务影响分级，支付链路和直播链路的告警优先级最高，日志类的延迟告警可以压后处理，避免半夜被低优先级告警吵醒然后发现是无关紧要的慢查询。
在金边做软件开发12年，服务语言是中文，系统bug修复免费，新增功能按工作量收费。报价面谈或Telegram详谈，按功能清单逐项评估，付款方式是先付30%，验收后结清尾款。这个付款节奏在东南亚客户里执行起来基本顺畅，偶有客户在验收阶段反复追加小需求导致尾款拖延，所以功能清单的边界在合同里要写得足够细，口头承诺的"顺手加一下"最后都会变成工作量。