精华内容
下载资源
问答
  • 程序员必知的几种软件架构模式

    千次阅读 2020-10-27 14:11:45
    程序员必知的几种软件架构模式前序分层架构模式多层模式管道 - 过滤器架构客户端 - 服务器架构模型 - 视图 - 控制器架构(MVC)事件驱动架构微服务架构 前序 架构模式是对给定上下文的软件架构中常见问题的一种通用...

    前序

    架构模式是对给定上下文的软件架构中常见问题的一种通用的可复用的解决方案。

    一种模式就是特定上下文的问题的一种解决方案。

    然而,很多开发者至今还对各种软件架构模式之间的差别搞不清,甚至对其所知甚少。

    大体上,主要有下面这几种架构模式:

    • 分层架构

    • 管道 - 过滤器架构

    • 客户端 - 服务器架构

    • 模型 - 视图 - 控制器架构

    • 事件驱动架构

    • 微服务架构

    程序员必知的几种软件架构模式

    分层架构模式

    最常见的架构模式就是分层架构或者称为 n 层架构。

    大部分软件架构师、设计师和开发者都对这个架构模式非常熟悉。尽管对于层的数量和类型没有具体限制,但大部分分层架构主要由四层组成:展现层、业务层、持久层和数据库层,如下图所示。

    一个很流行的 n 层架构示例

    一个很流行的 n 层架构示例

    上下文
    所有复杂的系统都会经历独立地发展和衍化系统各个部分的需要。出于这个原因,系统开发者需要对关注点进行清晰且条理分明的分离,以便系统的各个模块可以独立地开发和维护。

    问题
    软件需要以这样一种方式分割:各个模块可以独自开发和衍化,各自部分之间的交互非常少,支持可移植性、可修改性和复用性。

    方案
    为了实现关注点分离,分层模式将软件分割成各个单元(称为“层”)。每一层都是一组模块,提供了一组高内聚的服务。其使用必须是单向的。层将一组软件作为一个完整的分区,每个分区暴露一个公开接口。

    • 第一个概念是,每一层都有特定的角色和职责。例如,展现层负责处理所有的用户界面。分层架构的这种关注点分离,让构建高效的角色和职责非常简单。
    • 第二个概念是,分层架构模式是一个技术性的分区架构,而非一个领域性的分区架构。它们是由组件组成的,而不是领域。
    • 最后一个概念是,分层架构中的每一层都被标记为封闭或者开放。封闭层意味着请求从一层移到另一层,它必须通过它正下面的这一层才能达到下面这一层的再下一层。请求不能跳过任何层。

    在这里插入图片描述

    封闭层和请求访问

    弱点
    分层会导致性能下降。这种模式不适合高性能应用程序,因为经过架构中的多层来实现一个业务请求的效率是不高的。

    分层还会增加系统的前期成本和复杂性。

    用途
    我们应该将这种方式应用于小型简单的应用程序或网站。对于预算和时间非常紧张的场景,这是一个不错的选择。

    多层模式

    方案
    在这里插入图片描述

    一个多层模式示例:消费者网站 J2EE

    许多系统的执行结构被组织成一系列逻辑组件分组。每个分组被称为一个层。

    上下文
    在一个分布式部署中,通常需要将系统的基础设施分到不同的子集中。

    问题
    我们如何将系统分割到多个计算上独立的执行结构:由一些通信媒介连接的软件和硬件组?

    弱点
    大量前期成本和复杂性。

    用途
    用在分布式系统中。

    管道 - 过滤器架构

    软件架构中反复出现的一种模式是管道 - 过滤器(pipe-filter)模式。
    在这里插入图片描述

    管道过滤器模式

    上下文

    许多系统需要转换从输入到输出的离散数据流。许多类型转换在实践中重复出现,因此将其创建成独立的可复用的部分,这是比较理想的。

    问题

    这些系统需要被分割成可复用的松耦合的组件,组件之间拥有简单通用的交互机制。这样它们就可以灵活地相互结合。这些通用松耦合的组件就很容易复用。那些独立的组件可以并行执行。

    方案

    这种架构中的管道构成了过滤器之间的通信通道。第一个概念是,由于性能原因,每个管道都是非定向的和点对点的,接受来自一个源的输入并经常直接输出到另外一个源。

    在这种模式中,有如下四种过滤器。

    producer(source):一个过程的起点。
    transformer (map):对一些或所有数据进行转换。
    tester (reduce):测试一个或多个条件。
    consumer (sink):终点。
    

    弱点

    不太适合交互性的系统,因为它们的转换特性。

    过多的解析和反解析会导致性能损失,也会增加编写过滤器本身的复杂性。

    用途

    管道 - 过滤器架构用于各种应用程序,特别是简化单项处理的任务,例如 EDI、ETL 工具。

    编译器:连续的过滤器执行词法分析、语法分析、语义分析和代码生成。

    客户端 - 服务器架构

    在这里插入图片描述上下文

    有许多共享资源和服务是大量分布式的客户端希望访问的,我们希望控制访问或服务质量。

    问题

    通过管理一组共享资源和服务,我们可以通过分解公共服务并在单个位置或少数位置进行修改来提高可修改性和复用性。我们想要通过在将资源本身分布在多个物理服务器上的同时集中控制这些资源和服务,来提高可伸缩性和可用性。

    方案

    在客户端 - 服务器模式中,组件和连接器具有特定的行为。

    称为“客户端”的组件将请求发送到称为“服务器”的组件,然后等待回复。
    服务器组件接收到客户端的请求并向其发送回复。

    弱点

    服务器会成为性能瓶颈和单点故障位置。

    在系统建成后,关于功能位置(在客户端还是在服务器)的决策通常是复杂的而且变动成本很大。

    用途

    对于有许多组件(客户端)发送请求到另外一些提供服务的组件(服务器)的系统,我们可以使用客户端 - 服务器模式来建模这个系统的一部分:在线应用程序,例如电子邮件、共享文档或银行服务。

    模型 - 视图 - 控制器架构(MVC)

    在这里插入图片描述
    上下文

    用户界面通常是一个交互性应用程序的最频繁被修改的部分。用户通常希望从不同的视角查看数据,例如柱状图或者饼图。这些表示形式都应该反映数据当前的状态。

    问题

    用户界面功能如何独立于应用程序功能,同时还还对用户输入或底层应用程序数据的更改做出响应?

    当底层应用程序数据更改时,如何创建、维护和协调用户界面的多个视图?

    方案

    模型 - 视图 - 控制器(model-view-controller,即 MVC)模式将应用程序功能分为以下三种类型的组件:

    模型,包含应用程序的数据。
    视图,显示部分底层数据并与用户交互。
    控制器,在模型和视图之间进行中介并管理状态更改的通知。
    

    弱点

    对于简单的用户界面,其复杂性并不值得这么做。

    模型、视图和控制器抽象可能不适用于某些用户界面工具包。

    用途

    MVC 是网站或移动应用程序开发用户界面常用的一种架构模式。

    事件驱动架构

    上下文

    需要提供计算和信息资源来处理传入的应用程序生成的独立异步事件,这种方式可以随着需求的增加而扩展。

    问题

    构建分布式系统,这个系统可以服务异步到达的事件相关信息,并且能从简单小型扩展到复杂大型。

    方案
    在这里插入图片描述
    为事件处理部署独立的事件进程或处理器。到达的事件进入队列。调度程序根据调度策略从队列中拉取事件并将它们分配到合适的事件处理器。

    弱点

    性能和错误恢复可能是问题。

    用途

    使用这个方案的电商应用程序将工作如下:

    Order Service 创建一个 Order,这个订单处于待定状态,然后发布一个OrderCreated事件。

    • Customer Service 接收到这个事件并尝试为这个 Order 扣除信用。然后发布一个 Credit Reserved 事件或者CreditLimitExceeded(超出信用限额)事件。
    • Order Service 接收到 Customer Service 发送的事件并将订单状态更改为已核准或已取消。

    微服务架构

    上下文

    部署基于服务器的企业应用程序,支持各种浏览器和原生移动客户端。 应用程序通过执行业务逻辑、访问数据库、与其它系统交换信息并返回响应来处理客户端请求。这个应用程序可能会暴露一个第三方 API。

    问题

    一体化应用程序会变得过于庞大和复杂,无法得到有效支持和部署来实现最优的分布式资源利用,例如在云环境中。

    方案
    在这里插入图片描述将应用程序构建成服务套件。每个服务都是独立部署和可扩展的,拥有自己的 API 边界。不同的服务可以用不同的编程语言编写,管理它们自己的数据库,由不同的团队开发。

    弱点

    系统设计必须能容忍服务失败,需要更多的系统监控。服务编排和事件协作开销比较大。

    当然,我们还需要更多钱。

    用途

    许多使用场景都可以应用微服务架构,特别是那些涉及大量数据管道的场景。例如,一个微服务系统对关于一个公司的零售店销售的报表系统会比较理想。数据展现过程的每一步都会被一个微服务处理:数据收集、清理、规范化、浓缩、聚合、报告等。

    展开全文
  • 软件架构模式之分层架构

    万次阅读 2015-04-19 23:53:59
    对程序员来说很常见一种情况是在没有合理的程序架构时就开始编程,没有一个清晰的和定义好的架构的时候,大多数开发者和架构师通常会使用标准式的传统分层架构模式(也被称为多层架构)——通过将源码模块分割为几个...

    本章内容出自《软件架构模式》第一章,该书由 开发技术前线 项目组成员翻译,更多内容请访问 《软件架构模式》中文版pdf

    简介

    对程序员来说很常见一种情况是在没有合理的程序架构时就开始编程,没有一个清晰的和定义好的架构的时候,大多数开发者和架构师通常会使用标准式的传统分层架构模式(也被称为多层架构)——通过将源码模块分割为几个不同的层到不同的包中。不幸的是,这种编码方式会导致一系列没有组织性的代码模块,这些模块缺乏明确的规则、职责和同其他模块之间的关联。这通常被称为架构大泥球。

    应用程序缺乏合理的架构一般会导致程序过度耦合、容易被破坏、难以应对变化,同时很难有一个清晰的版本或者方向性。这样的结果是,如果你没有充分理解程序系统里每个组件和模块,就很难定义这个程序的结构特征。有关于程序的部署和维护的基本问题都难以回答,比如:程序架构是什么规模?应用程序有什么性能特点?应用程序有多容易应对变化?应用程序的部署特点是什么?架构是如何反应的?

    架构模式帮助你定义应用程序的基本特征和行为。例如,一些架构模式会让程序自己自然而然地朝着具有良好伸缩性的方向发展,而其他架构模式会让程序朝着高度灵活的方向发展。知道了这些特点,了解架构模式的优点和缺点是非常必要的,它帮助我们选择一个适合自己特定的业务需求和目标的的程序。

    作为一个架构师,你必须证明你的架构模式的决策是正确的,特别是当需要选择一个特定的体系结构模式或方法的时候。这本迷你书的目的就是给你足够的信息让你去做出正确的架构决策。

    第一章 分层架构

    分层架构是一种很常见的架构模式,它也叫N层架构。这种架构是大多数Jave EE应用的实际标准,因此很多的架构师,设计师,还有程序员都知道它。许多传统IT公司的组织架构和分层模式十分的相似。所以它很自然的成为大多数应用的架构模式。

    模式分析

    分层架构模式里的组件被分成几个平行的层次,每一层都代表了应用的一个功能(展示逻辑或者业务逻辑)。尽管分层架构没有规定自身要分成几层几种,大多数的结构都分成四个层次:展示层,业务层,持久层,和数据库层。如表1-1,有时候,业务层和持久层会合并成单独的一个业务层,尤其是持久层的逻辑绑定在业务层的组件当中。因此,有一些小的应用可能只有3层,一些有着更复杂的业务的大应用可能有5层或者更多的分层。

    分层架构中的每一层都着特定的角色和职能。举个例子,展示层负责处理所有的界面展示以及交互逻辑,业务层负责处理请求对应的业务。架构里的层次是具体工作的高度抽象,它们都是为了实现某种特定的业务请求。比如说展示层并不需要关心怎样得到用户数据,它只需在屏幕上以特定的格式展示信息。业务层并不关心要展示在屏幕上的用户数据格式,也不关心这些用户数据从哪里来。它只需要从持久层得到数据,执行与数据有关的相应业务逻辑,然后把这些信息传递给展示层。

    这里写图片描述

    分层架构的一个突出特性是组件间关注点分离 (separation of concerns)。一个层中的组件只会处理本层的逻辑。比如说,展示层的组件只会处理展示逻辑,业务层中的组件只会去处理业务逻辑。多亏了组件分离,让我们更容易构造有效的角色和强力的模型。这样应用变的更好开发,测试,管理和维护。

    关键概念

    注意表1-2中每一层都是封闭的。这是分层架构中非常重要的特点。这意味request必须一层一层的传递。举个例子,从展示层传递来的请求首先会传递到业务层,然后传递到持久层,最后才传递到数据层。

    这里写图片描述

    那么为什么不允许展示层直接访问数据层呢。如果只是获得以及读取数据,展示层直接访问数据层,比穿过一层一层来得到数据来的快多了。这涉及到一个概念:层隔离。

    层隔离就是说架构中的某一层的改变不会影响到其他层:这些变化的影响范围限于当前层次。如果展示层能够直接访问持久层了,假如持久层中的SQL变化了,这对业务层和展示层都有一定的影响。这只会让应用变得紧耦合,组件之间互相依赖。这种架构会非常的难以维护。

    从另外一个方面来说,分层隔离使得层与层之间都是相互独立的,架构中的每一层的互相了解都很少。为了说明这个概念的牛逼之处,想象一个超级重构,把展示层从JSP换成JSF。假设展示层和业务层的之间的联系保持一致,业务层不会受到重构的影响,它和展示层所使用的界面架构完全独立。

    然而封闭的架构层次也有不便之处,有时候也应该开放某一层。如果想往包含了一些由业务层的组件调用的普通服务组件的架构中添加一个分享服务层。在这个例子里,新建一个服务层通常是一个好主意,因为从架构上来说,它限制了分享服务访问业务层(也不允许访问展示层)。如果没有隔离层,就没有任何架构来限制展示层访问普通服务,难以进行权限管理。

    在这个例子中,新的服务层是处于业务层之下的,展示层不能直接访问这个服务层中的组件。但是现在业务层还要通过服务层才能访问到持久层,这一点也不合理。这是分层架构中的老问题了,解决的办法是开放某些层。如表1-3所示,服务层现在是开放的了。请求可以绕过这一层,直接访问这一层下面的层。既然服务层是开放的,业务层可以绕过服务层,直接访问数据持久层。这样就非常合理。

    1-3

    开放和封闭层的概念确定了架构层和请求流之间的关系,并且给设计师和开发人员提供了必要的信息理解架构里各种层之间的访问限制。如果随意的开放或者封闭架构里的层,整个项目可能都是紧耦合,一团糟的。以后也难以测试,维护和部署。

    示例

    为了演示分层架构是如何工作的,想象一个场景,如表1-4,用户发出了一个请求要获得客户的信息。黑色的箭头是从数据库中获得用户数据的请求流,红色箭头显示用户数据的返回流的方向。在这个例子中,用户信息由客户数据和订单数组组成(客户下的订单)。

    用户界面只管接受请求以及显示客户信息。它不管怎么得到数据的,或者说得到这些数据要用到哪些数据表。如果用户界面接到了一个查询客户信息的请求,它就会转发这个请求给用户委托(Customer Delegate)模块。这个模块能找到业务层里对应的模块处理对应数据(约束关系)。业务层里的customer object聚合了业务请求需要的所有信息(在这个例子里获取客户信息)。这个模块调用持久层中的 customer dao 来得到客户信息,调用order dao来得到订单信息。这些模块会执行SQL语句,然后返回相应的数据给业务层。当 customer object收到数据以后,它就会聚合这些数据然后传递给 customer delegate,然后传递这些数据到customer screen 展示在用户面前。

    这里写图片描述

    从技术的角度来说,有很多的方式能够实现这些模块。比如说在Java平台中,customer screen 对应的是 (JSF) Java Server Faces ,用 bean 组件来实现 customer delegate。用本地的Spring bean或者远程的EJB3 bean 来实现业务层中的customer object。上例中的数据访问可以用简单的POJP’s(Plain Old Java Objects),或者可以用MyBatis,还可以用JDBC或者Hibernate 查询。Microsoft平台上,customer screen能用 .NET 库的ASP模块来访问业务层中的C#模块,用ADO来实现用户和订单数据的访问模块。

    注意事项

    分层架构是一个很可靠的架构模式。它适合大多数的应用。如果你不确定在项目中使用什么架构,分层架构是再好不过的了。然后,从架构的角度上来说,选择这个模式还要考虑很多的东西。

    第一个要注意的就是 污水池反模式(architecture sinkhole anti-pattern)。
    在这个模式中,请求流只是简单的穿过层次,不留一点云彩,或者说只留下一阵青烟。比如说界面层响应了一个获得数据的请求。响应层把这个请求传递给了业务层,业务层也只是传递了这个请求到持久层,持久层对数据库做简单的SQL查询获得用户的数据。这个数据按照原理返回,不会有任何的二次处理,返回到界面上。

    每个分层架构或多或少都可能遇到这种场景。关键在于这样的请求有多少。80-20原则可以帮助你确定架构是否处于反污水模式。大概有百分之二十的请求仅仅是做简单的穿越,百分之八十的请求会做一些业务逻辑操作。然而,如果这个比例反过来,大部分的请求都是仅仅穿过层,不做逻辑操作。那么开放一些架构层会比较好。不过由于缺少了层次隔离,项目会变得难以控制。

    模式分析

    下面的的表里分析了分层架构的各个方面。

    整体灵活性

    评级:低
    分析:总体灵活性是响应环境变化的能力。尽管分层模式中的变化可以隔绝起来,想在这种架构中做一些也改变也是并且费时费力的。分层模式的笨重以及经常出现的组件之间的紧耦合是导致灵活性降低的原因。

    易于部署

    评级:低
    分析:这取决于你怎么发布这种模式,发布程序可能比较麻烦,尤其是很大的项目。一个组件的小小改动可能会影响到整个程序的发布(或者程序的大部分)。发布必须是按照计划,在非工作时间或者周末进行发布。因此。分层模式导致应用发布一点也不流畅,在发布上降低了灵活性。

    可测试性

    评级:高
    分析:因为组件都处于各自的层次中,可以模拟其他的层,或者说直接去掉层,所以分层模式很容易测试。开发者可以单独模拟一个展示组件,对业务组件进行隔绝测试。还可以模拟业务层来测试某个展示功能。

    性能

    评级:低
    分析:尽管某些分层架构的性能表现的确不错,但是这个模式的特点导致它无法带来高性能。因为一次业务请求要穿越所有的架构层,做了很多不必要的工作。

    伸缩性

    评级:低
    分析:由于这种模式以紧密耦合的趋势在发展,规模也比较大,用分层架构构建的程序都比较难以扩展。你可以把各个层分成单独的物理模块或者干脆把整个程序分成多个节点来扩展分层架构,但是总体的关系过于紧密,这样很难扩展。

    易开发性

    评级:容易
    分析:在开发难度上面,分层架构得到了比较高的分数。因为这种架构对大家来说很熟悉,不难实现。大部分公司在开发项目的都是通过层来区分技术的,这种模式对于大多数的商业项目开发来说都很合适。公司的组织架构和他们软件架构之间的联系被戏称为”Conway’s law”。你可以Google一下查查这个有趣的联系。

    展开全文
  • 常用7种软件架构模式

    2020-12-23 09:35:57
    架构模式是对给定上下文的软件架构中常见问题的一种通用的可复用的解决方案。 一种模式就是特定上下文的问题的一种解决方案。 大体上,主要有下面这7种架构模式: 分层架构; 多层架构; 管道 - 过滤器架构; 客户端 - ...

      架构模式是对给定上下文的软件架构中常见问题的一种通用的可复用的解决方案。

    • 一种模式就是特定上下文的问题的一种解决方案。

    大体上,主要有下面这7种架构模式:

    • 分层架构
    • 多层架构
    • 管道 - 过滤器架构
    • 客户端 - 服务器架构
    • 模型 - 视图 - 控制器架构
    • 事件驱动架构
    • 微服务架构

    1.分层架构模式

    • 最常见的架构模式就是分层架构或者称为 n 层架构。

      大部分软件架构师、设计师和开发者都对这个架构模式非常熟悉。尽管对于层的数量和类型没有具体限制,但大部分分层架构主要由四层组成:展现层、业务层、持久层和数据库层,如下图所示。
    分层架构

    n 层架构示例

    1.上下文
      所有复杂的系统都会经历独立地发展和衍化系统各个部分的需要。出于这个原因,系统开发者需要对关注点进行清晰且条理分明的分离,以便系统的各个模块可以独立地开发和维护。
    2.问题
      软件需要以这样一种方式分割:各个模块可以独自开发和衍化,各自部分之间的交互非常少,支持可移植性、可修改性和复用性。
    3.方案

    为了实现关注点分离,分层模式将软件分割成各个单元(称为“层”)。每一层都是一组模块,提供了一组高内聚的服务。其使用必须是单向的。层将一组软件作为一个完整的分区,每个分区暴露一个公开接口。

    • 第一个概念是,每一层都有特定的角色和职责。例如,展现层负责处理所有的用户界面。分层架构的这种关注点分离,让构建高效的角色和职责非常简单。
    • 第二个概念是,分层架构模式是一个技术性的分区架构,而非一个领域性的分区架构。它们是由组件组成的,而不是领域。
    • 最后一个概念是,分层架构中的每一层都被标记为封闭或者开放。封闭层意味着请求从一层移到另一层,它必须通过它正下面的这一层才能达到下面这一层的再下一层。请求不能跳过任何层。

    封闭层和请求访问

    封闭层和请求访问

    4.弱点

    • 分层会导致性能下降。这种模式不适合高性能应用程序,因为经过架构中的多层来实现一个业务请求的效率是不高的。
    • 分层还会增加系统的前期成本和复杂性。

    5.用途

    • 我们应该将这种方式应用于小型简单的应用程序或网站。对于预算和时间非常紧张的场景,这是一个不错的选择。

    2.多层模式

    1.上下文

    • 在一个分布式部署中,通常需要将系统的基础设施分到不同的子集中。

    2.问题

    • 我们如何将系统分割到多个计算上独立的执行结构:由一些通信媒介连接的软件和硬件组?

    3.方案

    • 许多系统的执行结构被组织成一系列逻辑组件分组。每个分组被称为一个层。

    一个多层模式示例

    多层模式示例

    4.弱点

    • 大量前期成本和复杂性。

    5.用途

    • 用在分布式系统中。

    3.管道-过滤器架构

    • 软件架构中反复出现的一种模式是管道 - 过滤器(pipe-filter)模式。

    管道过滤器模式

    管道过滤器模式

    1.上下文

    • 许多系统需要转换从输入到输出的离散数据流。许多类型转换在实践中重复出现,因此将其创建成独立的可复用的部分,这是比较理想的。

    2.问题

    • 这些系统需要被分割成可复用的松耦合的组件,组件之间拥有简单通用的交互机制。这样它们就可以灵活地相互结合。这些通用松耦合的组件就很容易复用。那些独立的组件可以并行执行。

    3.方案

      这种架构中的管道构成了过滤器之间的通信通道。第一个概念是,由于性能原因,每个管道都是非定向的和点对点的,接受来自一个源的输入并经常直接输出到另外一个源。

    在这种模式中,有如下四种过滤器:

    • producer(source):一个过程的起点
    • transformer (map):对一些或所有数据进行转换
    • tester (reduce):测试一个或多个条件
    • consumer (sink):终点

    4.弱点

    • 不太适合交互性的系统,因为它们的转换特性。
    • 过多的解析和反解析会导致性能损失,也会增加编写过滤器本身的复杂性。

    5.用途

    • 管道 - 过滤器架构用于各种应用程序,特别是简化单项处理的任务,例如 EDI、ETL 工具。
    • 编译器:连续的过滤器执行词法分析、语法分析、语义分析和代码生成。

    4.客户端-过滤器架构

    客户端-过滤器架构

    1.上下文

    • 有许多共享资源和服务是大量分布式的客户端希望访问的,我们希望控制访问或服务质量。

    2.问题

      通过管理一组共享资源和服务,我们可以通过分解公共服务并在单个位置或少数位置进行修改来提高可修改性和复用性。我们想要通过在将资源本身分布在多个物理服务器上的同时集中控制这些资源和服务,来提高可伸缩性和可用性。

    3.方案

    • 在客户端 - 服务器模式中,组件和连接器具有特定的行为。
    • 称为“客户端”的组件将请求发送到称为“服务器”的组件,然后等待回复。
    • 服务器组件接收到客户端的请求并向其发送回复。

    4.弱点

    • 服务器会成为性能瓶颈和单点故障位置。
    • 在系统建成后,关于功能位置(在客户端还是在服务器)的决策通常是复杂的而且变动成本很大。

    5.用途

      对于有许多组件(客户端)发送请求到另外一些提供服务的组件(服务器)的系统,我们可以使用客户端 - 服务器模式来建模这个系统的一部分:在线应用程序,例如电子邮件、共享文档或银行服务。

    5.模型-视图-控制器架构(MVC)

    MVC

    1.上下文

      用户界面通常是一个交互性应用程序的最频繁被修改的部分。用户通常希望从不同的视角查看数据,例如柱状图或者饼图。这些表示形式都应该反映数据当前的状态。

    2.问题

    • 用户界面功能如何独立于应用程序功能,同时还还对用户输入或底层应用程序数据的更改做出响应?
    • 当底层应用程序数据更改时,如何创建、维护和协调用户界面的多个视图?

    3.方案

    模型 - 视图 - 控制器(model-view-controller,即 MVC)模式将应用程序功能分为以下三种类型的组件:

    • 模型,包含应用程序的数据。
    • 视图,显示部分底层数据并与用户交互。
    • 控制器,在模型和视图之间进行中介并管理状态更改的通知。

    4.弱点

    • 对于简单的用户界面,其复杂性并不值得这么做。
    • 模型、视图和控制器抽象可能不适用于某些用户界面工具包。

    5.用途

    • MVC 是网站或移动应用程序开发用户界面常用的一种架构模式。

    6.事件驱动架构

    1.上下文

    • 需要提供计算和信息资源来处理传入的应用程序生成的独立异步事件,这种方式可以随着需求的增加而扩展。

    2.问题

    • 构建分布式系统,这个系统可以服务异步到达的事件相关信息,并且能从简单小型扩展到复杂大型。

    3.方案
    事件驱动架构

    • 为事件处理部署独立的事件进程或处理器。到达的事件进入队列。调度程序根据调度策略从队列中拉取事件并将它们分配到合适的事件处理器。

    4.弱点

    • 性能和错误恢复可能是问题。

    5.用途
    使用这个方案的电商应用程序将工作如下:

    • Order Service 创建一个 Order,这个订单处于待定状态,然后发布一个OrderCreated事件。
      • Customer Service 接收到这个事件并尝试为这个 Order 扣除信用。然后发布 一个 Credit Reserved 事件或者CreditLimitExceeded(超出信用限额)事件。
      • Order Service 接收到 Customer Service 发送的事件并将订单状态更改为已核准或已取消。

    7.微服务架构

    1.上下文

      部署基于服务器的企业应用程序,支持各种浏览器和原生移动客户端。应用程序通过执行业务逻辑、访问数据库、与其它系统交换信息并返回响应来处理客户端请求。这个应用程序可能会暴露一个第三方 API。

    2.问题

    • 一体化应用程序会变得过于庞大和复杂,无法得到有效支持和部署来实现最优的分布式资源利用,例如在云环境中。

    3.方案
    微服务架构

      将应用程序构建成服务套件。每个服务都是独立部署和可扩展的,拥有自己的 API 边界。不同的服务可以用不同的编程语言编写,管理它们自己的数据库,由不同的团队开发。

    4.弱点

    • 系统设计必须能容忍服务失败,需要更多的系统监控。服务编排和事件协作开销比较大。
    • 当然,我们还需要更多钱。

    5.用途

      许多使用场景都可以应用微服务架构,特别是那些涉及大量数据管道的场景。例如,一个微服务系统对关于一个公司的零售店销售的报表系统会比较理想。数据展现过程的每一步都会被一个微服务处理:数据收集、清理、规范化、浓缩、聚合、报告等。

    展开全文
  • 然而,很多开发者至今还对各种软件架构模式之间的差别搞不清,甚至对其所知甚少。 大体上,主要有下面这7种架构模式: 分层架构 多层架构 管道 - 过滤器架构 客户端 - 服务器架构 模型 - 视图 - 控制器架构 ...

    架构模式是对给定上下文的软件架构中常见问题的一种通用的可复用的解决方案。

    一种模式就是特定上下文的问题的一种解决方案。

    然而,很多开发者至今还对各种软件架构模式之间的差别搞不清,甚至对其所知甚少。

    大体上,主要有下面这7种架构模式:

    分层架构

    多层架构

    管道 - 过滤器架构

    客户端 - 服务器架构

    模型 - 视图 - 控制器架构

    事件驱动架构

    微服务架构

    1

    分层架构模式

    最常见的架构模式就是分层架构或者称为 n 层架构。

    大部分软件架构师、设计师和开发者都对这个架构模式非常熟悉。尽管对于层的数量和类型没有具体限制,但大部分分层架构主要由四层组成:展现层、业务层、持久层和数据库层,如下图所示。

    一个很流行的 n 层架构示例

     1 上下文 

    所有复杂的系统都会经历独立地发展和衍化系统各个部分的需要。出于这个原因,系统开发者需要对关注点进行清晰且条理分明的分离,以便系统的各个模块可以独立地开发和维护。

     2 问题 

    软件需要以这样一种方式分割:各个模块可以独自开发和衍化,各自部分之间的交互非常少,支持可移植性、可修改性和复用性。

     3 方案 

    为了实现关注点分离,分层模式将软件分割成各个单元(称为“层”)。每一层都是一组模块,提供了一组高内聚的服务。其使用必须是单向的。层将一组软件作为一个完整的分区,每个分区暴露一个公开接口。

    第一个概念是,每一层都有特定的角色和职责。例如,展现层负责处理所有的用户界面。分层架构的这种关注点分离,让构建高效的角色和职责非常简单。

    第二个概念是,分层架构模式是一个技术性的分区架构,而非一个领域性的分区架构。它们是由组件组成的,而不是领域。

    最后一个概念是,分层架构中的每一层都被标记为封闭或者开放。封闭层意味着请求从一层移到另一层,它必须通过它正下面的这一层才能达到下面这一层的再下一层。请求不能跳过任何层。

    封闭层和请求访问

     4 弱点 

    分层会导致性能下降。这种模式不适合高性能应用程序,因为经过架构中的多层来实现一个业务请求的效率是不高的。

    分层还会增加系统的前期成本和复杂性。

     5 用途 

    我们应该将这种方式应用于小型简单的应用程序或网站。对于预算和时间非常紧张的场景,这是一个不错的选择。

    2

    多层模式

     1 方案 

    一个多层模式示例:消费者网站 J2EE

    许多系统的执行结构被组织成一系列逻辑组件分组。每个分组被称为一个层。

     1 上下文 

    在一个分布式部署中,通常需要将系统的基础设施分到不同的子集中。

     2 问题 

    我们如何将系统分割到多个计算上独立的执行结构:由一些通信媒介连接的软件和硬件组?

     3 弱点 

    大量前期成本和复杂性。

     4 用途 

    用在分布式系统中。

    3

    管道-过滤器架构

    软件架构中反复出现的一种模式是管道 - 过滤器(pipe-filter)模式。

    管道过滤器模式

     1 上下文 

    许多系统需要转换从输入到输出的离散数据流。许多类型转换在实践中重复出现,因此将其创建成独立的可复用的部分,这是比较理想的。

     2 问题 

    这些系统需要被分割成可复用的松耦合的组件,组件之间拥有简单通用的交互机制。这样它们就可以灵活地相互结合。这些通用松耦合的组件就很容易复用。那些独立的组件可以并行执行。

     3 方案 

    这种架构中的管道构成了过滤器之间的通信通道。第一个概念是,由于性能原因,每个管道都是非定向的和点对点的,接受来自一个源的输入并经常直接输出到另外一个源。

    在这种模式中,有如下四种过滤器。

    producer(source):一个过程的起点。

    transformer (map):对一些或所有数据进行转换。

    tester (reduce):测试一个或多个条件。

    consumer (sink):终点。

     4 弱点 

    不太适合交互性的系统,因为它们的转换特性。

    过多的解析和反解析会导致性能损失,也会增加编写过滤器本身的复杂性。

     5 用途 

    管道 - 过滤器架构用于各种应用程序,特别是简化单项处理的任务,例如 EDI、ETL 工具。

    编译器:连续的过滤器执行词法分析、语法分析、语义分析和代码生成。

    4

    客户端-过滤器架构

     1 上下文 

    有许多共享资源和服务是大量分布式的客户端希望访问的,我们希望控制访问或服务质量。

     2 问题 

    通过管理一组共享资源和服务,我们可以通过分解公共服务并在单个位置或少数位置进行修改来提高可修改性和复用性。我们想要通过在将资源本身分布在多个物理服务器上的同时集中控制这些资源和服务,来提高可伸缩性和可用性。

     3 方案 

    在客户端 - 服务器模式中,组件和连接器具有特定的行为。

    称为“客户端”的组件将请求发送到称为“服务器”的组件,然后等待回复。

    服务器组件接收到客户端的请求并向其发送回复。

     4 弱点 

    服务器会成为性能瓶颈和单点故障位置。

    在系统建成后,关于功能位置(在客户端还是在服务器)的决策通常是复杂的而且变动成本很大。

     5 用途 

    对于有许多组件(客户端)发送请求到另外一些提供服务的组件(服务器)的系统,我们可以使用客户端 - 服务器模式来建模这个系统的一部分:在线应用程序,例如电子邮件、共享文档或银行服务。

    5

    模型-视图-控制器架构(MVC)

     1 上下文 

    用户界面通常是一个交互性应用程序的最频繁被修改的部分。用户通常希望从不同的视角查看数据,例如柱状图或者饼图。这些表示形式都应该反映数据当前的状态。

     2 问题 

    用户界面功能如何独立于应用程序功能,同时还还对用户输入或底层应用程序数据的更改做出响应?

    当底层应用程序数据更改时,如何创建、维护和协调用户界面的多个视图?

     3 方案 

    模型 - 视图 - 控制器(model-view-controller,即 MVC)模式将应用程序功能分为以下三种类型的组件:

    模型,包含应用程序的数据。

    视图,显示部分底层数据并与用户交互。

    控制器,在模型和视图之间进行中介并管理状态更改的通知。

     4 弱点 

    对于简单的用户界面,其复杂性并不值得这么做。

    模型、视图和控制器抽象可能不适用于某些用户界面工具包。

     5 用途 

    MVC 是网站或移动应用程序开发用户界面常用的一种架构模式。

    6

    事件驱动架构

     1 上下文 

    需要提供计算和信息资源来处理传入的应用程序生成的独立异步事件,这种方式可以随着需求的增加而扩展。

     2 问题 

    构建分布式系统,这个系统可以服务异步到达的事件相关信息,并且能从简单小型扩展到复杂大型。

     3 方案 

    为事件处理部署独立的事件进程或处理器。到达的事件进入队列。调度程序根据调度策略从队列中拉取事件并将它们分配到合适的事件处理器。

     4 弱点 

    性能和错误恢复可能是问题。

     5 用途 

    使用这个方案的电商应用程序将工作如下:

    Order Service 创建一个 Order,这个订单处于待定状态,然后发布一个OrderCreated事件。

    Customer Service 接收到这个事件并尝试为这个 Order 扣除信用。然后发布一个 Credit Reserved 事件或者CreditLimitExceeded(超出信用限额)事件。

    Order Service 接收到 Customer Service 发送的事件并将订单状态更改为已核准或已取消。

    7

    微服务架构

     1 上下文 

    部署基于服务器的企业应用程序,支持各种浏览器和原生移动客户端。应用程序通过执行业务逻辑、访问数据库、与其它系统交换信息并返回响应来处理客户端请求。这个应用程序可能会暴露一个第三方 API。

     2 问题 

    一体化应用程序会变得过于庞大和复杂,无法得到有效支持和部署来实现最优的分布式资源利用,例如在云环境中。

     3 方案 

    将应用程序构建成服务套件。每个服务都是独立部署和可扩展的,拥有自己的 API 边界。不同的服务可以用不同的编程语言编写,管理它们自己的数据库,由不同的团队开发。

     4 弱点 

    系统设计必须能容忍服务失败,需要更多的系统监控。服务编排和事件协作开销比较大。

    当然,我们还需要更多钱。

     5 用途 

    许多使用场景都可以应用微服务架构,特别是那些涉及大量数据管道的场景。例如,一个微服务系统对关于一个公司的零售店销售的报表系统会比较理想。数据展现过程的每一步都会被一个微服务处理:数据收集、清理、规范化、浓缩、聚合、报告等。

    展开全文
  • 然而,很多开发者至今还对各种软件架构模式之间的差别搞不清,甚至对其所知甚少。 大体上,主要有下面这7种架构模式: ①分层架构 ②多层架构 ③管道 - 过滤器架构 ④客户端 - 服务器架构 ⑤模型 - 视图 -...
  • 然而,很多开发者至今还对各种软件架构模式之间的差别搞不清,甚至对其所知甚少。大体上,主要有下面这7种架构模式:分层架构多层架构管道 - 过滤器架构客户端 - 服务器架构模型 - 视图 - 控制器架构事件驱动架构...
  • 程序员必知的几种软件架构模式前序分层架构模式多层模式管道 - 过滤器架构客户端 - 服务器架构模型 - 视图 - 控制器架构(MVC)事件驱动架构微服务架构来源:http://r6d.cn/8axk前序架构模式是对给定上下文的软件架构...
  • 有没有想过要设计多大的企业规模系统?在主要的软件开发开始之前,我们必须选择一个合适的体系结构,它将为我们提供所需的功能和质量属性。... 分层模式这种模式也称为多层体系架构模式。它可以用来构造可以分解...
  • 多层J2EE系统的架构模式设计

    千次阅读 2013-03-05 10:34:52
    多层J2EE系统的架构模式设计 目录 ---------- 摘要……………………………………………………………………2 文献综述………………………………………………………………3 第一章 前言……………………...
  • 软件架构的基本模式

    2017-12-18 23:49:00
    分层:C/S、B/S、多层,数据、计算与显示的分离(MVC)一个模块做很多事情->各负其责,分工明确牺牲了效率,提升了可维护性。 异步:事件、消息请求之后等待结果(同步)->请求之后继续执行,后续等待结果(异步) ...
  • 软件分层的概念一直很模糊,也没有一个统一的标准,即使有些人明白三层架构的理念但却不会使用,不是如何创建三层架构。在网上发现了一个很不错的网站架构设计模式,分别介绍了单层架构,二层架构,三层架构,有例字...
  • 几种常见架构模式

    千次阅读 2015-12-01 00:19:10
    本节说的是几种常见架构模式。 AD: 6.2.2 几种常见架构模式 前文讲过,在实践中,人们总结出了一些常用的软件系统结构高层模式,以供应用系统设计时参考。这些模式包括:单服务两层/多层C/S;MVC结构
  • 完整的后台管理系统,除了图片之外,还有文章管理,标签管理,页面管理,会员管理等9.100%原他的代码程序,基于多层架构模式,在展示层又使用MVC10.使用以来注入来解决层之间的以来问题11.完整的路由系统12............
  • 常用的软件架构模型可以归类为三种架构模型:3/N层架构、“框架+插件”架构、地域分布式架构。一.三种架构模型1.3/N层架构这是经典的多层架构模型,对于稍微复杂一点或特别复杂的系统,不使用分层架构是很难想象...
  • 9.100%原他的代码程序,基于多层架构模式,在展示层又使用MVC 10.使用以来注入来解决层之间的以来问题 11.完整的路由系统 12..............   2014年由于工作重心的转向,个人开发转php的开发,为了更快上手...
  • 大家有没有想过要设计多大的企业规模系统?...这种模式也称为多层体系架构模式。它可以用来构造可以分解为子任务组的程序,每个子任务都处于一个特定的抽象级别。每个层都为下一个提供更高层次服务。 .
  • 有没有想过要设计多大的企业规模系统...架构模式软件设计模式类似,但具有更广泛的范围。 在本文中,将简要地解释以下10种常见的体系架构模式,以及它们的用法、优缺点。 一、分层模式 这种模式也称为多层体系架构
  • 这些模式包括:单服务两层/多层C/S;MVC结构;面向服务的SOA与多服务集合;数据交换总线等。  1. 单机应用系统(Standalone)  准确地讲,单机应用系统是最简单的软件结构,是指运行在一台物理机器上的独立应用...
  • 写在前面最开始做架构最好的方式都是基于模仿的,我们可以找到一个...可复用的架构模式列出以下几个自己平时习惯套用的模式:分层模式;管道模式(过滤器模式);聚合网关模式;MVC模式;事件驱动模式;多层模式多层模...
  • iOS:设计模式架构

    2020-04-12 11:21:01
    何为架构架构(Architecture) 软件开发中的设计方案。 类与类之间的关系、模块与模块之间的关系、客户端与服务端的关系。...多层架构 设计模式 设计模式(Design Pattern) 是一套被反复使用、代码...
  • C/S多层架构有无出路

    2009-03-02 14:08:00
    曾经花了大量的时间(累计有...因为软件不仅仅是软件软件尤其自身环境,操作系统升级了、完善了、通信方式升级了、完善了,老的模式就无法很好的适用,因此,更换一种新的道路是需要的,但是,对于国内来说,有多少程
  • 在分解复杂的软件系统时,软件设计者用得最多的技术之一就是分层。 当用分层的观点来考虑系统时,可以将各个子系统想象成按照“多层蛋糕”的形式来组织,每一层都依托在其下层之上。在这种组织方式下,上层使用了...
  • 软件的三层架构

    万次阅读 热门讨论 2016-11-09 20:46:22
    基于软件三层架构的研究报告 引言 ...三层结构是传统的客户/服务器结构的发展,代表了企业级应用的未来,典型的有Web下的...(一) 软件架构(software architecture) 是一系列相关的抽象模式,用于指导大型软
  • 三层架构模式(开发实践很重要)

    千次阅读 2014-03-01 21:12:35
    题记: 多层开发模式 是开发软件 都要用到的一个思想 , 不管是Java还是C#都是要用到的. 经验: DLL : 动态链接库(就是类库)exe 和 dll 的区别? 就是一个有主函数(exe有),一个没有主函数(dll).面试考的比较多的...

空空如也

空空如也

1 2 3 4 5 6
收藏数 106
精华内容 42
关键字:

多层软件架构模式