关于Flink:腾讯游戏实时计算应用平台建设实践

本文由腾讯游戏增值服务部数据中心许振文分享，次要介绍腾讯游戏实时计算利用平台的建设实际。内容包含：

1. 建设背景
2. 对立实时大数据开发 OneData
3. 对立大数据接口服务 OneFun
4. 数据服务微服务化 & ServiceMesh 治理

一、建设背景

首先介绍一下相干背景，很早之前咱们就开始做游戏开发游戏经营，尤其是在五六年前开发过程还是比拟苦楚的。很多玩家心愿玩了游戏之后立马能失去处分，这其实是实时数据营销利用和离线数据营销利用的区别之一。

游戏是一个即时刺激反馈的我的项目，离线数据经营的痛点包含：提早大，体验差，反馈慢。而通过实时数据经营，能够进步用户体验，减少游戏支出，解决离线指标经营痛点，经营干涉越及时，成果越好。

下图是基于咱们数据利用平台衍生进去的一个数据服务工作零碎。很多时候有一个比拟好的工作引擎去驱动一件事件，事件的后果会向一个比拟好的方向去倒退。比方游戏内的工作零碎，玩家有工作能够支付，有处分和反馈，这是游戏中很相熟的场景。

另外一个是排行榜，也是一种刺激性的措施，是对大家致力、后劲或者是能力的一种认可。这种场景十分常见，在游戏外面咱们用的也十分多。这是一个典型的游戏的经营场景，当然这个背地缺离不了数据，尤其缺离不了实时数据。

以下是咱们数据平台演变的过程。

最开始是手工作坊式开发，咱们在接到游戏的数据营销流动开发时，去剖析需要、数据接入、逻辑编码开发、资源申请、公布验证交付，接口开发测试，线上监控，资源回收。这种开发过程门槛高，老本高，效率低，而且数据复用性差，易出错，不易积淀零碎。所以肯定要往平台方向去走。

但同时也须要具备肯定的前提，首先是数据的标准化和数据字典对立。咱们在 10 年到 15 年基本上实现了游戏数据标准化的过程，包含标准化的接入和标准化的字段映射。在此之上，咱们有对立的游戏数据服务，包含数据计算和接口服务。我明天讲的次要就是这一部分，而后在下面可能去撑持各种各样的业务。所以咱们的最终目标也是可能建设一个一站式的开发环境，开发者只关注如何实现逻辑即可，其余联调、运维公布、线上经营保障都由平台提供配置化解决方案。

咱们的开发思路次要有三点。

1. 第一点是规范化。流程标准，数据开发标准和开发框架。
2. 第二点是自动化，包含资源分配，公布上线，监控部署。
3. 第三点是一体化。从数据开发到数据接口开发，到测试公布和运维监控，要一站式实现。

所以咱们形象进去两个外围的服务，一个是数据服务，一个是对立的接口服务开发。因为在我的思考当中，大家做数据给谁去用，用什么样的形式提供数据给大家用，我认为最好的形式是 API 的形式，所有的实时数据可能以 API 的形式提供进来，在数据利用的被动、被动场景之下都能够笼罩到。另外，在这两种场景下必须有一个流程零碎来协调它。

以上是次要的思路，为各种数据利用场景提供一站式的数据开发和利用解决服务，对立流动治理、数据指标计算开发治理和各种数据利用接口自动化生产治理的一站式服务。

二、对立实时大数据开发 OneData

首先来看一下游戏数据的链路。数据产生之后，咱们会有一个 data server，而后会把数据传输到音讯队列，音讯队列当初次要是 Kafka，Pulsar 也在逐渐跟上。再到计算层，而后在贮存局部去做一个隔离。再到数据 API 这一层，计算的数据可能间接对外产生场景化的利用。这应该也是大家很多场景当中会想到的一种思路。然而咱们把整个过程都能串起来，在一个站点外面就能实现实现，不须要在多个站点外面跳来跳去，会大大降低技术栈的门槛。

首先是大数据这一块。原来用 C++, Java 去生产 Kafka 音讯队列，然而当初比拟少了。咱们当初从编译测试到提交公布的过程要做到三点，

• 第一个是指标配置 SQL 化。因为 SQL 化对很多产品人员来说门槛是比拟低的，然而咱们比 SQL 化还要更低，即图形化的 SQL。大家只有选哪张表，哪些字段，计算条件，聚合维度是什么就能够了。明确通知你要填的就是这些字段，从这张表外面选出来就能够。这张表其实就是咱们方才说的接进来的 Kafka 表，所以咱们这块就做了两个方面，一方面是反对根本的 SQL，另一方面大家都不须要懂 SQL，你只须要懂这张表，怎么去设计算法就能够了。
• 第二个是在线 WebIDE。udf 这一块其实是很麻烦的，齐全凋谢是不受控的。咱们到目前为止积攒的 udf 函数不到 100 个。如果这 100 个函数官网提供，就不须要去做了。所以咱们提供在线 WebIDE 的形式。
• 第三个就是数据场景化配置，前面具体介绍。

