云原生正发声第31期——云原生在高并发游戏推荐系统中的实践原创

线上的朋友周二晚上好，欢迎来到于原生正发声直播间，我是今天的主持人朱丽叶，于原生正发声与原生技术爱好者共同学习成长，那今天是我们节目的第31期了，我们邀请到了来自腾讯游戏IEG高级运营工程师李莹李老师来给大家做分享，那李老师呢，他是elastic search的开源研究爱好者，也是游戏战中陪伴推荐系统设计和开发的组成，那他今天给我们主要分享的主题呢，是于原生在高并发游戏推荐系统中的实践，那通过本次的分享呢，大家可以知道就是推荐系统在游戏大流量场景下的云原生解决方案，以及如何通过流量控制、服务治理S等手段来解决一些业务问题啊同时呢，李老师也会呃，给大家分享一些就是业务在服务上云的一些最佳时间，包括一些避坑指南啊。

帮助有需要的用户来平滑上云啊，那我们的节目分享流程呢，还是一样的，就是呃前面45分30到45分钟呢，就是老师会给我们先分享他的整体的呃PPT，然后呢，在分享结束之后呢，就会进入我们的互动问答环节，那大家可以扫描我们屏幕左侧的二维码，就进入到我们的提问专区进行提问，那扫描右侧的二维码呢，就可以直接进入到我们的技术交流群，那那我们的老师呢，会在分享的时候呢，选取啊大家的那个提问给大家进行分享，那同时我们也准备了一些精美的呃鹅创的礼品就是这个。

虎年的。可以看到虎年大吉的公仔，然后会给到提问的同学，欢迎大家多多提问和分享。以及我们在直播间也会有不定时的红包抽奖，奖品也是我们这一只虎年大吉的公仔，欢迎大家多多关注和互动哦。好，那么接下来就有请李老师来开始他的精彩分享吧。好的，李老师这边可以开始了。嗯，大家好，我是来自腾讯朵拉推荐团队的代表李莹，然后刚刚提到，今天给大家分享的主题是云原生在高并发游戏推荐系统中的实践。今天的分享内容主要会分为三个部分，首先我会跟大家介绍我们的团队负责的推荐业务以及演进的过程，包括架构的变化，上云的时机等等。嗯，接下来呢，会从云原生的关注点进行切入，分享我们的业务在实际上云过程中遇到的问题。

以及给到大家的一些建议，嗯，最后就是QA的环节。嗯，接下来我们就进入第一个部分的介绍业务的背景。我们的团队主要负责推荐架构，嗯，早期呢主要负责图文、视频、广告等的推荐，在PPT的左侧，嗯，心悦俱乐部APP，心悦俱乐部呢是腾讯游戏官方的福利平台，在APP内除了有福利礼包的领取之外，还有一些。呃，游戏、资讯、权益等等，心悦APP现在全平台的内容都已经接入到了我们的推荐系统，嗯，右侧呢，这里是展现一下，以及腾讯游戏社区，主要在里边会有各个游戏的玩家，嗯，进行一些分享和讨论，我们的推荐系统主要是给玩家做一些推荐，嗯，资讯的推荐，用户的分享和提问等等。

我们的团队是从2018年开始接触推荐系统，并且完成了从零到一推荐系统的搭建。在这个时期呢，我们就主要负责心悦APP内部的，呃，游戏垂类图文视频内容的推荐。在2019年到2020年间，随着闪现的接入以及新月推荐的呃。内容的一个扩展，我们的推荐架构进行了一个升级，完成了微服务化改造，并且呢，从C加加转向了购，这些改造都从一定程度上提升了我们服务的稳定性，但是还存在着一些问题，就比如说发布流程复杂，部署困难，流量洪峰等一系列的问题，于是在2021年，我们把业务的中心放在了服务上，云这件事情上，通过云原生的方式去解决我们的业务问题，服务的稳定性啊，这一系列的呃，DVS都得到了进一步的提升。

在这之后，也就是2021年到2022年，我们的推荐业务又迎来了一个新的挑战，就是接入了腾讯游戏知己，它是一个嗯，游戏陪伴助手，这是一种完全不同的推荐形式接入，在后面我会跟大家讲到。然后这种新的推荐形式对我们的服务架构、稳定性和性能都有了一个更高的要求，在这同时也给了我们嗯一个很好的实践机会，去对我们的推荐系统进行创新，并且去进一步的探索与生。嗯，刚刚他提到的游戏之可能会有一些陌，但是像王者荣耀里面的小妲己，嗯，和平精英里面的这个小己，大家可能都有听说过，其实呢，这些都是嗯游戏知己的化身，我们可以在游戏端内进行一些提问，然后自己会经过智能的分析之后给到大家答案。

