银行业和游戏业的技术体系架构

在本文中，我首先会考量金融系统企业架构的一些特性，并将其与我作为玩家所观察到的游戏环境的一些特性进行对比。

在本文的第二部分，我将继续讨论在云部署体系架构的发展过程中逐渐成长起来的一些技术和最佳实践。最后，基于这些案例分析，我将对未来进行一些预测，畅想一下将之前讨论的这些技术有机结合，能够为游戏行业开启哪些可能性。

首先是对金融机构的告诫。大型公司如此庞大，囊括多条业务线，一系列让人眼花缭乱的非功能性特征差异很大的各种不同类型的系统。因此，无论用什么方式描述他们，不足以表现其复杂性。一个工程师即使将其整个职业生涯都贡献给一家投资银行，最多也只能接触到这家银行所有的系统的很小一部分。

所以，当我在文中讨论金融机构和他们的系统时，我会将注意力集中在投资银行面向客户的这部分系统上。这些团队和项目通常十分关心系统的可靠性和稳定性。这非常符合他们的本性——银行是一群被严格监管的玩家，同时又身处于一个高度竞争且利润丰厚的市场。

客户订单管理系统可能是这种系统最典型的案例之一。系统代表客户接受股票和证券（或商品期货、外汇及其他金融工具）的订单，然后在电子市场中将订单提交，一般情况下基本无需银行工作人员人工干预。

使用这种系统的银行客户通常对特定的银行没有一点忠诚度可言。许多客户都在不同的银行同时拥有用于获取市场访问权限的客户账户。

某个银行的订单管理系统哪怕出现极短时间的不可用（例如几秒钟或更短），用户都会切换到竞争对手的系统中完成订单，然后可能几个月都不会切换回之前的供应商所提供的系统。即使在市场最繁忙的时期，也是如此。

这就意味着设计这类银行系统时，必须要保证非常高的可靠性。因为这类系统的客户群非常易变而且失去任何一个客户都可能会对银行某个部门的利润造成严重影响。

在这个市场中的经验让银行能够在可靠性方面保持相当高的水平，不过这是以付出巨大的成本为代价的。这既包括用于保证冗余度和系统监控的软件和硬件方面的成本，同时也包括人员方面的成本——需要一定数量的支持工程师以保持系统能够在所需要的可靠性水平上持续运转。

相比之下，如果玩家已经对某个特定的游戏形成了较多的情感依赖，那么他们对系统停机问题会更加宽容。对于常规部署的热门游戏，大型补丁可能让下载时间变得更长这一事实（通常几百 MB 大小）看起来已经基本上被用户所接收，即使有这样的情况发生，用户也不会大规模转移到另外一款游戏。

甚至连偶尔的服务器崩溃都被当作生活现实。只要不是频繁发生，玩家连系统崩溃甚至是少量的游戏状态和经验丢失都能够接受。

银行系统和游戏系统的另一个显著区别在于用户对系统的影响不同。不管多么铁杆的玩家，对系统的总体影响和对系统资源的消耗都是有限的。

而在银行系统中，某些特定的客户则比其他的客户重要得多——而且这些重要的“鲸鱼”客户通常能够消耗大量的系统容量和处理能力。

这就导致这样一种情况——分片模式很自然地适用于游戏系统，因为个体玩家能够被有效地分为大致相等的堆。而在银行系统中，这种模式则很难适用，如果要在银行系统中以一种有用的方式实现这种模式，则有很多工作要做。

银行业和游戏业技术之间的最后一个对比——在这两个行业都曾经有过针对网络栈这个领域所做出的大量优化工作。特别是延迟和带宽方面的问题是可能与游戏和银行系统都密切相关的。

离开金融领域后，我参与过一些很有意思的基于云的初创项目，并且接触到了一些有趣的新兴技术和实践的第一手资料——其中一些技术和实践关乎游戏基础设施可能演变的方式。

我们希望在云端构建的架构应该具备三个主要的非功能特性，同时具备基本的适用性并且能够真正执行所需的任务：

• 冗余性——系统架构应该能够承受任何个体服务器的损坏。在更超前的用例中，整个数据中心（甚至是整个 IAAS 区域）的损坏都不应该导致服务质量下降。
• 可恢复性——当瞬时故障结束后，系统应该能够自动恢复到良好的状态。
• 可复现性——系统应该有充足的日志和监控，当故障发生后，能够重现问题，分析其根本原因，然后修复问题避免其再次发生。

考虑到这些能力，我有时发现将云技术和最佳实践当前的演变划分成两个即相互独立又相互重叠的阶段是很有帮助的。

第一个阶段是从主机托管到基础设施即服务的转化，这一阶段以提供用于配置和指挥控制的 API 服务的发展为特征。如果没有这些接口，考虑真正意义上的“云”解决方案可以说还为时尚早。

除了配置 API 之外，我认为第一阶段还应该具备的典型技术是以一种对虚拟实例用户透明的方式将虚拟实例迁移到不同的物理硬件上的能力。