方才说了两个 SQL，一个是 Flink SQL，咱们要原生反对。另外一种就是自研 SQL，它能够图形化的配置，利落拽就能够配置进去，填表单就能够配置进去。除此之外，咱们还提供在线函数的 Jar 包的形式，在这外面咱们要做 SQL 的解析和代码的生成，另外还要做到 JIT 和隔离性，还有日志的对立上报告警。

咱们的一个思路是数据计算必须要服务于场景，必须要可能在某些中央输入。所以咱们在有了外围引擎层之后，下面是产品化服务层。比如说实时统计分析服务，用户抉择这几张表和字段，平台给出统计后果。另外一个就是实时指标计算服务，就是很多特征值的计算。还有通用规定触发服务，比如说用户一登录，咱们立马就要判断弹窗内容是什么，给他送礼包、还是给他举荐一个流动或者工作。再往上是利用零碎层，包含工作零碎，用户实时干涉零碎，等等。

以对上游的 qps 的管制为例，比方上游只能接受 500qps，然而当流动时用户量达到 1000 人，是否仍能依照 500qps 的调用速度，剩下的缓缓调，但保障服务失常运行等，这种场景也须要有一些通用的干涉的用户关心类的服务。

上面介绍一下咱们自研的 SQL。咱们以后用 SQL 解析的形式去做代码的生成，最终生成一串代码，而不是执行一个语法树，因为执行语法树的老本太高。所以咱们通过 SQL 解析进行这样的一些判断。如下图所示，最上面就是判断后果。最终生成了如下一串代码。

这是一个执行过程，自研 SQL 和 Flink SQL 之间的一个比照。

• FlinkSql 适宜的场景：状态值不能太大，最好不要超过 1G。ETL、数据转发等非常适合。
• 自研 Sql 适宜的场景：状态值十分大，超过 10G，甚至 100G，借用三方存储进行状态存储。

举个例子，某个用户最近几天的行为表现，如累计杀人数、对局数等，用户数量上亿。咱们的游戏业务场景须要反对大维度和长累加计算，无论多大的数据量，只有存储介质可能接受得住，采纳自研 SQL 都没问题。

这里提到一个问题，包含两点：

1. 配置的同表 SQL 反复生产数据。
2. 雷同纬度的数据指标每个保留一份节约存储。咱们整个平台有 13,000 多个指标，如果每个指标都要起工作的话，13,000 多个工作的耗费是十分微小的。很多工作计算的是同表同维度的，比如说两个 SQL 语句都是查问的同一张表，而且聚合的维度也雷同。这种状况下其实能够把它们合成一个 SQL 去算，如下图所示。

然而这外面坑也很多，因为一个 SQL 出问题，就全挂了。咱们要做到一个 SQL 出问题，也不要影响其余 SQL。尽管咱们把性能和效率晋升下来，资源也节俭了，然而带来的程序管理上的老本也是十分高的。目前咱们的总指标 13000+，纬度 3200+，理论节俭计算和存储约 60% 以上。

这个是咱们在线的 WebIDE 的做法，无需搭建本地开发环境，在线开发测试，严格的输入输出治理，标准化输出和输入，一站式开发测试公布监控。有两种形式，第一种，咱们有一个 Java 文件裸露进去，这个文件能够批改，但批改的幅度无限，提前用到的库曾经固定了，不能轻易乱加。咱们在零碎上做了一些管制，罕用的一些 udf 或者是用户要去做的一些个性化的开发都能够满足。另外一种就是间接提交 Jar 包了，但须要做一些审核。

上面是一个十分典型的场景，咱们做游戏经营的时候，通过这种渠道去告诉用户，比如说明天有流动你来参加。他登录之后有日志，咱们立马可能感知到。通过 Flink 去做计算，咱们能够定规定，用户是明天第几次登录，或本月累计登录多少次，或者是其余的一些离线的指标、实时的指标。算完之后就能够给用户去做工作零碎举荐之类的事件，这是一个根本的游戏经营的过程。

上面是 Flink 个性的利用。

• 首先是工夫个性：基于事件工夫水印的监控，缩小计算量，进步准确性。
• 另外一个是异步化 IO：进步吞吐量，确保程序性和一致性。

下图是咱们的一些案例介绍。

三、对立大数据接口服务 OneFun

第三局部是游戏数据接口服务。有了后面的铺垫之后，大数据开发的门槛很低了。然而开发数据服务接口的门槛依然很高。有没有一种服务让我可能把数据以 API 的形式提供进来，让他人持续来操作。在通过摸索之后，咱们有这样一种思路，就是函数化的服务。函数化服务是一种构建和部署服务端软件的新形式，是面向部署单个的函数的一种形式。

所以咱们开发了这样一个服务，在这块也是一个相似的核心层，底层是 K8s。执行引擎次要是两种，一种是疾速的规定表达式的判断，还有一些比较复杂的艰难表达式的判断。另外还有一个就是 JavaScript、Golang 的这种函数反对。而后在下面可能造成产品化服务，包含规定接口服务，函数接口服务，函数举荐服务，实时排行服务。

