王者荣耀背后的实时大数据平台用了什么黑科技？

你们好我是许振文，今天分享的主题是《基于 Flink+ServiceMesh 的腾讯游戏大数据服务应用实践》，内容主要分为如下四个部分：

1. 背景和解决框架介绍
2. 实时大数据计算 OneData
3. 数据接口服务 OneFun
4. 微服务化& ServiceMesh

1、背景和解决框架介绍

一、离线数据运营和实时数据运营

首先介绍下背景，咱们作游戏数据运营的时间是比较久的了，在 13 年的时候就已经在作游戏离线数据分析，而且能把数据运用到游戏的运营活动中去。

但那时候的数据有一个缺陷，就是大部分都是离线数据，好比今天产生的数据咱们算完后，次日才会把这个数据推到线上。因此数据的实时性，和对游戏用户的实时干预、实时运营效果就会很是很差。尤为是好比我今天中的奖，明天才能拿到礼包，这点是玩家很不爽的。

如今提倡的是：“我看到的就是我想要的”或者“我想要的我立马就要”，因此咱们从 16 年开始，整个游戏数据逐渐从离线运营转到实时运营，但同时咱们在作的过程当中，离线数据确定少不了，由于离线的一些计算、累计值、数据校准都是很是有价值的。

实时方面主要是补足咱们对游戏运营的体验，好比说在游戏里玩完一局或者作完一个任务后，立马就能获得相应的奖励，或者下一步的玩法指引。对用户来讲，这种及时的刺激和干预，对于他们玩游戏的体验会更好。

其实不仅仅是游戏，其余方面也是同样的，因此咱们在作这套系统的时候，就是离线+实时结合着用，但主要仍是往实时方面去靠拢，将来大数据的方向也是，尽可能会往实时方向去走。

二、应用场景

■ 1）游戏内任务系统

这个场景给你们介绍一下，是游戏内的任务系统，你们都应该看过。好比第一个是吃鸡里的，每日完成几局？分享没有？还有其余一些活动都会作简历，但这种简历咱们如今都是实时的，尤为是须要全盘计算或者分享到其余社区里的。之前咱们在作数据运营的时候，都是任务作完回去计算，次日才会发到奖励，而如今全部任务均可以作到实时干预。

游戏的任务系统是游戏中特别重要的环节，你们不要认为任务系统就是让你们完成任务，收你们钱，其实任务系统给了玩家很好的指引，让玩家在游戏中能够获得更好的游戏体验。

■ 2）实时排行版

还有一个很重要的应用场景就是游戏内的排行榜，好比说王者荣耀里要上星耀、王者，其实都是用排行榜的方式。但咱们这个排行榜可能会更具体一些，好比说是今天的战力排行榜，或者今天的对局排行榜，这些都是全局计算的实时排行榜。并且咱们有快照的功能，好比 0 点 00 分 的时候有一个快照，就能立马给快照里的玩家发奖励。

这些是实时计算的典型应用案例，一个任务系统一个排行榜，其余的咱们后面还会慢慢介绍。

三、游戏对数据的需求

再说一下为何会有这样一个平台，其实咱们最初在作数据运营的时候，是筒仓式或者手工做坊式的开发。当接到一个需求后，咱们会作一个资源的评审、数据接入、大数据的编码，编码和数据开发完后，还要作线上资源的申请、发布、验证，再去开发大数据计算完成后的服务接口，而后再开发页面和线上的系统，这些都完了后再发到线上去，作线上监控，最后会有一个资源回收。

其实这种方式在很早期的时候是没有问题的，那为何说如今不适应了？主要仍是流程太长了。咱们如今对游戏运营的要求很是高，好比说咱们会接入数据挖掘的能力，大数据实时计算完成以后，咱们还要把实时的用户画像，离线画像进行综合，接着推荐给他这我的适合哪些任务，而后指引去完成。

