另一种简单点的架构就是只做 F5 负载均衡，不做 was 集群，每台 websphere server 上的 HttpServer 接受 F5 转发的请求，只向本 server 的 was 转发。这样每台 websphere server 保持独立，相互间没有数据交换和转发。不妨称为架构 B 。

架构 A 和 B 各有优劣，适合不同的需要，下面进行些比较：

Ø         从应用部署上看：

A 使用了 websphere 集群，由一个 DeployManager 进行分发，部署应用，只需部署一次，由 DM 分发到几个节点上。而 B 每个 server 都是独立的，部署应用只能一台台部署，如果 server 较少差别还不明显，如果达到 10 台以上，一台台部署将是一个比较痛苦的事情。

Ø         从 session 上看：

A 使用了 websphere 集群，可以使用集群提供的 session 复制，对于一些关键应用（某台服务器宕机， session 也必须保持的应用）很有必要。而对于一些能够允许 session 丢失的应用，才可以使用 B 。当然 A 也可以关闭 session 复制，因为 session 复制不管是使用数据库方式还是内存方式，总会消耗一定的性能。具体消耗多少性能，就要看不同的 application server 的 session 复制方案了，想深入了解，可以看集群方面的文档，我也只记得一个比较简单的 round robbin 了。

Ø         从架构复杂性看：

B 更为简单，因为没有 DM 的概念，每台 server 都保持独立。而使用了 DM 有时也会出现莫名奇妙的问题，这当然是由于不了解 DM 的机制所致，但总归也增加了复杂度，这点在后面的教训中进行说明。

Ø         从水平扩展性上看：

B 肯定更胜一筹。只要 F5 能支持，多少台 server 都没关系。而 A 多台 server 做集群，要看 websphere 支持的节点数量，应该不会太大。这个如果哪位同学知道，敬请告知。

当然 A 和 B 在服务器较多的情况下是可以共存的，可以考虑几台机器做集群，然后集群间做负载均衡，这样既可以减少部署的复杂度，又可以带来较好的水平扩展。由于没做过更大型的项目，这个也只是我的假象，请做过的同学斧正。

说一说集群中碰到的问题。

Ø         首先是对各节点的同步：

有时为了方便测试，我们只对其中一个节点进行更改，测试通过再放到其它节点。而如果测试周期较长，有时就会造成节点的不同步，出现各种各样莫名其妙的问题。一个经验就是：无论如何，在每天下班前要保证各节点的同步，不同步的现象不要过夜。

Ø         然后是对 DM 的理解：

我现在还只是实践阶段，没有看过相关文档。从意义上看，它控制了相关的配置文件，如果进行节点同步，就会由它把配置文件同步到它管理的节点上。这对配置文件的修改提出了要求。我们开始只修改节点的配置文件而没有修改 DM 的，结果进行节点同步就会覆盖修改的配置文件，带来很多不必要的工作。经验就是：或者修改 DM 的配置文件，然后进行节点同步，或者直接同时修改所有节点和 DM 的。

Ø         还有关于 cache 的：

Cache 是性能优化的一个有效手段。在单机环境下，最简单的就是内存 cache ，使用 static 的 Map 就行。而在集群环境中， cache 就变的比较复杂了。首先还是从应用需求入手，是否要保持每台机器的 cache 同步。如果只是信息展示等要求不高的 cache ，不需保证 cache 的同步，问题也比较简单，自己写内存 cache ，或者使用开源的 cache 组件如 ehcache,oscache 等就可以很好的解决问题。而如果需要 cache 在几个节点保持同步，就需要特殊的机制了， ehcache 等号称支持分布式 cache ，但好像需要 jgroup ，配置比较麻烦，我没有用过，有用过的同学请指教。我本来想使用 session 保存，然后进行 session 同步，后来 IBM 建议使用数据库 cache ，即自己写代码， cache 在数据库中。这样不需要 session 同步，对象不大，性能也能得到保证，现在用下来效果还可以。

言归正传，就讲 openfans 现在经 ddd 思想改造过的模型。整体上看还是普通的三层架构体系：展现层、业务层、持久层。展现层用 spring mvc ，力图做到只是展示相关，避免出现业务逻辑。再具体细分，就是 jsp 页面只有展示逻辑，主要使用 jstl 完成显示功能。 Controller 负责从页面获得参数、把数据传回页面、控制页面流传和调用业务层的接口。持久层使用 hibernate ，在设计上我不是按 dao 方式为每个对象建立相应的 dao ，也不是 ddd 推荐的每个 domain 一个 repository ，而是分成了 Persistence 和 Fetcher2 个接口。 Persistence 处理持久相关如 save 和 remove 方法， Fetcher 则处理 get 相关。这样分的原因也很简单， persistence 是很稳固的，对象都可以共用一个接口如 save （ Object ），而 fetcher 就千变万化，需要分页、排序等接口。

