大多数基于Web的业务应用程序遵循相同的一般请求流程：来自浏览器的请求命中Web服务器，然后是应用程序服务器，最后是数据库服务器。虽然这种模式适用于一小部分用户，但随着用户负载的增加，瓶颈开始出现，首先是在Web服务器层，然后是应用程序服务器层，最后是数据库服务器层。基于用户负载增加的常见瓶颈响应是扩展Web服务器。这相对简单且便宜，有时可以解决瓶颈问题。但是，在大多数用户负载较高的情况下，扩展Web服务器层只会将瓶颈向下移动到应用程序服务器。扩展应用程序服务器可能比Web服务器更复杂和昂贵，并且通常只是将瓶颈向下移动到数据库服务器，这对于扩展来说更加困难和昂贵。即使您可以扩展数据库，最终最终会得到的是三角形拓扑，三角形的最宽部分是Web服务器（最容易扩展），最小的部分是数据库（最难扩展）。
在任何具有极大并发用户负载的高容量应用程序中，数据库通常是您可以同时处理多少事务的最终限制因素。虽然各种缓存技术和数据库扩展产品有助于解决这些问题，但事实仍然是扩展极端负载的正常应用程序是一个非常困难的主张。
基于空间的体系结构模式专门用于解决和解决可伸缩性和并发性问题。对于具有可变和不可预测的并发用户卷的应用程序，它也是一种有用的体系结构模式。在架构上解决极端和可变的可伸缩性问题通常比尝试扩展数据库或将缓存技术改进为不可扩展的体系结构更好。

模式描述

基于空间的模式（有时也称为云架构模式）最大限度地减少了限制应用程序扩展的因素。这种模式的名称来源于元组空间 的概念，即分布式共享内存的概念。通过删除中央数据库约束并使用复制的内存数据网格来实现高可伸缩性。应用程序数据保存在内存中并在所有活动处理单元之间复制。随着用户负载的增加和减少，处理单元可以动态启动和关闭，从而解决可变的可扩展性问题。由于没有中央数据库，因此删除了数据库瓶颈，在应用程序中提供了近乎无限的可伸缩性。
适合此模式的大多数应用程序都是标准网站，它们从浏览器接收请求并执行某种操作。竞标拍卖网站就是一个很好的例子。该网站通过浏览器请求不断收到互联网用户的出价。该应用程序将收到特定项目的出价，使用时间戳记录该出价，并更新该项目的最新出价信息，并将该信息发送回浏览器。
此体系结构模式中有两个主要组件：处理单元和虚拟化中间件。图5-1 说明了基于空间的基本架构模式及其主要架构组件。
处理单元组件包含应用程序组件（或应用程序组件的一部分）。这包括基于Web的组件以及后端业务逻辑。处理单元的内容基于应用程序的类型而变化 - 较小的基于web的应用程序可能被部署到单个处理单元中，而较大的应用程序可以基于应用程序的功能区域将应用程序功能分成多个处理单元。处理单元通常包含应用程序模块，以及内存数据网格和用于故障转移的可选异步持久存储。它还包含一个复制引擎，虚拟化中间件使用该复制引擎将一个处理单元所做的数据更改复制到其他活动处理单元。

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

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

模式动力学

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

图5-2。处理单元组件

消息网格

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

数据网格

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

图5-3。消息网格组件

图5-4。数据网格组件

处理网格

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

图5-5。处理网格组件

部署经理

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

注意事项

基于空间的架构模式是一种复杂且昂贵的模式。对于具有可变负载的较小的基于web的应用程序（例如，社交媒体站点，投标和拍卖站点），它是良好的架构选择。但是，它不适合具有大量操作数据的传统大规模关系数据库应用程序。
尽管基于空间的体系结构模式不需要集中式数据存储，但通常包括一个用于执行初始内存数据网格加载并且异步地保持由处理单元进行的数据更新。通常的做法是创建单独的分区，将易失性和广泛使用的事务数据与非活动数据隔离，以减少每个处理单元内的内存数据网格的内存占用。
值得注意的是，虽然此模式的替代名称是基于云的体系结构，但处理单元（以及虚拟化中间件）不必驻留在基于云的托管服务或PaaS（平台即服务）上。它可以很容易地驻留在本地服务器上，这是我更喜欢名称“基于空间的架构”的原因之一。
从产品实现的角度来看，您可以通过第三方产品（如GemFire，JavaSpaces，GigaSpaces，IBM Object Grid，nCache和Oracle Coherence）实现此模式中的许多体系结构组件。由于此模式的实现在成本和功能（特别是数据复制时间）方面差异很大，因此作为架构师，您应首先确定您的特定目标和需求，然后再进行任何产品选择。

模式分析

整体敏捷
评级：高
分析：整体敏捷性是指能够快速响应不断变化的环境。由于处理单元（应用程序的已部署实例）可以快速启动和调低，因此应用程序可以很好地响应与用户负载（环境变化）增加或减少相关的变化。使用此模式创建的体系结构通常对编码更改做出很好的响应，因为应用程序的大小和模式的动态性质。

易于部署
评级：高
分析：虽然基于空间的体系结构通常不是分离和分布式的，但它们是动态的，而基于云的复杂工具允许将应用程序轻松地“推送”到服务器，从而简化部署。

可测性
评级：低
分析：在测试环境中实现非常高的用户负载既昂贵又耗时，使得难以测试应用程序的可伸缩性方面。

性能
评级：高
分析：通过内存数据访问和构建到此模式的缓存机制实现高性能。

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

易于开发
评级：低
分析：复杂的缓存和内存数据网格产品使得这种模式的开发相对复杂，主要是因为不熟悉用于创建此类架构的工具和产品。此外，在开发这些类型的体系结构时必须特别小心，以确保源代码中的任何内容都不会影响性能和可伸缩性。

参考链接：https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch05.html