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

总是埋头写代码，突然发现自己的理论水平有待提高。

在书架上发现了这本《企业应用架构模式》，读了几页，感觉收获很大，这本书是对项目经验的一个总结。熟悉下概念，参考下书中的模式

 《企业应用架构模式》  英文原名《Pattern of Enterprise Application Architecture》 Martin Fowler著， 王怀民 等译

 一 引言

 01 架构是 专家级的项目开发人员对系统设计的一些可共享的理解，具有主观性。一般表现为系统的主要组成部分和之间的交互关系。（好抽象!!!）

 02 企业应用

在某些方面，企业应用比 电信软件复杂。

企业应用特征：

持久化的数据===数据库系统

大量数据===

高并发性====

大量操作数据的UI===很烦并且容易出错，JS， AJAX， RIA。。。。。

相关系统的集成===每个企业都有大量的遗留系统，特别是异构的, RPC, Web Service.. SOA....

概念的不一致==在企业的不同部门的业务中领域模型会不同，并且业务中有太多的“特殊情况”，做BA的要努力解决的问题。

03 企业应用的分类

B2C: (哈哈 taobao),B/S结构，大量的用户，可伸缩性-方便硬件扩展，跨浏览器，业务规则相对单一。 （这种系统还没有机会接触，应该很不错）

 租赁合同处理系统，用户少，但是业务规则很复杂很多变，业务随意性很大，（没有人规定业务有什么标准，我们最常见的系统，总是感觉业务搞不顺，业务的随意性对技术架构提出了很高的要求，所以大家喜欢说可扩展性）

小公司 的开支跟踪系统，用户少，功能简单，但是要求快速开发和后续信息化系统的集成。（这种快速开发是关键，但是长远来看，要注意自己的架构，免的N年后留下N次方个历史遗留系统，但是又集成不起来。还要注意和业界其他系统有可能的接口）

3个很简单的例子，说的很有代表性，从大到小，点出需要注意的地方。

04 性能的考虑

 作者的办法： 首先建立系统，然后通过严格的优化过程来提高性能。 （我们很多系统采用的发展道路，客观上讲，首先要有东西出来，不然老板要骂人了）

但是有些架构（结构）上的问题是很难性能优化的， 举例，我们曾在很差的网络环境下采用asp.net+infragistic来最UI，后来没有办法了。UI成了瓶颈。

 作者的建议： 1. 少用远程调用（现在很时髦的东西） 2, 性能优化的前提是一个严格的测量指标（很科学的说） 3，配置上的改变使性能优化失效，如升级数据库。

名称解释

响应时间：完成一次请求所花的时间

响应性：系统响应请求的速度，（点个按钮等了1分钟，哈哈，UI要友好）

        等待时间：调用的往返时间，不包括业务处理，比如Web Service的空调用

        吞吐率: 略，发现自己很啰嗦

        性能可以指上面指标的综合，或其中部分

        负载：略  

        负载敏感度： 响应时间和在线用户的关系

        容量： 最大有效负载活吞吐率的指标。

        可伸缩性：添加硬件对性能的影响； 垂直伸缩，提高单个服务器的性能，  水平伸缩，增加服务器

        水平可伸缩很重要，因为硬件比软件成本低，但是也有BT的系统来再多的硬件也可以消耗，这种系统其实是有BUG，内存泄漏。