大多数基于 Web 的业务应用都有着相似的请求流程：来自浏览器的请求首先到达 Web 服务器，然后是业务服务器，最后到达数据库服务器。 随着用户负载的增加，系统的瓶颈开始出现。首先是在 Web 服务器层，然后是业务服务器层，最后是数据库服务器层。为了解决瓶颈问题，通常我们会先横向扩展 Web 服务器。因为扩展 Web 服务器相对容易且便宜，有时可以解决瓶颈问题。然而，在大多数高用户负载的情况下，横向扩展 Web 服务器层只会将瓶颈向下移动到业务服务器。扩展业务服务器可能比 Web 服务器更复杂、更昂贵，并且通常也只是将瓶颈转移到数据库服务器上，而数据库服务器的扩展更加困难和昂贵。即使您可以扩展数据库，最终得到的是三角形拓扑，三角形最宽的部分是 Web 服务器（最容易扩展），最小的部分是数据库（最难扩展）。

在任何并发用户负载非常大的大容量应用中，数据库通常是系统可以同时处理多少事务的最终限制因素。虽然各种缓存技术和数据库扩展产品有助于解决问题，但为极端负载扩展普通应用是一个非常浪费且抵消的选择。

基于空间的架构模式（space-based architecture，也叫云架构模式，cloud architecutre）专门设计用于解决可伸缩性和并发性问题。对于具有可变且不可预测的并发用户量的应用，它也是一种有用的架构模式。

模式介绍

基于空间的架构模式最大限度的减少了限制应用程序扩展的因素。

通过消除中央数据库约束并改用可复制的内存数据网格来实现高可伸缩性。应用的数据保存在内存中，并在所有活动的处理单元（processing unit）之间复制。随着用户负载的增加和减少，处理单元可以动态启动和关闭，从而解决可变的可扩展性。因为没有中央数据库，所以消除了数据库瓶颈，给应用提供了近乎无限的可扩展性。

上图展示了基于空间的架构模式的基本结构，有两个主要组成部分：处理单元（processing unit）和虚拟化中间件（virtualized middleware）。

处理单元

处理单元通常包含业务模块（application module），以及内存中的数据网格（in-memory data grid）和用于故障转移的可选异步持久化存储（asynchronous persistence store）。它还包含一个数据复制引擎（data-replication engine），虚拟化中间件使用该复制引擎将一个处理单元所做的数据更改复制到其他活动处理单元中。下图展示了处理单元架构图。

虚拟化中间件

虚拟化中间件负责处理内务和通信，管理请求、会话、数据复制、分布式请求处理和流程单元部署，是整个架构的控制器。虚拟化中间件中有四个主要架构组件：消息网格（messaging grid）、数据网格（data grid）、处理网格（processing grid）和部署管理器（deployment manager）。

消息网格

上图展示了消息网格是如何处理请求和会话信息的。当请求进入虚拟化中间件时，消息网格确定哪些活动处理单元可用于接收请求并将请求转发到这些处理单元中的某一个。

数据网格

上图展示了数据网格的工作方式。数据网格应该是整个架构模式中最重要的一块了。数据网格与每个处理单元中的数据复制引擎交互，从而在发生数据更新时，在处理单元之间复制数据。由于消息网格可以将请求转发到任何可用的处理单元，因此每个处理单元在其内存数据网格中包含完全相同的数据至关重要，数据网格的数据复制通常是在毫秒级。

处理网格

上图展示了处理网格的工作方式。处理网格是虚拟化中间件中的一个可选组件，当有多个处理单元，每个处理单元实现应用的一部分功能时，它负责管理分布式请求处理。如果一个请求需要在处理单元类型（例如，订单处理单元和客户处理单元）之间进行协调，则处理网格会在这两个处理单元之间协调请求。

部署管理器

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

其他说明

基于空间的架构模式比较复杂，适用于具有可变负载的小型基于 Web 的应用（例如，社交媒体网站），它不太适合具有大量操作数据的传统大型关系数据库应用。

尽管基于空间的架构模式不需要集中式数据存储，但通常会包含一个集中式数据存储，用于执行初始内存数据网格数据加载和处理单元进行的异步持久化数据更新。

小结

因为处理单元可以快速启动和关闭，应用可以很好地响应与用户负载增加或减少相关的环境变化。

尽管基于空间的架构通常不是解耦和分布式的，但它们是动态的，并且各种基于云的复杂工具可以将应用轻松“推送”到服务器，从而简化部署。

通过该模式中内置的内存数据访问和缓存机制可以轻松实现高性能。

由于该模式减少了对集中式数据库的依赖或完全不依赖，从本质上消除了瓶颈限制，是的该模式具备很强的可扩展性。

除了以上优势以外，基于空间的架构模式也存在弱势。

在测试环境通过模拟大数据量的用户负载是非常复杂的，因此比较难以测试。

复杂的缓存和内存数据网格使这种模式的开发相对复杂。此外，在开发这些类型的架构时必须特别小心，以确保源代码中的任何内容都不会影响性能和可伸缩性。

关注微信公众号，获取最新推送~

加微信，深入交流~