上面是函数引擎的一个执行，目前咱们反对了这 4 种，别离是 Privileged V8，V8，Go VM，Lua VM。而后有对立的接入层，所有的函数片段可能动静加载进来，而后在这外面去执行。

执行的时候咱们通过 Common Library 的一个公共库在这块去做。比如说，数据 redis，http，SQL 等，在公共库我只有实现一遍，其它中央做一个利用就能够间接过去。通过这样的一个执行引擎，咱们的数据指标可能以 API 的形式规范化的提供给用户。

这是函数开发的一个接口。通过函数接口开发，升高启动老本，更快的部署流水线，更快的开发速度，零碎安全性更高，适应微服务架构，主动扩大能力。这块做了之后，咱们把数据到应用层，到用户层的通路买通了。原来咱们的数据都是在后盾计算完了之后放到数据库外面，等着他人来写接口。当初一个人通过图形化的页面去配指标，再通过这种页面形式去配接口，或者写大量的代码，实现一个数据接口服务的开发，就能够上线了。

这是一个 Flink 实时计算和函数服务联合的例子。比方，等级达到 15 级，且一个月之内沉闷天数少于 5 天的用户，赠送皮肤。玩家的登录日志过去之后，Flink 计算的时候要判断等级，再判断登录天数。登录天数是用自研的 SQL 算进去的后果值。满足条件的话进行一个 RPC call，调用的后果须要依附函数服务。

下图为游戏内基于实时数据的社交关系举荐。比如说，活跃期的在线好友举荐，成熟期的在线站队举荐，散失衰退期的好友召回，都会通过离线和实时的形式，以及 API 接口去实现。

以下是咱们整体的一个架构图。底层灰色的局部不是这个平台的一部分。只有下面这一部分是整个平台的内容，包含服务场景，配置管理系统，服务调度零碎。这个平台不关注底层的 Flink 在哪，K8s 在哪，只有有人能提供相似的计算资源即可，但前提是稳固。整体架构就不具体介绍了。

四、数据服务微服务化 & ServiceMesh 治理

目前线上总上线流动 8.5K+，均匀每周新上线 100+。如何保障应用服务撑持公司数百款业务的数据利用，如何疾速复用，灵便开发同时还要稳固服务。

咱们的业务开发场景面临的艰难包含：

1. 功能模块疾速组合。
2. 功能模块各自独立开发迭代。
3. 不同性能依据理论状况独立部署经营。

所以咱们引入了微服务，微服务化带来的便当包含：

1. 开发更加灵便高效。
2. 去中心化效率更高。
3. 能力失去积淀和复用。

下图为咱们针对线上流量的一个治理平台。咱们参考业界比拟驰名的 ServiceMesh 框架，做东西南北流量的管控。在整个体系当中，如果数据 API 开发门槛过低，大量的 API 会很容易生成。然而 API 的应用是否标准、API 平安等是咱们关注的问题。

所以咱们花了很多功夫，心愿把这些平安问题、治理问题解决好。咱们在外部做了这个东西南北流量的管控，构建了这样一个平台专门去做流量的一个管控。

如下所示，货色流量的管控依附咱们的流量治理零碎，一个平台可能反对多个集群。咱们在去年花了差不多半年工夫把多集群的问题解决掉，可能严格控制 data API 的接口容许哪些人拜访，以及容许哪些服务拜访。数据很多时候是高敏感性的，包含一些用户的画像数据，不能存在平安问题。所以咱们基于 istiod 和 K8s 的一些性能，去做货色流量的治理。货色流量次要是集群类的流量。

对于南北向的流量治理，次要是进口流量。比如说，进来的流量个别都须要加密和鉴权，至多要启用简略的 acl 鉴权。所以做了这样一个管控的形式，把各种信息可能更快的下发到数据面，可能在数据面这块去做一些鉴权，还有一些告警日志追踪。

另外，在线服务很容易呈现一些问题，在咱们预知的流量稳定或者未知的流量稳定的状况之下，如何晓得上游的服务应该做多大量的扩容。在咱们上线的时候常常会呈现这样的问题，上线了忽然来一波流量，须要扩容但后果咱们只扩了一个服务，其余服务没扩，或者是漏掉了一些服务。这种状况下漏掉的服务必定会成为整个服务的一个瓶颈点。

所以咱们用 ServiceMesh 的技术来做全链路流量的剖析。全链路前端通过上报数据，主动生成 DAG 图形展现，通过压测后，将链路数据生成快照，通过工夫点比照，能够疾速的剖析出各个模块的流量放大与瓶颈点。如此，咱们就晓得了入口如果要扩容一倍，或者减少一台机器的时候，相应的服务是否须要扩容，以及须要减少多少。在测试了这个性能，包含可察看性、安全性当前，咱们认为这块还是十分有必要去做的。

以下是外部的一些案例介绍。整个游戏板块都是基于咱们的实时加离线的数据，包含当初所有的 170 多款游戏，比拟沉闷的游戏外面中还会波及营销流动，缺了数据玩不转，缺了咱们的平台，缺了咱们的试验数据也玩不转。