多年来，关于容器历史的讨论已经很多，让我感到惊讶的是，我们在游戏行业中交谈的许多人还没有开始寻找利用它们进行可扩展性和自动化的方式。然而，这是可以理解的：他们关注的是他们认为重要的事情，那就是他们的游戏，玩家的乐趣，以及维持日常运转。

与此同时，应用程序和网站开发人员已经充分利用了这项技术的可扩展性和节省成本的潜力。我将介绍我（非常谦虚的）对容器历史的看法，以及为什么在未来几个月内这一切将要改变的原因。

容器的历史始于虚拟化

虚拟化的概念非常好。创建一个抽象层，以更好地利用物理资源。我第一次听说它是在2003年，当时我在贝尔流动公司，正在考虑推出EVDO，一个来自Sun Microsystems的代表向我展示他想展示的“新技术”。那就是VMWare，一家我们并不了解的公司，刚刚推出了虚拟中心和vmotion。

作为极客，我们对这项技术充满了兴趣，但整个工程团队都表示怀疑。由于我们已经将硬件推到了极限，这种怀疑是有道理的。CDMA流量直线上升，人们开始使用手机进行数据传输，我们必须以疯狂的速度增长。使用一些珍贵的资源将其“拆分”为多个虚拟机并没有带来太多价值。更重要的是，应用程序供应商阻止我们出于“支持原因”转向虚拟机。那时这没什么意义，价值也微乎其微。

虚拟机的挑战

我们现在知道VMWare和此类技术发生了什么。SDN/NFV，Openstack等已经成为常态。这使得通过这一抽象层进行更灵活的“应用程序管理”成为可能。向亚马逊的工程师致敬，他看到了这一浪潮的来临。虚拟机给我们带来了简便性，以及许多工具，使系统管理员、开发人员和DevOps的生活变得更加轻松。服务器变得更加强大，因此突然之间，虚拟化所需的资源堆积并没有像它可以带来的好处那样有害。

一个问题在这个虚拟层中持续存在：“操作系统”。对于每个虚拟机，我们被迫根据应用程序的需求来打包操作系统。即使是针对同一个应用程序，对于每个实例，我们也必须存储两次操作系统，为这个操作系统运行每个组件两次，为最终用户增加另一层不必要的元素。解决这个问题是容器历史的下一个章节。

解决方案

在我第一次听说VMware的三年后，谷歌的一些聪明人开始研究一种叫做Cgroup的东西。他们的目标是隔离应用程序的资源。这项工作与命名空间隔离结合起来，创造了我们现在所称的容器。

容器的一个关键好处是避免为每个特定应用程序实例复制整个操作系统。它允许你以优化的方式使用CPU和内存资源，防止你为不旨在改善服务的项目付费。除了节省成本外，它还带来了许多其他好处，比如快速部署、开发人员的易用性、更快的测试（加上自动化流水线）、几乎无限的迁移等等。

什么是容器？

把容器想象成一个烹饪食谱。你列出你想要的应用程序运行时需要的内容，最终服务你最关心的，将会启动并运行。“我需要这个类型的操作系统，这个特定版本，请包含那些包，更改X和Y，添加我的应用程序，然后这样运行。”一旦你的食谱完成，你就可以创建一个运行中的容器。

容器的本质是无状态的。这在理解如何使用它们时相当关键。虚拟机与容器之间的典型类比是“猫与牛”。如果虚拟机是一只猫，而你的猫生病了，你会带它去看兽医进行检查（这就像你登录到你的虚拟机修复它）。如果容器崩溃，就像一个大农场上的一头牛，你可能无法挽救它，而选择用一头更年轻的牛来替换它。

容器的无状态特性

这就是无状态特性发挥作用的地方。在容器中存储信息是由各种机制支持的（要么在容器内映射一个有状态的卷，要么提取/推送数据到外部等）。如果你在没有这些机制的容器中写入任何内容，一旦由于重启而杀死容器，你将失去这些信息。

