今天许多大型 AAA 级游戏，都致力打造“身历其境”的丰富体验，让玩家穿梭于逼真的游戏世界与故事线中。当然，要运营这样的一款游戏，就需要大量的储存、高效能的储存技术来确保游戏资料能达到玩家要求水平。游戏开发人员不仅需要储存不同类型的资料（例如存档、库存、补丁、回放等），还必须保持储存系统的高性能、可用​​性、可扩展性和成本效益。

近期 Google 就与游戏商 2K 共同开源一项 Open Saves 项目，这是一项专为多个储存后端所打造的单一界面，由 Google Cloud 提供支援并与 2K 合作开发。现在，开发团队可以储存游戏资料，而无需为该使用哪种储存解决方案如：Cloud Storage、Memorystore、Firestore 做出技术决策。

2K 的 IT 安全副总裁 Joe Garfola 表示：“Open Saves 表明了我们致力与顶尖开发者，合作游戏解决方案的承诺。要做到这件事，需要具备游戏产业的丰富经验，以及 Google 这样的规模。我们很期待和 Google Cloud 的持续合作。”

Open Saves 技术架构

对游戏开发团队而言，他们可以根据 Open Saves 保存游戏资料，而不必顾虑后端储存解决方案；对运营团队来说，他们可以专注于所需的扩展性和储存选择。下图是 Open Saves 的架构概述：

游戏开发者可以利用 Open Saves 运行一套云原生的游戏储存系统，优点如下：

1.简单

Open Saves 为 metadata、结构化 / 非结构化物件，提供统一且定义明确的 gRPC 端点

2.快速

借由内建的缓存系统，Open Saves 能根据存取频率和资料大小，优化资料放置。如此，能同时使较小的二元物件实现低延迟，并在大型物件上实现高吞吐量。

3.可扩展

Open Saves API 服务器可以在 Google Kubernetes Engine 或 Cloud Run 上运行。这两个平台都可以水平扩展、每秒处理数十万个请求。Open Saves 还将资料储存在 Firestore 和 Cloud Storage 中，每秒可以处理数百 GB 的资料和高达数百万的请求。

Open Saves 的设计考虑到了可扩展性，并且，可以整合到任何游戏中 — 从手游到游戏机、从多人游戏到单人游戏 — 它能在任何基础设施上运行，不论是地端、云端或混合式基础架构。Open Saves 的服务器由 Go 编写，但因为 API 被定义在 gRPC，用户可使用多种程序语言并从客户端或服务器进行连接。

写入和读取 Open Saves 就像以下代码一样简单：

// To write
	record := &pb.Record{
		Key:      uuid.New().String(),
		Tags:     []string{"tag1", "tag2"},
		OwnerId:  "owner",
	}
	createReq := &pb.CreateRecordRequest{
		StoreKey: storeKey,
		Record:   record,
	}
	_, err := client.CreateRecord(ctx, createReq)
	if err != nil {
		t.Fatalf("CreateRecord failed: %v", err)
	}

	// To read
	getReq := &pb.GetRecordRequest{StoreKey: storeKey, Key: recordKey}
	response, err := client.GetRecord(ctx, getReq)
	if err != nil {
		t.Errorf("GetRecord failed: %v", err)
	}

文章来源：谷歌云

Github链接：