除此之外呢，我们的知己还可以跟大家进行语音对话，下面就会以和平精英为例给大家展示一个视频，然后视频中展示的部分内容就是我们今天要说的新的推荐形式。在播放之前先跟大家简单介绍一下，呃，知己就是视频中声音比较可爱的小几，然后为了给玩家带来更好的游戏体验，小几会在合适的时候给玩家进行一些危险提示，策略分析等等。然后小姐的运营会分为主动和对话两种形式，视频中会有一个男性玩家的声音跟小几进行对话。你好呀，特种兵高达降临海岛，带来了机动空投，现实内开启将会获得优质物资哦。

这把就P场好的一位特种兵标记上。P成了上城区，资源丰富，也是枪战集中爆发区域，要时刻注意敌人的动向哦。P城和研究所在航线附近为必争之地，进圈路线可选择绕开寻找载具，沿左侧公路进圈为最佳选择。跑车好累啊，要是有车就好了。小鸡在地图上标记了刷车点速度，停车吧。怎么啦？小摸摸你的额头烫不烫？东南方向70米有敌人，小鸡闭嘴好嘞。嗯，看完这个视频呢？我不知道大家会不会有一点疑惑，就是刚刚我提到的视频中可以推荐的点在哪里？嗯，关于视频中对话的部分，其实和游戏端内的文字对话是差不多的，只是在文字的基础之上新增了一些语音的识别和播报。今天我们主要要聊的是小主动给玩家进行策略提醒的这一点，其实在一开始我们也没有把它当做推荐去做，就像视频中刚刚出现的嗯，视野范围内某个方向有敌人这种推荐的话术，这种话术不就是逻辑判断吗？

你还拉特？于是我们首先想到的第一个方案就是通过条件判断去做，同时呢，考虑到这些策略点通常会存在一个比较频繁的变更，就比如说某些策略点它的用户反馈比较差，需要马上下掉，又或者是说随着版本的迭代，突然新增了某个重要的策略点，需要马上上线，于是我们使用了瓦去实现。嗯，在PPT中我们可以看到这个流程图。首先呢，我们会。事件的量级是非常大的，玩家在对局里面的一举一动都会通过数据上报的形式进行一个接入，嗯，当然这里的数据是在用户允许的前提之下进行采集的。接下来呢，就是事件处理的模块，就是这里的event logic。

我们使用了撸瓦，嗯，利用撸它本身的一个语言特性，以及它上手非常快的优势，去实现了一个游戏对局中关键策略点的脚本文化。嗯，就像PPT中这里展示的样子，嗯，它其实就是一些这里的逻辑。是比较简单的，并且已经支持了动态的变更，在最开始呢，这一切都是非常的美好的，游戏的对局中一些关键的策略点的播报都能够，但是随着时间的推移，慢慢的脚本的数量越来越多，维护起来非常的困难，而且嗯，这些人为定义的策略点会存在特别强的主观性。

难道我们要一直这样去堆砌脚本吗？我们其实应该是可以做的更好的，就比如说呃，在游戏对局里面刷圈了，嗯，玩家在跑的时候，我们的策略点其实应该倾向于去提醒玩家哪里可能会有车，但是在目前的这个方案里面，我们是没有办法，呃，直接通过以fails的方式去实现。我们就只能去，呃，尝试提醒快点跑，但是这对玩家来说是毫无意义的，又或者是说，呃，当玩家的周围有敌人的时候，我们应该是让玩家苟住呢，还是让玩家去进攻呢？这些具体的行为方式其实是跟玩家的历史偏好有关系的，就刚刚我描述到的这些策略点，其实听起来就非常推荐它，本质上呢，就是根据用户的行为偏好，结合离线的算法和定时的一些策略去给用户输出最合适的内容。

