大家好我是许振文，明天分享的主题是《基于 Flink+ServiceMesh 的腾讯游戏大数据服务利用实际》，内容次要分为以下四个局部：

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

一、背景和解决框架介绍

1、离线数据经营和实时数据经营

首先介绍下背景，咱们做游戏数据经营的工夫是比拟久的了，在 13 年的时候就曾经在做游戏离线数据分析，并且能把数据使用到游戏的经营流动中去。

但那时候的数据有一个缺点，就是大部分都是离线数据，比方明天产生的数据咱们算完后，第二天才会把这个数据推到线上。所以数据的实时性，和对游戏用户的实时干涉、实时经营成果就会十分不好。尤其是比方我明天中的奖，今天能力拿到礼包，这点是玩家很不爽的。

当初提倡的是：“我看到的就是我想要的”或者“我想要的我立马就要”，所以咱们从 16 年开始，整个游戏数据逐步从离线经营转到实时经营，但同时咱们在做的过程中，离线数据必定少不了，因为离线的一些计算、累计值、数据校准都是十分有价值的。

实时方面次要是补足咱们对游戏经营的体验，比如说在游戏里玩完一局或者做完一个工作后，立马就能失去相应的处分，或者下一步的玩法指引。对用户来说，这种及时的刺激和干涉，对于他们玩游戏的体验会更好。

其实不单单是游戏，其余方面也是一样的，所以咱们在做这套零碎的时候，就是离线 + 实时联合着用，但次要还是往实时方面去聚拢，将来大数据的方向也是，尽量会往实时方向去走。

2、利用场景

■ 1）游戏内工作零碎

这个场景给大家介绍一下，是游戏内的工作零碎，大家都应该看过。比方第一个是吃鸡里的，每日实现几局？分享没有？还有其余一些流动都会做简历，但这种简历咱们当初都是实时的，尤其是须要全盘计算或者分享到其余社区里的。以前咱们在做数据经营的时候，都是工作做完回去计算，第二天才会发到处分，而当初所有工作都能够做到实时干涉。

游戏的工作零碎是游戏中特地重要的环节，大家不要认为工作零碎就是让大家实现工作，收大家钱，其实工作零碎给了玩家很好的指引，让玩家在游戏中能够失去更好的游戏体验。

■ 2）实时排行版

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

这些是实时计算的典型利用案例，一个工作零碎一个排行榜，其余的咱们前面还会缓缓介绍。

3、游戏对数据的需要

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

其实这种形式在很晚期的时候是没有问题的，那为什么说当初不适应了？次要还是流程太长了。咱们当初对游戏经营的要求十分高，比如说咱们会接入数据挖掘的能力，大数据实时计算实现之后，咱们还要把实时的用户画像，离线画像进行综合，接着举荐给他这个人适宜哪些工作，而后指引去实现。

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

所以咱们心愿能有一个平台化的形式，从我的项目的创立、资源分配、服务开发、在线测试、独立部署、服务上线、线上监控、成果剖析、资源回收、我的项目结项整个综合成一站式的服务。

其实这块咱们是借鉴 DevOps 的思路，就是你的开发和经营应该是一个人就能够独立实现的，有这样一个零碎可能去撑持这件事。当一个服务在平台上出现进去的时候，有可能会复用到计算的数据，比说实时的登录次数或击杀数，那这个指标在前面的服务中就能够共用。

而且有了这样一个平台之后，开发者只需次要关注他的开发逻辑就行了，其余两条运维公布和线上经营都由平台来保障。所以咱们心愿有一个平台化的形式，把数据计算和接口服务对立起来，通过数据的标准化和数据字典的对立，可能造成下面不同的数据利用，这个是咱们的第一个指标。

其实咱们当初都是这种形式了，第一是要在 DevOps 的指导思想上来做，尤其是腾讯去做的时候数据服务的量是十分大的，比方咱们去年一共做了 5、6 万的营销服务，在这种状况下如果没有平台撑持，没有平台去治理和治理这些服务，单靠人的话老本十分大。

4、思路

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

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

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