这种状况下，原来的作法门槛就比较高了，每个都要单独去作，并且成本高效率低，在数据的复用性上也比较差，容易出错，并且没有办法沉淀。每个作完以后代码回收就扔到一块，最多下次作的时候，想起来我有这个代码了能够稍微借鉴一下，但这种借鉴基本上也都是一种手工的方式。

因此咱们但愿能有一个平台化的方式，从项目的建立、资源分配、服务开发、在线测试、独立部署、服务上线、线上监控、效果分析、资源回收、项目结项整个综合成一站式的服务。

其实这块咱们是借鉴 DevOps 的思路，就是你的开发和运营应该是一我的就能够独立完成的，有这样一个系统可以去支撑这件事。当一个服务在平台上呈现出来的时候，有可能会复用到计算的数据，比说实时的登陆次数或击杀数，那这个指标在后面的服务中就能够共用。

并且有了这样一个平台以后，开发者只需主要关注他的开发逻辑就好了，其他两条运维发布和线上运营都由平台来保证。因此咱们但愿有一个平台化的方式，把数据计算和接口服务统一块儿来，经过数据的标准化和数据字典的统一，可以造成上面不一样的数据应用，这个是咱们的第一个目标。

其实咱们如今都是这种方式了，第一是要在 DevOps 的指导思想下去作，尤为是腾讯去作的时候数据服务的量是很是大的，好比咱们去年一共作了 五、6 万的营销服务，在这种状况下若是没有平台支撑，没有平台去治理和管理这些服务，单靠人的话成本很是大。

四、思路

3 个现代化，大数据应用的 DevOps。

咱们的思路也是这样，三个现代化，并且把大数据应用的 DevOps 思路实现起来。

• 规范化：流程规范、数据开发规范和开发框架；
• 自动化：资源分配、发布上线、监控部署（这是 DevOps 里不可缺乏的）；
• 一体化：数据开发、数据接口开发、测试发布、运维监控。

因此咱们针对大数据的应用系统，会把它拆成这样三块，一个是大数据的开发，另一个是数据服务接口的开发，固然接口后面就是一些页面和客户端，这些完了后这些开发还要有一个完整的开发流程支持。

这样咱们就可以为各类数据应用场景提供一站式的数据开发及应用解决服务、统一的活动管理、数据指标计算开发管理和各类数据应用接口自动化生产管理的一站式的服务。

这样的系统能保障这些的事情，并且咱们这里也合理拆分，不要把大数据和接口混到一块去，必定要作解耦，这是一个很是关键的地方。

五、数据服务平台总体架构

■ 1）计算存储 

这个框架你们能够看一下，我认为能够借鉴，若是你内部要去作一个数据服务平台的话，基本上思路也是这样的，底层的 Iass 能够不用管，直接用腾讯云或者阿里云或者其余云上的服务就能够了。

咱们主要是作上层这一块的东西，最下面的计算存储这个部分咱们内部在作系统的时候也不是 care 的，这块最好是能承包出去。如今 Iass 发展到这个程度，这些东西在云上能够直接像 MySQL 数据库或者 Redis 数据库同样购买就好了，好比 Kafka、Pulsar、Flink、Storm。

存储这块咱们内部的有 TRedis、TSpider，其实就是 Redis 和 MySQL 的升级版本。基础这块我建议你们若是本身构建的话，也不须要太过于关注。

■ 2）服务调度

系统核心主要是在中间的服务调度这个部分，它是统一的调度 API，就是上层的一些服务能发下来，而后去统一调度。另一个就是流程的开发，咱们有一个不可缺乏的调度系统，这里咱们使用的是 DAG 调度引擎，这样咱们能够把离线任务、实时任务、实时+离线、离线+函数接口的服务可以组合起来，来完成更复杂实时数据应用场景。

好比咱们如今作的实时排行榜，把实时计算任务下发到 Flink 后，同时会给 Flink 下发一个 URL，Flink 拿到 URL 后，它会把符合条件的数据都发送到 URL，这个 URL 其实就是函数服务，这些函数服务把数据，在 Redis 里作排序，最终生成一个排行榜。

