成都网站建设scyiyou,免费空间能放网站吗,wordpress cache选PHp,好视通视频会议app下载推荐语#xff1a;互动游戏是一个系统化工程#xff0c;在笔者的“喵果总动员”质量方案中#xff0c;可以看到为保障用户体验#xff0c;我们在各个难点的解决方案#xff0c; 例如#xff1a;用线上压测能力支持业务及时调整各服务容量、通过强化学习覆盖游戏行业的测试…推荐语互动游戏是一个系统化工程在笔者的“喵果总动员”质量方案中可以看到为保障用户体验我们在各个难点的解决方案 例如用线上压测能力支持业务及时调整各服务容量、通过强化学习覆盖游戏行业的测试路径覆盖难题、利用系统异常注入发现corner case等 都为互动游戏的系统性质量保障提供了方法。——大淘宝技术质量工程师 搏天背景介绍2022年淘宝双11的互动游戏推出三款游戏单人割草升级、多人组队PK、在线猜题闯关兼顾了不同用户对休闲娱乐和竞技对抗的差异化诉求。▐ 玩法核心策略单人割草升级魔性有趣的核心玩法吸引用户创造记忆点操作简单易上手降低用户学习门槛。多人组队PK复刻盖楼狂欢增加竞技的刺激感。在线猜题闯关每天定时开启价格竞猜玩法营造大促氛围打造话题爆点。核心挑战▐ 相较于往年大促的变化猜价格玩法流量集中严格时序用户有异常退出、提前结束比赛的风险猜价格每天12点、18点准时发车用户需要提前停留在页面参与因此会有集中的流量流入预计千万量级用户参与。猜价格玩法要求严格时序依次进行查看题目、提交答案、查看排名、使用复活卡等操作过程中因用户网络超时或者切后台等原因导致用户没有在规定时间内完成对应操作导致无法完成比赛。IGF游戏化架构重构了PK模型引入的数据一致性风险虽然PK玩法相较于过去两年没有明显的变化但是技术架构的重构依然引入一些新的数据一致性风险和问题新的序列化协议数据压缩方案序列化性能、对于某些特定的数据类型是否支撑数据是否存在丢失的问题新的玩家-战队-房间存储模型设计今年核心数据首次选择了存储在RDB中数据迁移过程中的异常重试并发锁、幂等重试的逻辑需要重新设计重点保障。RDB核心用户资产数据存储的稳定性数据大小/QPS对存储的性能的影响RDB对核心资产数据的监控和对账能力保障数据丢失后的回补能力。实时类互动对端性能要求更高从端性能问题导致的影响来看crash渲染不出来等问题会直接影响到用户行为链路的中断卡顿会导致用户关键操作的决策、失真掉电过快等问题会导致用户对游戏品质的质疑从而流失。从问题发生的概率来讲这次整个地图渲染的实体更多端计算存储量增多更加对端性能提出了更高的要求。割草玩法前端计算和存储引入的场景覆盖、安全性等新问题本次单人割草玩法战斗逻辑写在客户端。战斗逻辑是包括技能逻辑、普攻、属性、伤害、移动、AI、检测、碰撞等等的一系列内容。这块在互动是全新的技术尝试以往所有的逻辑都是在服务端处理。所以端计算数据存储稳定性逻辑一致性的验证比以往的要求更高例如数据丢失后的回档问题。另外就是安全性问题以往所有逻辑和数值都是在服务端如果想作弊就必须攻击服务器而攻击服务器的难度比更改自己客户端数据的难度高得多而且更容易被追踪被追踪到了还会有极高的法律风险。而帧同步因为所有数据全部在客户端所以解析客户端的数据之后就可以轻松达到自己想要的效果例如 moba 类游戏的全图挂吃鸡游戏的透视挂都是没办法防止的而更改数据达到胜利的作弊方式例如更改自己的英雄攻击力可以通过服务器比对同局其他人的战斗结果来预防。▐ 风险评估表测试内容风险等级测试策略风险点单人-割草收能量高功能测试、前端碰撞模型算法测试、故障点测试、兼容性测试1.草的割取和能量的收取的一致性2.关键地图信息、背包能量、PK道具buff等信息存储在indexDBlocalStorage的稳定性保障3.客户端性能的风险crash渲染不出来卡顿、失真4.前端防刷防止有用户能快速刷满所有能量单人-升级发红包中功能测试、故障点测试1.能量和等级一致性保障升级发红包兑奖中功能测试、故障点测试1.红包必得的逻辑保障IGF序列化协议中功能测试性能测试1.序列化后的字节数大小2.序列化和反序列化的效率3.是否支持被序列化对象新旧版本的兼容性问题。4.是否可以直接序列化对象而不需要额外的辅助类猜价格-并发度高功能测试、故障点测试、性能测试1.通过性能压测摸底合理安排资源和限流最大程度保障用户体验2.限流情况下的产品/前端表达引导用户重试 或 补偿3.前端打散请求4.前端防刷减少无效请求猜价格-排名算法中功能测试、故障点测试、性能测试1.排名算法时效性要求高从方案层面设计未能及时产出结果的保障方案2.通过性能压测摸底合理设计限流最大程度保障用户体验猜价格-选品一致性中方案设计保障、定时巡检1.从方案层面保证选品价格不能轻易变更 或者 活动方案不依赖选品实时状态2.保证项目组能第一时间感知选品价格变更、上下架变更猜价格-异常重连中功能测试、故障点测试1.方案层面保障用户在任何异常主动退出、crash等、任何状态下都能有重连的机制质量保障方案本次双11的测试目标是“大规模用户同时在线下的实时游戏类互动的质量保障”。目标是0故障、0资损、用户游戏体验流畅度千万用户同时在线。▐ 目标核心策略如图所示▐ 目标完成情况定义了双11主互动体验的目标新增回档率等体验指标分析过程中数据优化提升体验水位中断率、可视时间、帧率等高峰期无大规模体验舆情主互动发热、卡顿显著改善。舆情15分钟定位。无稳定性问题造成的大规模用户舆情和核心链路不可用问题事前压测数据构造了亿级战队高峰期千万用户行为模拟上线前期通过观察流量占比/数据存储大小发现地图上报接口流量模型不一致的风险根据当前架构梳理出低成本的线上可压测方案具备稳定性变更可验证的能力。自动生成用例占比76%冒烟用例场景开发可执行占比67%异常场景覆盖占比85%专项建设和结果▐ 稳定性测试策略——线上压测能力建设除了事前——让压测方案更加趋近真实、和事中——数据观察模型修正的方案外本次双11稳定性测试想要重点建设线上压测的能力。解决的问题预期外的流量作为线上容器存储的扩容的演练手段压测模型评估不准确的情况下线上需要变更的验证能力核心原则线上容器存储资源等系统稳定性不受影响线上压测执行压测实战最重要的两点是确保压测结果的可靠性以及保证压测对线上性能无影响。不影响线上稳定性的几个关键点 容器的稳定性理想情况将服务单独部署到相同规格的机器上从物理层面将压测系统与真实业务系统进行隔离确保压测对真实业务系统的硬件资源无影响。缺点成本高可行性方案线上压测的目的不是为了压系统的瓶颈是为了验证预期流量下的系统表现因此可以在业务流量低峰期在当前集群进行线上压测拉起流量还原发生问题时的场景对容器的压力可控风险较低。 数据隔离的安全性DB的数据隔离DB数据隔离一般有两种方式通过新建影子表或新建一套db来保证压测数据与真实业务数据隔离确保压测数据不会污染线上数据。新建db的时间成本和资金成本很高本次互动玩法DB只存储个人-战队-房间的索引关系和流水单行的数据量较小。经过压测验证读写的高峰发生在匹配和结算的定时任务时系统可以通过限制任务的执行的速度使DB性能处于安全水位之下。用户自然流量对于DB的读写的峰值按照200%的流量模型评估在QPS、TPS、接口成功率、RT评估均无性能风险因此可以采用影子表作为数据隔离策略。在压测系统水位时以影子表作为数据隔离策略需要注意的是影子表与真实的线上表存在于一个db中压测对db整体性能存在影响可以选择用户访问量低谷时间段内进行压测来能保证压测不影响线上用户且保证压测结果的可靠性。RDB的数据隔离RDB是本次核心数据的存储RDB没有DB影子表的隔离能力可以通过申请新的RDB实例进行物理隔离底层IGF框架通过配置进行压测流量的路由。LDB的数据隔离LDB支持影子链路存储的隔离能力业务层无需改造本地缓存隔离记录时需要带上影子标记和正常流量进行区分中间件隔离压测服务使用单独的版本号可以将压测服务与真实业务服务隔离确保线上流量不会打进压测系统通过修改压测应用groupId实现定时任务的分组隔离保证线上任务不会调用压测机器执行等等。 保证压测结果可靠性的几个关键点 压测接口要满足压测需求在对存在上下游依赖的业务链路压测时会将该业务链中的功能接口组装成几个压测接口该压测接口应体现真实业务链路的上下游依赖。业务逻辑改动要仿真业务场景在不改变业务请求对系统性能产生的影响时开发同学可能会修改部分业务逻辑进行压测。比如真实业务链路的非幂等性导致同一用户在同一状态下只能进入该业务链路一次这种场景对压测造成的最直观影响是需要生成极大量入参来满足压测需求。为解决该问题开发同学可能会将压测的业务链路修改为幂等业务链此时便需要注意当前修改不能改变请求对系统稳定性的影响。qps配比要仿真业务场景在同一场景下不同接口的qps配比是否能够反映真实业务场景是判断压测结果是否可靠的重要依据。qps配比需要基于能够衡量真实业务访问量的统计结果来制定。入参满足业务仿真的需求如果入参的取值对系统稳定性影响较大比如不同的入参对cpu计算量或者io访问时长影响较大相同的入参并发请求时对io阻塞影响较重等等。,需要调研真实业务场景的入参并发间隔、入参离散程度来设计压测入参。影子数据满足业务仿真的需求若通过分析发现db数据不是本次压测需求的瓶颈或关键点可以忽略此条建议。不过最好还是在压测前将线上数据同步到影子表做到高度仿真RDB同理。关键问题 数据准备线上真实数据同步到新的RDB实例目的是能做到数据存储大小的仿真。备份恢复方案概览类别实施方案说明是否采纳数据备份自动或手动备份云数据库Redis支持数据持久化会按照默认的策略自动备份数据基于 RDB 您可以根据业务需求修改自动备份策略也可以手动发起临时的备份。是下载备份文件云数据库Redis的备份文件会免费保留7天如果需要更长时间的备份存档例如监管或信息安全需要您可以将备份文件下载到本地进行存储。备份文件过大无法本地存储使用redis-shake备份Redis实例通过Redis-shake的dump模式您可以将Redis实例中的数据备份为RDB文件并存储至本地。备份文件过大无法本地存储数据恢复从备份集恢复至新实例云数据库Redis支持从指定的备份集创建新实例新实例中的数据将和该备份集中的数据一致可用于数据恢复、快速部署业务或数据验证等场景。 是通过数据闪回按时间点恢复数据开启数据闪回功能基于 AOF 后在备份文件的保存期内您可以恢复指定时间点精确到秒级的Redis数据可最大限度地避免误操作带来的数据损失或者在频繁回档的业务场景快速完成数据切换。说明 该功能仅在企业版内存型中支持。否使用redis-shake恢复数据借助Redis-shake的restore模式您可以恢复RDB文件到Redis。否参考https://help.aliyun.com/document_detail/43886.html链路改造上线前的压测链路改造保留压测环境准备时长千万账号登录加压测数据上传同步amazon压测平台时间较长可在流量低峰期操作减少登陆的时间。▐ 瓦力——基于强化学习引擎的PK全链路场景自动生成互动瓦力机器人是大淘宝技术互动测试团队于2019年推出的一款用户行为链路仿真平台底层基于强化学习引擎实现了用例的自动生成解决了互动业务测“新”的痛点问题如今已广泛应用于天猫淘宝大促主互动场景和芭芭农场、淘金币等多个日常业务。之前我们的工作模式更多是在提测后做质量保障工作包括功能验证、稳定性性能、资损等等通过提测后问题发现和风险发现来保障整体的交付质量往往在最后的提测阶段暴露大量的风险和问题导致整个项目再最后时间压力最大。从2022年618开始我们尝试重点解决开发自测和前后端联调阶段开发不明确自测场景范围以及测试数据/环境无法快速构造自测用例无法执行的痛点问题。以本次的“喵糖总动员”的结算场景为例需要先组成多个战队离线DTS任务匹配穿越到PK期升级/助力最后才能进入结算整个链路的测试成本是非常高的。借助强化学习用例生成引擎简化了测试用例前置条件用例特征的构造成本用例特征原子化在提测前快速生成了60的冒烟用例占比全用例的76%提测通过率100%提测冒烟时间从过去的3天缩短至1天。挑战与技术创新点借助瓦力机器人提升了核心场景的自动生成能力问题和风险前置提高了联调和冒烟阶段开发自测的效率提前发现问题19个沉淀了可稳定执行的场景case变更后可快速回归验证问题和展望继续提升开发联调和自测阶段可执行用例的占比提升研发自测的幸福感简化用例的表达和执行结果的描述减少用户理解的成本▐ 大白——业务异常场景自动生成业务容灾平台-bighero大白一种不需要编写脚本通过分析正常流量的核心调用依赖批量生成异常用例并通过互动机器人鹰眼标凤凰和jvm-sandbox构造流量隔离的异常用例执行环境最后针对异常用例结果进行系统化布防的测试工具目标是在上线前自动识别出系统的潜在风险并通过布防等方式将业务损失降到最小。挑战与技术创新点IGF框架的引入放大了同方法多次调用异常精准命中需求本次基于链路上下文开发了指定方法index||参数的用例生成攻防满足特殊异常链路的覆盖自定义异常返回异步消息链路的异常测试hsf接口进行异常用例的自动生成和攻防将定时任务包成hsf接口进行同逻辑小数据测试避免同接口异常误命中叠加参数进行攻防对象的流量筛选落地效果自动化产出喵果总动员有效容灾用例216条P1P2故障点覆盖率为82.6%多人15个P1P2故障点12个覆盖占比80%开奖4个P1 P2故障点4个覆盖占比100%单人4个P1P2故障点3个覆盖占比75%展望提升大白-异常测试平台的产品化程度降低异常测试的使用门槛简化使用流程提高异常场景的覆盖面MT、并发、奥格、安全等提升异常攻防的自动化程度未来展望挑战大规模用户实时在线游戏已经成为互动游戏发展的必然趋势同时在线、低时延、3D渲染等新的课题对互动游戏化架构的稳定性保障、体验标准衡量等提出了更高的要求。短期规划通过完善交付场景用例的生成和执行能力提供给开发更多的自测验证的场景和手段提升研发自测阶段的效率提升交付的质量。预研大规模用户实时在线游戏下的架构梳理相关问题和技术难点构建相应的质量保障策略和方案。团队介绍我们是大淘宝技术质量团队负责保障整个淘宝和天猫主站的业务质量一直致力于技术驱动构建业界领先的质量体系。我们有QCon、QECon、MTSC、GIAC、绿盟、TOP100 Summit等众多行业大会的讲师有GitHub获得3.2k Star的开源产品JVM-Sandbox作者最关键的是有对技术极致追求对生活充满热爱的大家庭欢迎加入我们简历投递邮箱wenbo.shbalibaba-inc.com。¤ 拓展阅读 ¤3DXR技术 | 终端技术 | 音视频技术服务端技术 | 技术质量 | 数据算法