所以咱们针对大数据的利用零碎，会把它拆成这样三块，一个是大数据的开发，另外一个是数据服务接口的开发，当然接口前面就是一些页面和客户端，这些完了后这些开发还要有一个残缺的开发流程反对。

这样咱们就可能为各种数据利用场景提供一站式的数据开发及利用解决服务、对立的流动治理、数据指标计算开发治理和各种数据利用接口自动化生产治理的一站式的服务。

这样的零碎能保障这些的事件，而且咱们这里也正当拆分，不要把大数据和接口混到一块去，肯定要做解耦，这是一个十分要害的中央。

5、数据服务平台整体架构

■ 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 去操作。

这是整个流程，讲得比拟细前面大家才会更清晰。

二、实时大数据计算 OneData

1、数据开发流程

这是咱们整体的数据利用流程：

咱们的 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 或者一些简略的逻辑函数编写，那就能够去实现大数据的开发。

2、数据计算对立

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

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

另一个是场景化的配置，咱们个性化的 Jar 包可能对立调度，依据调度逻辑去执行。

3、数据计算服务体系

这是咱们整个 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 包开发要简略一些，能够在线写代码，写完代码间接提交和测试就能实现后果的输入。而且这种的益处是，数据的上报逻辑，数据的统计逻辑，我都在这外面分装好了。只有管业务逻辑的开发就好了。

4、Flink 个性利用

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

咱们最早在 Storm 里做的时候，数据产生的工夫和数据进到音讯队列的工夫，都是通过这种音讯里自带的工夫戳，每一个音讯都是要比照的。有了 Flink 之后，有了 watermark 这个机制之后，这一部分的计算就能够缩小了。

理论测试下来的成果也是比拟现实的，咱们原来在 Storm 里单核计算，大略是以前的 QPS，加上读写和解决性能，单核五个线程的状况下。然而 Flink 的时候咱们能够到一万，还加上 Redis 存储 IO 的开销。

另一个咱们原来数据想要从 Redis 里取出来，再去算最大值最小值，完了算了再写到 Redis 里，这个都是同步去写的，然而同步 IO 有一个问题就是性能不高。所以咱们当初在把它改成异步 IO，然而异步 IO 也有个特点就是整个一条数据的解决必须是同步的，必须先从 Redis 里把数据取出来，而后再把值计算完，再塞到外面去，保障塞完后再解决下一个对立的数据。

咱们再做这样的一些优化。Flink 这里有些个性能够保障咱们数据的一致性，而且晋升效率。

5、对立大数据开发服务—服务案例

接着介绍下更多的案例，如果大家玩英雄联盟的话，那这个工作零碎就是咱们设计的，下次玩做这个工作的时候，你就能够想起我。还有天龙八部、CF、王者光荣 LBS 光荣战区（通过大数据实时计算 +LBS 的数据排行）、王者光荣的日常流动（实时数据 + 接口 + 规定计算）、有哪些好友是实时在线的，跟你匹配的。

三、数据接口服务 OneFun

1、数据利用的进口

上面介绍下函数，咱们原来在做的时候也是存在着一些问题，把数据存到存储外面，如果存储间接凋谢进来，让他人任意去应用的话，其实对存储的压力和治理水平都是很有问题的。所以起初咱们采纳了一种相似于 Fass 的的解决形式。咱们把存储在外面的元数据进行治理，完了之后接口再配置化的形式，你要应用我这个 DB，这个 DB 最大 QPS 多少，我就进行比照，容许你之后能力应用这个量。

比方我这个 DB 的最大 QPS 只有 10 万，你要申请 11 万，那我就给你申请不了，我就只能告诉 DB 把这个 Redis 进行扩容，扩容后才给你提供应用。所以这外面牵扯到咱们的指标数据的元数据管理和接口之间的买通。

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

这个和方才 OneData 的形式是一样的，比方这块提供了疾速的函数，还有一些在线函数编程的形式的接口，你能够在下面写一点 JavaScript 或者 Golang 代码，而后就生成接口，接口外面能够间接对外提供服务，把他造成产品化的包装，在下层依据接口衍生出更多其余的一些利用零碎。

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

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