再往下的这个调度器，你能够不断地去横向拓展，好比我能够作 Storm 的调度器、Flink 的调度器、Spark 的调度器等等一系列。在这块能够造成本身算法库，这个算法库能够根据场景去作，好比有些是 Flink 的 SQL 的分装，也就是把 SQL 传进来，它就可以计算和封装的 Jar 包。另外好比一些简单的数据出发、规则判断也能够去作，直接把算法库分装到这块就行。

其实这块和业务场景没有直接关系的，但算法库必定是和场景是有关系的，另外下层咱们会有写文件通道，好比说一些 Jar 包的分发，这里腾讯用的是 COS，可以去作一些数据的传输和 Jar 包的提交。

还有一个命令管道，它主要针对机器，好比提交 Flink 任务的时候必定是经过命令管道，而后在一台机器去把 Jar 包拉下来，而后同时把任务提交到 Flink 集群里去。数据管道也是相似的一个做用。

■ 3）各类管理

另外还要将一个蛮重要的内容，右边绿色这块的运营监控、集群管理、系统管理（用户权限管理，业务管理，场景管理，菜单配置管理等等），还有消息中心、帮助文档，这些都是配套的，整个系统不可缺乏的。

还有一部分是组件管理，包括大数据组件管理、函数管理、服务的二进制管理均可以在这里可以作统一的管理。

数据资产，好比咱们经过 Flink 或者 Storm 可以生成的数据指标，它的计算逻辑的管理都在这里面，包括咱们计算出来后，把这些指标打上标签或者划后，咱们也做为数据资产。

还有一个最重要的是数据表的管理，咱们不管是 Flink 或 Storm，它的计算最终的落地点必定是经过一个数据表能算出来的。其余都还好，数据报表，好比天天计算多少数据，成功计算多少，天天有多少任务在跑，新增多少任务，这些都在里面能够作，包括咱们版本的发布变动。还有一个是外部管理端，这个根据业务场景去作就好了，等会演示咱们管理端的时候你们就能够看到，其实咱们的菜单相对来讲比较简单，根据好比咱们的数据接入，从源头把数据接入到 Kafka 或者 Pulsar 里去。而后数据指标基于接入的数据表，进行数据指标的计算，好比一些特性的 Jar 包，它是多张表的数据混合计算，或者是加上的表的混合计算，等等一系列经过硬场景作的一些分装。

咱们最终把这些作完后，全部的大数据都是经过对外的服务 API 暴露出去的，好比最终游戏任务是否完成，用户 ID 过来后咱们能看这个用户的任务是否完成，这样的一些应用场景能够直接使用 API 去操做。

这是整个流程，讲得比较细后面你们才会更清晰。

2、实时大数据计算 OneData

一、数据开发流程

这是咱们总体的数据应用流程：

咱们的 Game Server 先把数据上传到日志 Server（数据接入部分），日志 Server 再把数据转到 Kafka 或者 Pulsar，就是消息队列里。

接进来后是数据表，数据表是描述，基于描述的表去开发指标、数据。好比咱们这里一共有三类，一类是 SQL，另一类是咱们已经分装好的框架，你能够本身去填充它的个性代码，而后就能够在线完成 Flink 程序的编写。

还有一种是本身全新的在本地把代码写好，再发到系统里去调测。以前说了在大数据计算和数据接口必定要作解耦，咱们解耦的方式是存储，存储咱们用 Redis。它这种作法是把 Redis 和 SSD 盘可以结合起来，而后再加上 RockDB，就是 Redis 里面它 hold 热点数据，同时它把这些数据都经过这个 RockDB 落地到 SSD 盘里去，因此它的读写性很是好，就是把整个磁盘做为数据库存储，而不像普通的 Redis 同样再大数据状况下智能把内存做为存储对象。

