在开始设计光环（Halo）系列视频游戏的下一代——光环4 的时候，现有的游戏引擎与可用的服务已经无法满足游戏的需求了，因此开发者基于 Actor 模型设计了一套全新的解决方案，并使用 Orleans 框架完成了这套模型的实现。在 QCon 伦敦大会上， Caitie McCaffrey 在演讲中为听众介绍了他们设计与创建这个新游戏背后的服务的过程。
McCaffrey 原本在微软游戏工作室就职，目前则在 Twitter 担任分布式系统工程师的职位。他提到了在游戏开发过程中所遇到的一个架构上的挑战，是如何设计该游戏将要面对的海量访问的负载。在光环 4 上线当天，共有 100 万独立在线用户参与了游戏，这个数字在一周之内就上升到了 400 位，游戏时间总和超过了 3000 万小时。为了应对如此庞大的负载，该项目选择了在云端进行托管，更具体地说是托管在 Azure 上，毕竟光环 4 是微软所推出的游戏。其它的挑战还包括如何保证游戏能够始终在线运行，这就要求服务器永远保持可用状态，还要尽量降低延迟，并且提高并发能力。
在寻找能够满足该项目需求的解决方案过程中，项目组的目光投向了 Actor 模型。从本质上说，Actor（角色）是并发的基础，该模型的核心概念在于：作为并发计算的基元，每个 Actor 将通过异步消息发送的方式与另一个 Actor 进行通信。当某个 Actor 收到一条消息之后，它可以选择将消息发送给其它 Actor，或是创建一个新的 Actor，也可以修改它的内部状态。这样一来，就能够高效地将某个 Actor 的所有数据保存在同一个地方，因此 McCaffrey 和他的团队通过实现这些保持状态的服务，创建了一套能够保持状态的中间层，它一方面具有缓存的高性能优点，另一方面也不会产生由于并发造成的问题。
项目组在微软内部四处寻找可行的方案，他们最终发现了 Orleans 框架，这是一个用于创建基于 Actor 模型的分布式系统的运行时与编程模型。Orleans 框架与其它 Actor 模型框架最重要的不同之处在于它所独有的概念：虚拟 Actor。这个虚拟 Actor 永远不会被创建或是销毁，从逻辑上来说它是永远存在的。虚拟 Actor 所具有的关键思想，一是地址的透明性，即发送给某个 Actor 的消息会被自动路由至该 Actor，无论该 Actor 的地址在哪里；二是能够在不重新进行部署的情况下进行自动横向扩展。
McCaffrey 声称，在使用了新技术的全新架构中，服务器的 CPU 利用率能够持续稳定在 90% 的水平上，并且能够实现接近线性增长的可扩展性，能够轻易地应对负载的变量，这一点在访问量突发性增长的时刻相当实用，例如当游戏刚刚上线的时候。
McCaffrey 相信，如果没有 Orleans 这个框架，光环 4 的项目就不可能获得成功。由于 Orleans 能够为开发者编写在分布式环境中运行的代码提供极大的帮助，因此寻找合适的开发者也变得简单了许多。并且由于它提高了开发者的生产力，因此开发者能够专注于提高游戏的用户体验，让它的表现更加出色。
McCaffrey 在一篇较早的博客帖子中，曾经介绍了使用 Orleans创建RESTful 服务的过程。
对于实现 Actor 模型的不同途径，InfoQ 之前曾经专门进行过讨论和报告。
注册/登录 InfoQ 发表评论