于是我们做了一个简单的可行性分析，首先呢，是推荐的基础，嗯，需要海量的数据，像和平精英这种游戏，它的历史对局数据是非常多的，用来做建模是绰绰有余的。嗯，接着呢，就是推荐的内容，在图文视频的推荐场景下，我们会进行一个内容理解，将图文视频抽象为标签或者是向量，然后来给用户进行推荐。在刚刚的播报场景里面，推荐的内容是话术，话术就是一些策略点，嗯，其实可以理解，它是很很容易去进行一个标签化的。在接下来的话就是用户画像，在游戏的场景下，他，呃，用户的历史，对局行为，以及用户当前在对局中的状态，这些都是用户的画像，并且都是可以计算的。嗯，现在PPT展示的呢，是我们之前常规的一个推荐系统的架构，主要是支撑图文视频的推荐，整体呢已经实现了微服务化，并且全面上云，在云原生方面也有了一些实践，比如说自动化的CICD以及服务治理等等。

下面我先简单的介绍一下这这个架构，呃，主要分为了几大模块，首先是这里的应用层，呃主要是业务就不用太关心，然后是接入层，我们引入了API去做两倍流量的管理，并且借助网插件实现了ID的生成，呃，去贯穿到我们的整个链路。比较重点的是这里的推荐引擎。这里可以看到，嗯，列出了。比较多的。列出了比较多每一层它所负责的功能点看起来会比较复杂一些，但是呃，其实整体的链度还是算比较简单的。首先是招回层。

嗯，召回的话会负责呃，通过不同的召回算法去进行一个内容的召回，然后给到金牌层，金牌层呢，根据用户的特征去做一些更精更加精细化的排序，最后给到重排层，重排层会呃对金牌层返回的结果进行一个动态的运营规则，或者是说置顶策略等等，呃在最后呢，就是给到填充层去做一个内容的填充返回，给到我们的应用层去做一个展示。在最下面这里是一个内容中台，内容中台就是负责呃去各个渠道拉取一些优质作者发布的优质内容，并行进行一个内容理解自动化的运营。不知道大家这里能不能看到这里右边这里的管理端，呃，其实也算是内容中台的一部分，主要负责内容运营，内容管理以及一些数据看板的展示。

然后这里的评估模块的话，主要就是一些呃，线上策略的AB实验的策略效果评估呀等等。接下来呢，我就会主要介绍一下我们是如何将游戏内的播报和推荐进行结合的。嗯，首先是关于用户画像，嗯在这个场景下，它的画像和传统推荐其实并不一样，在离线的部分其实还好，但是对于呃对局实时中他的画像是特别多的，比如说呃玩家当前的血量状态，又或者是说对局进行到什么情况了，他有没有队友，队友的状态又是如何？而且呃状态在对局中的变化可能会非常的快，有很强的时时效性，所以对性的要求特别高。我们抽象出了一个画像层，在刚刚的事件消费之后呢，嗯，画像层会负责呃对用户的数据进行一个呃对局数据缓存状状态的计算等等，这些数据都会存在内存里面，并且配合上呃，我们自定义的一个对局ID去做一个一致性哈希来保证用户画像的快速读取，同时为了避免库缩容导致内存的数据丢失，所以说进行了一个RA的数据备份。

画像之外呢，这个产品就比如说它的推荐数量是很少的，嗯，只有最优的那一条，并且他的推荐的频率和时机的把控都非常的重要，我们不能去影响玩家正常的游戏体验，嗯，第二点是不像正常，就传统的那种图文视频，我们可以从各个渠道去拉取作者发布的内容，在这个场景下面，策略点有可能有成千上万种，我们不可能人为的去呃一一的去列举。

最后是像和平精英这种游戏，它会有很多的呃游戏地图，每一个地图都有不同的策略点，我们也不可能逐个的去进行开发。嗯，右图呢，这里是我们目前的一个。除了上面的事件消费画像层之外，其他的部分其实上和我们的推荐架构是有一个完美的契合的，它最大的差异应该主要是在礼仪线的模型训练上面。在推荐实时的部分呢，我们的画像层，呃，根据事件计算出用户的实时画像之后，一部分会走离线上报给到数据中台去进行一个离线计算，另一部分就会进行实时的推荐啊，这里填充层会嗯缓存一些历史状态缓存啊和一些历史推荐的缓存，主要是用来做呃策略的呃，做一些特征的计算。

