云游戏全栈自主可控的底层逻辑与应用探索

刘克飞 咪咕互动娱乐有限公司应用运维总监 刘克飞 公司职位咪咕互动娱乐有限公司应用运维总监 拥有10年以上的IT系统维护经验，精通系统架构设计和平台能力优化。从事5年以上云游戏相关的维护工作，擅长数据分析、算力管理和业务支撑。基于公司业务产品的特点制定系统化和数字化的运维体系，着力技术创新、自动化协同和持续集成，重点保障企业系统运行的可靠性、安全性和可扩展性，助力业务产品的稳定、快速发展。 01云 游 戏 介 绍 目录 02云 游 戏 自 主 可 控 的 关 键 点 和 全 栈 分 析 03云 游 戏 自 主 可 控 过 程 中 的 探 索 和 实 践 04未 来 规 划 和 方 向 什么是云游戏 有什么特色？ 云游戏是什么? p基于ARM/X86架构的安卓、主机游戏的云化 p无需下载和安装，即点即玩 p无平台限制，可以在任何平台和终端进行访问 以云计算为基础，游戏在云端服务器运行，将渲染完毕后的游戏画面压缩编码后通过网络传送给用户，客户端设备只需要基本的视频解码和输入能力，实现即点即玩的游戏理念。 公司介绍 “咪咕快游”电信级云游戏平台 充分发挥中国移动5G+算力网络的技术优势，探索“5G+X”应用创新，打造了全国首个电信级云游戏平台 云游戏自主可控的关键点和全栈分析 云游戏自主可控行业现状 自主可控过程中的困难 性能有差距技术生态成熟度不足依赖原厂与三方支持 上云？处理器和图形处理器的性能设备兼容性能力底层维护能力暂不具备 软硬件协同不足标准和规范尚未落地业务代码改造和规范整改大 系统相关问题无有效支撑性能问题解决方案匮乏 咪咕快游自主可控全貌 为提升应对供应链风险的能力，保障网络安全和业务发展，根据国家战略需要和中国移动集团关于深化自主可控应用替代工作的相关要求，自主可控替代工作按照“1345”工作体系落实开展，通过“严格管住增量、自然淘汰存量”方式推进自主可控替代，至2027年重要领域及系统自主可控替代实现“应替尽替、能替尽替” 咪咕快游自主可控核心能力建设 云游戏质量指标体系建设自主可控过程中持续以云游戏质量指标体系为核心标准 云游戏自主可控过程中的探索和实践 应用服务器操作系统国产化--操作系统介绍 主流操作系统 n是华为自研的数字基础设施开源操作系统，是一个开源、免费的Linux发行版平台n安全性强，采用了内核级别的数据加密算法，可以有效保护用户的安全性和隐私性n稳定性好，支持多种故障隔离技术，可将故障范围控制在最小，保证系统的整体稳定性和可用性n支持鲲鹏处理器和容器虚拟化技术，满足各类企业级应用的需求 应用服务器操作系统国产化--云游戏平台实践 p云游戏平台共有3000+台应用服务器，其中包括2800+台Redhat、Centos系统和200+台Suse系统 p截止2024年4月，已全部完成应用服务器的操作系统切换，并在运行过程中解决了相关问题，稳定运行。 应用服务器操作系统国产化--案例1 内存异常增长问题 服务器（龙蜥8.6内核4.xx和5.xx）存在crontab定时任务情况下，服务器的内存会逐渐增长且不可逆，尤其是在对内存操作频繁、crontab任务越多的情况下，增长越大。 应用服务器操作系统国产化--案例1 原因定位： 原因1：系统日志写入/run/log，而这个目录是虚拟文件系统，其中的内容会占用内存空间，随着日志文件的积累，内存会被使用掉尝试解决：1：改变日志的存储位置2：确认日志是否存在清理或回滚动作，如果存在，则不会一直增加 原因2：在观察期间，Java、redis等应用程序本身占用内存有所增加，这可能与业务压力或应用预热有关，在排除应用程序Bug的前提上，这部分内存不会持续增长 原因3：cgroup_memory_kmem存在引用计数无法及时回收的问题，该问题在当前的业务场景下被放大，结果造成大量内存无法及时回收 注：该项功能在老系统中不存在，因此没有问题，但在龙蜥系统中存在 解决方法： 1：通过内核参数禁用该功能grubby --update-kernel=ALL --args=cgroup.memory=nokmem（整改命令） 2：升级内核到已修复的版本 3：评估和改变业务流程，规避上述问题 目前采用的方法1，状态：有效性已验证成功，内存不再异常增加 应用服务器操作系统国产化--案例2 CPULoad增长问题 CPU负载对比原先Redhat增长4~5倍，无异常进程，且CPU使用率不足20%，但在应用进程启动后，CPU负载就显著增高 应用服务器操作系统国产化--案例2 原因定位： 1：经观察，系统负载上升明显，但并没有伴随明显的CPU使用率上升，是因为存在D状态进程拉长了待运行队列。 问题分析： 操作1：从内核版本切入，观察内核对CPU负载的影响。 将一台在用机器的内核从2.6升级到3.10、4.18以及5.10版本，系统负载增加明显，确认系统负载增加由内核差异导致。操作2：应用内核参数优化，确认与CPU负载的关系使用mitigations和audit内核参数屏蔽内核安全加固与审计，负载变化不大，推断负载增加与这两者无关。操作3：关闭D状态进程高的filebeat进程，观察对CPU负载的影响对比2.6、3.10、4.19和5.10不同内核在业务高峰以及关闭filebeat前后的表现，发现关闭后cpu负载下降一倍左右，但仍然比老版本系统高3-4倍左右。 问题原因： 1：系统负载由新老内核在特定业务形态上的处理性能差异导致。2：通过4个版本系统在业务高峰的性能比对，并采用关闭filebeat进程的方式，确认龙蜥系统各个版本的性能在业务高峰，相对红帽系统的要低。 解决方法： 1：通过应用代码逻辑修改调整日志生成规则，增加日志备份频率，目前业务高峰期验证未出现高负载情况。2：采用最新的优化内核方式，针对严重的性能瓶颈需要及时扩容分摊CPU负载压力。 数据库国产化--OceanBase应用分析 n原生分布式架构，替换成功案例较多，对O兼容性完善，改造难度相对较低。经过验证可以满足核心生产库稳定性及性能要求。 技术架构 l原生分布式节点对等，多副本数据冗余，支持异地多活部署l大量x86可聚集成DBaaS资源池，集约管理、弹性分配租户资源l数据和负载可在集群内自动分布和压力均衡，资源利用率高 l纯自研，对O库兼容性较好，小库几乎不用改造；大库改动相对较少，工具分析数据库对象99%以上兼容l分布式的高可用能力超越Oracle架构，整体吞吐量和节点数线性增长，数据存储相比原库节省70%以上l配套生态工具相对完善，有较多移动系统内核心系统去O经验 优势 l分布式架构下，数据跨节点访问的性能会部分降低（业务感知不明显）l日志跟踪手段、知识体系不如O库，目前依赖原厂与三方支持l技术生态相比Oracle、MySQL不够成熟，技术封闭 劣势 数据库国产化--OceanBase兼容性分析 数据库对象 分区 字段 l物化视图（Materialized view）暂不支持，需要进行改造l不支持Oracle的系统包dbms_sqllJob暂不支持，需要业务侧进行改造lOB不建议使用触发器lOB建议序列的cache值大于1000，cache值小于1000可能影响数据库性能 l存在部分表字段类型不支持，需要评估修改字段类型【OB不支持迁移NCLOB、LONG、ROWID、BFILE、LONG RAW、XMLType、UROWID、UNDEFINED和UDT类型的数据】lLOB字段表没有主键，LOB要加主键才可以反向同步lOB不支持超过48M的大LOB字段，需要代码改造。OB迁移过程中超过48M的字段只能截断后再迁移。【CLOB和BLOB类型的数据必须小于48 MB】 l不支持分区名纯数字，建议以P或PART关键字为前缀l不支持INTERVAL自动分区，迁到OB需要手动维护l不支持max分区表 其他 SQL lLock Table方式，后续需要业务侧评估改造成select ... for update【LOCK TABLE tablename IN lock_modeMODE NOWAIT;】lnchr函数、lengthb函数，EXTRACTVALUE不支持l超长SQL（存在大量UNION ALL的SQL，inlist）,建议不超过100行 lOracle数据库中有24种数据类型，OceanBase数据库目前支持20种，4种基本已废弃lOracle数据库中支持内建函数257个，OceanBase数据库当前支持主流的155个，基本满足大部分场景 数据库国产化--案例1 读写分离的针对性应用 l互联网产品普遍存在读多写少的业务场景，数据库读写分离技术是一种常见的数据库优化手段，将一部分的读请求路由到Follower副本上，从而降低复杂查询对资源的侵占，影响在线业务的响应延迟lOceanBase数据库也提供了读写分离的能力，通过将定时任务、排行榜等具体的业务场景分离出单独的服务，连接单独的弱读Proxy实现读写分离。减轻了PrimaryZone的压力，提升效率 设置条件： •设置弱一致性读OBProxy：obproxy_read_consistency = 1;•设置Primary Zone为：zone1,zone2;zone3•设置LDC策略，OBProxy和OBServer绑定•配置了FOLLOWER_FIRST 路由策略：•需要弱一致性读的SQL，连接设置了弱读的OBProxy，其余SQL连接正常 OBProxy；•通过连接弱读的OBProxy的所有SQL，会基于LDC路由策略，以及FOLLOWER_FIRST策略，会自动访问本地Follower副本。•因为设置了Primary Zone（zone1,zone2;zone3），所有的Leader副本都被迁移到了zone1和zone2中，因此zone3默认情况下都为Follower副本，那么zone3的副本就可以只给弱一致性读的分析计算类SQL提供服务。 优缺点：•优点：zone级别隔离读写请求，隔离比较彻底； •缺点：需要单独配置一个弱读的OBProxy，需要设置Primary Zone。 数据库国产化--案例2 OB表连接顺序错误导致SQL运行效率降低 SELECTCOUNT(DISTINCT T.ID)FROM T_SUBLIVE_FLOOR FLEFT JOIN T_SUBLIVE_LIVE_VIDEO_REL R ONR.FLOOR_ID = F.IDLEFT JOIN T_TRIBE_ARTICLE_INFO T ONR.ARTICLE_ID = T.IDLEFT JOIN T_USER_INFO_KOL KON T.AUTHOR_ID=K.ID AND K.DELETE_FLAG=0LEFT JOIN T_TRIBE_THEME_INFO O ONT.THEME_ID=O.IDWHERE F.SUBLIVE_ID = '33000'AND T.AUDIT_STATUS=2AND T.EFFECTIVE_TIME <= SYSDATE ANDT.EXPIRE_TIME >= SYSDATEAND O.STATUS=1AND O.DELETE_FLAG=0AND T.SHOW_IN_VIDEOZONE=1 问题现象： Oracle运行6ms，迁移OB运行4.5s问题分析：T_TRIBE_ARTICLE_INFO没有走PK_TRIBE_ARTICLE_ID ,错误的选择了IDX_ARTICLE_INFO_ID修复措施：添加hint /*+ LEADING( F R T O )*/选择的正确的索引，时间降到9.5ms。Table get表示直接用主键定位，返回0行或者1行数据。 OB优化前后执行计划对比 G O P S全 球 运 维 大 会 暨X O p s技 术