Pinkapp 讲述了其在 Azure 云平台上的工作经验

对于三维策略游戏 WarMach，其概念灵感来源于《部落冲突》，年轻的公司 Pinkapp 决定使用微软的云平台。关于这一过程，公司在 App2top.ru 上进行了详细描述。

WarMach 是一款三维在线战争游戏，讲述人类与兽人之间的战争，玩家可以在战场上指挥军队并进行公会互动。

在游戏中，玩家可以建造城堡，通过多种方式强化它，自己选择墙体的配置和驻军的组成。如果建筑资源不足，可以袭击其他玩家的城堡，攻破其防御并夺取宝藏。与许多其他同类游戏不同，在战斗中玩家可以完全控制军队，展现自己的指挥才能。

关于项目情况。

至于游戏的创建，在一开始的开发阶段，我们决定不重蹈覆辙：在设计阶段就选择了成熟可靠的解决方案，以实现可扩展性和高可用性。我们的服务器本质上是一个 ASP.NET 应用，选择部署在 Microsoft Azure 上。

于是，在2015年初我们在 Azure 上部署了开发服务器——最初使用的是试用订阅，随后转为按需付费的订阅。

当时（现在也是）运行情况大致如此：客户端使用 Unity 5，服务器使用 C# 4.5 编写，并作为 ASP.NET 应用程序。接下来，数据存储使用了 AzureSQL（设备、玩家的基本信息、社交媒体关联、游戏指标）、DocumentDb（玩家城市、战斗历史）和 AzureStorage（战斗记录）。为了与 AzureSQL 进行交互，使用 ORM Entity Framework。客户端通过 HTTP 请求向游戏服务器发送数据，数据以 JSON 格式进行序列化。与聊天服务器（独立于游戏服务器）连接时使用 WebSocket。

在开发和部署过程中，我们参加了2015年的 WhiteNights，并偶然发现微软在 BizSpark 计划中积极支持年轻的开发者。我们毫不犹豫地提交了申请，并得到了肯定的回复。

之后，我们在云中展开了合作。

在 BizSpark 计划中，每月都会分配一定金额用于部署可投入生产的系统。这让我们在项目的 Alpha 和 Beta 测试阶段节省了开支。在将我们的开发服务器分配到 5 个 BizSpark 计划提供的账户后，我们几乎将 Azure 的支出降低到了零。

夏季进行了软启动，部署了生产服务器于北欧。服务器在资源规划上留有余地，随后 Azure 的使用费用远远超出了 BizSpark 支持的上限。现在我们正在讨论是否能获得更高级别的支持——BizSpark+。

初步的负载测试显示，目前尚未优化的游戏服务器表现如下：

由于 BizSpark 的订阅限制为 20 个核心，而且部分核心已用于软启动，因此尚未进行更大规模的测试。我们在选择数据库时预留了足够的规模，以避免出现数据库性能瓶颈。根据我们的计算，建立自己的服务器基础设施将使游戏开发时间增加大约 1.5 倍。因此，我们对与该服务的合作感到满意。

关于我们遇到的困难。

在所有开发中，客户耗费了大部分精力。服务器的开发起步较晚，时间紧迫，因此我们开始在熟悉的基础上实现，并将服务器制作成一个网站。这导致了一些困难：HTTP 协议对于游戏项目并不友好，因为服务器无法主动向客户端报告某个事件的发生。而且无法准确判断玩家何时结束游戏会话，因为没有任何连接，而登出请求可能无法发送（如果用户仅是从设备的进程中退出应用程序）。

作为建议，我们可以推荐在开发之初就拥有至少两个实例的测试服务器，以便捕捉可扩展性方面的缺陷。此外，在使用 HTTP 服务器的情况下，需要立刻检查 sticky session 的工作情况（对于游戏项目，stateless 的做法并不适合，尽管它对网站来说很好）。在 Azure 的 Web Sites 中，sticky session 需要在客户端支持 ARRAffinitycookie。对于 cloud services，绑定是通过 IP 和端口进行的（有不同的配置选项）。

仅在游戏会话期间，玩家才可以在实例中进行缓存。会话结束后，需要立即将用户从服务器缓存中移除，因为在一段时间后，他们可能会在不同的 IP 下登录，进入另一个实例（例如，从地铁出来到咖啡馆——IP 发生了变化）。还需考虑到某些用户数据可能在不同实例间发生变化，即使在线时也是如此（这种数据最好存放在独立的表中）。

更为理想且正确的方案是使用分布式缓存，支持读写后延的方式。希望在 Azure 中能出现这样的解决方案，这样我们就能去掉自己编写的迷你缓存，避免许多临时解决方案。

玩家在不同实例间可以进行互动，因此需考虑实例之间的数据交换。理想情况下，应使用分布式缓存或比如 azureservicebus，但也可以通过数据库进行实现。另一种选择是为某些任务创建独立角色，这个角色不进行扩展，但需要注意，它可能成为瓶颈。例如，在我们的项目中，聊天就是这样一个角色，其实例始终是唯一的。在负载过重的情况下，可能不得不将其部署在最昂贵的虚拟机上，配备大量的核心和内存。

根据我们的经验，我们仍然不建议在游戏项目的网络部分玩弄 HTTP，以避免在服务器想向客户发送某个事件时产生很多临时解决方案——对于网络层，最好使用通常的 TCP/UDP，而数据可以使用 protobuff 进行序列化（这样比 JSON 更经济）。如果计划推出网页版，或者想尝试一些新东西，可以考虑 WebSocket。至于与数据库的交互，使用 NoSql 数据库（DocumentDb、MongoDb）时不会有分片问题。但如果选择关系型数据库，建议立即确保做好水平扩展数据的实现，因为对于关系型数据库来说，这并不是一项简单的任务。

顺便提一下，在莫斯科的 White Nights 上，我们的游戏设计师 Всеволод Иванов 简要分享了文章中描述的使用 Microsoft Azure 的经验（视频将在不久后发布）。

游戏的官方网站：http://warmach.pinkappgames.com

目前，该项目在 Windows Phone 平台上可用。可以通过 这里下载。