想象你开了一家餐厅。餐厅正式营业之前你需要做很多准备工作。厨师要练习新菜品可能会做失败可能会浪费食材可能会把厨房搞得一团糟。服务员要演练点餐流程可能会搞错桌号可能会上错菜可能会忘记结账。收银系统要测试可能会多收钱可能会少收钱可能会崩溃。这些练习和测试你敢在正式营业的餐厅里做吗不敢。因为那里有真实的顾客花的是真实的钱吃的是真实的食物。一旦出错顾客投诉钱款纠纷声誉受损。所以你需要一个练习厨房一个内部演练场和一个正式营业厅。三个地方做的是同一件事但服务的对象不同容错程度不同要求不同。游戏里的货币购买系统也是同样的道理。一、先说清楚货币购买系统有多复杂很多人觉得游戏里买东西不就是点一下按钮扣钱给道具吗能有多复杂非常复杂。一次完整的购买流程背后发生的事情远比你看到的多。玩家点击购买按钮。客户端发送购买请求到游戏服务器。游戏服务器验证玩家身份确认玩家在线确认请求合法。游戏服务器查询玩家当前货币余额。游戏服务器检查商品是否还有库存是否在售卖时间内是否有购买数量限制。游戏服务器调用支付系统扣除玩家货币。支付系统记录这笔交易写入数据库。游戏服务器给玩家发放道具写入玩家背包数据库。游戏服务器返回购买成功的消息。客户端收到消息更新界面显示新道具更新货币余额显示。这十个步骤每一步都可能出错。网络超时数据库写入失败并发冲突余额计算错误道具发放失败……任何一步出错都可能导致玩家钱扣了道具没收到。玩家没扣钱道具却收到了。玩家被重复扣款。玩家账户数据损坏。这些问题在正式环境里出现会引发玩家投诉、退款纠纷、甚至法律问题。所以在正式上线之前必须在安全的地方把每一种可能的错误都测试一遍。这个安全的地方就是测试环境。二、三套环境各司其职游戏的货币购买系统通常需要三套环境开发环境Development测试环境Testing / Staging正式环境Production三套环境就像同一家餐厅的三扇门。进哪扇门决定了你在哪个世界里。三、开发环境厨师的练习厨房开发环境是程序员写代码、调试代码的地方。这里一切都是混乱的一切都是临时的一切都是可以随时推倒重来的。程序员在这里写新功能写到一半发现思路不对全部删掉重写。测试一个想法发现行不通换另一个方向。故意制造各种错误看看系统会怎么反应。把数据库清空重新填入测试数据。把服务器重启一百次看看重启后系统状态是否正确。开发环境的货币系统是完全虚假的。货币不是真实货币是程序员随手填入的假数据。想要多少钱直接改数据库给自己填一个亿。购买记录不重要随时可以清空。道具发放失败了没关系手动改数据库补上。这里没有真实玩家没有真实数据没有任何后果。程序员可以放心大胆地折腾。开发环境的货币余额999999999程序员手动填的 开发环境的购买记录随时清空 开发环境的数据库每天重置 开发环境的服务器随时重启开发环境的核心价值让程序员可以快速试错不用担心后果。四、测试环境服务员的演练场代码写完了在开发环境里跑通了。但这不够。程序员自己测试自己写的代码很容易有盲点。他知道系统是怎么工作的所以他会下意识地避开那些可能出错的地方。他不会像真实玩家那样做出各种奇怪的操作。所以需要一个专门的测试团队在一个专门的环境里系统地测试每一个功能。这个环境就是测试环境。测试环境比开发环境更接近正式环境但仍然是隔离的不影响真实玩家。测试环境的货币系统是受控的虚假系统。测试人员有专门的测试账号账号里有预设的测试货币。测试货币看起来和真实货币一样但不是真实货币不能提现不能转账。测试人员用测试货币购买测试商品走完整个购买流程。然后检查货币余额是否正确扣除道具是否正确发放购买记录是否正确写入数据库界面显示是否正确更新如果玩家在购买过程中断网会发生什么如果同时有一千个玩家购买同一件商品会发生什么如果玩家余额不足系统会正确拒绝吗如果商品已经售罄系统会正确提示吗测试环境的核心价值在安全的地方模拟真实场景发现真实问题。测试环境的货币余额测试专用预设固定金额 测试环境的购买记录保留用于分析问题 测试环境的数据库定期从正式环境同步数据结构但不同步真实数据 测试环境的服务器配置接近正式环境但规模较小五、正式环境真正营业的餐厅正式环境是真实玩家使用的地方。这里的一切都是真实的。真实的玩家账号。真实的货币余额可能是玩家充值的真实金钱。真实的购买记录每一笔都有法律意义。真实的道具玩家花了真实的钱买来的。正式环境容不得任何错误。一旦出错玩家钱扣了道具没收到玩家会投诉要求退款。玩家没扣钱道具却收到了游戏公司损失收入还可能被玩家利用刷道具。数据库损坏玩家数据丢失这是灾难性的事故。正式环境的核心原则稳定安全不出错。任何新功能任何代码修改都不能直接在正式环境里测试。必须先在开发环境里开发在测试环境里验证确认没有问题才能部署到正式环境。正式环境的货币余额真实数据严格保护 正式环境的购买记录永久保留法律凭证 正式环境的数据库多重备份高可用 正式环境的服务器高性能高可用24小时监控六、如果只有一套环境会发生什么有人可能会问为什么不能只用一套环境程序员直接在正式环境里开发和测试不是更简单吗让我们想象一下这会发生什么。场景一程序员在测试新的折扣功能。他写了一段代码给所有商品打一折。他在正式环境里运行这段代码想看看效果。结果所有真实玩家都以一折的价格买走了所有商品。游戏公司损失了大量收入。玩家们欢天喜地程序员欲哭无泪。场景二程序员在测试数据库清理功能。他写了一段代码清空过期的购买记录。他在正式环境里运行想验证代码是否正确。结果他的代码有bug把所有购买记录都清空了不只是过期的。几百万玩家的购买历史全部消失。客服电话被打爆退款请求雪崩式涌来。场景三程序员在测试并发处理。他想测试如果一千个玩家同时购买同一件限量商品系统会不会超卖。他在正式环境里发起测试用脚本模拟一千个并发请求。结果正式环境的服务器被压垮所有真实玩家无法登录游戏宕机两小时。这三个场景每一个都是真实发生过的事故。每一个都可以用多套环境来避免。七、三套环境之间数据怎么流动三套环境不是完全隔离的孤岛。它们之间有特定的数据流动规则。代码的流动方向开发环境 → 测试环境 → 正式环境。代码只能从左往右流动不能反向。程序员在开发环境写好代码提交到代码仓库。测试环境从代码仓库拉取代码部署测试。测试通过正式环境从代码仓库拉取代码部署上线。数据的流动方向正式环境 → 测试环境单向且只同步结构不同步内容。测试环境的数据库结构需要和正式环境保持一致。但测试环境的数据内容不能是真实玩家的数据。所以定期从正式环境同步数据库结构表结构、索引、约束但用假数据填充。绝对禁止的操作把测试环境或开发环境的数据同步到正式环境。测试数据污染正式数据是非常严重的事故。八、货币系统的环境配置具体怎么做不同环境货币系统的配置不同。开发环境配置# 开发环境配置文件 config.dev.yamlcurrency:# 货币系统使用mock模拟不连接真实支付系统mode:mock# 购买时不真正扣款直接返回成功skip_deduction:true# 道具发放失败时打印日志不报警on_item_fail:log_onlydatabase:host:localhostname:game_dev# 开发数据库随时可以重置allow_reset:truepayment:# 使用假的支付接口gateway:fake_gateway# 所有支付请求直接返回成功always_succeed:true测试环境配置# 测试环境配置文件 config.test.yamlcurrency:# 使用真实逻辑但连接测试支付系统mode:real# 正常扣款但扣的是测试货币skip_deduction:false# 道具发放失败时记录详细日志发送内部告警on_item_fail:alert_internaldatabase:host:test-db.internalname:game_test# 测试数据库不允许随意重置allow_reset:falsepayment:# 使用支付系统的沙箱环境gateway:sandbox_gateway# 沙箱环境支付不产生真实资金流动sandbox:true正式环境配置# 正式环境配置文件 config.prod.yamlcurrency:# 使用真实逻辑连接真实支付系统mode:real# 正常扣款扣真实货币skip_deduction:false# 道具发放失败时立即报警自动补偿on_item_fail:alert_and_compensatedatabase:host:prod-db.internalname:game_prod# 正式数据库绝对不允许重置allow_reset:falsepayment:# 使用真实支付网关gateway:real_gatewaysandbox:falsemonitoring:# 每笔交易都记录异常立即报警log_every_transaction:truealert_on_anomaly:true同一套代码读取不同的配置文件就在不同的环境里运行。代码不变行为因配置而不同。九、一个真实的事故案例某款手游上线了一个限时活动玩家可以用游戏币购买限定皮肤。程序员在开发环境里开发完毕简单测试了一下觉得没问题。因为赶时间跳过了测试环境直接部署到正式环境。活动上线后玩家疯狂购买。两小时后客服收到大量投诉有玩家说买了皮肤钱扣了但皮肤没到账。有玩家说买了一次却被扣了两次钱。有玩家说明明余额不足却购买成功了。技术团队紧急排查发现了三个bug第一个bug在高并发情况下道具发放和扣款不是原子操作可能出现扣款成功但发放失败的情况。第二个bug网络超时重试逻辑有问题导致部分玩家被重复扣款。第三个bug余额检查和扣款之间有时间差在极端并发情况下余额不足的玩家也能购买成功。这三个bug如果在测试环境里做过并发测试都会被发现。但因为跳过了测试环境这三个bug直接在正式环境里爆发。最终游戏公司花了三天时间修复bug手动补偿了所有受影响的玩家退还了所有重复扣款还发了公告道歉。损失的不只是金钱还有玩家的信任。十、多套环境是对玩家的承诺多套环境表面上是技术架构的选择。本质上是对玩家的一种承诺我们在把代码交给你之前已经在安全的地方把所有可能的问题都测试过了。玩家花真实的钱买游戏里的道具。这笔钱可能是玩家辛苦工作赚来的。可能是孩子攒了很久的零花钱。可能是玩家对这款游戏的热爱和信任。游戏公司有责任确保每一笔交易都安全、准确、可靠。多套环境是实现这个责任的技术手段。开发环境让程序员可以大胆创新不用担心搞坏正式系统。测试环境让测试团队可以系统验证找出所有潜在问题。正式环境让玩家可以放心使用知道背后有完善的保障。三扇门通向同一家餐厅。但只有走过前两扇门的检验才有资格打开第三扇门迎接真正的顾客。这就是多套环境存在的意义。