嗯，在召回层呢，这里和之前一样。呃，走一个fast召回，或者是算法的召回，呃把内容给到金排层去做一个TF2的评分，再给到重排层，这里重排层的逻辑会相对之呃图文视频的推荐更加严格一些，因为他要去把控它的推荐时机和频率，最后给到填充层去调用我们的消极播报，呃在客户端里面给玩家进行播报。目前呢，呃还有离线的部分，离线的部分的话，主要就是呃用会进行一个用户画像的计算，以及使用VE纳S平台去做一个呃用户状态的自动挖掘，以及我们播报策略点的自动挖掘去探索，在什么情况下给呃玩家去推荐最合适的话呢，我们呃的方案已经得到了实现。

但是为了能够给大家带来更好的体验，就是细节的部分我们还在进一步细化之中，嗯，期待可以尽快的上线。呃，讲到这里，大家应该对我们的业务有一个大概的了解了，在正式开始第二个部分上云实践的介绍之前呢，我们其实应该明确一点，什么才是真正的上云。上云就是简单的，我们现在的服务做一个打包，并且容器化部署嘛。嗯，其实想一下。这样好像只是换了一种部署的方式，它并没有给我带来太多实际的收益。上云，上云其实应该是利用云原生的技术去实现我们一个稳定性的提升，全方面的提高我们的效率，并且强化对资源的合理利用。它的关注点非常多，嗯，服务化，微服务化，容器化只是它的一方面，还有例如标准化部署，嗯，使用单容器单进程的部署方式，以及持续交付，持续集成。

通过尽量自动化的方式去提高效率，快速测试，快速的发现问题，以及下面的服务治理南北东西流量的管理，服务发现呃以及可观性等等。接下来呢，我会我就会从我们实际上云的呃例子中跟大家进行一个分享。嗯，图中展示的呢，是我们的服务目前在CICD方面的体现，呃，目前呢，我们已经实现了全面的版本控制，自动化的一个代码规范校验，单侧覆盖等等，嗯，流水以及这里的流水线全自动的发布和部署。像这样一套，其实已经可以满足大部分业务场景下的可持续性了，但是呢，在刚刚提到的其实还是呃，有一些特殊性存在的。

首先呢，在体下面它的用户状种类非常的多，呃，我在PPT里面列举了一部分，但是这里只是九牛一毛。刚刚提到我们的。呃，状态的获取已经实现了，呃，离线的策略，策略挖掘，嗯，这样的自动化流程让我们的用户数、用户状态增长速度特别快，目前总量已经超过了10万。嗯，一些状态会存在着时效性，就比如说附近有枪声，这种状态它只会短暂的存在几秒钟，嗯，或者是说一一部分的状态它会存在着。联动性，呃，举一个简单的例子，就比如说用户的血量低，嗯，他的背包现在有绷带，用户在使用了绷带之后就会变成了用户状态良好，在真实的情况中还会比这个更加的复杂，在我们的推荐链路里面，召回的结果会强依赖用户的状态，所以说这些微小的变更都都会呃无限的被放大，就有可能会导致我们推荐前后结果会存在互制性，就比如说这里展示的，呃，既让玩家去战斗，又让他苟住，就会存，就会有一些自相矛盾。

以及下面的补充燃料，它的嗯，话术表达的意思其实是一样的。我们需要就是在CICD流程去尽量避免这些问题，他们都严重的影响了用户的体验。但是像大家可以想象一下，像和平这种游戏，它单局的游戏时间特别长，测试的成本特别高，而且这种开放性的模式会导致出现的情况非常的多，人为的测试根本就没有办法就是去覆盖全面，而且对一些已知的问题现也非常的复杂。

这一系列的问题都会导致，呃，我们没有办法去快速验证服务功能的稳定性。对于可持续集成来说。就存在着一个比较重大的隐患。关于相当用户状态的变更快，并且存在关联性的问题，我们提出了重放，嗯，就是把我们的对局通过文本的形式去做一个重放，并且呃支持结果的一个对比。PPT中目前展示的页面效果，呃，我们会用红色去标注，呃删除绿色表示状态的新增第一个图，这里展示的是多版本之间的一个对比，呃，我们可以比较明显的看出来，这两个版本之间，呃，在同一个对局，同一个时刻，它是否会有一些状态的差异。第二个图的话，就是在单局呃，玩家前后的一个状态可视化展示，我们就可以直观的看出他状态的一个变化。