在大数据把数据计算存储进去后，后面的就简单了，咱们提供查询的服务有两种，一种是计算的指标，点一下就能够生成接口，咱们叫规则接口；而后咱们另一种，也提供特性化的存储到介质里，我能够本身去定义他的 SQL 或者查询方式，而后在数据进行加工处理，生成接口 。

还有一种方式，是咱们在 Flink 和 Storm 直接把数据配置咱们这边的一个函数接口，好比我刚才讲的排行榜的方式，就给一个接口，他直接在 Flink 这边处理完成以后，把数据吐到函数接口里面，函数接口对这个数据进行二次处理。

这个是整个处理方式，因此咱们前面讲的就是，基于 Flink 和 Storm 构建一个全面的、托管的、可配置化的大数据处理服务。主要消费的是 Kafka 的数据，Pulsar 如今在少许的使用。

这样作就是咱们把数据的开发门槛下降，不须要不少人懂 Flink 或者 Storm，他只要会 SQL 或者一些简单的逻辑函数编写，那就能够去完成大数据的开发。

二、数据计算统一

其实咱们以前在作的时候，有一些优化的过程，原来每个计算任务都是用 Jar 包去写，写完以后就是编辑、打包、开发、发布。后来咱们划分了三种场景，一种是 SQL 化，就是一些咱们能用 SQL 表示的咱们就尽可能分装成 SQL，而后有一个 Jar 包能去执行这个提交的 SQL 就能够了。

还有一种是在线的 WebIDE，是处理函数的逻辑，举例子 Storm 里能够把 blot 和 spout 暴露出来，你把这两函数写完后，再把并行度提交就能够运行。但这里咱们具体实现的时候是基于 Flink 去作的。

另外一个是场景化的配置，咱们个性化的 Jar 包可以统一调度，根据调度逻辑去执行。

三、数据计算服务体系

这是咱们整个 OneData 计算体系的过程，支持三种，一种的自研的 SQL，一种是 Flink SQL，还有是 Jar 包。

咱们自研的 SQL 是怎么存储，最先是使用 Storm，但 StormSQL 的效率很是低，因此咱们根据 SQL Parser 作的 SQL 的分装，咱们对 SQL 本身进行解析，本身造成函数，在 SQL 提交以后，咱们用这样的方式直接把它编译成 Java 的字节码，再把字节码扔到 Storm 里去计算。

Flink 这块咱们也继承了这种方式，后面会讲一下两种方式有什么区别。其实咱们自研 SQL 在灵活性上比 Flink SQL 要好一点。

这里是作平台化，不能说直接放一个 FlinkSQL 去跑，由于咱们想要在里面统计整个业务逻辑的执行状况，好比 SQL 处理的数据量，正确的和错误的，包括一些衰减，都是要作统计。

这是基本的过程，完了后咱们在上面造成的一些基本场景，好比实时统计的场景，PV，UV，用独立的 Jar 包去算就好了，配置一下表就能够去计算。另外实时指标的服务，好比杀人书，金币的积累数，游戏的场次，王者荣耀里下路走的次数，这种数据均可以做为实时指标。

还有一种是规则触发服务，表里的某个数据知足什么条件时，触发一个接口。还有通信实时排行榜和一些定制化的服务。

■ 1）自研 SQL

接下来讲咱们自研 SQL 的过程，咱们早期为了不像 Hive 同样（函数栈调用），而咱们本身经过 SQL Paser 的语法抽象后，把它生成一段函数，就不须要这么多的对帐调用。

这个是函数生成过程，最终生成的就是这样一段代码，它去作计算逻辑，一个函数完成，不须要函数栈的调用，这样效率就会大大提高。咱们原来单核跑八万，放在如今能够跑二十多万。

整个处理的时候，咱们把 SQL 编译成字节码，Flink 消费了数据后，把数据转化成 SQL 可以执行的函数，就是 roll 的方式。而后把 Roll 整个数据传到 class 里去执行，最后输出。

