这个可扩展数据中心平台的优点包括增加了应用的处理能力
（映维网资讯）云游戏和元宇宙正在兴起，但它们对技术的要求非常高。另外，传统游戏是为运行在单个硬件的游戏引擎设计，当执行实例时，游戏最终将受到现有游戏引擎的计算资源的静态分配的约束。
在名为“Scalable data center platform for cloud gaming and metaverse”的专利申请中，索尼提出了一种用于云游戏和元宇宙的可扩展数据中心平台。团队指出，这个可扩展数据中心平台的优点包括增加了应用的处理能力。其中，当执行相应的应用程序时，可以基于相应的工作负载动态地向相应的基于云的游戏引擎添加计算资源或从相应的游戏引擎中移除计算资源。
换句话说，游戏引擎不再受计算资源的静态分配的限制，因为在执行相应的应用程序时，基于云的游戏引擎可以根据工作负载动态配置微服务。这允许动态分配执行相应应用程序所需的适当数量的资源。
所以，可以将应用程序设计为通过利用众多服务器甚至服务器机架的马力，而不是针对单个硬件来设计。以这种方式，云原生应用程序可以提供以前不可能的体验，因为计算资源的按需分配可以部分地提供增加的图像质量，而且即便与本地游戏体验相比都可以减少云游戏系统和客户端设备之间的延迟。
其他优点包括与数据中心的资源利用相关的效率提高。总体而言，数据中心可以最大限度地利用计算资源，并将计算资源闲置的时间降到最低。
![]()
图1示出了系统100，系统包括基于云的游戏网络190，游戏网络190配置为建立和实现一个或多个基于云的游戏引擎，每个游戏引擎包括用于执行应用程序的微服务。基于云的游戏网络190包括微服务架构300，该微服务架构包括多个微服务，其中对应的基于云的游戏引擎被配置为在执行应用程序时基于需求动态扩展和收缩微服务和/或微服务的计算资源。
如图所示，系统100可以通过网络150为一个或多个客户端设备110提供对应用服务的访问。游戏服务器160可以配置为提供和管理对多个应用程序的访问，例如元宇宙应用程序。
这样，系统100可以配置为经由云游戏网络190向参与单人或多人游戏会话的用户提供游戏控制，其中，云游戏网络190配置为提供用于玩游戏的相应用户执行游戏的基于云的游戏引擎。换句话说，系统100可以在多玩家会话中经由网络150通过在云游戏网络190中操作的基于云的实例向控制一个或多个应用的一个或更多个用户提供游戏控制。
在一个实施例中，云游戏网络190可以包括在主机的管理程序运行的多个虚拟机（VM），其中一个或多个虚拟机器配置为使用通过微服务架构300访问的微服务来建立和实现一个或更多个游戏引擎。
例如，游戏服务器160可以管理支持基于云的游戏引擎220的虚拟机，游戏引擎220为用户实例化应用程序的基于云的实例。另外，游戏服务器160可以配置为管理用于基于云的游戏引擎220的计算资源的分配。
基于云的实例能够渲染图像和/或帧，然后对其进行编码（例如压缩）并将其流式传输到相应的客户端设备以供显示。这样，由作为多个虚拟机的游戏服务器160管理的多个游戏引擎配置为执行与多个用户的游戏相关联的一个或多个应用程序的多个实例。
游戏服务器160配置为通过网络150将数据流式传输回相应的客户端设备110。在其他实施例中，除了流式传输视频和音频，后端服务器可以配置为交换其他类型的数据，并且可以配置成执行不同的功能。
用户利用客户端设备110访问由云游戏网络190提供的远程服务，客户端设备110至少包括CPU、显示器和输入/输出（I/O）。
例如，用户可以使用配置为实现能够执行应用程序的基于云的游戏引擎的对应客户端设备110经由通信网络150访问云游戏网络190，其中对应的基于云游戏引擎包括通过微服务架构300访问的微服务，并且配置为在对应应用程序的执行期间基于需求扩展和收缩微服务和/或为微服务分配计算资源。
![]()
图2A示出了应用程序的基于云的实例210，所述应用程序包括基于云的游戏引擎220，游戏引擎220基于在执行应用程时所经历和/或预测的工作负载动态地配置有微服务。例如，应用程序的基于云的实例210可以包括从微服务架构300分配的多个微服务230，其中应用程序的云实例210在图1的云游戏网络190内建立和实现。
基于云的实例210在云游戏网络190内执行应用程序。特别地，实例210的基于云的游戏引擎220被配置为执行应用程序。
如图所示，应用程序的基于云的实例210可以配置为彼此协作的集合或多个微服务230，其中微服务构建在配置为执行与相应应用程序相关联的游戏逻辑225的游戏引擎220之上。传统的应用程序或游戏只是一个“过程”，而基于云的云原生游戏实例包括跨越多个服务器的微服务集合。
特别地，基于云的游戏引擎被配置有用于执行应用程序的微服务，并且配置为在执行应用程序时基于对计算资源的需求动态地扩展和收缩微服务和/或为微服务分配计算资源。
每个微服务包括计算资源，其中，根据对应的微服务的工作负载，微服务的计算资源的对应分配可以根据工作负载而扩展或收缩。例如，微服务集合230中的每个微服务由用实线绘制的圆和用虚线绘制的两个外部同心圆示出，这指示用于该微服务的计算资源可以扩展或收缩。例如，当用于照明微服务230g的工作负载增加时，可以添加执行用于微服务的照明的额外计算资源。相反，当用于照明微服务230g的工作负载正在减少时，可以移除执行用于该微服务的照明的计算资源，或者可以从微服务230的集合中整体移除照明微服务230。
![]()
图2B的流程图200B涉及用于建立和实现配置有微服务的基于云游戏引擎以执行应用程序的基于云的实例。
在250，接收实例化应用程序的基于云的实例的请求
在255，该建立用于执行应用程序的游戏逻辑的基于云的游戏引擎。
在260，为基于云的游戏引擎组装一组微服务，以实例化应用程序的实例。
在265，通过通信结构在基于云的游戏引擎和微服务集合中的每个微服务之间建立通信。
在270，使用基于云的游戏引擎在应用程序的实例中执行游戏逻辑。
在275，在执行应用程序实例内的游戏逻辑的同时监视对计算资源的需求。
在280，基于所确定的需求来调整用于微服务的计算资源的分配。
另外，计算资源可以从微服务集合中移除。例如，当确定提供服务的微服务需要更少的计算资源时，可以从微服务的计算资源的分配中移除微服务所需的一个或多个计算资源。
同时，可以添加提供新服务或功能的新计算资源。例如，当确定执行应用程序需要不是由微服务集合提供的新微服务时，将新的微服务添加到微服务集合。
![]()
图3A示出了一个实施例的微服务架构300，其包括在一个或多个数据中心上逻辑排列的多个微服务。
在一个实施例中，层可以指示可用于应用程序的云实例的微服务之间的优先级。因为内核层310中的微服务比其他层中的微业务具有更高的优先级，所以特定微服务的密度可能更高。例如，与相邻层320A中的微服务的密度或数量相比，内部核心层310中可能存在更高密度或数量的微服务。另外，与相邻层320B中的微服务的密度或数量相比，层320A中可能存在更高密度的微服务等等。
在一个实施例中，层之间的优先级可以指示来自一个或多个应用的基于云的实例的需求水平。例如，内核层310中的微服务具有最高优先级，并且可以指示这些微服务的需求更高。
![]()
图3B示出了根据使用可通过资源架构305访问的计算资源的微服务架构300实现。特别地，微服务架构300中提供的微服务可以由位于资源架构305的一个或多个数据中心350的计算资源来支持。
另外，一个或多个微服务可以由资源架构305中的计算资源355提供，而计算资源355可以不位于数据中心中。例如，计算资源355B可以位于网络的边缘，或者位于更靠近终端设备的位置。在一种情况下，边缘计算资源355B可以是具有在微服务架构300中使用的可用计算资源的游戏控制台或客户端设备。
云控制器390和/或控制平面380可以配置用于在位于不同组件和/或数据中心的计算资源和/或微服务之间传输作业。例如，提供微服务的一个组件可能负担过重，因此，该微服务正在执行的作业可以转移到同一数据中心或不同数据中心的不同组件上的另一个微服务，以执行相同的作业来支持相应应用程序的同一基于云的实例。
在其他示例中，提供微服务的组件可能正在进行维护，或者组件可能由于硬件故障而离线，或者执行由已知条件触发的预防性维护。
在一个实施例中，云原生应用程序可以配置为持久应用程序，使得该应用程序永远不会“宕机”，并且在任何和所有条件下都应该是有弹性的。在这种情况下，持久的云原生应用程序会将故障微服务执行的功能转移到执行相同功能的另一个微服务，包括所需数据的转移。
以这种方式，用于相应应用程序的微服务可以与其他微服务交换和/或交换和/或者替换，而在应用程序的执行过程中没有任何明显的性能下降。
![]()
图3C示出了支持微服务架构的计算资源。为了便于说明和理解，图3C中所示的计算资源位于一个数据中心350内。
如图所示，计算资源在资源架构的分布提供了一个“分解的硬件平台”，以支持用于执行应用程序的基于云的游戏引擎。其中基于云的游戏引擎配置有用于执行相应应用程序的微服务，并且其中基于云游戏引擎配置为在相应应用程序执行期间基于工作负载和/或对这些计算资源的需求来动态扩展和收缩微服务和/或为微服务分配计算资源。
如图所示，结构交换机和/或通信平面370中的高速、低延迟互连提供了单个组件的组件之间以及数据中心350的组件395A-395N之间的组件之间的互连和通信。
云控制器390和/或控制平面380协同工作以管理计算资源的分配，以支持一个或多个应用程序的对应的基于云的实例。在一个实施例中，微服务的工作负载仅跨越组件中的几个计算资源，但在其他实施例中的微服务或支持相应应用程序的基于云的实例的各种微服务的工作量可以跨越许多服务器、组件，甚至跨越不同的数据中心。
在一个实施例中，资源碎片化可以发生在机架组件和/或数据中心之间。这种碎片可能会阻止作业的计算资源在组件的正确混合，而在数据中心级别的所有组件上都有大量的计算资源。因此，需要通过在服务器/组件之间移动作业来对计算资源进行碎片整理，以释放组件的计算资源。
![]()
图4示出了基于云的游戏引擎。在一个实施例中，使用控制平面380和来自云控制器390的信息，控制平面380配置为基于应用的基于云的实例210的执行所经历的工作负载的需要来分配一个或多个微服务的各种计算资源。
微服务需要协同工作的能力，并且需要找到彼此的方法，以便在微服务之间建立通信路径。在一个实施例中，控制平面380配置为分配特定微服务可以与之通信和协同工作的服务器列表。在另一个实施例中，微服务可以动态地定位彼此。
因此，一旦启动了应用程序的相应基于云的实例的所有微服务，就可以开始游戏工作负载。相应的客户端将向云游戏服务器发送输入，而云游戏服务器配置为使用动态配置的微服务提供应用程序的基于云的实例。
![]()
图5示出了两个或多个基于云的游戏引擎之间的资源共享，每个引擎执行对应游戏的对应实例。如图所示，应用程序的基于云的实例210A包括位于微服务架构300内的多个微服务230A。多个微服务230A内的核心微服务位于微服务架构300的微服务310的内部核心内。
另外，另一应用程序或同一应用程序的基于云的实例210B包括位于微服务架构300内的多个微服务230B。多个微服务230B内的核心微服务位于微服务架构300的微服务310的内部核心内。
在一个实施例中，可以以高得多的帧速率执行游戏渲染。例如，应用程序的基于云的实例的执行不需要像传统上所要求那样被限制于特定的帧速率（例如每秒60帧等）。对于应用程序的基于云的实例，可以在多个微服务的多个GPU执行渲染。
因此，可以想象的是，图像帧可以在1毫秒内生成，这可以有助于减少流传输时的延迟。在这种情况下，剩余的15毫秒可能用于其他工作负载。
因此，在各种实施例中，专利描述的基于云的游戏引擎配置有用于执行应用程序的微服务。其中，基于云的游戏引擎配置为基于在执行游戏时确定的对计算资源的需求来动态扩展和收缩微服务和/或为微服务分配计算资源。
相关专利：Sony Patent | Scalable data center platform for cloud gaming and metaverse
https://patent.nweon.com/35365
名为“Scalable data center platform for cloud gaming and metaverse”的索尼专利申请最初在202年10月提交，并在日前由美国专利商标局公布。
---
原文链接：https://news.nweon.com/120482
![]()