呃，我们会呃，定期的去获取一些离线的对局，并且。就是放在管理端上给大家进行一个重放，呃，并且从代码的层面去保证了重放功能的正确性，一致性和密等性这些操作简单的页面，然后以及我们提供了查询的功能，多环境多版本的历史数据都支持重放，并且也支持数据的保存，在这些都实现了之后，测试的同测试同学的测试效率有了一个极大的提升，像之前20分钟一局的游戏，在平台内十秒内就可以重放完成呃，并且可以非常直观的看出状态在局内之间的变化，而且也可以呃看到多版本之间的差异性。除此之外呢，我们还将这个功能集成到了流水线上，嗯，去实现一个自动化的检测，分别在发布之前和发布之后都支持手动的去输入允许变更的用户状态，并且进行大批量的数据重放，在对比之后会得到结论，并且输出到结尾。

这样就可以比较直观的看出版本前后，呃，用户状态的一个变化。可以预知我们的服务发布是否会对线上带来一些影响，并且可以配合前面可视化重放的功能进行一个问题的快速排查。呃，另外呢，关于刚刚提到的策略点的互斥性和相相似性，这里需要依赖到NLP的能力啊，解决的思路其实是一样的，这里就不再细说了。嗯，在部署这些CCD有了保障之后呢，我们服务优雅的启停也是非常重要的。嗯，这里第一点，嗯，由于我们其实po的和服务的可用状态，它的时机并不完全一致，在大部分的情况下，我们的服务还没有办法正常提供功能的时候，Pod就已经running了，这个时候流量输入的话，会给用户带来很差的体验。

然后第二点是在常规情况下，我们的日志上报，监控上报，这些都需要和我们的业务逻辑进行分离，我们这边的话是采用了模式，但是在默认的情况下。大家可以看到右边这里的时序图，它set和主容器的启停顺序其实是没有办法得到保证的。在服务的启动和停止的时候，都有可能会存在一段时间服务会受到呃数据的影响。嗯，最后呢，是关于服务在更新和重启时，如果说直接退出的话后，如果直接退出就会导致我们正在处理的请求被直接丢弃掉，用户就得不到一个正常响应，这些呢都是稳定性差的表现。

关于刚刚提到的呃服务启动的稳定性，我们可以通过就绪检查来保证，这里提供了呃可选择的一些配置的方式，就比如说TCP的端口检查，以及TP请求，或者是说我们自定义命令都是可以的。然后关于和主容器的解停顺序，以及保证服务的优雅退出，这里我们都可以用post和stop来解决。呃，可以看到PPT上它都是支持我们通过自定义的命令去呃操作的。除了可以解决启停的顺序之外，它其实非常灵活，可以帮助我们解决很多业务方面的问题，可操作性是很强的，大家可以根据自己的实际业务场景去进行一个适配。嗯，在配置完成之后，大家可以看一下正常的时序图，我们的生命周期其实应该是比主容器的生命周期更长的。

另外在服务稳定性方面呢，我们还面临着流量洪峰的挑战，在游戏的业务场景下，玩家可能更倾向于在休息的时间去玩游戏，呃，峰值可能会集中在中午的一点，晚上的八点到十点，我们可以看到图中它的流量波动还是比较明显的。但是。嗯，其实不算特别的剧烈，它不会在短时间内进行一个猛涨，呃，右边这里的话是呃，它所需的po数量的一个变化。它和流量的一个变化趋势基本是一致的。但是对比我们的新月这种福利平台来说，呃，游戏礼包通常都会在每天固定的时间去刷新，比如说每天的零点或者是说十点，大量的用户呢，都会在这同一时间去进入APP。

流量会在短时间内翻倍，然后其他的时间的话，流量都会趋于一个平缓。这里呃，可以看到它所需的po的数量也是呃同步的一个增加的，像这种业务场景，对于传统的运维方式来说，保证服务稳定性的风险是很大的，嗯，以前的话，我们就只能通过人力或者是说资源的牺牲来换取一些稳定性，但是这样其实并不能完全的保证。在服务上，云之后呢，HP所提供的自动扩容以及定时的扩能力完美的解决了我们的问题，但是在使用的方式上面还是有一些需要注意的地方。首先第一条是建议大家根据业务合理的去配置期望指标值以及容忍度，去避免我们的扩缩容，嗯，会存在一个抖动。

