网络游戏架构的前世今生——数据架构

上文：

网络游戏架构的前世今生——拓展数据库https://blog.csdn.net/finishy/article/details/129228338

5. 数据架构

数据架构，或者说是数据存储架构，其实包含了上文介绍的数据库方案。之所以先着重介绍了数据库方案，是因为这一块在游戏行业应用广泛，和业务联系紧密，避不开。而本篇中介绍的数据架构内容，大部分中小型游戏公司选择接入第三方平台，或是从略从简的做这些功能。通常意义上，这些不是游戏后端的核心内容，但我认为这些系统同样有价值，我将数据架构整理成下面这张图：

 

当我们把数据分析处理好存入数据库，运营、决策层和发行商希望部分数据能够实时展示出来，例如当前同时在线玩家、当前同时游戏对局数等，我们需要一个实时的展示系统；此外，他们还希望部分数据能够每天生成为报表，例如次日留存、七日留存、月留存、玩家访问漏斗等数据，我们需要每天制作类似的表格展示这些数据。这些需求汇总成数据报表展示的需求。

我们可以选择一个 BI 展示工具，例如图中画的 PowerBI 或是 Tableau，通过简单的图表配置，即可将数据库中抽象的数据以图表的形式具象化的展现出来。运营决策能够利用这些数据分析玩家行为，判断玩家更喜欢什么内容、不喜欢什么内容、想要什么内容，从而针对性的对游戏做出调整，以便于提高用户留存，提高游戏的商业价值。

（图片来源于 PowerBI 官网）

我们的游戏前后端每时每刻都在输出日志信息，例如打印玩家当前在修改存档、匹配对战等。我们会将有用的信息都以日志的信息输出出来，帮助我们判断当前客户端、服务器正在执行什么操作，遇到了什么问题。如果没有这些日志，我们将很难弄清楚玩家遇到的 bug 是怎么产生的。所以我们需要一套日志分析系统，来统一收集并展示日志。

图中左侧给出了个人喜欢的 EFK 日志分析体系，早期是 ELK。这套体系的特点是完全免费，而且足够高效好用。

Elasticsearch 作为存储，能将半结构化的数据，例如日志数据，分布式的存储下来，同时支持高效的查询与聚合。

Filebeat 可以通过简单的配置，将输出到文件中，或是打印在标准输出（stdout）下，或是容器内的日志，统一规整好，分门别类的发送到 Elasticsearch 不同的索引（index）内。你可以将逻辑服、战斗服、数据库、客户端的日志分类放入不同的索引，方便查找。Fluentd 和 Filebeat 作用类似，在生产环境的 Kubernetes 集群中，考虑到性能因素，可以把它们替换为 Fluentbit，性能对比 Filebeat 有质的提升，当然相关筛选分类逻辑较弱，大部分场景足够使用，这是一个需要权衡的点。

在Kubernetes 集群中，其他条件相同的情况下，每个 Filebeat 消耗了 2 GiB 左右的内存，而 Fluentbit 只需要消耗 10 MiB 左右的内存，他们整理好的日志是差不多的！

Kibana 是日志分析体系的可视化平台，当然也可以用作数据分析，它能将 Elasticsearch 存储的日志信息友好的展现出来。你可以通过时间，或者多种条件复合在一起进行筛选，快速定位到出问题时段的日志信息。当然它还支持其他丰富的功能，例如导出 csv，生命周期策略等，在这里就不赘述了。

（图片来源于 Kibana 官网）

仅仅看日志是不够的，我们还需要实时监控服务器的 CPU、内存、磁盘等指标，建立告警体系。如果应用了微服务，我们还需要查看每个服务容器的 CPU、GC 等指标。我们可以提前设置异常阈值，例如 CPU 大于 80% 时告警，接入邮件、Slack 或是企业微信等通知工具，让运维人员及时处理。开发人员也能根据当时的各项指标状况，结合日志进行准确的 bug 原因分析，从而更好的修复 bug。

图中画了两套，一套是 Zabbix，这个是流行的老牌监控告警应用。我更喜欢使用另一套开源的方案——Prometheus+Grafana，开源以及天然亲和 Kubernetes 体系，成为了微服务监控告警的首选。使用 Webhook 能接入企业微信或是钉钉，快速通知到运维部门群内，得到快速的响应处理。

（图片截取自 Grafana 官网）

配置项也是数据架构的一环。配置项属于半结构化或是非结构化的数据，在游戏里起到举足轻重的作用。游戏内角色属性、等级、关卡等数据，通常存储为二进制格式的文件，客户端和服务器都需要使用到它们。服务器也需要自己的配置文件，决定当前服务器的环境模式、连接哪个数据库、重试次数超时时间等。如果使用统一部署，例如使用 Kubernetes 容器集群，还需要部署配置文件，决定如何部署、版本信息、对外暴露哪些端口等。

这些配置文件可以存储在对象存储中，或是存储在本地的文件系统内。存储在对象存储的好处是可以在运行时远程查看当前的配置项，同样也可以为修复 bug 、解决玩家问题提供便利。

最后，如果我们把这些数据系统中的数据整合到一起，那就是一个数据湖（data lake）。我们可以自己写一个服务，实现所有数据存储的访问，将所有数据整合到一起进行分析。例如，我们可以将某一时段的数据全部整合到一起，发送给开发人员，全面的分析玩家遇到的问题；或是将数据加工后，放入机器学习模型，预测服务器的故障概率、玩家的行为模式等。这是一片广阔的数据舞台，里面的价值不可估量，也是未来的重要发展方向。

有不少大厂推出了数据湖的第三方服务，在其他行业有不少应用案例。我没在真正的游戏项目中应用过，这里就不妄加阐述推测了。我当前的项目里所有数据架构都是自行搭建的，没有使用第三方平台，后续会尝试实现数据湖整合数据、挖掘数据价值，这是一件想想都觉得兴奋的事。