企业应用架构模式 (简单笔记)

目标：

   做什么和怎么做就够了

   本书分为两部分，第一部分要细读，第二部分参考

前言

1.企业应用：

涉及大量复杂数据，各种不同的业务规则，也叫做信息系统，特点如下：

      大量数据；  并发度高；  和相关系统集成；  持久化数据

   最具条件性的：了解有哪些候选方法及各种方法间的优缺点比较，最后决定用那种

2.企业应用种类

   对于特定的问题，要在特定的条件下选择一合适的设计，没有万能药，任何模式都有局限性

   在线零售系统特点：用户量大（考虑用户突然增大时怎么办）；逻辑简单；访问方便（使用web实现，并支持各种浏览器）；数据源（可能需要与外部交互）

   合同自动处理系统特点：用户量不大；业务逻辑复杂； 用户界面复杂（使用ext或富客户端实现）；交互时间长（可能2-3个小时）

   小公司的开支跟踪系统：开发速度要快；可扩展；集成性要好

3.基于性能考虑

   尽量避免远程调用

   构建系统时，关注硬件可伸缩性比关注软件的容量或效率更有用

   常见做法：先建立系统，调试运行，用基于测量的严格优化来提高性能，在做优化时要与前两次对比

4.模式

   模式使用时，需要进行变化

表述——分层

    1.决定建立哪些层次及每一层的功能

       已经有通用的view-action-service-dao结构

    2.层间消息传递

       层次之间是从上向下单向依赖，尽量不要让底层依赖上层，如果需要此功能，可通过事件方式进行

    3.功能该放入哪一层

      在实际开发中，某一个功能该放在view还是controller不太好区分，一个办法是：假设换一种显示方式，如freemarker，是否在html和freemarker中有重复的逻辑，则这个功能应该在controller中

    4.部署

       客户端有利于响应时间、网络中断时；服务器端有利于系统维护

       尽量不要把一层放在多个进程中完成

    5.complexity booster：增加复杂度

       分布、多线程、泛型差异、多平台开发及极限性能要求

表述-组织业务逻辑

三种方式transactionscript 、objectmodel（面向对象基本都是这种吧）、tablemodule（不考虑类继承和映射）。对于复杂逻辑或考虑可扩展性，基本上没悬念都是第二种

   服务层：业务逻辑进一步细分为DAO层和服务层；作用：事务封装和安全检查

映射到关系数据库

1.业务对象和数据库完全独立

   间接层完成业务对象和表之间的映射，完成数据库和业务对象之间所有存取操作

   工作单元模式：解决数据库对象读取和修改的同步问题，大概是脏数据、不可重复读等，基本思路是：其他部分不直接调用保存方法，而是通过工作单元读取数据，保存数据。用于数据库交互比较复杂时

   标识映射：当系统加载一个对象时，先检查是否已存在，是则返回它的引用，避免多次加载。

   延迟加载

   如果使用objectmodel，一次加载相关对象

2.读取数据

   元数据映射：把映射浓缩到元数据映射上（XML映射）

   连接对于事务是密不可分的，一个方法是：将其捆绑到事务中，工作单元模式很自然地适合管理事务和链接

web表现层

    第九章javaweb设计

并发

1.场景：跨事务数据处理（offline concurrency），服务器端同步   ；请求 client和server一次交互，会话由一系列requst组成

2.解决方法：1）分离可变与不可变数据，只有修改才会并发；2）隔离：每一片数据只能被一个执行单元访问（读写）；文件锁（只能一个修改，其他只读拷贝）可使用隔离区安排资源，设计方法是：保证每个隔离区完成尽可能的任务。 1.考虑哪些数据不变或基本不变（共享它们）；2.让只读取数据的程序使用slave数据源

乐观和悲观并发控制：（对可变数据）乐观锁考虑冲突进行提交时会提示怎么处理，当冲突很少时，应选择乐观锁，冲突较多且后果严重则选择悲观锁，悲观锁当文件编辑时，其他人不能访问。

   通过时间戳进行冲突检测（乐观锁）

   检测不一致读：所有读取的数据都要与共享数据进行版本标记（时间戳）比较，任何不同意味着冲突的发生，可通过分离使用过的数据（修改时间戳）和仅仅读过的数据（时间戳不变）

   时序读：使用时间戳或不变标签做约束条件

   死锁：强制所有人开始获取全部可能的锁，并加上时间限制

事务

   请求开始时启动事务，结束时提交事务（尽量简短）

   使用事务时，清楚被所中的是什么（行，表，数据库）

   要在性能和错误之间折中

    事务：原子性、持久性（崩溃下能保存数据）、一致性、隔离性

   让业务事务支持ACID最简单的方法是在单个系统事务中，执行完整业务事务（当只需适度并发）

   跨系统事务处理并发控制：乐观离线锁；在业务事务期间使用乐观的并发控制

   尽量避免显示同步和锁

   对类变量或全局变量考虑同步

   为线程创建一个隔离区，让每次都新的对象来处理请求

会话状态

   无状态会话：若在请求中不保存状态，则不用关心哪个对象来处理请求，若状态要保存，则找同一个对象来处理有状态会话，可在客户、服务器、数据库中实现。

   通常将会话信息放在服务器中最容易使用，特别是会话信息不需要存储在持久介质中，也可使用客户对话状态存放数据标示号和较小的会话；数据库会话模式在集群中使用。

分布策略

   远程使用的对象接口和本地使用的有所区别：本地接口细粒度（扩展性）； 远程接口要粗粒度（一次得到大量信息，最小化远程调用的数量）

   利用多处理器资源：使用集群系统，在每个处理器上都部署所有的对象，并在其他几个几点复制它们

   系统中每个地方尽量减少远程调用，调用接口选择更高效，而非XML

   若两个系统使用相同平台构建，最好使用该系统的远程调用机制，webservice更适合跨平台的。

   异步的，基于消息的处理方式。

通盘考虑：设计企业应用

    1.从领域层开始

       优先考虑业务对象模型：简单问题也可，复杂问题非你莫属

    2.深入到数据源层

       领域模型的数据源：行数据（对应表中一行，逻辑简单时）；数据库映射（类和表不是一一映射）；使用工作单元（ThreadLocal）进行并发控制（映射工具有）

    3.表现层

       胖客户界面：extJs、MVC等

    4.具体的建议

       存储过程与数据库处于同一过程中，速度最快，但会和数据库绑定，除非有很强的性能开销，否则不适用