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

读后感

从《企业应用架构模式》中能学到企业应用的整体模式知识，例如：业务组织模式、并发控制、分布模式、数据源模式、分层模式、行为模式、结构模式等。可以从基础原理的模式了解整个企业应用基础，并为以后的架构设计提供思考的方向。

从本书中的分层思想结合以往的架构经验，把公司的商品中心系统分为3层设计：前台、中台、后台，并从中规划5个阶段执行。并从书中启迪，并设计出解决企业应用中很多问题的策略：

• 里面就用到了业务组织模式设计出业务单元，达到细粒度的微服务效果。

• 离线并发控制对比版本号解决销售价格更新丢失的问题。

• 远程外观的分布模式解决前后端分离解决大批量调用细粒度接口的问题。

• 工作单元模式解决数据处理速度和页面加载过慢的问题。

上述只是一部分从本书中获得的实际应用场景，还有很多本人没有理解到的知识。因此《企业应用架构模式》是一本值得细细品读的书籍。

--------------------读书笔记分割线-------------------

1.企业应用架构模式

• 架构

  • 架构的定义：最高层次的系统分解、系统中不容易改变的部分。

  • 架构中最有价值的部分是：分层设计。

• 企业应用的特点

  • 一般都涉及持久化数据

  • 一般都涉及大量数据

  • 一般还涉及很多人同时访问系统

  • 还涉及大量操作数据的用户界面屏幕

  • 通常还与企业周围的其他企业应用集成

  • 还存在数据的概念不一致性

  • 复杂的业务”无逻辑“

  • 系统庞大，须具有”分而治之“的思想

• 企业应用的种类（抽象、提炼）

  • 处理大量数据的系统

  • 用户界面高要求的系统

  • 数据管理系统

• 关于性能的考虑

  • 响应时间

  • 响应性：进度条

  • 等待时间

  • 吞吐率

  • 负载

  • 效率

  • 可伸缩性

• 模式

  • 模式最主要的是”意图“和”概要”

  • 所有的模式都是行为方式的抽象概念，都是不完备的，需要不断学习完善。

 

2.分层

• 专业的人做专业的事情

• 分层的好处

  • 可以将某一层当初一个有机整体来理解

  • 可以替换某层的内部实现，只要提供的服务相同即可

  • 可以降低耦合性，把各个层次的依赖性减到最低

  • 分层有利于标准化工作

• 企业应用层次的演化

  • 三个基本层次：表现层、领域层、数据源层

 

3.组织业务逻辑

• 业务逻辑的模式

  • 三种模式：事务脚本、业务模型、表模块。

  • 事务脚本：一个过程控制一个动作的逻辑。

  • 业务模型：每个对象都承担一部分相关的逻辑 。

  • 表模块：以表为单位设计的模式。

• 将处理业务逻辑分为业务层、服务层

  • 服务层：放置事务控制和安全校验，提供一个易于使用的API。

 

4.映射到关系数据库

• 架构模式

  • 主要时解决驱动领域逻辑访问数据库的方式

  • 把领域模型和数据库完全独立，让间接层完成领域对象和数据库表之间的映射

• 行为问题

  • 行为时从数据库读取数据以及修改数据的动作

  • 需要保证数据的一致性

  • 延迟加载也是必要的思想，延迟加载主要是拥有一个对象引用的占位符

• 读取数据

  • 读取数据的方法可以看作一个查找器

  • 读取数据关键的问题是性能问题

  • 读取数据的准则是尽量进行批量操作，避免重复查询相同的表

• 结构映射模式

  • 关系的映射：对象和键的映射

  • 依赖映射可以简化映射关系

• 继承

  • 单表继承：所有类建立一个表

  • 具体表继承：每个具体类建立一个表

  • 类表继承：一个层次的每个类建立一个表

• 建立映射

  • 两步映射：先把内存方案转换为逻辑数据存储方案，然后从逻辑数据存储到物理数据存储

