大多数基于网络的商业应用都遵循相同的一般请求流：从浏览器发出的请求击中网络服务器，然后是应用服务器，最后是数据库服务器。虽然这种模式对一小部分用户来说很有效，但随着用户负载的增加，瓶颈开始出现，首先是在网络服务器层，然后是应用服务器层，最后是数据库服务器层。对基于用户负载增加的瓶颈的通常反应是扩大网络服务器的规模。这是相对容易和便宜的，而且有时能解决瓶颈问题。然而，在大多数高用户负荷的情况下，扩展网络服务器层只是将瓶颈下移到应用服务器上。扩展应用服务器可能比网络服务器更复杂、更昂贵，而且通常只是将瓶颈下移到数据库服务器，而数据库服务器的扩展甚至更困难、更昂贵。即使你能扩展数据库，你最终得到的是一个三角形的拓扑结构，三角形的最宽部分是网络服务器（最容易扩展），最小的部分是数据库（最难扩展）。

在任何具有极大并发用户负荷的高容量应用中，数据库通常是你能并发处理多少事务的最终限制因素。虽然各种缓存技术和数据库扩展产品有助于解决这些问题，但事实是，为极端负载扩展一个正常的应用程序是一个非常困难的提议。

基于空间的架构模式是专门为处理和解决可扩展性和并发性问题而设计的。它也是一个适用于具有可变和不可预测的并发用户量的应用程序的架构模式。从架构上解决极端的和可变的可扩展性问题，通常是比试图扩展数据库或将缓存技术改造成不可扩展的架构更好的方法。

模式描述

基于空间的模式（有时也被称为云架构模式）将限制应用程序扩展的因素降到最低。这种模式的名字来源于元组空间的概念，即分布式共享内存的理念。通过消除中央数据库的限制，使用复制的内存数据网格来实现高可扩展性。应用数据被保存在内存中，并在所有活动的处理单元之间进行复制。处理单元可以随着用户负载的增加和减少而动态地启动和关闭，从而解决可变的可扩展性。由于没有中央数据库，数据库的瓶颈被消除，在应用中提供了近乎无限的可扩展性。

大多数符合这种模式的应用程序是标准的网站，它们接收来自浏览器的请求并执行某种动作。一个竞价拍卖网站就是一个很好的例子。该网站通过浏览器请求不断地接收互联网用户的出价。该应用程序将接收对某一特定物品的出价，用时间戳记录该出价，并更新该物品的最新出价信息，并将信息发回给浏览器。

在这个架构模式中，有两个主要组件：处理单元和虚拟化的中间件。图 5-1 说明了基于空间的基本架构模式及其主要的架构组件。

处理单元组件包含应用组件（或应用组件的一部分）。这包括基于网络的组件以及后端业务逻辑。处理单元的内容根据应用程序的类型而不同 —— 较小的基于 Web 的应用程序可能会被部署到一个单独的处理单元中，而较大的应用程序可能会根据应用程序的功能区域将应用程序的功能分成多个处理单元。处理单元通常包含应用模块，以及一个内存数据网格和一个可选的用于故障转移的异步持久性存储。它还包含一个复制引擎，被虚拟化中间件用来将一个处理单元的数据变化复制到其他活动的处理单元上。
image.png

图 5-1. 基于空间的架构模式

虚拟化中间件组件处理内部管理和通信。它包含控制数据同步和请求处理的各个方面的组件。虚拟化中间件包括消息传递网格、数据网格、生产网格和部署管理器。下一节将详细介绍这些组件，它们可以自定义编写或作为第三方产品购买。

模式动力学

基于空间的架构模式的魅力在于虚拟化的中间件组件和每个处理单元中包含的内存数据网格。图 5-2 显示了典型的处理单元架构，包括应用模块、内存数据网格、用于故障转移的可选异步持久性存储以及数据复制引擎。虚拟化中间件本质上是架构的控制器，管理请求、会话、数据复制、分布式请求处理和处理单元部署。虚拟化中间件有四个主要架构组件：消息网格、数据网格、处理网格和部署管理器。
image.png

图 5-2. 处理单元组件

消息网格

图 5-3 所示的消息传递网格，管理着输入请求和会话信息。当一个请求进入虚拟化中间件组件时，消息传递网格组件确定哪些活动的处理组件可以接收该请求，并将该请求转发给这些处理单元之一。信息传递网格的复杂程度可以从简单的轮流算法到更复杂的下一个可用算法，该算法可以跟踪哪个请求正在被哪个处理单元处理。
image.png

