网易游戏大数据平台上云架构设计( 二 ) _架构设计

一致性：在当时，我们对 S3 进行了调研，但在 2020 年第一季度之前，并没有实现强一致性，而目前也并非所有平台都能做到强一致性。
容量管理：对于我们当前自建的集群，有一个重要的问题是需要预留资源。也就是说，我们不可能使用到 100% 的资源，因此按需使用是一个非常节省成本的方向。
性能：基于 HDFS 可以达到我们国内自建的 HDFS 的性能水平。我们国内提供给业务的 SLA 是在单集群下 4 万 QPS 的情况下，能够实现 p90 在 10 毫秒以内的 RPC 性能。但是对于类似 S3 的情况，实现这样的性能非常困难。
权限认证：在自建集群中，使用 Kerberos 和 Ranger 做认证和权限管理。但 S3 当时并不支持。JuiceFS 社区版本同样也不支持。
数据可靠性：HDFS 使用三副本来确保数据可靠性。当时我们测试时 JuiceFS 元数据引擎使用的是 redis 。我们发现，在高可用模式下，如果发生主节点切换，存储会出现卡顿，这对我们来说是很难接受的。所以我们采用在每台机器上独立部署 Redis 元数据服务的方式，细节将在下文展开。
成本：块设备这样的方案成本很高。我们的目标是要使用 S3，如果每个人都只使用 S3，成本当然是最低的。如果使用 JuiceFS，后面的架构会有一定的额外成本，因此我们后面会解释为什么它的成本不是最低的。
02. Hadoop 海外多云迁移方案
【网易游戏大数据平台上云架构设计】存储层存算分离 - Hadoop+JuiceFS+S3
JuiceFS 与 Hadoop 的结合可以降低业务的兼容的成本，快速实现已有的业务出海。许多用户在使用 JuiceFS 方案时，是通过 SDK 加上 Hadoop 开源版本来实现的。但这样使用会有一个权限认证的问题，JuiceFS 社区版不支持 Ranger 和 Kerberos 的权限认证。因此，我们还是使用了 Hadoop 的整个框架。维护成本看上去很高，但在国内我们有一套自建的组件在维护着，所以对我们来说差不多没有成本。如下图所示，我们使用 Fuse 将 JuiceFS 挂载到 Hadoop，再使用 S3 存储。

文章插图
（JuiceFS 使用示意图）
先简单对比我们与基于 EBS 自建单集群的性能。

在 4 万 QPS 的情况下可以达到 p90 10ms；
单节点能够承受 30000 IOPS 。

一开始我们上云时采用了 HDD 模式，具体来说就是 st1 存储类型。但很快我们发现，当节点数量较少时，实际的 IOPS 远远不能满足我们的要求。因此，我们决定将所有的 st1 存储类型全部升级到 gp3 。

文章插图
（Hadoop+JuiceFS+S3 部署架构图）每块 gp3 默认提供大约 3000 个 IOPS 。为了提升性能，我们挂载了 10 块 gp3 存储卷，总共实现了 30000 IOPS 的性能。这个改进让我们的系统可以更好地满足 IOPS 的需求，不再受限于节点数量较少时的性能瓶颈。gp3 的高性能和灵活性使得它成为我们解决 IOPS 问题的理想选择。
每个节点目前的默认带宽是 10Gb 。但是不同的机型带宽也有所不同。我们取了一个基准，即 30000 个 IOPS 单节点，带宽为 10Gb 。我们的目标是要能够整合我们的 S3 存储，即在高性能的同时也要考虑存储的成本，数据最终会落在 S3 上面。
而最重要的是要兼容 Hadoop 访问，也就是所有的业务其实都不需要做任何修改，可以直接上云解决兼容性问题。对于一些历史业务来说，它可能有一定的业务价值，但是我们要评估业务的改造成本和平台兼容的成本，在我们场景业务中重构所有历史业务的人力成本当前是大于平台兼容成本，而且不可能短时间完成。
我们对 JuiceFS 的挂载方式与官网可能有所不同。我们在每台机器上都部署了本地的 JuiceFS 和 Redis（如下图所示）。这样做是为了最大化 JuiceFS 的性能，并将本地元数据的损耗降到最低。我们曾尝试过使用 Redis 集群和 TiDB 集群，但发现元数据性能差了好几个数量级。因此，我们一开始就决定采用本地的部署方式。

文章插图
（JuiceFS 部署方式）另一个好处是我们的系统与 DNO（Data Node Object）绑定。我们可以控制每个 DNO 的文件数量，即单个节点的文件数量，使其稳定在一个合理的水平范围内。例如，我们一个 DNO 大约有 3 百万到 8 百万个元数据文件的上限，所以元数据单节点大约为 20GB 。这样，我们不需要过于关注其膨胀情况，将一个大规模的分布式 Redis 需求转化为单节点元数据可控的 Redis 需求。但稳定性也是一个问题，如果单节点出现稳定性问题，我们就会面临丢失的风险。