并且咱们能够把咱们写的代码作为函数库，积攒下来而后放进去，它能够在执行的时候去调用这些函数库，而这外面写的代码语法和 Golang 是齐全一样的。

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

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

这是咱们的 Javascript 的执行引擎，咱们次要是做了 V8 引擎的池子，所有 Javascript 写完之后，丢到 V8 引擎下来执行，这应该大家都可能了解，如果大家玩过 JS 的能够了解这种形式，就是 V8 引擎里间接去执行。

5、一体化函数执行引擎 – 函数即服务

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

右下角是咱们的函数代码编写区，写完后右边的黑框是点击测试，输入能够在这里写，点击测试就会把后果输入进去，通过这种形式，咱们极大地扩张了咱们数据平台的开发能力。原来是本地要把 Golang 代码写完，而后调试完再发到线上环境去测试，而当初咱们能够很大的规范化，比如说数据源的引入，咱们就间接能够在这里去规定了，你只能引入申请过的数据源，你不能轻易乱引入数据源，包含你数据源引入的时候，QPS 放大我都能够通过这种形式晓得。

• 升高启动老本；
• 更快的部署流水线；
• 更快的开发速度；
• 零碎安全性更高；
• 适应微服务架构；
• 主动扩大能力。

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

6、案例介绍

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

四、微服务化 & ServiceMesh

1、数据利用必走之路—微服务化

下面讲的是 OneData 和 OneFun 的实现原理和机制，咱们在外部是怎么去利用的，这套零碎咱们在游戏外部是大力推广。

这里尤其是接口这块，其实如果说要微服务化的话，大数据咱们能做的也就是那样了，可能用 yarn 或者 K8S 去做资源的管控，和工作的管控，但真正去做服务治理还是在接口这块。目前咱们高低接口大略是三千五百个，每周新增 50 个接口。

所以咱们在做的时候也思考到。原来咱们服务是一个个开发，然而没有治理，当初咱们加上服务还是一个个去开发，甚至有些服务咱们会把它变成一个服务，然而咱们退出了这个服务的治理。

好多人在提微服务，微服务如果没有一个平台去治理的话，将会是一种劫难。所以微服务化给咱们带来便当的同时，也会给咱们带来一些问题，所以在咱们的场景外面，微服务是十分好的，每一个接口就能够作为一个服务，这种是人造的微服务。

2、一体化服务治理设计

然而这种微服务的治理将会是咱们很大的一个问题，所以咱们花了很大的精力去做了一个微服务的治理零碎，从我的项目注册的时候，他就把我的项目注册的微服务中心，并且把 API 注册上来，而后在服务公布的时候，发到集群里的时候，这些服务都要被动的注册到咱们的名册服务，就是 Consoul。

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

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

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

所以这外面咱们还加了一个基于 Consul 的一个配置，就是咱们包含 server 的实时控制都能够通过 Consul 去配置，配置完了后立马可能 watch 到，而后去执行。

这个是根本的服务治理，但当初咱们的服务治理降级了，比这个要更好一点，根本的原理是这样。

3、南北流量 + 货色流量的对立管控

并且咱们在这外面实现了一个对 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 的性能，咱们当初还在钻研，咱们筹备在这套零碎里把它实现了。

4、基于 ServiceMesh 的全链路流量剖析

这是一个咱们通过 ServiceMesh 做的剖析，咱们尽管能够宏观地看进去咱们接口对 DB 的压力有多大，但实际上咱们把流量导进来是咱们对压力的监控是不够的，所以这种状况咱们通过 ServiceMesh，他对进口流量和进口流量的管控，而后能够把流量进行具体的统计，统计完后能够生成一个快照，这次快照和下次快照之间的数据比照，入流量有多少的时候，对上面各个流量压力有多少。

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

5、案例介绍

最初再介绍下咱们目前用这套零碎实现的一些案例，大数据的游戏回归，比方做一个游戏数据的回顾（生涯回顾）、工作零碎、排行榜。

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：回放场景下客户端走什么协定将数据发送到服务端？

个别是游戏的公有协定。