??xml version="1.0" encoding="utf-8" standalone="yes"?>
另一U简单点的架构就是只?/span> F5 负蝲均衡Q不?/span> was 集群Q每?/span> websphere server 上的 HttpServer 接受 F5 转发的请求,只向?/span> server ?/span> was 转发。这h?/span> websphere server 保持独立Q相互间没有数据交换和{发。不妨称为架?/span> B ?/span>
架构 A ?/span> B 各有优劣Q适合不同的需要,下面q行些比较:
Ø
从应用部|上看:
A 使用?/span> websphere 集群Q由一?/span> DeployManager q行分发Q部|应用,只需部v一ơ,?/span> DM 分发到几个节点上。?/span> B 每个 server 都是独立的,部v应用只能一台台部vQ如?/span> server 较少差别q不明显Q如果达?/span> 10 C上,一台台部v是一个比较痛苦的事情?/span>
Ø
?/span>
session
上看Q?/span>
A 使用?/span> websphere 集群Q可以用集提供的 session 复制Q对于一些关键应用(某台服务器宕机, session 也必M持的应用Q很有必要。而对于一些能够允?/span> session 丢失的应用,才可以?/span> B 。当?/span> A 也可以关?/span> session 复制Q因?/span> session 复制不管是用数据库方式q是内存方式QM消耗一定的性能。具体消耗多性能Q就要看不同?/span> application server ?/span> session 复制Ҏ(gu)了,x入了解,可以看集方面的文档Q我也只记得一个比较简单的 round robbin 了?/span>
Ø
从架构复杂性看Q?/span>
B 更ؓ单,因ؓ没有 DM 的概念,每台 server 都保持独立。而用了 DM 有时也会出现莫名奇妙的问题,q当然是׃不了?/span> DM 的机制所_但d也增加了复杂度,q点在后面的教训中进行说明?/span>
Ø
从水qx展性上看:
B 肯定更胜一{V只?/span> F5 能支持,多少?/span> server 都没关系。?/span> A 多台 server 做集,要看 websphere 支持的节Ҏ(gu)量,应该不会太大。这个如果哪位同学知道,敬请告知?/span>
当然 A ?/span> B 在服务器较多的情况下是可以共存的Q可以考虑几台机器做集,然后集群间做负蝲均衡Q这h可以减少部v的复杂度Q又可以带来较好的水qx展。由于没做过更大型的目Q这个也只是我的假象Q请做过的同学斧正?/span>
说一说集中到的问题?/span>
Ø
首先是对各节点的同步Q?/span>
有时Z方便试Q我们只对其中一个节点进行更改,试通过再放到其它节炏V而如果测试周期较长,有时׃造成节点的不同步Q出现各U各栯名其妙的问题。一个经验就是:无论如何Q在每天下班前要保证各节点的同步Q不同步的现象不要过夜?/b>
Ø
然后是对
DM
的理解:
我现在还只是实践阶段Q没有看q相x档。从意义上看Q它控制了相关的配置文gQ如果进行节点同步,׃由它把配|文件同步到它管理的节点上。这寚w|文件的修改提出了要求。我们开始只修改节点的配|文件而没有修?/span>
DM
的,l果q行节点同步׃覆盖修改的配|文Ӟ带来很多不必要的工作。经验就是:或者修?/b>
DM
的配|文Ӟ然后q行节点同步Q或者直接同时修Ҏ(gu)有节点和
DM
的?/span>
Ø
q有关于
cache
的:
Cache 是性能优化的一个有效手Dc在单机环境下,最单的是内存 cache Q?/span> static ?/span> Map p。而在集群环境中, cache 变的比较复杂了。首先还是从应用需求入手,是否要保持每台机器的 cache 同步。如果只是信息展C等要求不高?/span> cache Q不需保证 cache 的同步,问题也比较简单,自己写内?/span> cache Q或者用开源的 cache lg?/span> ehcache,oscache {就可以很好的解决问题。而如果需?/span> cache 在几个节点保持同步,需要特D的机制了, ehcache {号U支持分布式 cache Q但好像需?/span> jgroup Q配|比较麻烦,我没有用q,有用q的同学h教。我本来想?/span> session 保存Q然后进?/span> session 同步Q后?/span> IBM 使用数据?/span> cache Q即自己写代码, cache 在数据库中。这样不需?/span> session 同步Q对象不大,性能也能得到保证Q现在用下来效果q可以?/span>
a归正传,p openfans 现在l?/span> ddd 思想攚w过的模型。整体上看还是普通的三层架构体系Q展现层、业务层、持久层。展现层?/span> spring mvc Q力囑ց到只是展C相养I避免出现业务逻辑。再具体l分Q就?/span> jsp 面只有展示逻辑Q主要?/span> jstl 完成昄功能?/span> Controller 负责从页面获得参数、把数据传回面、控刉面流传和调用业务层的接口。持久层使用 hibernate Q在设计上我不是?/span> dao 方式为每个对象徏立相应的 dao Q也不是 ddd 推荐的每?/span> domain 一?/span> repository Q而是分成?/span> Persistence ?/span> Fetcher2 个接口?/span> Persistence 处理持久相关?/span> save ?/span> remove Ҏ(gu)Q?/span> Fetcher 则处?/span> get 相关。这样分的原因也很简单, persistence 是很E_的,对象都可以共用一个接口如 save Q?/span> Object Q,?/span> fetcher 千变万化,需要分c排序等接口?/span>
q样设计是与业务层架构相关的。我采用的是 domain 对象Q简U?/span> DO Q?/span> + 一层薄?/span> façade 的方式?/span> DO 处理自n的逻辑Q包括持久功能。本w?/span> DO 是没有持久能力的Q需要依靠注入的 persistence 接口Q这里就体现?/span> Persistence ?/span> Fetcher 分开的一个好处, persistence 所?/span> DO 可以q一个,l编E带来了方便?/span> Openfans 中采用的?/span> DO l承一个抽?/span> PersistentObject cȝ方式Q这?/span> DO 方便的获得了注入的能力和持久的能力。这样做有何优缺点还需要做些讨论,Z方便我也先q么用?/span> PersistentObject 代码如下Q?/span>
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;
}
}
q样 DO 只需要注?/span> persistence p得了持久的能力,而且可以把这U能力往下传递?/span> DO 获得了持久能力,有Ҏ(gu)q富血模型的想法了Q他能够处理一些业务,做持久然后调用引用对象的业务和持久方?/span> ( 从另外的角度看持久与业务其实是分不开?/span> ) 。这h业务装在了领域本nQ更适于用领域对象出发的方式L考问题。领域层?/span> façade 主要是ؓ?/span> Transaction 理和隐?/span> DO 接口。这?/span> DO 的业务方法都可以讄?/span> friendly Q仅怺间可见?/span> Façade 放?/span> domain 包中Q它负责l?/span> DO 注入 persistence bean Q调?/span> DO 的接口,提供l?/span> controller 一?/span> use case U别的接口,同时它也代理 fetcher 的接口?/span>
有了q个架构Q实现v来也不复杂,要配|的 bean 很少Q现在还没有使用 spring 2.0 ?/span> DO 配置在容器中Q。设计就?/span> DO 出发Q明它的属性和Ҏ(gu)Q让 hibernate 自己生成数据库表?/span>
q样设计也算是一ơ尝试吧Q其中肯定有很多考虑不周的地方,需要不断的讨论和改q?/span>
1.1 ?/SPAN>log.error表示pȝU错?/SPAN>
1.2 ?/SPAN>log.warn表示应用U错?/SPAN>
1.3 服务初始化或l束?/SPAN>log.info
1.4 ?/SPAN>log.debug替代outQ?/SPAN>debug要判?/SPAN>isDebugEnable
1.5 ?/SPAN>log.warn("",e)替代e.printstack
1.6 ?/SPAN>log4e生成log相关代码
1.7 Log信息要保证可L,需记录现场信息Q如当前处理id{?/SPAN>
2 exception
2.1 try catch内的代码不要太长
2.2 因ؓ性能原因Q?/SPAN>try catch放循环?/SPAN>
2.3 量避免catch(Exception)q样的写?/SPAN>
2.4 不同模块定义不同?/SPAN>exception
2.5 创徏应用的基c?/SPAN>exceptionQ特别是有定?/SPAN>error code需要的应用
2.6 只要catchplog error message
2.7 catchq封装成另一U?/SPAN>exceptionQ如果不nest原来?/SPAN>exceptionplog stackTrace
2.8 持久?/SPAN>throw dataAccessExceptionQ业务层throw checked exceptionQ展现层只显C?/SPAN>exception信息
2.9 规范?/SPAN>exception程定义如下Q?/SPAN>
业务层不需处理?/SPAN>runtime exceptionQ由展现层定义的exception controller捕获Q交l相应的error面昄q记?/SPAN>stack信息。业务层捕获下层?/SPAN>exceptionQƈ装成业务层?/SPAN>checked exceptionQ如?/SPAN>nest所捕获?/SPAN>exceptionQ则?/SPAN>log error messageQ如果不nest需要用log.warn(“?e)记录stack信息。展现层捕获业务层的exceptionQ应由处理业务层exception?/SPAN>error面来处理?/SPAN>
再谈一谈对真正的系l架构师的认识?/SPAN>JEF?/SPAN>2个主要设计者我都见q了Q都是香港hQ都温文雅Q学识渊博,l验丰富。能够聆听它们对软g架构的理解,寚w目实际问题的分析和解冻I真的是受益匪,对自己将来进行设计时思考问题的深度和广度都有很大的提高。这才是真正的架构师Q他需要对各种框架Q组仉了如指掌Q在面对具体的项目需求时能正的选择最适用的技术;他需要对软g整体架构有清晰的认识和理解,知道在面对实际项目时该用何U架构,包括thin clientq是rich clientQ?/SPAN>with EJBq是without EJB{等Q他需要有一U严谨求证的性格Q对M东西不是盲目下结论,而是Ҏ(gu)具体的分析和实证q行取舍。。。。。。通往真正的架构师的\q很长,需要经历的目Q需要做的事情还很多。我们不能盲目尊大(?/SPAN>springQ?/SPAN>hibernate做个项目就以ؓ很牛Q,也不能׃心(l验和领会都是靠目做出来的Q。我们应该时M持向上的心态,M动参与项目,L通,M,LȝQ去思考。即使将来成不了真正的架构师Q我们也可以自豪的说Q“我每一步都是踏实的C来的Q我每一个项目都是用心在做的Q我的代码都是注释详实,单易懂,为后来者提供很好的可重用基的而不是被人咒骂的Q我做的是可用的软g而不是垃圾Y件。”希望与所有有志于成ؓ真正的系l架构师的同学共勉?/SPAN>