这里。是一个配置的页面展示，除了容忍度之外，还有一些其他的配置，这里我们主要聊一下容忍度，默认情况下容忍度的值是0.1，嗯，这就意味着它指标允许的波动范围是当前指标是0.9到当前指标乘0.1，嗯，这样描述可能会不太清晰，所以我画了一个图。嗯，这里展示的可能是一个bad case，横坐标表示的是时间，纵坐标表示的是指标，就比如说我们当前的目标值定义的是50%，如果说呃，容忍值。配置的比较小的话，就会导致这种频繁的扩容出现。这种情况呢，我们就应该去扩大我们的容忍度。呃，就例如下面的这张图，正常情况下只有就是允许它在60%到百分之十四十之间进行一个呃，正常范围内的波动，如果超过的话，就进行一个扩容，呃，如果低于的话，就进行一个缩容，去节约我们的资源。

然后呢，呃，我们还需要去的，这是因为呃hpa在扩缩容计算的时候，它是按照po整体资源占用量进行计算的，通常情况下，由于我们卡所负责的功能会相对简单一些，所以它的资源占用量会比较小。如果不合理的把控主容器和的。资源占比的话，就有可能会导致呃没有办法进行扩容，比如说这里PPT也列举了一个bad case，呃主容器和它都配置了一盒呃容器的占比，呃占用量达到了95%，但是这个时候只占了5%，所以说呃总的CPU指标是50%，如果这个时候我们的配置是呃大于50%才进行一个扩容的。

我们的，呃，自动的HP就不会生效。呃，第三点的话就是建议大家在呃定时HP配置的时候，需要考虑它扩容的一个耗时，呃需要在我们需要的就是呃希望它生效的时间之前一点进行一个配置。这是因为呃，定时的策略，它只会在开始的时刻和结束的时刻去检测我们的实力数量是否满足要求，如果不满足要求就进行扩容，如果嗯，或者是缩容。对，嗯，就比如说我们新月的场景之下，嗯，会有一个正常十点到11点的一个活动，所以说我们会在呃，09:40的时候提前就给他配好。第二点的话就是定时的hpa，呃，它的时间区间配置不能有交集，呃刚刚提到这是一个比较固定的配置，就每天都会生效，那比如说这个时候我们的运营今天会有一个特殊的活动，它的流量会比之前更多，呃，时间是在十点半到十一点半。

后我们直接按照T最终的这样直接去配，呃提前20分钟，然后在十一点半的时候终止，那么其实就会出现问题，呃这一条他在10:10的时候，他会去检测我们的数量，如果不够的话，他会进行一个扩容，扩容然后呃，我们的常规的天任务在11点的时候也会去做一个校验，他会把结呃去判断我们的容量数量满不满足这个结束后的实例数，如果不满足的话，就会去进行一个缩容，这个时候就会导致我们的服务不可用。正常的配置的话，应该是像右边这个图一样。最后呢，是建议大家定时的hpa和自动的hpa去配合使用，因为定时的策略都是我们一般根据人为的历史经验去进行配置的，可能会存在着一些无法预料到的情况，自动的hpa会根据呃实际情况选择最大的po的数量去配置，就比如说刚刚我们不小心配置了交集，在缩之后还可以用自动的HPH做个兜底。

接下来呢，是关于服务发现，目前我们常用的服务发现有北极星和COB2种，北极星是腾讯推出的一个服务发现和治理中心。COB的话，它的全称是cloud load balancer是一个呃，负载均衡器，它更加注重如何让流量分配的更加均衡。PPT中简单的列举了部分他们之间的对比吧，呃，其中呢，因为CB它是通过VIP的，就是虚拟IP的方式去提供的，所以说没有办法直接的获取到下游的实例IP，对于单的问题的排查来说，可能会有一些局限性。

嗯，然后是最后这里。刚刚有提到，在我们的推荐系统下面，我们会需要根据自己的呃，自定义的对局ID去做一个一致性哈希，来保证我们用户状态获取的一个高效性。嗯，据我所知呢，目前COB的管理端是不支持我们去用自定义的可进行执行哈希的，在我们目前的这个场景之下，COB可能会略显有一些不足，但是呃，这里只是列举了一些他们部分的功能，并不是说Co不好的意思，嗯，总的来看的话，还是需要具体的问题具体进行分析的。最后的话聊一下性。我们的服务呢，已经是接入了呃cos日志，并且支持了一个全链路的追踪。嗯，Cos日志接入的便利性以及它强大的功能，就比如说关键字的查询，自定义表盘，这些都给我们的观测性带来了极大的便利。呃，并且我们也接入了监控平台，呃，上报了matrix，然后呃，配置了各种服务的告警，但是在推荐业务下还是会存在着一些可观测性的问题。