• 使用元数据

  • 元数据映射：数据库中的列映射到对象的域。

• 数据库链接

  • 数据库链接建立开销很大，因此需要建立一个连接池

  • 一个事务必须保证每个命令都是同一个链接发出

  • 链接使用完后需要关闭，一般是用垃圾回收机制关闭链接

  • 避免使用select* ，使用预编译机制避免sql注入。

 

5.Web表现层

• web服务器应用程序

  • 使用脚本：接受HTTP请求数据，通过写出stream形式输出这个字符串

  • 服务器页面：程序和返回的文本页组合在一起

  • 把非表现层逻辑剥离出来

• 视图模式

  • 转换视图、模板视图和两步视图

  • 转换视图：程序的一种转换风格

  • 模板视图：网页结构中编写表现层，页面中嵌入标签。不过这样会导致代码混乱难以维护。

  • 两步视图：可以理解为前后端分离，两者独立业务逻辑更清晰，但是在性能方面有一定的损耗。

• 输入控制器模式

  • 一个页面准备一个控制器

  • 控制器分离出单独的对象，一个动作对应一个页面。

 

6.并发

• 并发问题

  • 开发者能简单的避开并发问题是因为有了事务管理程序。

  • 离线并发：多数据库事务中数据操作的并发控制。

  • 更新丢失：A先更新数据1，然后B更新数据1，而B在A之前更新完数据。那么会导致B更新的数据就会丢失，因为B在A开始之后开始，却在A结束之前结束，导致A没有读到B的更新。

  • 不一致读：A读数据过程中，B修改了数据，导致A读取的不是最新的数据。

• 执行语境

  • 请求：应对软件工作的外部环境发出的单个调用。

  • 会话：客户端和服务端长时间的交互

  • 事务：多个请求看作是单个请求

• 隔离与不变性

  • 对数据加锁

  • 识别不变的数据

• 乐观并发控制和悲观并发控制

  • 乐观锁：冲突检测，适用场景是冲突少且冲突结果不严重。

  • 悲观锁：冲突避免，减少并发程度，但是会产生大量阻塞影响性能。

• 避免不一致读

  • 悲观锁策略是读数据加一个读锁（共享锁），写数据加一个写锁（排他锁）。

  • 乐观锁策略是将冲突检测建立在数据的某种版本标记上。

• 死锁

  • 悲观锁技术有一个特别的问题就是死锁。

  • 死锁：A对数据1加了锁，B对数据2加了锁，如果后面A要用到数据2，B要用到数据1。因为B对数据2加了锁，A就会等待B执行完，而B获取数据1也需要等待A执行完。这样A和B之间就出现了死锁。

  • 处理死锁的一个方法是超时控制和检测机制。

  • 尽量避免死锁才是最有效的解决方案：一开始获取所有锁，或者按照相同的顺序获取锁。

• 事务

  • ACID：原子性、一致性、隔离性、持久性。

  • 长事务：跨越多个请求的事务称做长事务。

  • 延迟事务：尽可能晚的打开事务，可以减少事务执行时间，但是可能会导致不一致读。

  • 锁升级：如果一个事务锁住了多行数据，数据库无法处理那么多锁，就会升级为表锁。

  • 减少事务隔离：可串行化的、可重复读、读已提交、读未提交。

    • 可串行化：完全隔离，所有事务时串行化执行的。

    • 可重复读：允许幻读，幻读就是A向一个集合中加入一批元素，而B只读到其中一部分数据。通常是插入数据引起的。

    • 读已提交：重新读取已经提交的数据

    • 读未提交：允许脏读，读取没有提交的数据，而这些数据又被回滚了，这种情况称之为脏读。

  • 业务事务和系统事务

    • 系统事务：通常说的数据库事务

    • 业务事务：是一组业务操作，业务也期望它有ACID的属性，解决这一问题的方案是离线并发。

    • 离线并发：把业务事务分成一系列的短事务。

    • 业务事务最大的问题是隔离性。