这样设计是与业务层架构相关的。我采用的是 domain 对象（简称 DO ） + 一层薄薄 façade 的方式。 DO 处理自身的逻辑，包括持久功能。本身 DO 是没有持久能力的，需要依靠注入的 persistence 接口，这里就体现按 Persistence 和 Fetcher 分开的一个好处， persistence 所有 DO 可以共用一个，给编程带来了方便。 Openfans 中采用的是 DO 继承一个抽象 PersistentObject 类的方式，这样 DO 方便的获得了注入的能力和持久的能力。这样做有何优缺点还需要做些讨论，为了方便我也就先这么用。 PersistentObject 代码如下：

public abstract class PersistentObject implements NeedPersist {

       private Persistence persistence;

       public void save() {

              persistence.save(this);

       }

       public void remove() {

              persistence.remove(this);

       }

       public void setPersistence(Persistence persistence) {

              this.persistence = persistence;

       }

       public Persistence getPersistence() {

              return persistence;

       }

}

这样 DO 只需要注入 persistence 就获得了持久的能力，而且可以把这种能力往下传递。 DO 获得了持久能力，就有点接近富血模型的想法了，他能够处理一些业务，做持久然后调用引用对象的业务和持久方法 ( 从另外的角度看持久与业务其实是分不开的 ) 。这样把业务封装在了领域本身，更适于用领域对象出发的方式去思考问题。领域层的 façade 主要是为了 Transaction 管理和隐藏 DO 接口。这样 DO 的业务方法都可以设置成 friendly ，仅相互间可见。 Façade 就放在 domain 包中，它负责给 DO 注入 persistence bean ，调用 DO 的接口，提供给 controller 一个 use case 级别的接口，同时它也代理 fetcher 的接口。

有了这个架构，实现起来也不复杂，要配置的 bean 很少（现在还没有使用 spring 2.0 将 DO 配置在容器中）。设计就从 DO 出发，明确它的属性和方法，让 hibernate 自己生成数据库表。

       这样设计也算是一次尝试吧，其中肯定有很多考虑不周的地方，需要不断的讨论和改进。

1.1 用log.error表示系统级错误

1.2 用log.warn表示应用级错误

1.3 服务初始化或结束用log.info

1.4 用log.debug替代out，debug要判断isDebugEnable

1.5 用log.warn("",e)替代e.printstack

1.6 用log4e生成log相关代码

1.7 Log信息要保证可读性，需记录现场信息，如当前处理id等

2 exception

2.1 try catch内的代码不要太长

2.2 因为性能原因，try catch少放循环内

2.3 尽量避免catch(Exception)这样的写法

2.4 不同模块定义不同的exception

2.5 建议创建应用的基类exception，特别是有定义error code需要的应用

2.6 只要catch就要log error message

2.7 catch并封装成另一种exception，如果不nest原来的exception就要log stackTrace

2.8 持久层throw dataAccessException，业务层throw checked exception，展现层只显示exception信息

2.9 规范的exception流程定义如下：

业务层不需处理的runtime exception，由展现层定义的exception controller捕获，交给相应的error页面显示并记录stack信息。业务层捕获下层的exception，并封装成业务层的checked exception，如果nest所捕获的exception，则仅log error message，如果不nest就需要用log.warn(“”,e)记录stack信息。展现层捕获业务层的exception，应由处理业务层exception的error页面来处理。

的整体架构图：

 

再谈一谈对真正的系统架构师的认识。JEF的2个主要设计者我都见过了，都是香港人，都温文尔雅，学识渊博，经验丰富。能够聆听它们对软件架构的理解，对项目实际问题的分析和解决，真的是受益匪浅，对自己将来进行设计时思考问题的深度和广度都有很大的提高。这才是真正的架构师！他需要对各种框架，组件都了如指掌，在面对具体的项目需求时能正确的选择最适用的技术；他需要对软件整体架构有清晰的认识和理解，知道在面对实际项目时该使用何种架构，包括thin client还是rich client，with EJB还是without EJB等等；他需要有一种严谨求证的性格，对任何东西不是盲目下结论，而是根据具体的分析和实证进行取舍。。。。。。通往真正的架构师的路还很长，需要经历的项目，需要做的事情还很多。我们不能盲目尊大（拿spring＋hibernate做个小项目就以为很牛），也不能丧失信心（经验和领会都是靠项目做出来的）。我们应该时刻保持向上的心态，去主动参与项目，去沟通，去交流，去总结，去思考。即使将来成不了真正的架构师，我们也可以自豪的说：“我每一步都是踏实的走下来的，我每一个项目都是用心在做的，我的代码都是注释详实，简单易懂，为后来者提供很好的可重用基础的而不是被人咒骂的，我做的是可用的软件而不是垃圾软件。”希望与所有有志于成为真正的系统架构师的同学共勉。