就比如说呃，复杂的业务逻辑导致日志数量非常的多，嗯，日志的量级很大，在问题排查的时候，关键信息的获取会受到一定的干扰性，以及这种纯文字的页面，对于我们这种长链的推荐服务来说，呃，长问题其实还是不是特别的直观。嗯，以以及全链路的关键信息指标会非常的多，日志会存在，呃，监控会存在一个泛滥的问题。嗯，在可服观测性方面呢，一些其他额外的定制化，首先是关于刚刚的播报，我们做了一个呃，实时的可视化页面。

像这里展示的一样，我们会在呃页面中去实时的展示用户在对局中的状态，前后对比，红色的表示删除状态，绿色表示新增，然后这里的蓝色表示的是呃触发播报的内容的一个用户状态集合。我们可以在这里看到它可能字比较小，呃，我们的播报内容是什么？然后这里有个动态参数，动态参数会根据呃实时对局去进行一个变化。以及在调链方面，呃，我们根据业务的情况，底层使用ES定义定制化了一个，呃第8LOG的平台，嗯，支持我们通过多种方式去进行一个检索，以及实时的去观察线上的情况。大家可以看到这里有一些可视化的指标，就比如说呃，用户画像的偏好，每个服务的耗时，以及它返回的数量。

呃，这次请求他命中了哪一个召回实验，走了哪个金牌算法，这些呢，都为我们的问题排查提供了非常清晰的方向，嗯，提高了我们的可观测性。最后呢，想说呃，上云的收益是巨大的，大幅度的DVOPS的效率提升，以及我们的资源得到了非常合理的利用，在服务稳定性方面呢，也得到了几乎完美的保证。关于未来呢，我们也还会进行继续的去学习，尝试和创新，就比如说呃，在滴滴滴思想的引导之下，去进行进一步的改造，更加深入的去理解原生，后续可以新增一些。引入一些新的模式，比如说AP之类的。然后到这里我的分享就结束了，现在进入一个QA环节，大家可以扫码进行提问，然后我们的团队同学都在我的旁边，然后大家有什么问题我们会一起帮大家解答。

对，好的谢，感谢李老师的精彩分享，那现在我们进入呃问答环节，然后线上的观众呢，呃，我刚看到也有在直播间直接提问的，然后那个大家也可以扫码，以及我刚我们刚刚在呃直播间发的那个链接，进入那个问答专区提问都可以对。

看到有同学正在写，可能老师要稍等一下。嗯，老师可以切换到那个互动问答专区，现在同学正在那个互动问答专区在写问题。

线上的观众朋友，呃呃，可以在我们的直播间里面提问，也可以，呃，刚刚那个扫码，以及在直播间发的那个链接直接进行提问。呃，请大家尽量在我们的提问链接里面进行提问，因为老师这边，呃，他会统一在这个页面上给大家进行作答。

老师，这边可以看到提问专区的问题了吗？可以，我现在已经投出来了，可以看到吗？还是说对你你可以就是我看第一个问题还在写，就是您可以先把问题出来，然后再回答，因为线上有些朋友他可能不一定能够看到啊，提问专区的这个问题。嗯。第一个问题我看好像还在编辑，那我们我们先有请我们这里的同学来给大家解答一下，第二个问题就是K8S再看启动顺序不稳定，呃，K8S官方他有没有一个解决方案，我们有请我们的团队同学来给大家做一个介绍。

呃，关于这个问题，其实K8S的社区早呃在2016年就有人开始讨论了，但是呢，他们是呃也也有相应的提案，比如说给set增加一些什么lifele的控制，但是这个是这个呃也提了KP，然后叫KP753，有兴趣的同学可以去K8S的社区上去去看一下，但是这个最终被被废弃了，因为呃set启动数据，这个涉及到KS容器的启动顺序，那么就不是一个简单的呃事情了，如果说为set单独去给它进行一个这么一个配置的话，会导致这个配置配置非常特殊，所以KS社区的人认为呃需要呃等于说有一些比较全面的更好的方法去配置，因为他们觉得考虑到呃，比如说有的有的有的服务它的呃初始化容器需要用C卡，那么按我们现在的配置是不可以接受的。