这种场景适合于，好比 FlinkSQL 它有状态值，咱们要统计某个最大值的话，要一直把用户的最大值 hold 到内存里去。而咱们自研的 SQL 呢，本身写的函数，它把数据借助第三方存储，好比刚才说的 TRedis 存储。每次只须要读取和写入数据便可，不须要作过多的内存的 hold。

当前作到状态的实时落地，就算挂掉也能立马起来接着去执行，因此超过 10G、100G 的数据计算，都不成问题，可是 FlinkSQL 若是要算的话，它的状态值就一直要 hould 到内存里去了，并且挂掉后只能用它的 check point 去恢复。

因此这是这两种 SQL 的应用场景。

■ 2）SQL 化

另外 SQL 里咱们还能够作些其余的事情。咱们的数据是持久化保存在存储里的，那存储里若是是同一张表，同一个纬度，好比咱们都是用 QQ，在这个纬度上咱们配置了两个指标，那能不能一次算完？只消费一次把数据算完，而后存储一次。

其实这种在大数据计算里是不少的，目前在咱们在作的平台化就能够，好比一个是计算登陆次数，另外一个是计算最高等级，这两个计算逻辑不同，可是消费的数据表是同样的，而后聚合纬度也是同样的，聚合关键字也是同样。那这个数据就能够进行一次消费，同时把数据计算出来同时去落地，大大减小了存储和计算成本。

咱们如今整个游戏里面有一万一千多个指标，就是计算出来的，存储的纬度有两千六百多，实际节省计算和存储约有 60%以上。

两个 SQL，甚至更多的 SQL，咱们一张表算十几个指标很正常，原来要消费十几回如今只须要一次就能够算出来。并且这种状况对用户是无感知的。A 用户在这张表上配了指标是 A 纬度，B 用户在这张表上配了指标也是 A 纬度，那这两个用户的数据，咱们在底层计算的时候就消费一次计算两次存储一次，最终拿到的数据也是同样的。

**■ 3）在线实时编程

**

• 无需搭建本地开发环境；
• 在线开发测试；
• 严格的输入输出管理；
• 标准化输入和输出；
• 一站式开发测试发布监控。

再介绍下刚才提到的在线实时编程，其实不少时候对开发者来讲，搭建一个本地的 Flink 集群作开发调测也是很是麻烦的，因此咱们如今就是提供一种测试环境，上层的代码都是固定的，不能修改。好比数据已经消费过来了，进行数据的加工处理，最终往存储里去塞就能够了。

经过这种方式，咱们能够对简单逻辑进行分装，须要函数代码，但比 SQL 复杂，比自动的 Jar 包开发要简单一些，能够在线写代码，写完代码直接提交和测试就能完成结果的输出。并且这种的好处是，数据的上报逻辑，数据的统计逻辑，我都在这里面分装好了。只要管业务逻辑的开发就行了。

四、Flink 特性应用

• 时间特性：基于事件时间水印的监控，减小计算量，提升准确性；
• 异步化 IO：提升吞吐量，确保顺序性和一致性。

咱们最先在 Storm 里作的时候，数据产生的时间和数据进到消息队列的时间，都是经过这种消息里自带的时间戳，每个消息都是要对比的。有了 Flink 以后，有了 watermark 这个机制以后，这一部分的计算就能够减小了。

实际测试下来的效果也是比较理想的，咱们原来在 Storm 里单核计算，大概是之前的 QPS，加上读写和处理性能，单核五个线程的状况下。可是 Flink 的时候咱们能够到一万，还加上 Redis 存储 IO 的开销。

另外一个咱们原来数据想要从 Redis 里取出来，再去算最大值最小值，完了算了再写到 Redis 里，这个都是同步去写的，可是同步 IO 有一个问题就是性能不高。因此咱们如今在把它改为异步 IO，可是异步 IO 也有个特色就是整个一条数据的处理必须是同步的，必须先从 Redis 里把数据取出来，而后再把值计算完，再塞到里面去，保证塞完后再处理下一个统一的数据。

咱们再作这样的一些优化。Flink 这里有些特性能够保证咱们数据的一致性，并且提高效率。

