乐正

Actions speak louder than words.

企业应用架构概述

《企业应用架构模式》读书笔记 (一)

企业应用的具体定义是什么?

我无法给出一个具体的定义,但是可以罗列一些自己的理解:

  • 企业应用一般都涉及到持久化数据。这些数据一般会被持久化若干年,数据本身的结 构也可能改变,使得它在不影响原本数据的基础上还能表示更多的信息。
  • 企业应用一般还涉及到大量数据。目前,我们主要使用数据库系统存储数据,大多数 是关系型数据库。
  • 企业应用一般都涉及到很多人同时访问数据。尤其是对于一些基于Web的系统,人数更 是呈指数增长。而我们要确保这些人能够正确的访问和操作这些数据。
  • 企业应用还设计到大量操作数据的用户界面。有几百个用户界面也是不足为奇的,用 户的使用频率也相差很大。
  • 企业应用通常很少独立存在,通常需要与其他企业应用集成。这些系统是在不同的时 期,采用不同的技术创建的,甚至连协作机制都不相同。
  • 企业应用还会遇到业务过程中的差异,以及数据中的概念不一致性
  • 企业应用还会在业务逻辑上遇到困难。很多的特殊情况导致了复杂业务的无逻辑。而 且,可以确定的是,这些逻辑会随着时间不断变化。

企业应用的分类

考虑这样的三种情况。

一个B2C的网上商城系统。这样的系统必须能够应对大量的客户访问,因此,其解决方案不 但要考虑资源利用的有效性,还需要考虑到系统的可伸缩性,以便在用户量加大的时候,能 够通过增加硬件的方式解决。我们希望任何人都能访问这个系统,所以图形界面可以选择通 用的Web表现方式,以支持不同的浏览器。

再考虑一个租赁合同的自动处理程序。这个系统比前面系统的访问人数要少,但是业务逻辑 却比较复杂。租赁的标准规则会因交易发生很多不同的变化,正式因为规则的随意性很大, 才使得这样的一个复杂的业务领域具有挑战性。

第三个例子是一个公司的开支跟踪系统。它功能少,逻辑简单,用户也少,能够很容易的实 现。然后,这样的系统也不是没有挑战:一方面是你需要很快速的开发出来,另一方面你又 需要为它以后的发展考虑。

企业应用的性能

很多架构的设计和决策和性能有关。在做性能优化之后一定要和优化前进行测量对比,以确 定真的得到了优化。配置上的重大变化会使得某些优化失效,所以在升级硬件、数据库或者 其他东西到新版本之后,必须重新确认性能优化工作的有效性。

列举下和性能有关的术语:

  • 响应时间:系统完成一次外部请求所需要的时间。
  • 响应性:不同于响应时间,它是指系统响应请求的速度有多快。如果在请求期间,系 统一直处于等待状态,则响应性等于响应时间。举例:在文件拷贝过程中的进度条就是提 高响应性但并不会提高响应时间。
  • 等待时间:是获得系统任何形式响应的最小时间。
  • 吞吐量:是给定时间内,能够处理请求量。吞吐量以每秒事务数来表示(单位:tps)。
  • 负载:关于当前系统负荷的表述。
  • 负载敏感度:是指响应时间随着负载变化的程度。
  • 系统的容量:是指最大有效负载或者吞吐量的指标。它可以是一个绝对最大值,或者 性能衰减至一个可接受的阀值的临界点。
  • 可伸缩性:是向系统中添加资源(通常是硬件),对系统性能的影响。一个可伸缩的 系统允许在添加硬件后性能得到合理提升。垂直可伸缩性「或称垂直延展」是提高单 台服务器的性能,水平可伸缩性「或称水平延展」是提高服务器的数量。

当构建企业应用时,关注硬件的可伸缩性比关注容量或者效率更重要。

企业应用的模式

模式的核心就是特定的解决方案,它有效而且有足够的通用性,可以解决重复出现的问题。 一旦决定使用模式,就必须知道如何将它应用在当前问题上。使用模式的关键之一就是不能 盲目使用。

模式的结构

  • 模式的名称。
  • 意图和概要。意图用一两句话总结模式;而概要是模式的一种可视化表示,通常(但不总 是)用一个UML图表示。
  • 运行机制和使用时机。运行机制描述了解决方案;使用时机描述了模式何时应该被使用。

模式的局限性

所有模式都是不完备的。

分层

在分层组织方式下,上层既对下层定义了各种服务;又对下层隐藏了其细节。将系统按层次 分解又很多重要好处:

  • 在无需了解过多其他层次的基础上,可以将某一层作为一个整体来理解。
  • 可以替换某层的全部实现,只要其提供同样的服务就可以。
  • 分层可以降低层次间的依赖性。
  • 分层有利于标准化工作。
  • 构建好某一层次后,可以让它为很多上次服务提供支持。

分层是一种重要的技术,但是也有缺陷

  • 层次并不能封装所有的东西。有时它会为我们带来级联修改。比如在一个分层设计的企业 应用中,要增加视图上的数据域,必须要在数据库中添加响应的字段,还需要修改数据库 和视图之间的其他层。
  • 过多的层次会影响性能。

分层架构中,最困难的地方在于确定层次结构以及它们的职责

三个层次

三个基本的层次为:

层次 职责
表现层 提供服务、显示信息、用户请求、HTTP请求和命令行调用。
领域层 逻辑处理,系统中真正的核心。
数据层 与数据库、消息系统、事物管理器和其他软件包通讯。

伴随着分层,还有一条关于依赖性的普遍原则:数据层和领域层绝对不要依赖表现层。

为各层选择运行环境

对于大多数信息系统,主要的决定就是在那里运行处理工作。通常,最简单的情况就是所有 的东西都运行在服务器上。这样做最大的好处是所有东西运行在有限的环境内,很容易修改 和维护。

在客户机上运行应用程序的好处是系统的响应性好,或者是在脱离网络的环境下也能工作。

领域逻辑既可以全部运行在服务器端,也可以全部运行在客户端或者一分为二也可以。全部 运行在服务器端有助于系统维护,像客户端转移是为了响应时间和离线操作的需求。如果你 在客户端运行领域逻辑,可以考虑将全部的该类逻辑都在客户端运行,可以保证一致性。

组织领域逻辑

领域逻辑的组织可以分为三种主要的模式:事务脚本、领域模型以及表模型。

事务脚本是这样的一个过程:从表示层中获取输入、进行校验和计算处理,将数据存储到数 据库中,以及调用其他系统操作等。然后,该过程将更多的数据返回给表现层。

事务脚本具有以下优点:

  • 它是一个大多数程序员都能理解的简单过程模型。
  • 它能狗与一个使用行数据入口或者表数据入口的数据层很好的协作。
  • 事务脚本的边界很明显:起源于脚本打开,终止于脚本关闭。

领域模型中,不再是每个过程控制用户的动作逻辑,而是由对象承担动作逻辑的一部分。领 域模型的好处在于可以使用较多的技术来组织日趋复杂的领域逻辑。

第三种组织领域逻辑的模式为表模型,表模型看起来与领域模型很相似,关键区别在于:领 域模型对于数据库中的每一条数据都有一个相对应类的实例;而表模型只有一个公共类的实 例。

选择

这三种模式并不互相排斥,但是更倾向于主要使用领域模型,同时使用事务脚本和表模型处 理剩余逻辑。

服务层

处理领域逻辑的常见方法是将领域层再细分为两层。服务层置于领域模型或者表模型之上。

技术

« 发声器和光敏电阻 Laravel 源码解读 »

Comments