黑科技王者荣耀背后的实时大数据平台用了什么黑科技？( 八 ) |腾讯|数据|

这是整个展示图，我们有多个测试用例，这两个测试用例之间我们可以算出来对下游的压力的流量分析，后期对下游压力的分析和下游资源的扩容、缩容都有非常大的价值。
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：回放场景下客户端走什么协议将数据发送到服务端？
一般是游戏的私有协议。
作者：阿里云实时计算Flink