• 离线并发控制的模式

  • 处理离线并发问题的首选是乐观离线锁。因为它易于实现，提供最好的灵活性。

• 应用服务器并发

  • 避免显示的处理同步和锁，最简单的方法是每会话一进程

 

7.会话状态

• 无状态的价值

  • 如果请求之间不需要保持状态，就不用关心哪个对象来处理某一次请求。有状态则需要找同一个对象来处理。无状态使得我们可以缓存这些对象，用很少的对象就可以处理很多的用户。

• 会话状态

  • 会话状态存在于一次业务事务中，它并不具有ACID的特性。

  • 会话状态就是一组数据，它必须在各次请求间记录以保证程序的正确执行。

• 存储会话状态的方法

  • 客户会话状态：在客户端保存数据。

  • 服务器会话状态：请求数据放在内存中，也可以序列化的方式长久保存，偏向于使用这种会话状态。

  • 数据库会话状态：把会话数据分解成多个表和域。

  • 如果使用集群来提高系统吞吐率，就需要考虑会话迁移。

 

8.分布策略

• 分布对象的诱惑

  • 分布对象可以独立的可分布到不同处理节点上，看上去能提升性能，但是结果只会影响性能。因为这种设计只会使得系统更难构建和部署。

• 远程接口和本地接口

  • 本地接口：最好是细粒度接口。

  • 远程接口：使用粗粒度接口。

• 分布对象设计第一定律：不要分布使用对象。

• 必须使用分布的情况

  • 传统客户机和服务器之间

  • 应用软件和数据库之间

• 关于分布边界

  • 尽量减少远程调用，这样才能发使得性能开销最小

  • 远程外观：粗粒度接口不做任何业务，只是充当细粒度对象的外观，或者说一层适配的壳。

  • 延迟加载的方案传递对象。

• 分布接口

  • 远程调用过程：RPC

  • 更建议使用基于消息的处理方式，其本质是异步的。

 

9.通盘考虑

• 三个方面的技术实践：持续集成、测试驱动开发、重构。

• 从领域层开始主要可选事务模式、表模块、领域模式。

  • 事务模式比较简单，但是不适合复杂的业务。领域模式比较复杂，但是可维护性和可扩展性较好。表模式是事务模式和领域模式折中。

• 深入到数据源

  • 事务脚本的数据源：脚本本身包含数据库逻辑，一般使用离线乐观锁避免并发问题。简单易用、维护性差。

  • 表模块数据源：数据库逻辑集中处理。

  • 领域模型的数据源：数据库逻辑处理比较复杂，常使用数据映射器。

• 表现层有转换视图、模板视图、两步视图

  • 转换视图就是服务器代码夹杂HTML代码，适合简单的页面展示。

  • 模板视图适合较为复杂的页面。

  • 两步视图更能表现多种形式的站点，但是最好能做到将领域层远程外观包装

• 常见的分层方式

  • Brown分层模型：表现层、控制层、领域层、数据映射层、数据源层

  • Core J2EE分层模型：客户层、表现层、业务层、集成层、资源层

  • DNA架构分层模型：表现层、业务层、数据访问层

 

10.领域逻辑模式

• 事务脚本

  • 简介：使用过程来组织业务逻辑，在过程中直接调用数据库。

  • 运行机制：可以将多个相关事务脚本组织在一起形成一个类，也可以一个事务脚本一个类。

  • 使用时机：事务脚本适应于少量逻辑的应用程序。

• 领域模型

  • 简介：合并了行为和数据领域的对象模型，需要对目标业务领域建模，模拟业务数据和业务运行规则，并整合到一起。从而使得数据和数据之上的操作紧密聚合。

  • 常见问题：领域对象常见的问题是过于臃肿，但是重构可以较好的解决这个问题，因此不建议分离行为。

  • 运行机制：领域模型应当使用细粒度的对象，建议不进行同级调用，避免重进入行为。

  • 使用时机：使用领域模型首选的数据库交互方式是数据映射器。它有助于保持领域模型对数据库的独立性。