随着配置 API 和透明迁移这两种能力相互结合，云所能提供的潜在收益开始逐渐展露。这些收益通常以几种方式体现：弹性扩展、将计算能力作为商品按时计费以及可能更高的可靠性。

用这样的词来形容第二阶段最恰当不过——“服务器是牲畜，不是宠物”。传统环境下，系统管理员会手工构建订购的服务器。在这种环境下，即使是借助脚本和半自动化的方式，也很难保证能够以完全相同的方式构建两台不同的服务器。

更糟的是，即使构建了完全相同的服务器，如何验证这一事实仍是个问题。因为服务器是由各个系统管理员分别升级和维护，随着时间的推移，这个问题会变得越来越糟。如果一台重要的服务器出现问题，管理员会像照料心爱的家庭宠物一样照料这台服务器。

第二个云时代的开启以持续集成等技术和 DevOps 运动的兴起为标志。诸如 Puppet 和 Chef 这样的技术让从零开始自动构建完全相同的服务器成为可能。这种构建方式更加强调重新构建和重新部署，而不是大量的手工修补。这一方案的基础是不过高估值任何一个体实例，对待它们就像对待牲畜一样。

有意思的是，金融行业长久以来就需要部署大批量服务器和忽略个体服务器宕机的影响。摩根斯坦利是为数不多的几家投资银行之一，能够相对公开的谈论其基础设施特性。根据其记录在案的数据，早在 1995 年，摩根斯坦利已经拥有上万台分布于 30 个不同位置的 Unix 服务器（Gittler, Moore and Rambhaskar, LISA 95），而且随着时间的推移，机器的数量已经增长到数十万计。

然而，尽管这种有能力的基础设施技术 20 多年之前就已经存在，这些技术直到最近才广为流传，造成这种状况的原因有二：

1. 这一技术曾经是完全专属的，并且在很多情况下与某一公司的特定问题领域密切绑定。
2. 确实很少有公司需要管理和统筹如此多的基础设施。

这些有能力的银行所开发的专属技术的确为现代化的大规模技术奠定了基础。因此，当谷歌这类公司刚刚出现时，将银行作为其招揽人才的主要来源也就不足为奇。

Chef 和 Puppet 这类开源的配置和管理解决方案的发展将会证明云技术第二阶段的关键正在到来，这与越来越多的公司发现廉价的大规模计算带来了潜在机遇时的场景如出一辙。

着眼未来，下一个正在兴起的新理念就是集装箱化。这一概念推崇自包含的应用部署单元发布，只需部署到一个基本的应用主机上就能够具备完善的功能，同时还能够避免依赖地狱。

首款具备此功能的可行产品是 Docker。Docker 利用 Linux Containers（LXC）为用户提供运行在联合挂载文件系统上的隔离应用环境。

Docker 有着相当雄伟的目标，不过目前仍然十分不成熟，对于无法应对这些棱角的团队，最好不要将 Docker 应用到生产环境中。

不过，Docker 的社区已经具有相当规模（而且规模还在不断增长）并且还有多家主流供应商的支持，包括 Red Hat 和谷歌。

Docker 也许将继而成为这一领域具有统治能力的技术——也有可能会有其他既可信又有竞争力的产品在这一领域出现（这与其他可选工具开始出现时，发生在 DevOps 和配置管理身上的故事类似）。

然而，无论竞争的格局最终将如何演变，将集装箱化作为一种部署方法的理念都是相当引人瞩目的。对于已经采纳这种理念的团队，在考虑系统架构和应用打包时，会受益良多。

最后，让我们转到与主题相关的问题上——云部署技术能够在多大程度上指明方向，通往更加高效和可信的游戏基础设施。

更好的游戏基础设施能够产生如下两个主要收益：对游戏开发者来说大幅降低的游戏运行成本，以及更可信的基础设施和更少的分片。

从经济角度来说，游戏生产商也能够受益于云 ---- 因为云可以降低其前期成本 ---- 如果一款游戏不能立刻就开始迅速发展，就不需要建立可能会闲置很长时间的数据中心。

游戏玩家从中也将获益匪浅。如果游戏运营的主要成本消耗（可能超过游戏运营所需成本的 10%）能够有所降低，并且可伸缩性更强，这将为更多的独立制作游戏，更多偏爱 AAA 空间探险和范围更广的游戏体验打开市场。

长久以来就属于银行体系架构一部分的可靠性技术也能够在游戏行业发挥其应有的作用，主要体现在防止宕机和降低分片对整体游戏体验影响等方面。

关于作者

Ben Evans是 Java/JVM 性能分析初创公司 jClarity 的 CEO。在业余时间他是伦敦 Java 社区的领导者之一并且是 Java 社区进程执行委员会的一员。之前的项目经验包括谷歌 IPO 的性能测试，金融交易系统，为 90 年代一些最大的电影编写备受好评的网站，以及其他。

查看英文原文： Technical Architecture in Banking and Gaming