精华内容
下载资源
问答
  • 常见的软件架构

    2019-06-19 17:08:00
    软件架构 定义:用来指导软件开发的一种思想,目前来说最常见的两种架构模式是 B/S 和 C/S B : browser 浏览器 C: client 客户端 S: server 服务端 两种架构的比较 标准:相对于C/S架构来说,B/S...

    软件架构

    • 定义:用来指导软件开发的一种思想,目前来说最常见的两种架构模式是 B/S 和 C/S
      • B : browser  浏览器
      • C:  client      客户端
      • S:  server     服务端
    • 两种架构的比较
      • 标准:相对于C/S架构来说,B/S架构的两端都是使用现成的成熟产品,所以B/S会显示的标准一些
      • 效率:B/S架构中所有数据的处理都来自于服务器端,浏览器只负责展示服务器处理后的数据结果,而C/S架构中的客户端会分担一些数据的处理,所以C/S执行的效率会高一些
      • 安全:B/S架构当中的数据传输都是以http协议进行的输出,而http协议是明文传输,可以被抓包,所以相对于C/S来说,B/S不是很安全
      • 升级:B/S架构只需要在服务器端进行更新,前台只需要刷新页面,C/S架构需要两端都进行更新
      • 开发成本:C/S架构的客户端需要自己开发,B/S的两端都不要自己开发

    转载于:https://www.cnblogs.com/SakuraYuanYuan/p/11052524.html

    展开全文
  • 五种最常见的软件架构 文章摘录自阮老师的:《软件架构入门》,架构很入门的文章,强烈推荐! 软件架构(software architecture)就是软件的基本结构。O’Reilly 出版过一本小册子《Software Architecture Patterns...

    五种最常见的软件架构

    文章摘录自阮老师的:《软件架构入门》,架构很入门的文章,强烈推荐!

    软件架构(software architecture)就是软件的基本结构。O’Reilly 出版过一本小册子《Software Architecture Patterns》(PDF), 介绍了五种最常见的软件架构,是非常好的入门读物。

    一、分层架构

    分层架构(layered architecture)是最常见的软件架构,也是事实上的标准架构。如果你不知道要用什么架构,那就用它。
    这种架构将软件分成若干个水平层,每一层都有清晰的角色和分工,不需要知道其他层的细节。层与层之间通过接口通信。虽然没有明确约定,软件一定要分成多少层,但是四层的结构最常见。
    在这里插入图片描述

    • 表现层(presentation):用户界面,负责视觉和用户互动
    • 业务层(business):实现业务逻辑
    • 持久层(persistence):提供数据,SQL 语句就放在这一层
    • 数据库(database) :保存数据

    有的软件在逻辑层和持久层之间,加了一个服务层(service),提供不同业务逻辑需要的一些通用接口。
    用户的请求将依次通过这四层的处理,不能跳过其中任何一层。
    在这里插入图片描述

    • 优点
    • 结构简单,容易理解和开发
    • 不同技能的程序员可以分工,负责不同的层,天然适合大多数软件公司的组织架构
    • 每一层都可以独立测试,其他层的接口通过模拟解决
    • 缺点
    • 一旦环境变化,需要代码调整或增加功能时,通常比较麻烦和费时
    • 部署比较麻烦,即使只修改一个小地方,往往需要整个软件重新部署,不容易做持续发布
    • 软件升级时,可能需要整个服务暂停
    • 扩展性差。用户请求大量增加时,必须依次扩展每一层,由于每一层内部是耦合的,扩展会很困难

    二、事件驱动架构

    事件(event)是状态发生变化时,软件发出的通知。
    事件驱动架构(event-driven architecture)就是通过事件进行通信的软件架构。它分成四个部分。
    在这里插入图片描述

    • 事件队列(event queue):接收事件的入口
    • 分发器(event mediator):将不同的事件分发到不同的业务逻辑单元
    • 事件通道(event channel):分发器与处理器之间的联系渠道
    • 事件处理器(event processor):实现业务逻辑,处理完成后会发出事件,触发下一步操作

    对于简单的项目,事件队列、分发器和事件通道,可以合为一体,整个软件就分成事件代理和事件处理器两部分。
    在这里插入图片描述

    • 优点
    • 分布式的异步架构,事件处理器之间高度解耦,软件的扩展性好
    • 适用性广,各种类型的项目都可以用
    • 性能较好,因为事件的异步本质,软件不易产生堵塞
    • 事件处理器可以独立地加载和卸载,容易部署
    • 缺点
    • 涉及异步编程(要考虑远程通信、失去响应等情况),开发相对复杂
    • 难以支持原子性操作,因为事件通过会涉及多个处理器,很难回滚
    • 分布式和异步特性导致这个架构较难测试

    三、微核架构

    微核架构(microkernel architecture)又称为"插件架构"(plug-in architecture),指的是软件的内核相对较小,主要功能和业务逻辑都通过插件实现。

    内核(core)通常只包含系统运行的最小功能。插件则是互相独立的,插件之间的通信,应该减少到最低,避免出现互相依赖的问题。
    在这里插入图片描述

    • 优点
    • 良好的功能延伸性(extensibility),需要什么功能,开发一个插件即可
    • 功能之间是隔离的,插件可以独立的加载和卸载,使得它比较容易部署,
    • 可定制性高,适应不同的开发需要
    • 可以渐进式地开发,逐步增加功能
    • 缺点
    • 扩展性(scalability)差,内核通常是一个独立单元,不容易做成分布式
    • 开发难度相对较高,因为涉及到插件与内核的通信,以及内部的插件登记机制

    四、微服务架构

    微服务架构(microservices architecture)是服务导向架构(service-oriented architecture,缩写 SOA)的升级。

    每一个服务就是一个独立的部署单元(separately deployed unit)。这些单元都是分布式的,互相解耦,通过远程通信协议(比如REST、SOAP)联系。
    在这里插入图片描述

    微服务架构分成三种实现模式。

    • RESTful API 模式:服务通过 API 提供,云服务就属于这一类

    • RESTful 应用模式:服务通过传统的网络协议或者应用协议提供,背后通常是一个多功能的应用程序,常见于企业内部

    • 集中消息模式:采用消息代理(message broker),可以实现消息队列、负载均衡、统一日志和异常处理,缺点是会出现单点失败,消息代理可能要做成集群

    • 优点

    • 扩展性好,各个服务之间低耦合
    • 容易部署,软件从单一可部署单元,被拆成了多个服务,每个服务都是可部署单元
    • 容易开发,每个组件都可以进行持续集成式的开发,可以做到实时部署,不间断地升级
    • 易于测试,可以单独测试每一个服务
    • 缺点
    • 由于强调互相独立和低耦合,服务可能会拆分得很细。这导致系统依赖大量的微服务,变得很凌乱和笨重,性能也会不佳。
    • 一旦服务之间需要通信(即一个服务要用到另一个服务),整个架构就会变得复杂。典型的例子就是一些通用的 Utility 类,一种解决方案是把它们拷贝到每一个服务中去,用冗余换取架构的简单性。
    • 分布式的本质使得这种架构很难实现原子性操作,交易回滚会比较困难。

    五、云架构

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

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

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

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

    在这里插入图片描述
    虚拟中间件又包含四个组件:

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

    2020-01-21 17:17:25
    分层架构(layered architecture)是最常见的软件架构,也是事实上的标准架构。如果你不知道要用什么架构,那就用它。 这种架构将软件分成若干个水平层,每一层都有清晰的角色和分工,不需要知道其他层的细节。层与...

    转载地址

    一、分层架构

    分层架构(layered architecture)是最常见的软件架构,也是事实上的标准架构。如果你不知道要用什么架构,那就用它。

    这种架构将软件分成若干个水平层,每一层都有清晰的角色和分工,不需要知道其他层的细节。层与层之间通过接口通信。

    虽然没有明确约定,软件一定要分成多少层,但是四层的结构最常见。

    • 表现层(presentation):用户界面,负责视觉和用户互动
    • 业务层(business):实现业务逻辑
    • 持久层(persistence):提供数据,SQL 语句就放在这一层
    • 数据库(database) :保存数据

    有的软件在逻辑层和持久层之间,加了一个服务层(service),提供不同业务逻辑需要的一些通用接口。

    用户的请求将依次通过这四层的处理,不能跳过其中任何一层。

    优点

    • 结构简单,容易理解和开发
    • 不同技能的程序员可以分工,负责不同的层,天然适合大多数软件公司的组织架构
    • 每一层都可以独立测试,其他层的接口通过模拟解决

    缺点

    • 一旦环境变化,需要代码调整或增加功能时,通常比较麻烦和费时
    • 部署比较麻烦,即使只修改一个小地方,往往需要整个软件重新部署,不容易做持续发布
    • 软件升级时,可能需要整个服务暂停
    • 扩展性差。用户请求大量增加时,必须依次扩展每一层,由于每一层内部是耦合的,扩展会很困难

    二、事件驱动架构

    事件(event)是状态发生变化时,软件发出的通知。

    事件驱动架构(event-driven architecture)就是通过事件进行通信的软件架构。它分成四个部分。

    • 事件队列(event queue):接收事件的入口
    • 分发器(event mediator):将不同的事件分发到不同的业务逻辑单元
    • 事件通道(event channel):分发器与处理器之间的联系渠道
    • 事件处理器(event processor):实现业务逻辑,处理完成后会发出事件,触发下一步操作

    对于简单的项目,事件队列、分发器和事件通道,可以合为一体,整个软件就分成事件代理和事件处理器两部分。

    优点

    • 分布式的异步架构,事件处理器之间高度解耦,软件的扩展性好
    • 适用性广,各种类型的项目都可以用
    • 性能较好,因为事件的异步本质,软件不易产生堵塞
    • 事件处理器可以独立地加载和卸载,容易部署

    缺点

    • 涉及异步编程(要考虑远程通信、失去响应等情况),开发相对复杂
    • 难以支持原子性操作,因为事件通过会涉及多个处理器,很难回滚
    • 分布式和异步特性导致这个架构较难测试

    三、微核架构

    微核架构(microkernel architecture)又称为"插件架构"(plug-in architecture),指的是软件的内核相对较小,主要功能和业务逻辑都通过插件实现。

    内核(core)通常只包含系统运行的最小功能。插件则是互相独立的,插件之间的通信,应该减少到最低,避免出现互相依赖的问题。

    优点

    • 良好的功能延伸性(extensibility),需要什么功能,开发一个插件即可
    • 功能之间是隔离的,插件可以独立的加载和卸载,使得它比较容易部署,
    • 可定制性高,适应不同的开发需要
    • 可以渐进式地开发,逐步增加功能

    缺点

    • 扩展性(scalability)差,内核通常是一个独立单元,不容易做成分布式
    • 开发难度相对较高,因为涉及到插件与内核的通信,以及内部的插件登记机制

    四、微服务架构

    微服务架构(microservices architecture)是服务导向架构(service-oriented architecture,缩写 SOA)的升级。

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

    微服务架构分成三种实现模式。

    • RESTful API 模式:服务通过 API 提供,云服务就属于这一类
    • RESTful 应用模式:服务通过传统的网络协议或者应用协议提供,背后通常是一个多功能的应用程序,常见于企业内部
    • 集中消息模式:采用消息代理(message broker),可以实现消息队列、负载均衡、统一日志和异常处理,缺点是会出现单点失败,消息代理可能要做成集群

    优点

    • 扩展性好,各个服务之间低耦合
    • 容易部署,软件从单一可部署单元,被拆成了多个服务,每个服务都是可部署单元
    • 容易开发,每个组件都可以进行持续集成式的开发,可以做到实时部署,不间断地升级
    • 易于测试,可以单独测试每一个服务

    缺点

    • 由于强调互相独立和低耦合,服务可能会拆分得很细。这导致系统依赖大量的微服务,变得很凌乱和笨重,性能也会不佳。
    • 一旦服务之间需要通信(即一个服务要用到另一个服务),整个架构就会变得复杂。典型的例子就是一些通用的 Utility 类,一种解决方案是把它们拷贝到每一个服务中去,用冗余换取架构的简单性。
    • 分布式的本质使得这种架构很难实现原子性操作,交易回滚会比较困难。

    五、云架构

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

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

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

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

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

    • 消息中间件(Messaging Grid):管理用户请求和session,当一个请求进来以后,决定分配给哪一个处理单元。
    • 数据中间件(Data Grid):将数据复制到每一个处理单元,即数据同步。保证某个处理单元都得到同样的数据。
    • 处理中间件(Processing Grid):可选,如果一个请求涉及不同类型的处理单元,该中间件负责协调处理单元
    • 部署中间件(Deployment Manager):负责处理单元的启动和关闭,监控负载和响应时间,当负载增加,就新启动处理单元,负载减少,就关闭处理单元。

    优点

    • 高负载,高扩展性
    • 动态部署

    缺点

    • 实现复杂,成本较高
    • 主要适合网站类应用,不合适大量数据吞吐的大型数据库应用
    • 较难测试

    http://www.ruanyifeng.com/blog/2016/09/software-architecture.html

    对javaer来说,分层架构的实例很多;事件驱动架构最经典的就是Netty,还有Spring mvc;插件架构最经典的就是eclipse,还有Shiro;微服务架构可以了解一下Spring boot和Spring cloud,国内的dubbo也很流行;云架构估计只有大公司才有。

    展开全文
  • #10种常见的软件架构模式 飞机票链接

    #10种常见的软件架构模式

    飞机票链接

    展开全文
  • 分层架构(layered architecture)是最常见的软件架构,也是事实上的标准架构。如果你不知道要用什么架构,那就用它。 这种架构将软件分成若干个水平层,每一层都有清晰的角色和分工,不需要知道其他层的细节。层与...
  • 10种常见的软件架构模式-快速记忆 这里通过数字宫殿的方法快速记忆10种常见的设计模式,通过记忆名字+理解的情况下熟悉常见的软件架构模式 文章目录10种常见的软件架构模式-快速记忆前言一、快速记忆二、详细解释...
  • Web开发常见的软件架构 一、看需求分析,看产品PRD:Product Requirement Document 二、根据PRD和产品原型建数据库表,注意三范式要求,用工具到处数据库关系图,并快速地理清数据库思路 三、搭建项目架构,...
  • 架构模式是在给定上下文中解决软件架构中常见问题的通用、可重用的解决方案。架构模式类似于软件设计模式,但范围更广。 在本文中,我会简单介绍下列10种常见的架构模式,及其用途、优势和劣势。 分层模式 该模式可...
  • 分层架构(layered architecture)2. 事件驱动架构(event-driven architecture)3. 微核架构(microkernel architecture)or 插件架构(plug-in architecture)4. 微服务架构(microservices architecture)5. 云...
  • 5种最常见的软件架构

    2018-11-30 10:08:19
    软件架构(software architecture)就是软件基本结构。 先把一个软件系统想象成一个黑盒子,可以实现某些业务功能。 那么你会不会好奇这个黑盒子里面内容是什么,具有怎样结构? 你可以想象这个黑盒子里有...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,744
精华内容 1,497
关键字:

常见的软件架构