• 策略模式：将一组操作组合在一个小的类层次结构中。

• 表模块

  • 简介：表模块以一个类对应数据库中的一个表来组织领域逻辑。

  • 运行机制：表模块是模拟一个SQL表，基于表的行为分组将行为和操控的数据进行封装。

  • 使用时机：当应用程序基于一个公用的面向表的数据结构时，更适合使用表模块。

• 服务层

  • 数据源层->领域模型层->服务层->控制层->表现层。

  • 简介：服务层定义了应用的边界和从控制层所能看到的可用操作集，它封装了应用的业务逻辑、事务控制机器操作实现中的响应协调。

  • 运行机制：

    • 业务逻辑：分层两类，分别是”领域逻辑“和”应用逻辑“，领域逻辑的”领域模型“往往更优于应用逻辑的”事务脚本“。

    • 实现方法：分为”领域外观“和”操作脚本“两种基本实现方法。领域外观就是封装细粒度的领域模型，而操作脚本就是组合应用实现。

    • 是否远程：从接口粒度来讲服务层适合远程，但是要考虑”分布式对象设计第一定律“，从系统层面不建议大量使用远程。

    • 识别服务和操作：可以把一组操作抽象化，但是更建议使用领域模型的划分来抽象。

  • 使用时机：适用于多个操作集合，多个事务性资源之间进行原子化的应用逻辑处理。

 

11.数据源架构模式

• 表数据入口

  • 简介：表数据入口包含了用于访问单个表或视图的所有SQL。

  • 运行机制：一般是从数据库中获取数据的查找方法以及更新、插入、删除方法。

  • 使用时机：表数据入口和表模块模式可以很好的契合，同样也非常适合事务脚本。

  • 特点：把常用的sql组织在一起形成一个独立单元，这种模式类似于存储过程和表数据库入口。

• 行数据库入口

  • 简介：行数据入口提供了看起来像记录结构中记录的对象，但可以用编程语言的常规机制访问它。所有对数据源的访问细节都隐藏在这个接口之后。

  • 运行机制：每一行数据都是一个内存对象。

  • 使用时机：行数据入口适合事务脚本模式。

• 活动记录

  • 简介：封装了数据表的一行，并在这些数据上增加了领域逻辑。

  • 运行机制：构造数据的实例，并在实例上增加业务逻辑。

  • 使用时机：活动记录适用于不太复杂的领域逻辑。其是领域模式中的一种选择，另一种是数据映射器。

  • 特点：简单，活动记录容易创建，并且容易理解。但是不适合集合、继承等，这样会导致活动记录凌乱。

• 数据映射层

  • 简介：分离内存对象与数据库的一个软件层。

  • 运行机制：

    • 要从数据库中加载数据对象，将调用映射器上的查找方法。映射器使用标识映射判断加载的对象是否已经读入，如果没有读入将其读入。

    • 要保存一个领域对象，映射器从领域对象读出数据然后将它写入数据库。

    • 工作单元模式是将它们组织起来的好方法。

  • 使用时机：数据库方案和对象模型彼此独立演变时需要用映射器。

 

12.对象-关系行为模式

• 工作单元

  • 简介：记录在业务事务过程中对数据库有影响的所有变化，并在操作结束后，作为一种结果保存到数据库。这需要工作单元了解所有需要对数据库做的改变。

  • 解决的问题：解决大量规模很小的数据库调用。

  • 运行机制：

    • 用调用者注册方式、用对象注册的方式、工作单元控制器。

    • 把变化记录下来，然后统一处理。

    • 批量更新也是工作单元的一个处理方式。

  • 使用时机：

    • 处理大量规模很小的数据更新。。

    • 处理利用乐观离线锁和悲观离线锁跨越几个系统事务的业务事务。

