首页 > 编程知识 正文

各种软件架构,软件架构的概念

时间:2023-05-06 06:25:31 阅读:217160 作者:3166

五篇最常见的软件体系结构文章摘自xxdhm的《软件架构入门》。 体系结构是一篇入门文章,强烈推荐。

软件体系结构(software architecture )是软件的基本结构。 o’Reilly出版了小册子《Software Architecture Patterns》(pdf ),介绍了5种最常见的软件体系结构,是一本非常好的入门书。

另一方面,分层结构分层结构(layered architecture)是最常见的软件结构,也是事实上的标准结构。 如果你不知道使用什么样的架构,就用它。

该体系结构将软件分为几个级别,每个级别都有明确的作用和分工,无需了解其他级别的细节。 层和层之间通过接口进行通信。 虽然没有明确规定必须将软件分为多少层,但四个层的结构是最常见的。

提供表示层用户接口、负责视觉和用户交互的业务层(business )实现业务逻辑持久层的数据,SQL语句是这一层的数据库一些存储数据的软件在逻辑层和持久层之间添加了服务层

用户请求依次通过这四个层次结构的处理,不能跳过任何一个层次结构。

优点结构简单,容易理解,容易开发不同技能的程序员,能够担当不同的层。 自然适合很多软件公司的组织结构可以每层独立测试。 其他层的界面通过仿真解决了缺点,当环境发生变化,需要调整代码和增加功能时,通常比较麻烦、费时,部署也比较麻烦。 即使只修改小的地方,也经常需要重新部署整个软件,如果很难继续发布软件的升级,则整个服务的暂停可扩展性可能很差。 在用户要求大幅增加的情况下,必须依次扩展各层,因为各层内部结合在一起,所以扩展很困难。 二、事件驱动架构事件(event )是当状态改变时来自软件的通知。

事件驱动体系结构(event-driven architecture)是通过事件进行通信的软件体系结构。 它分为四个部分。

用于接收“事件队列”(event queue )事件的入口调度器(event mediator )将不同的事件分发到不同业务逻辑单元的“事件通道”(event channel )。 调度程序和处理器之间的联系通道事件处理器(event processor )实现业务逻辑,并在处理完成时发出事件

优点分布式异步架构,事件处理器间高级解耦,软件可扩展性和适应性广,在各种类型的项目中性能良好。 由于事件异步的本质,软件不易堵塞的事件处理器可以独立加载和卸载,容易部署,这一缺点与异步编程有关,开发相对复杂,难以支持原子操作。 由于事件的传递涉及多个处理器,难以回滚分布式和异步特性,该结构难以测试三、微核结构的微核结构(microkernel architecture),“插件体系结构”

内核(core )通常只包含系统执行的最小功能。 插件相互独立,为了不发生相互依存的问题,应该将插件之间的通信抑制到最小限度。

良好的功能可扩展性(extensibility )易于部署、可定制、可增量部署,因为开发插件时功能相互隔离,插件可以独立加载和卸载内核通常是独立的单元。 插件与内核的通信以及内部插件注册机制4、微服务体系结构微服务体系结构(microservices architecture)是面向服务的体系结构(service-orvice )

每个服务都是独立的部署单元(separately deployed unit )。 这些单元都是分布式的,相互解耦,通过REST、SOAP等远程通信协议进行联系。

http://www.Sina.com/rest风格的API模式:服务通过API提供,云服务属于此类

rest风格的APP应用模型:服务以传统网络协议或APP应用协议提供,背后通常是企业中常见的多功能APP

集中消息模式:消息阻止程序提供消息队列、负载平衡、统一日志和异常处理。 其缺点是可能出现单点故障,导致消息代理群集化

好处

可扩展性好,各服务之间低耦合,易于部署,软件从单个可部署单元分解为多个服务,各服务易于在可部署单元上开发,各组件可持续集成开发,可实时部署,无中断升级为了强调相互独立和低耦合,服务有可能被细分。 结果,系统依赖于许多微服务器,既杂乱又笨重

性能也会不佳。一旦服务之间需要通信(即一个服务要用到另一个服务),整个架构就会变得复杂。典型的例子就是一些通用的 Utility 类,一种解决方案是把它们拷贝到每一个服务中去,用冗余换取架构的简单性。分布式的本质使得这种架构很难实现原子性操作,交易回滚会比较困难。 五、云架构

云结构(cloud architecture)主要解决扩展性和并发的问题,是最容易扩展的架构。

它的高扩展性,主要原因是没使用中央数据库,而是把数据都复制到内存中,变成可复制的内存数据单元。然后,业务处理能力封装成一个个处理单元(prcessing unit)。访问量增加,就新建处理单元;访问量减少,就关闭处理单元。由于没有中央数据库,所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里,最好要进行数据持久化。

这个模式主要分成两部分:处理单元(processing unit)和虚拟中间件(virtualized middleware)。

处理单元:实现业务逻辑虚拟中间件:负责通信、保持sessions、数据复制、分布式处理、处理单元的部署。


虚拟中间件又包含四个组件:

消息中间件(Messaging Grid):管理用户请求和session,当一个请求进来以后,决定分配给哪一个处理单元。数据中间件(Data Grid):将数据复制到每一个处理单元,即数据同步。保证某个处理单元都得到同样的数据。处理中间件(Processing Grid):可选,如果一个请求涉及不同类型的处理单元,该中间件负责协调处理单元部署中间件(Deployment Manager):负责处理单元的启动和关闭,监控负载和响应时间,当负载增加,就新启动处理单元,负载减少,就关闭处理单元。 优点 高负载,高扩展性动态部署 缺点 实现复杂,成本较高主要适合网站类应用,不合适大量数据吞吐的大型数据库应用较难测试

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。