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

目标:

   做什么和怎么做就够了

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

前言

1.企业应用:

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

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

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

2.企业应用种类

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

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

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

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

3.基于性能考虑

   尽量避免远程调用

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

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

4.模式

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

表述——分层

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

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

    2.层间消息传递

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

    3.功能该放入哪一层

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

    4.部署

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

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

    5.complexity booster:增加复杂度

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

表述-组织业务逻辑

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

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

映射到关系数据库

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

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

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

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

   延迟加载

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

2.读取数据

   元数据映射:把映射浓缩到元数据映射上(XML映射)

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

web表现层

    第九章javaweb设计

并发

1.场景:跨事务数据处理(offline concurrency),服务器端同步   ;请求 clientserver一次交互,会话由一系列requst组成

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

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

   通过时间戳进行冲突检测(乐观锁)

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

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

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

事务

   请求开始时启动事务,结束时提交事务(尽量简短)

   使用事务时,清楚被所中的是什么(行,表,数据库)

   要在性能和错误之间折中

    事务:原子性、持久性(崩溃下能保存数据)、一致性、隔离性

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

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

   尽量避免显示同步和锁

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

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

会话状态

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

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

分布策略

   远程使用的对象接口和本地使用的有所区别:本地接口细粒度(扩展性); 远程接口要粗粒度(一次得到大量信息,最小化远程调用的数量)

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

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

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

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

通盘考虑:设计企业应用

    1.从领域层开始

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

    2.深入到数据源层

       领域模型的数据源:行数据(对应表中一行,逻辑简单时);数据库映射(类和表不是一一映射);使用工作单元(ThreadLocal)进行并发控制(映射工具有)

    3.表现层

       胖客户界面:extJsMVC

    4.具体的建议

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


展开阅读全文

没有更多推荐了,返回首页