图 5-3. 消息网格组件

数据网格

数据网格组件可能是这个模式中最重要和最关键的组件。数据网格与每个处理单元的数据复制引擎互动，在数据更新时管理处理单元之间的数据重复。由于消息传递网格可以将请求转发给任何一个可用的处理单元，因此每个处理单元在其内存数据网格中包含完全相同的数据是至关重要的。虽然 图 5-4 显示了处理单元之间的同步数据复制，但实际上这是异步并行完成的，而且速度非常快，有时在微秒（百万分之一秒）的时间内就完成了数据同步。
image.png

图 5-4. 数据网格组件

处理网格

处理网格，如 图 5-5 所示，是虚拟化中间件中的一个可选的组件，当有多个处理单元，每个处理单元处理一部分应用程序时，它管理分布式请求处理。如果一个请求需要处理单元类型之间的协调（例如，一个订单处理单元和一个客户处理单元），那么处理网格将在这两个处理单元之间调解和协调该请求。
image.png

图 5-5. 处理网格组件

部署管理器

部署管理器组件根据负载情况管理处理单元的动态启动和关闭。该组件持续监控响应时间和用户负载，并在负载增加时启动新的处理单元，而在负载减少时关闭处理单元。它是实现应用程序内可变可伸缩性需求的一个关键组件。

一些思考

基于空间的架构模式是一个复杂而昂贵的实现模式。对于具有可变负载的小型网络应用（如社交媒体网站、投标和拍卖网站）来说，它是一个不错的架构选择。然而，它不太适合传统的具有大量操作数据的大规模关系型数据库应用。虽然基于空间的架构模式不需要一个集中的数据存储，但通常包括一个数据存储来执行初始的内存数据网格加载和异步保持处理单元的数据更新。创建单独的分区，将易失性和广泛使用的交易数据与非活动数据隔离开来，以减少每个处理单元内的内存网格的内存占用，这也是一种常见做法。

需要注意的是，虽然这种模式的替代名称是基于云的架构，但处理单元（以及虚拟化的中间件）不一定要驻扎在基于云的服务或 PaaS（平台即服务）上。它也可以很容易地驻留在本地服务器上，这是我更喜欢 “基于空间的架构” 这一名称的原因之一。

从产品实现的角度来看，你可以通过第三方产品来实现这种模式中的许多架构组件，如 GemFire、JavaSpaces、GigaSpaces、IBM Object Grid、nCache 和 Oracle Coherence。由于这种模式的实施在成本和能力（特别是数据复制时间）方面有很大的不同，作为一个架构师，在进行任何产品选择之前，你应该首先确定你的具体目标和需求是什么。

模式分析

下表包含了对天基架构模式的常见架构特征的评级和分析。每个特征的评级是基于该特征作为一种能力的自然趋势，基于该模式的典型实现，以及该模式的普遍知名度。关于该模式与本报告中其他模式的关系的侧面比较，请参考本报告末尾的 附录 A。

整体敏捷性评级：高

整体敏捷性是指对不断变化的环境做出快速反应的能力。由于处理单元（应用程序的部署实例）可以快速地被提起和放下，应用程序对与用户负载的增加或减少（环境变化）有关的变化反应良好。使用这种模式创建的架构通常对编码变化反应良好，因为这种模式的应用规模小，且具有动态性质。

易于部署的评级：高

虽然基于空间的架构通常不是解耦和分布式的，但它们是动态的，复杂的基于云的工具允许应用程序很容易被 “推” 到服务器上，简化了部署。

可测试性等级：低

在测试环境中实现非常高的用户负载既昂贵又耗时，使得测试应用程序的可扩展性方面变得困难。

性能评级：高

高性能是通过该模式中的内存数据访问和缓存机制实现的。

可扩展性评级：高

高可扩展性来自于几乎没有对集中式数据库的依赖，因此基本上从可扩展性方程中消除了这个限制性瓶颈。

易于开发的评级：低

复杂的缓存和内存数据网格产品使这种模式的开发相对复杂，主要是因为对用于创建这种架构的工具和产品不熟悉。此外，在开发这些类型的架构时必须特别小心，以确保源代码中没有任何东西影响性能和可扩展性。