容器通常不是“重启”的，而是关闭，并且一旦你想要服务回来，就会启动一个新的容器。我们曾有客户在他们的虚拟机中写入日志文件，并每天进行分析。将其转换为基于容器的解决方案需要更改这个过程，以便实时推送这些日志，防止丢失。这并不是一个重大变化，并带来了若干额外的好处，但这表明，有时看似轻而易举的事情也需要一些规划。

容器的历史仍在书写中

这项新技术带来了新的移动性和可扩展性能力，创造了一个全新的生态系统。Kubernetes在过去几年中一直是一个热门话题，我们现在有一系列围绕这一点的解决方案和替代方案。

注意，我还没有谈论Docker。原因是Docker是使用容器的众多技术之一。在Edgegap，我们通常使用Docker，因为它是最流行的，但我们不得不使用其他技术，比如LXC、ContainerD和Rkt。每种技术都有优缺点，我们已经看到一些特定市场“更喜欢”一个而不是另一个。在Edgegap，我们在游戏元素上成功地使用了Docker。那些已经在使用容器的客户主要是利用Docker的强大功能。

关于用户空间与内核空间的辩论

并不是所有事情都是围绕容器的。在过去两年中，我们听到了几些反对意见。我们经常听到的一个担忧涉及技术的核心。容器将在用户空间与内核空间中运行。内核空间是你的操作系统的核心运行的地方，处理内存等资源；而用户空间是应用程序通常运行的地方。如果在共享环境中有来自不同客户的两个应用程序，就存在进行这种操作的潜在风险。

如果环境未正确配置，这种情况是可能的。无论是来自于错误分配的共享资源（配额未强制），以超出需要的用户权限运行（根权限还需要吗？），镜像管理，还是从虚拟网络的角度，有一系列最佳实践需要遵循。Edgegap自豪地列出我们支持这些并积极关注市场，以确保修复零日攻击并遵循最佳实践。

游戏的容器？

大型游戏工作室多年来一直在使用Windows虚拟机。其中一些转向了基于Linux的，但仍在使用虚拟机。无论是基于VMWare的基础设施，还是基于Openstack的，超过两年的游戏将主要在虚拟机中运行。这种情况自云供应商进入市场以来已经持续了很长时间。

多年来出现了多种工具来管理这些虚拟机。例如，AWS Gametech提供了一种工具，可以根据过去的流量扩展和缩减你的虚拟机需求。这利用了它们高度集中的数据中心，可以视为一种解决已经存在多年的问题的解决方案。

游戏的容器历史刚刚开始

谷歌创建了一个名为Agones的项目，以在Kubernetes之上创建一个插件，作为游戏服务器管理器。这在正确的方向上迈出了一步，因为它帮助工作室在利用现有基础设施（如匹配引擎）的同时转向容器。

游戏分配、集群等的通信流程保持不变。缺点是你仍然必须使用“集群”，即高度集中的环境。你无法更接近你的玩家，提供更低的延迟。即便在不使用的情况下，你也必须“保留”资源并为其中一些付费。

容器的真正优势在于仅在需要时启动，停止不再使用时移动，就像一个简单的小LEGO块一样。忘记虚拟机的“热/冷预热”，启动容器只需几秒钟，甚至毫秒。

在过去的两年中，我们会见的所有工作室都告诉我们他们对基于容器的技术的好处感兴趣。问题不是“这是否是时刻添加容器到全球多玩家游戏开发工具集的时刻”，而是“何时”。

需要帮助吗？

在Edgegap，我们专注于基于容器的解决方案，如微服务。我们的平台和团队帮助工作室为全球玩家提供更好的在线体验，以增加留存率和活服务游戏的收益。我们在这里帮助您将服务迁移到基于容器的解决方案，并利用我们平台的强大来充分发挥容器为您的工作室带来的新价值。