• 标识映射

  • 简介：通过在映射中保存每个已经加载的对象，确保每个对象只加载一次。

  • 运行机制：通过键保存在某个特定会话的对象中。工作单元是放置标识映射最理想的地方。

  • 使用时机：标识映射是作为数据库读取操作的高速缓存，在同一会话存在更新冲突时比较适用。

• 延迟加载

  • 简介：在对象被使用时才会加载。

  • 运行机制：延迟初始化、虚代理、值保持器、重影。

    • 延迟初始化：每次访问属性域，检测属性是否为空，如果为空则计算域的值。

    • 虚代理：一个空对象，调用时才会从数据库加载恰当的对象。

    • 值保持器：第一次访问时，从数据库获取数据。

    • 重影：只包含一部分数据，使用某个属性时才会加载这个属性值。

  • 使用时机：取决于加载的数据量和调用的数据库次数。

 

13.对象-关系结构模式

• 标识域

  • 简介：为了在内存对象和数据库行之间维护标识，而建立的存储域。

  • 运行机制：

    • 选择无意义的键，因为键须具有唯一、恒定的特性。而有意义的键可能冲突、变化。

    • 建议使用数字计数器生成新的键，减少键表争夺引起的锁表风险。

  • 使用时机：在内存对象和数据库行之间存在映射关系的时候使用标识域。

• 外键映射

  • 简介：外键映射把对象引用映射到数据库中的外键。

  • 运行机制：关联关系由数据库中的外键取代。

  • 使用时机：外键映射适用于一对一或一对多的关联。

• 关联表映射

  • 简介：把关联关系保持为一个表。

  • 运行机制：用一个链表保持这种关联关系，这个链表仅仅包含相互关联的外键ID。

  • 使用时机：适用于多对多的关联关系。

• 依赖映射

  • 简介：让一个类的映射器执行相关映射来简化映射过程，就看作依赖映射。

  • 运行机制：

    • 把依赖类当成所有者类的一部分加载，如果依赖者加载比较耗时且不常用，就可以适用延迟加载的方式。

    • 依赖者的更新可以通过删除和插入来处理。

  • 使用时机：

    • 当一个对象只被另一个对象引用时使用。

    • 每个依赖者只有一个所有者，依赖者不能被除所有者之外的对象引用。

    • 工作单元中不建议使用依赖映射。

• 嵌入值

  • 简介：把一个对象映射成另外一个对象表的若干字段。可以当成一种特殊的依赖映射。

  • 运行机制：当所有这对象加载时，依赖者对象也被加载。

  • 使用时机：需要把值转换成对象的时候。

• 序列化LOB

  • 简介：通过将多个对象序列化到一个大对象中来保存一个对象图，并存储在一个数据库字段中叫做序列化LOB。

  • 运行机制：二进制序列化和文本字符序列化。

  • 使用时机：对象关系复杂，存在链式关系时可以使用。

• 单表继承

  • 简介：把一个继承结构中所有类的所有域都映射到一个单表中。

  • 运行机制：使用一个表包含某个继承层次中所有类的所有数据。

  • 使用时机：只关注一个数据表和获取数据不需要执行连接操作时使用。

• 类表继承

  • 简介：用每个类对应一个表来表示类的继承层次。

  • 运行机制：

    • 每个类对应一个表，领域类中的域直接映射到相应表中的字段。

    • 最大的问题是多表查询，建议先读取根表，然后根据根表查询其他表数据。

  • 使用时机：在数据库字段较为稳定，并且为了更加简单明了的体现领域模型和数据库之间的关系时使用

• 继承映射器

  • 简介：用来组织可以处理继承层次的数据库映射器的一种结构。

  • 运行机制：采用层次的方式组织映射器，这样每个领域类都有一个映射器保存和加载数据。

  • 使用时机：通用的方案，对任何基于继承的数据库映射都有意义。

 