五、统一大数据开发服务—服务案例

接着介绍下更多的案例，若是你们玩英雄联盟的话，那这个任务系统就是咱们设计的，下次玩作这个任务的时候，你就能够想起我。还有天龙八部、CF、王者荣耀 LBS 荣耀战区（经过大数据实时计算+LBS 的数据排行）、王者荣耀的平常活动（实时数据+接口+规则计算）、有哪些好友是实时在线的，跟你匹配的。

3、数据接口服务 OneFun

一、数据应用的出口

下面介绍下函数，咱们原来在作的时候也是存在着一些问题，把数据存到存储里面，若是存储直接开放出去，让别人任意去使用的话，其实对存储的压力和管理程度都是颇有问题的。因此后来咱们采用了一种相似于 Fass 的的解决方式。咱们把存储在里面的元数据进行管理，完了以后接口再配置化的方式，你要使用我这个 DB，这个 DB 最大 QPS 多少，我就进行对比，容许你以后才能使用这个量。

好比我这个 DB 的最大 QPS 只有 10 万，你要申请 11 万，那我就给你申请不了，我就只能通知 DB 把这个 Redis 进行扩容，扩容后才给你提供使用。因此这里面牵扯到咱们的指标数据的元数据管理和接口之间的打通。

二、一体化函数执行引擎—OneFun

这个和刚才 OneData 的方式是同样的，好比这块提供了快速的函数，还有一些在线函数编程的方式的接口，你能够在上面写一点 JavaScript 或者 Golang 代码，而后就生成接口，接口里面能够直接对外提供服务，把他造成产品化的包装，在上层根据接口衍生出更多其余的一些应用系统。

三、基于 ssa 的在线 Golang 函数执行引擎

这里重点介绍下 Golang，其实咱们是基于 Golang 语言自己 ssa 的特色去作的，咱们有一个执行器，这个执行器已经写好的，它的做用就是能够把你写的 Golang 代码提交过来，加载到它的执行器里。

而且咱们能够把咱们写的代码做为函数库，积累下来而后放进去，它能够在执行的时候去调用这些函数库，而这里面写的代码语法和 Golang 是彻底同样的。

同时咱们在这里面执行的时候，指定了一个协程，每个协程咱们规定它的做用域，就是以沙箱机制的方式来去执行，最早实现的就是外部 context 去实现的，咱们就能够实现 Web 化的 Golang 开发，这种有点像 Lua 那种脚本语言同样，你在线写完语言直接提交执行。

四、基于 V8 引擎的在线函数服务引擎

这是咱们的 Javascript 的执行引擎，咱们主要是作了 V8 引擎的池子，全部 Javascript 写完以后，丢到 V8 引擎上去执行，这应该你们都可以理解，若是你们玩过 JS 的能够理解这种方式，就是 V8 引擎里直接去执行。

五、一体化函数执行引擎--函数即服务

这是咱们的在线函数编写过程：

右下角是咱们的函数代码编写区，写完后左边的黑框是点击测试，输出能够在这里写，点击测试就会把结果输出出来，经过这种方式，咱们极大地扩张了咱们数据平台的开发能力。原来是本地要把 Golang 代码写完，而后调试完再发到线上环境去测试，而如今咱们能够很大的规范化，好比说数据源的引入，咱们就直接能够在这里去规定了，你只能引入申请过的数据源，你不能随便乱引入数据源，包括你数据源引入的时候，QPS 放大我均可以经过这种方式知道。

• 下降启动成本；
• 更快的部署流水线；
• 更快的开发速度；
• 系统安全性更高；
• 适应微服务架构；
• 自动扩展能力。

这个是咱们一站式，把函数开发完后，直接提交，咱们用 Prometheus + Grafana 能够里面看到实时报表。

六、案例介绍

