编辑推荐: |
本文主要介绍了软件架构模式-基于空间的架构相关内容。希望对你的学习有帮助。
本文来自于Harries Blog,由火龙果软件Linda编辑、推荐。 |
|
大部分Web应用的处理流程为:浏览器发起的请求精经过Web服务器、应用服务器和数据库服务器的处理。当用户量不大时这样的模式没有任何问题。但随着用户访问量的增加,系统开始出现性能瓶颈,首先是Web服务器层,其次是应用服务器层,最后是数据库服务器层。处理的措施通常是水平扩展Web服务器。这是比较容易实现的。但是用户量过大时,水平扩展Web服务层后,瓶颈会转移到应用服务层。应用服务层的水平扩展相对比较复杂一些了,也会导致瓶颈转移到数据库服务层。而数据库服务层扩展起来代价更高。
对于有大量用户并发访问的应用,通常数据库的并发处理事务量是关键的限制因素。尽管有很多缓存技术和数据库扩展工具可以解决该问题,但事实上扩展出可承受极端负载的应用是很难的。
基于空间的架构模式被设计用于解决扩展性和并发的问题。可用于有大量不可预测的并发用户量的应用。
模式描述
基于空间的架构模式(有时也称为云架构模式)将限制应用扩展的因素最小化了。它的名称来源于元组空间(tuple
space)的概念,也就是分布式共享内存的概念。通过冗余的内存中的数据网格代替数据库来实现高伸缩性。应用数据保存在内存中,并在所有活动的处理单元中保存一份副本。处理单元可以根据负载大小动态地添加或关闭。这样数据库的瓶颈就不存在了,提供了几乎可以无线扩展的能力。
该架构模式中有两个主要组件:处理单元(processing unit)和虚拟化中间件(virtualized
middleware)。如图1所示。处理单元组件包含应用组件(或部分应用组件),它包含Web组件和后端的业务逻辑。处理单元通常包含应用程序模块、内存中的数据网格和一个可选的异步持久化转移模块。还包含一个复制引擎供虚拟中间件调用,来同步各单元之间的数据变化。
图1 基于空间的架构
虚拟化中间件组件用于管理和通信。它包含可以控制各种数据同步和请求处理的组件。在虚拟化中间件内,有消息网格、数据网格、处理网格、调度管理器。
模式动态
基于空间架构的魔力在于虚拟化中间件和各个处理单元内部的内存中数据网格。图2所示,典型的处理组件包含应用模块、内存中数据网格、可选的异步持久化转移模块和数据复制引擎。
图2 处理单元组件
虚拟化中间件是该架构的控制器,处理请求、会话、数据复制、分布式请求处理、处理单元配置。主要有四种类型:消息网格、数据网格、处理网格、配置管理器。
消息网格
如图3所示,消息网格管理输入的请求和会话信息。当一个请求到达虚拟化中间件组件,消息网格组件决定哪些活动的处理组件是可以接收请求,并将其指派给某一个处理单元。可以使用简单的轮询算法,也可以跟踪处理单元的处理情况使用下一个可用的算法。
图3 消息网格组件
数据网格
数据网格组件在数据变化时和每个处理单元的数据复制引擎交互,进行同步数据。由于消息网格会将请求指派给任意一个处理单元,每个处理单元的内存中的数据必须是完全一致的。尽管图4中展示的是单元间的同步数据复制,实际上是异步完成的,处理时间在微秒级别。
图4 数据网格组件
处理网格
处理网格是可选的组件,用于协调和编排多个处理组件之间的分布式请求处理。
图5 处理网格
配置管理器
配置管理器组件持续监控响应时间和用户负载,动态地开启或关闭处理单元。它是决定应用可伸缩性的重要组件。
架构考量
基于空间的架构非常复杂,实现起来代价比较高。它对于负载不稳定的一些Web应用很有用,如媒体社交网站等。它不太适合使用传统的大规模关系数据库的应用。
尽管基于空间的架构不需要数据仓库,通常还是会建立一个数据仓库,用于初始化内存数据,并异步地将变化的数据持久化。通常还会创建独立的分区来分离非活跃数据和不稳定的以及大量使用的数据,来减少内存的占用。
该架构也叫基于云的架构,但是处理组件和虚拟化中间件不是必须部署在云服务或PaaS上,可以只是在本地服务器上。
有很多第三方产品实现该架构。如GemFire、JavaSpaces、GigaSpaces、IBM
Object Grid、nCache、Oracle Coherence。
模式分析
下表展示了分层架构模式的通用架构特性的评级和分析。
整体灵活性
评级:高
分析:整体灵活性是对环境变化快速响应的能力。处理单元(应用实例)可以很快地开启或关闭,应用可以快速响应用户负载的变化。
易于部署
评级:高分析:
尽管基于空间的架构不是低耦合且分布式的,但是它们是动态的,而且复杂的云管理工具可以轻松地将应用推送到服务器上,简化了部署。
可测试性
评级:低
分析:在测试环境模拟高用户负载是很困难的,因此测试应用的可伸缩性比较困难。
性能
评级:高
分析:数据存放在内存中加上缓存机制保证了应用的高性能。
可伸缩性
评级:高
分析:(几乎)不依赖中央数据库消除了扩展的瓶颈因素。
开发容易度
评级:低
分析:复杂的缓存和内存数据网格使得开发起来比较复杂。 |