14.对象-关系元数据映射模式

• 元数据映射

  • 简介：在元数据中保持关系-对象映射的详细信息。

  • 运行机制：通过代码生成和反射程序表示元数据信息。

  • 使用时机：元数据映射能大大减少处理数据库映射所需工作量。

• 查询对象

  • 简介：描述一次数据库查询的对象。

  • 运行机制：

    • 查询对象时解释器模式在表示SQL查询上的应用，可以把对象结构转换为适当的SQL字符串。

    • 结合标识映射使用，能够避免冗余查询。

  • 使用时机：查询对象时一种用于组装的高级模式，适用于领域模型和数据库映射器。

• 资源库

  • 简介：协调领域和数据映射层，利用类似于集合的接口来访问领域对象。

  • 运行机制：资源库是一种模式集合的高级模式。

  • 适用时机：在大型系统中，减少用于处理所有要执行查询的代码总量。

 

15.Web表现模式

• MVC

  • 简介：模型-视图-控制器模式。

  • 运行机制：

    • 模型：一个表示领域信息的对象，包含UI之外的所有数据和行为。

    • 视图：UI中模型的显示。

    • 控制器：处理请求动作的对象。

    • 从模型中分离表现：建立观察者模式，使得表现依赖模型的模式灵活使用。

  • 使用时机：Web设计中大部分模式都适用。

• 页面控制器

  • 简介：在Web站点上为特定页面或者动作处理请求的对象。

  • 运行机制：

    • 控制器绑定在每个动作上。

    • 从请求对象中获取必要的请求数据

    • 创建和调用模型对象来处理数据

    • 把处理后的数据传送到页面显示

  • 使用时机：在具有导航性值的Web站点中非常适用

• 前端控制器

  • 简介：为Web站点处理所有请求的控制器，解决输入控制器行为分散的问题。

  • 运行机制：前端控制器处理Web站点的所有应用，通常由Web处理程序和Command集合组成。

  • 使用时机：在需要简化Web服务器的配置，且解决重复控制器代码问题的时候适用。

• 模板视图

  • 简介：通过在Html页面嵌入标记向Html发送消息。

  • 运行机制：

    • 在静态页面中插入标记。

    • 条件显示：进行条件判断，只有满足条件才会显示。

    • 适用脚本：使用服务器页面。

  • 使用时机：可以很好的支持图形设计者设计页面，但很容易被插入复杂逻辑，从而导致很难维护。

• 转换视图

  • 简介：一个视图，它一项一项地处理领域数据，并且把他们转换成HTML。

  • 运行机制：

    • 写一个查看面向领域的数据并将其转换成HTML内容的程序。

    • 转换视图的组织是围绕每种输入元素单独转换，而模板视图的组织是围绕输出。

  • 使用时机：转换视图能避免在视图中引入太多的其他逻辑，但是视图代码容易混淆。

• 两步视图

  • 简介：用两个步骤来把领域数据转换HTML，第一步：形成某种逻辑页面，第二步：把逻辑页面转换为HTML页面。

  • 特点：可以使页面有一致的风格和组成形式，能轻松地对站点中所有页面进行全局性地外观改变。

  • 运行机制：

    • 第一阶段：把信息装配到一个逻辑屏幕结构中。

    • 第二阶段：获得面向表现的结构，并把它放入HTML中。

  • 使用时机：需要有一致的风格和更灵活的全局改变时使用。

• 应用控制器

  • 简介：一个用来处理应用程序流的集中控制点。

  • 运行机制：通常维持两个指向类的引用集合，一个是指向领域命令，另一个是指向视图。

  • 使用时机：应用控制器能解决流程变化时，修改多个地方的问题。

 

16.分布模式