这是一个典型的应用，Flink 里面去计算的时候，他对这个数据进行过滤，完了以后进行一个远程的 call，这个远程调用执行函数代码，大多数这种状况就是一个开发就能够完成大数据的开发和这个函数接口的开发，就能够完成这样一个活动的开发，整个活动开发的门槛就低了不少，真正实现了咱们 DevOps，就是开发可以把整个流程本身走完。

4、微服务化 & ServiceMesh

一、数据应用必走之路—微服务化

上面讲的是 OneData 和 OneFun 的实现原理和机制，咱们在内部是怎么去应用的，这套系统咱们在游戏内部是大力推广。

这里尤为是接口这块，其实若是说要微服务化的话，大数据咱们能作的也就是那样了，可以用 yarn 或者 K8S 去作资源的管控，和任务的管控，但真正去作服务治理仍是在接口这块。目前咱们上下接口大概是三千五百个，每周新增 50 个接口。

因此咱们在作的时候也考虑到。原来咱们服务是一个个开发，可是没有治理，如今咱们加上服务仍是一个个去开发，甚至有些服务咱们会把它变成一个服务，可是咱们加入了这个服务的治理。

好多人在提微服务，微服务若是没有一个平台去治理的话，将会是一种灾难。因此微服务化给咱们带来便利的同时，也会给咱们带来一些问题，因此在咱们的场景里面，微服务是很是好的，每个接口就能够做为一个服务，这种是自然的微服务。

二、一体化服务治理设计

可是这种微服务的治理将会是咱们很大的一个问题，因此咱们花了很大的精力去作了一个微服务的治理系统，从项目注册的时候，他就把项目注册的微服务中心，而且把 API 注册上来，而后在服务发布的时候，发到集群里的时候，这些服务都要主动的注册到咱们的名册服务，就是 Consoul。

但注册到服务里不是做为服务路由来用的，而是到服务里后，咱们在普罗米修斯这块去作它的健康检查和状态采集，只要注册上来，我立马就能感知和把状态采集过来，而后主要作实时报表和告警。

首先在服务的稳定性和健康度这块咱们有一个保障，另一个就是服务的信息注册到 Consul 里去后，咱们有一个服务的网关，咱们用的是 envoy，其实内部咱们还把它做为 SideCar 使用，后面会介绍。

注册完了以后，envoy 会把这个全部的负载进信息加载到这块来，它去作它服务的路由，同时咱们会把整个日志上报到日志中心去，包括网关的日志也会上传到日志中心去，日志中心再去作离线的报表和实时的一些报警监控。

因此这里面咱们还加了一个基于 Consul 的一个配置，就是咱们包括 server 的实时控制均可以经过 Consul 去配置，配置完了后立马可以 watch 到，而后去执行。

这个是基本的服务治理，但如今咱们的服务治理升级了，比这个要更好一点，基本的原理是这样。

三、南北流量+东西流量的统一管控

而且咱们在这里面实现了一个对 envoy 的管控，咱们说是服务治理，主要是对流量的一些治理，好比贫富负载策略，路由策略，熔断，超时控制，故障注入等等一系列。

咱们是经过 Consul 的配置管理，经过它可以下发到咱们的 Agent，这个 Agent 再把这个数据可以经过 Istio 的接口和 K8s 的 API 可以下发到 envoy，这里面就是 API GeteWay 和 SideCar 都是 envoy，因此咱们经过 Istio 对他的 XDS 的接口写入，就能够把全部的配置信息下发到这里。

这套系统可以整个去管控整个集群，南北流量和东西流量的统一管控。这套系统咱们将来准备开源，如今主要是内部在使用，并且这里面咱们也作了图形化的配置，全部 envoy 和 Istio 的配置咱们都通过 YAML 转 Istio 再转 UI 的方式，把它图形化了，在这块可以作统一的管控。

并且咱们把 Agent 开发完了以后就是多集群的支持，就是多个 K8s 集群只要加入进来，没问题能够去支持，咱们管理 API GeteWay。

还有一块是 SideCar 的管理，就是 ServiceMash 里的 SideCar 管理。咱们刚才说的函数接口也好，规则接口也好，是一个 server。

