「这是我参与2022首次更文挑战的第40天，活动详情查看：2022首次更文挑战」

基于空间的架构模式

大部分基于web的程序的请求都会经过以下流程: 浏览器发送请求道web server,到应用服务,最后到数据库. 用户少时,这种模式没有问题,当用户增多时,瓶颈就出现了, 第一个就是web server层,再是应用层,最后数据服务层也会出现. web server扩展会解决用户负载问题,这种处理方式相对便宜. 大多数情况下,用户负载会很高,扩展web server层, 瓶颈会出现在应用层.应用层的扩展相对昂贵一些, 直到最后瓶颈出现在数据库. 当各层都做了扩展,就变成了倒三角形的拓扑结构, 最上面最宽的是web server,易扩展, 最下面最杂的是数据库,最难扩展.

在大容量高并发程序中,数据库的最终限制是能并发处理多少事务. 缓冲技术和数据库扩展产品可以解决这些问题. 最终,应用层扩展到极限才是最困难的事.

基于空间的架构模式就是为了解决这个问题而设计的, (可伸缩性和并发问题),支持用户容量的可变和并发容量的可变.

比起缓冲技术/数据库扩展/应用程序扩展, 使用基于空间的架构模式会更好一点.

云架构模式

基于空间的架构模式,有时也称云架构.下面简称云架构.

云架构会尽量减少限制应用伸缩的因子. 云架构的想法来至分布式共享内存,概念来至tuple space. 通过冗余的内存数据网格代替中央数据库来实现高可伸缩性. 程序数据保存在内存中,并在活动的处理单元中都保持一份. 基于用户的负载,处理单元可动态启动和结束,这点是解决可伸缩的关键. 不存在中央数据库,那数据库的瓶颈就不存在了.

标准的web站点都适合使用这种模式, 标准的web站点,都是从浏览器接收请求,然后处理.

云架构有两类主要的组件:处理单元和虚拟化中间件. 处理单元包含应用组件(或者部分应用组件). 处理单元包含基于web的组件,也包含后端业务逻辑. 如果应用类型很小,web程序可能就部署在一个处理单元中, 如果应用类型很大,可按应用程序的功能拆分,部署在多个处理单元中. 处理单元一般包含应用模块/内存数据网格/可选的异步持久化存储(为了故障转移). 除此之外,处理单元还包含一个rc引擎(复制引擎), rc引擎由虚拟化中间件使用, 作用是将因处理单元引起的数据变更复制到其他活动的处理单元上.

虚拟化中间件负责管理和通讯. 虚拟化中间件类的组件包括"控制数据同步/请求处理的方方面面", 虚拟化中间件内部包含:消息网格/数据网格/处理网格/部署管理, 这些可以自己定制开发,或直接购买第三方的.

细说模式内部组件

云架构模式的魔力在于虚拟化中间件和每个处理单元内存中的数据网格.

虚拟化中间件本质上是架构控制器,且管理请求/会话/数据复制/分布式请求处理, 以及处理单元的部署.有4种主流的架构组件: 消息网格/数据网格/处理网格/部署管理.

消息网格

消息网格负责管理输入的请求信息和会话信息. 当虚拟化中间件组件收到一条请求时,消息网格决定有哪个处理组件接收, 并将请求传递给对应的处理组件.

决定请求由哪个处理组件处理,策略可简单可复杂, 简单的可以用轮询,复杂的可以用next-available算法 来跟踪哪个处理单元处理了哪个请求.

数据网格

云架构中最重要最关键的组件. 数据网格和每个处理单元中的数据复制引擎交互, 数据复制引擎(rc引擎)在数据有变更时负责同步. 消息网格可以将请求丢个任意一个处理单元, 那么每个处理单元内部维护的数据要保持一致就很有必要了.

数据的同步是并发异步,非常快,基本在微秒级.

处理网格

可选组件,当有多个处理单元时负责分布式请求的编排和协调, 让处理单元只处理一部分. 如果一个请求要跨多个处理组件(eg:请求要跨订单处理和用户处理), 此时处理网格就要编排和协调了.

部署管理

基于负载动态起停处理单元,部署管理组件不断监听响应时间和用户负载, 视情况对处理单元进行启动和停止.对于可变伸缩性的需求, 部署管理是关键.

注意事项

云架构的实现非常复杂和昂贵,对于可变伸缩性的需求,这个架构是好选择, 对于传统的高可伸缩性关系数据库程序(还带大量数据操作的),云架构不适合.

没有中央数据库,初始通过数据网格加载,后面的数据变更做异步持久化. 创建单独的分区也是常见做法,分区是隔离的,将经常使用的数据和非活动数据分区, 分区的好处是减少每个处理单元内存中数据网格的内存占用量.

云架构,处理单元不是非得基于云主机或paas,本地也是ok的.

从产品实施角度,这个架构中很多组件都可以使用第三方产品. 云架构的实现在成本和功能上有很大的差异,功能主要体现在数据复制上, 所以在决策时需要明确知道目标和需求.

模式分析

具体见附录

整体灵活性

高,处理单元可快速起停,利用这点可以快速适应变更.

部署难度

低,松耦合和分布式,利用云工具可以方便的进行部署.

可测试性

低,测试环境下的高用户负载,很花时间也花钱, 很难测试可伸缩的方方面面.

性能

高,内存访问和缓冲机制注定高效.

可伸缩性

高,高可伸缩性的瓶颈来至中央数据库的依赖, 云架构没有中央数据库,也就没有来至数据库的瓶颈.

开发难度

高,复杂的缓存和内存数据网格产品提高了开发难度, 缺少云架构相关的工具和产品也是难点之一.