呃，还有很多一些边界条件，呃，而且更重要的是在KS社区看来，用现在的post star跟这两种方式已经可以很好的解决我们大部分遇到的问题，所以他们把这个呃呃，官方对这个问题的呃解决把它置了，还在讨论中，有兴趣同学可以去get上get上参考。大概第二个问题就是这样的。好的，感谢团队的各位同学一起上阵，来来给大家做答疑互动。好的，那那呃，我们第一个问题，呃，李老师看一下他这边是否写已经写的完整了，我看他这个应该是关于刚刚前面那个H的那个。

相关的问题。关于容忍度设置这个问题，我们需要根据每一个服务的呃特性去去处理，比如说我们的服务在CP呃，你先从CPU考虑吧，如果我们的服务CPU使用率在70以下时，它的呃它的服务的稳定性是可靠的，那么我们的我们的服务呃配置的时候就要让容忍度的目标值乘以容忍度小于70。呃，同理。呃，如果说我们的服务CPU使用CPU超过50的时候，就会导致我们的呃响应延迟增大，那么我们我们的配置方法就是需要让容忍呃CPU使用的目标值乘以乘以一加容忍度必须小于50。

呃，这里，呃，这里的提问涉及到是如何尽可能的避免速容慢导致CPU的浪费，那举个例子，如果说我们期望它CPU使用使用小于60的时候就开始缩容，那么我们我们的目标值就是目标值乘以一减容度必须小于60。不错了，一减目标值乘以一键容忍度必须大于60，呃，举个例子吧。假设我们的呃，我们的目标值是CPU使用率目标值60，然后我们希望它能尽快的扩速容，比如说它小于54的时候，就就CPU使用率小于54的时候就缩容，然后让C让这些资源能到能能得到合理的释放，那么就这时候就可以设置为0.1。如果我们希望它CPU小于嗯，57的时候就开始缩容，那么这时候把容忍度改为0.05。

这样就是通过调整容忍度的大小，让它进行快一点或者慢一点的缩容。啊，大概是。这样的，我们的我们这边实验经验是这样的。好，这个第一个问题就是这样。嗯，好的，我们后面还有那个，还有两个问题，老师看一下。嗯，PPT中讲到的HP是用的是腾讯云的H。然后云生高发在游戏中担任什么样的初始角色？是否可以做出人工智能那样的？辅助。7000。嗯，这个问题其实我有一点没太明白是什么意思。嗯，在游戏中担任什么初始角色？

呃，因为这个其实时间也是比较有限的，我看到这位同学刚刚也打字，应该是用手机打的吧，那个刚刚也说了，就是呃，那个呃，李老师，你那边方便再把我们PPT那最后页投一下吗？就是想有更多交流，然后在这边可能问题的描述，包括一些背景没有那么清晰的，那可以进到我们的那个技术交流群，那后续我们可以有更多的一些交流，对，因为现在就是呃，在这个提问版里面呢，大家可能就是每个人的背景也是不一样的，看这些业务的问题的角度也会不同，对，所以所以就说如果希望了解的更清楚，希望有更多深入度的交流的话呢，可以进到我们那个技术交流群，后续再更多的一个，嗯。互动对。好的，那我看到今天那个就是有相关问题的同学都已经在问了啊，我们的时间也差不多了，对，所以那我们今天的那个互动问答环节就暂时先到这里了，对，呃。

呃，刚刚那个就是在我们直播间有抽参与抽奖的同学啊，记得要呃留下你的联系方式，然后包括刚刚参与我们互动问答的那个同学也是一样的，那个我们今天送出的礼品是最。虎年大吉的公仔对，他的帽子都还可以摘下来的，就是很惊喜的，精美的礼品啊，大家不要错过，要记得留下你们的那个呃微信号对加我们的小助手，然后再会联系工作人员会联系你给你发进行发放，这个为什么放不出来？对对对，你现在可以看的清楚了。好的。呃，那今天我们的分享就到这里了，感谢李老师今晚的精彩分享，也感谢线上的观众朋友全程的一起观看，那来不及观看或者是呃，错过本次直播的朋友也不用遗憾，我们每一次的直播呢，那都是会有回放沉淀的，你可以进到我们的视频号，以及相关我们在腾讯云官方的医院，深圳发生的那个专区都可以去，嗯，观看我们所有的回放链接。

好的，那我们今天的云生正发生直播节目就到这里了，感谢大家，我们下一期再见。拜拜。