• 远程外观

  • 简介：为细粒度对象提供粗粒度的外观来改进网络上的效率。原因：远程调用会有更大的开销，例如：数据可能需要编组、可能需要安全检查、发送的数据包需要路由等。

  • 运行机制：把复杂业务逻辑的细粒度接口转换到可一次调用的的外观对象。一组远程外观资源库组成一个远程调用服务层

  • 使用时机：当需要调用远程接口的时候，就应该使用远程外观。

• 数据传输对象

  • 简介：为了减少调用次数而在进程间传递数据的对象（可以理解为json格式数据）。

  • 运行机制：它包含集结所有远端对象可能需要的数据。

  • 使用时机：当需要在两个进程之间传输多个数据项时，应该使用数据传输对象。

 

17.离线并发模式

• 乐观离线锁

  • 简介：通过冲突检测和事务回滚来防止并发事务中的冲突。针对一个业务事务中有一系列系统事务，需要保证数据一致性状态和不丢失更新数据的场景（冲突检测）。

  • 运行机制：

    • 乐观离线锁通过检查在会话读取一条记录，业务事务提交时检测数据是否发生变化来保证数据的一致性。

    • 最常见的实现方式是记录版本号，通过版本号来对比判断数据是否发生变化。

    • 乐观锁通常是业务事务提交时报告冲突，如果能提前通知冲突会有更好的效果。

  • 使用时机：乐观锁适用于并发管理中业务事务冲突低的情况。

• 悲观离线锁

  • 简介：每次只允许一个业务事务访问数据以防止并发业务事务中的冲突（冲突避免）。

  • 运行机制：

    • 使用数据库的写锁（排他锁）和读锁（共享锁），来控制并发问题。

    • 悲观锁需要防止并发问题，可通过超时控制、锁检测、一开始读取所有锁、按顺序读锁的策略来解决死锁问题。

  • 使用时机：悲观离线锁适用于冲突率很高的并发场景中。但也会影响系统性能，需要考虑多方面的因素来使用。

• 粗粒度锁

  • 简介：用一个锁锁住一组相关的对象。

  • 运行机制：为一组对象建立一个控制点，例如版本号，每个对象共享同一个版本号。

  • 使用时机：当一组业务具有一致性的关联时，使用粗粒度锁是一个很好的选择。

• 隐含锁

  • 简介：允许框架或超类型代码来获取离线锁。

  • 允许机制：分解代码，在应用框架中完成那些不能跳过的锁机制。

  • 使用时机：在应用框架中都适用。

 

18.会话状态模式

• 客户会话状态

  • 简介：将会话状态保存在客户端。

  • 运行机制：服务器每次响应都会把所有的会话状态传给客户，这样服务器就是完全无状态的。

  • 使用时机：支持无状态服务器对象，从而提供最大的集群性能和容错恢复，适用于小数据量。一般只作为会话标识号来使用。

• 服务器会话状态

  • 简介：将会话状态以序列化形式存放在服务器端。

  • 运行机制：

    • 把会话数据放在应用服务器的内存中。

    • 可以把会话数据以客户端的会话标识作为键标识存放在内存映射表中，只需要客户给出会话标识号，服务器就可以从映射表中取出会话数据。

    • 把会话数据存放在共享服务器，例如redis中就可以支持集群和故障恢复，也可以支持分布式服务器。

  • 使用时机：需要支持分布式、集群和故障恢复的情况下适用。

• 数据库会话状态

  • 简介：将会话数据作为已提交的数据保存到数据库中。

  • 运行机制：当客户向服务器发送请求时，服务器要先从数据库中读出请求所需的数据，进行处理后再将数据存回数据库中。

  • 使用时机：数据库会话状态可以支持集群和故障恢复。但是对比redis，数据库会话性能较低。

 

19.基本模式

• Gateway

  • 简介：Gateway是封装外部系统或资源访问的对象。

  • 运行机制：使用包装器模式，封装外部资源，创建一个简单的API，并用入口将对该API的调用转移到外部资源上。

  • 使用时机：将接口的复杂性封装起来，而不要让复杂性蔓延到整个系统中。

  •