固然这里面还提到一个 chaos mesh 的功能，咱们如今还在研究，咱们准备在这套系统里把它实现了。

四、基于 ServiceMesh 的全链路流量分析

这是一个咱们经过 ServiceMesh 作的分析，咱们虽然能够宏观地看出来咱们接口对 DB 的压力有多大，但实际上咱们把流量导进来是咱们对压力的监控是不够的，因此这种状况咱们经过 ServiceMesh，他对出口流量和进口流量的管控，而后能够把流量进行详细的统计，统计完后能够生成一个快照，此次快照和下次快照之间的数据对比，入流量有多少的时候，对下面各个流量压力有多少。

这是整个展现图，咱们有多个测试用例，这两个测试用例之间咱们能够算出来对下游的压力的流量分析，后期对下游压力的分析和下游资源的扩容、缩容都有很是大的价值。

五、案例介绍

最后再介绍下咱们目前用这套系统实现的一些案例，大数据的游戏回归，好比作一个游戏数据的回顾 （生涯回顾）、任务系统、排行榜。

Q & A

Q1：ServiceMesh 是怎么部署的？主要用来解决什么问题？

目前咱们在使用的 ServiceMesh 技术实现是 Istio，版本是 1.3.6。这个版本还不支持物理机方式部署，因此咱们是在 K8s 中部署使用，部署方式有 2 种，能够是直接使用 istioctl 命令安装，或者是生成 Yaml 文件后使用 kubectl 进行安装。

Servicemesh 的架构主要解决的问题是集群内东西流量的治理问题。同时 Servicemesh 的 Sidercar 做为协议代理服务和能够屏蔽后面的服务开发技术栈， Sidercar 后面的服务能够是各类语言开发，可是流量的管理和路由能够有统一的管控。

Q2：微服务治理架构能介绍一下吗？

微服务治理架构在我看来能够分为两类：

• 服务实例的治理，这个在目前的 K8s 架构下，基本都是由 K8s 来管理了，包含了服务实例的发布，升级，阔所容，服务注册发现等等；
• 服务流量的治理，这一个你们一般说的服务治理，目前主要是由微服务网关和服务网格两种技术来实现。服务网关实现集群内和集群外的流量治理，服务网格实现了集群内的流量治理。

Q3：开发人员主要具备什么样的技术背景？

针对大数据开发人员，要使用咱们这套系统只须要会 SQL 语句和基本统计知识就能够了。

针对应用接口开发人员，要使用咱们这套系统只须要会 JavaScript 或者 Golang，会基本的正则表达式，了解 HTTP 协议，会调试 HTTP 的 API 接口就能够了。

Q4：实时计算，Flink 与 Spark 选择上有没啥建议？

Spark 在 15，16 年的时候咱们也在大规模使用，也在实时计算中使用过，可是当时的版本在实时计算上仍是比较弱，在 500ms 的批处理中仍是会出现数据堆积，因此在实时性上会有必定的问题，Spark 擅长在数据迭代计算和算法计算中。可是若是实时性要求不高并且有算法要求的场景中 Spark 仍是不错的选择。

Flink 在设计之初就是一种流失处理模型，因此在针对实时性要求较高的场景中 Flink 仍是比较合适的，在咱们内部测试发现 Flink 的流失计算吞吐确实要比 Storm 好不少，比 Spark 也是好不少，并且 Flink 目前的窗口机制针对实时计算中的窗口计算很是好用。因此通常实时计算或者对实时性要求较高的场景 Flink 仍是比较推荐的。

Q5：游戏回放数据服务端存储场景有么？

这种场景也是有的，游戏回放通常有 2 种方式，一种是录屏传输回放，这种成本很是高，可是简单且及时性比较好，另一种是控制指令发回 Server，在另外的服务中去恢复当时的场景，这种方式在成本相对较小，可是使用复杂。

Q6：回放场景下客户端走什么协议将数据发送到服务端？

通常是游戏的私有协议。