选择框架需要考虑的问题

2008-12-2
需要考虑的问题：
1.集群
2.事务处理
3.安全
4. 日志
5. cache
6.国际化
7.报表
8.打印
9. 客户端校验
10.重复提交
11.异常处理
12.分页 等等

考虑集群的目的：
负载均衡和高可用性（HA）,需要分布式集群,在不同的机器发布不同的模块的集群是很少的.

需要集群的对象：

能集[/b]群[/b]的对象只能是哪些部署的分布式对象。因此，负载均衡和故障转移发生在调用分布式对象方法时。这样的分布式对象包括：JSP&Servlet(HTTP),DB Object(Statement execute),EJB Object(method invoke),JMS Broker(message.send),JNDI Object(Context.lookup),Web Service(SOAP/HTTP)

按照层次划分集群可以分为：
1. web层集群
2.app（业务逻辑）层集群
3.数据库层集群

按照这3层分别简述ejb和spring的区别

对于ejb集群：
1.web层集群
2. Application集群

3. 再加上一个数据库层集群
ejb集群,一般web和app物理上分开好处：
1：更加安全，因为app server一般部署在放火墙里面；
2：对于一些关键业务，不会相互抢占资源；
3：如果采用ejb的话，可以在不同的机器发布不同的模块，进行分布式计算； （也可以不进行分布式计算）

对于spring的集群：
1. 对于spring只能做一个web层集群；
2. 加上一个数据库层集群；

web服务器和App服务器在物理上分开的好处有：

Cache ：

结论：

1. spring不支持集群是指：
spring 不支持集群，是指业务层的集群，但每层都可以做集群，包括数据库层，所以我们可以在web层集群，就用lvs，或tomcat、jboss、weblogic、apache等都可以

其他网站上的一些其他论调: 供参考： 以后理解了，再放到上面的文章里；

标准的JavaEE集群，一般情况下是这样的。
入口是一个负载均衡器（有时候也用apache之类的），然后是若干台web服务器（如Tomcat），再后边是EJB集群。最后是数据库。
这是JavaEE集群模型的标准构造。JavaEE集群的核心是EJB集群。但是如果应用没有达到足够大的规模，且设计不好的话，会产生很多问题。这也是当初为什么老EJB架构被人诟病的地方。

单机应用是中小型项目的主流。我们在中小型项目中一般只用到事务处理，分布式、容灾等功能一般用不上。所以Spring才会发展这么快。但是企业在发展，当初用Spring开发的程序需要跑集群了，结果发现无法在集群上使用，所以才会出现用AOP方式对Spring添加集群和JVM分布式缓存来进行集群化的方案。但即使如此，很多单机下可以使用的代码，在集群下可能是根本无法跑的。单例、静态对象等等，在集群模式下会出现各种问题。
所以，现在很多人都只用F5和Apache做分发器，后边跟一大堆互不往来的Tomcat之类的Web服务器。这么做最大的问题是无法使用缓存。因为如果使用缓存，那么其他机器更改了数据库的话，缓存无法刷新而形成脏数据。结果大大拖累了性能。
如果你的应用是中小型低负载应用，那么可以只考虑单机。如果以后要使用集群，可以先用Spring集群（好像是叫Cluster4Spring）和JVM分布式缓存。如果应用大到必须分布式的程度，那么还是更换成EJB架构吧。

另外一个观点 ：
EJB解决的是分布式计算问题，不是群集问题，就算你用EJB，你照样无法做到缓存同步，Session同步，分布式和群集是两个不同的概念；
Spring的集群应该不是问题，我倒比较头疼像hibernate这样的orm，如果用于集群，那么cache就完全不能使用，否则一台机器修改了数据，另一台不知道还在用cache中的数据， 解决方式如下：

可以用memcached作为缓存服务器，Hibernate把二级缓存放进memcached，现在Java的memcached client已经比较成熟了，性能还不错

可是如果是属于需要记录一些数据的单例就不好说了。比如监听者模式、记录在线人数的Bean

要做大规模的群集，就得走SNA架构，所以在编程模式上面，这种东西就不能用，但你可以把这些状态数据放进缓存服务器，效果是一样的

继续增加中 ........

本文出自 “技术、业务模型” 博客，请务必保留此出处http://zhaocz.blog.51cto.com/542576/116727