|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-01-04
引用 2台Tomcat服务器 hibernate貌似自己维护一级缓存，在会话期间多个服务器的一致性估计比较难保证。 |
| 返回顶楼 | |
|
发表时间：2012-01-04
mazzystar 写道 引用 2。单从开发成本上讲却还是可以，另外hibernate的好处是可以少写sql,而我们系统经常需要更改，hibernate也带来一些方便，例如增加某个字段，采用sql方式需要把sql和entity对象都改过来，采用hibernate是比较的方便，只要修改entity对象和xml或者annotation即可 hibernate 开发速度毋庸置疑，如果能做到“尽量不用他的那个配置做复杂的关联。 ” 应该会不错的。主要是上个项目里hibernate没用好，产生了性能问题，最后把大部分查询转到mybatis上了。另外hibernate 会自动持久化，有一次一个方法的事物忘记设置成只读的了，发版后才发现有个关联表的数据被删掉了，造成了比较严重的事故。从哪以后就感觉用hibernate不太放心。希望你们用的顺利 我们在使用hibernate中也是发现了不少问题，比如在xml或者annotation中配置表与表的关系之后，他会根据配置自动发送其他代码，我认为这个对代码的可阅读性是很不好的实践，因为从代码没有显式调用却产生了sql,不小心就会漏读，如果关系复杂的还很难看懂。 我想要的效果是能从逻辑代码中就能读懂一切逻辑。不要把逻辑采用hibernate方式表达出来。所以我基本不会在hibernate的xml配置文件中写one-to-many和many-to-one, 除非做左连接时不得已要加上，hibernate做复杂连接真的很不方便，性能差不说，还不好表达，HQL最终不如SQL直观。往往这个时候我们会把复杂逻辑采用view封装一次，例如4，5个表一起join,group by之类的操作，在hibernate中把这个视图作为table来对待， 实践中发现还真是挺管用，不过采用了视图毕竟多了一层，性能可能会有所下降，不过却没有测试过，如果真的对性能要求很高的时候，这个时候jdbcTemplate就出场了，这个是spring对jdbc的简单封装，就是直接写SQL了。到此，那些hibernate高手可能会藐视我 ，这样就没有利用上hibernate的面向对象的好处，是面向过程的编程，不过我承认我还不能随心所欲的像使用SQL一样使用HQL,也没有办法完全记住hibernate繁琐的配置。 不过最终我们还是没有抛弃hibernate,我就用其核心部分，经验告诉我使用开源产品的高级功能往往是需要付出代价的。如果有bug那就很难跳过去了，但毕竟他也有自己的长处所在。例如事务控制方面，缓存方面，而且在复杂的长流程逻辑中会合并部分SQL,例如前一段代码是别人写的他update了某个table,后面一个人也update了这个table的另外一个字段，实际上最后hibernate只会发出一条SQL。 引用 4。 Tomcat会在启动时把class通过classloader加载到内存，即使你增加了class在classes目录下也没有办法认出来。尤其spring context是没有你新增的bean的，除非你reload这个应用（反复reload会有问题的），或者重启Tomcat,另外还有一个办法是通过OSGI动态加载,我们经常用的开发工具Eclipse就是基于OSGI开发的，但是那个会给我们带来极大的复杂度和架构上的更改。 除此之外，还有什么办法能做到不用重启tomcat，改动java class实时生效? 我是说做一套模板 应该是 html（或模板文件）、js、css、img 这些东西吧，如果不涉及class，就没有热加载的问题了。 引用 spring mvc 和struts都是mvc架构的， controller部分都是写在java class里面的，如果要增加功能那就需要增加java class,如果在jsp中写入逻辑那就会破坏了mvc原则了。例如JSTL的sql相关的taglib我们是不会用的，因为那个会破坏mvc原则，重要的是会破环代码的可读性。不过像某些CMS那样，提供自定义的标签也是个折中办法，但不会把sql写在页面，php是解析性的语言，他是把所有东西都写在php里面才会导致他无法作大型的应用，因为那样的系统扩展性会差些。 但最后经过试验之后公司还是回归了spring框架，自己维护一套表示层或者业务层框架而又跟主业不太相关时，那个代价也太大了点，而且功能无法跟不断升级的开源框架比。  |
| 返回顶楼 | |
|
发表时间：2012-01-04
lz这的东西好多啊~~~ 很全啊
|
| 返回顶楼 | |
|
发表时间：2012-01-04
osacar 写道 到底大型体现在哪?说点核心的东西吧。别光堆框架。
大型系统却不是很好去定义，是由功能去定义还是访问量去定义呢？就说一下我们这边的情况 第一，我们的目标很远大，是要做"java 商城"里面的数一数二的能和目前php商城抗衡的经典之作，因此我们对代码规范和质量上要下狠功夫。 第二，我希望我们的系统能部分使用J2EE的最优实践，能给大家带来技术上的帮助和启发，这个影响也是挺大的。 第三，我们确实是实现了一个java商城的功能，已经包括B2C商城的基本功能，包括支付宝的直接/担保支付，货到付款功能都已经上去，是Java商城中功能比较全的一个。 第四，我们同时支持B2C/C2C，甚至观望B2B2C的功能，我不是做一个技术框架DEMO，而是一个可以实战使用的，并且已经使用中的商城。可以弥补java商城的空白部分，我们的任务就是要使用适合的开发模式降低Java商城的开发成本而已。 虽然目前还不是很完善，但是google/baidu “java 商城”前面3页还是有我们的连接的。 |
| 返回顶楼 | |
|
发表时间：2012-01-04
nick.s.ni 写道 mazzystar 写道 从维护成本考虑，感觉应该去掉dwr ,hibernate，直接用jquery和mybatis。
另外感觉静态化没什么必要，平白增加开发和维护的成本 还有 引用 1。模板技术缺少灵活性，目前Php的大型商城系统有很多的模板可以用，这个也不全都是官方自己开发的，这个是Java商城需要向php商城学习的地方。因为java是mvc方式建设的，有java,jsp, html等，java class需要重启服务器才能生效，而且很难像php一样，把所有东西写在一个目录拷贝到服务器上即可使用，目前我还是没有什么好的思路能达到这个效果的，考察了apache tiles/sitemesh/freemarker/velocity等，都没有想到办法。。。只能做到内置好模板让用户挑选。要达到大家都能做模板的程度，需要把代码和文档继续完善和开源。 这个跟java class 需要重启有什么关系呢？ 因為php不需要重啟，當然用Java實現，只要把原本Servlet的功能，全部用JSP去控制，也可以實現的。更新只是更新jsp文件，也不會需要重啟。 这个就回到servlet/jsp没有mvc model1 model2的时代了，这个所带来的混乱会限制了系统的灵活性和可扩展性和维护性，你试想一堆几百几千行的JSP你能轻易看懂不？反正我是不容易的 |
| 返回顶楼 | |
|
发表时间：2012-01-04
xieboxin 写道 onecan 写道 1. java本来就号称高性能和安全，我们的目标当然不会是针对量不多的情况来考虑了。需要把各种情况考虑清楚，因为java是分层开发的，可以通过测试找出对应薄弱环节进行增强。
2. redeploy web app或者spring context个人觉得只是适合开发阶段或者趁晚上没人reload次数不多的情况，这种情况还不如重启服务器。不适合生产环境，reload过程无法提供连续访问，如果我们很多客户需要增加模板，频繁reload，那客户体验也太差了，生产环境是基本上不能停止的。淘宝也可以自己改模板，你见他有中断过服务吗？ 此法不可行也。 如果你用负载均衡的话，你就知道重启一个个应用服务器，是不会中断服务的。。。。。 谢谢，我在前面提到了我们最优的部署架构是2台tomcat服务器，就是用来升级用的，不是用于升级模板的，另外经过测试，我发现reload spring context是有副作用的，例如之前的Datasource无法释放，我们使用Proxool，在控制台中就发现2个Datasource，之前那个已经废了，但是还是存在内存中。tomcat reload appliacation 以前也是有问题的，部分class无法释放，不知道现在新版的tomcat好了没 |
| 返回顶楼 | |
|
发表时间：2012-01-04
hanfeng450 写道 onecan 写道 一个中小型的部署方案是1台Web 服务器 + 2台Tomcat服务器 + 1台memcached服务器 + 1台图片服务器 + 1台数据库，此方案是方便系统不断的升级，而又使得投资比较少。 当然更大型的解决方案需要更多的服务器和在数据库上做更多的优化动作。最省钱的办法就是1个服务器就运行以上所有的服务，这个也不是不行，有个1G的内存都已经能应付不少流量了。在那些便宜的JSP空间只要有256/512M内存也可以跑，大有大的跑法，小有小的跑法。 楼主能否说一下,你的服务器配置? 还有就是有没有测试过在这样的配置下,最大能应付多少的访问.能应付多大的并发量? 暂时没有测试数据呢，在重构中，不过我们目前Demo版的JSP空间也就几百块，也能流畅跑3个应用了，还有论坛加上官网。这个测试一定会做的。。 |
| 返回顶楼 | |
|
发表时间：2012-01-04
非要拿掉Hibernate的主要原因就是在一个“大”字，做大型网站，是不能用Hibernate的。
我平常做金融类产品居多，深知这个东西的害处。onecan说的对，Hibernate用来做简单操作确实省时省力，使用通用Dao的话那是非常痛快的。但做到后期，分表分库，集群，不同类型数据库混用阶段，Hibernate是重构的第一大障碍。而且这个阶段还涉及到人员的素质问题，Hibernate这东西用好不易，开发人员水平参差不齐，乱写乱用，看似省事，其实隐患很大，此时进行培训改进又遇到各种各样问题导致无法顺利进行。我多次遇到使用Hibernate操作数据库资金管理类库表导致数据不一致记错账的事情，管钱的记错账那都是一级生产事故啊，教训极惨痛。 onecan做的业务和我的领域比较重合，正好我也负责过电子商务网站的后台系统，如果你还不理解为什么要避免使用Hibernate，咱们可以慢慢聊，都是花大钱买来的经验教训，大家就不要再重蹈覆辙了。 |
| 返回顶楼 | |
|
发表时间：2012-01-04
evanzzy 写道 支持使用Spring和SpringMVC，另外严重建议把Hibernate拿掉，真不是个好东西，网站规模越大越难受。我倒是建议电子商务网站使用spring JdbcTemplate做数据库访问层
+1 也可以使用mybatis 替换 |
| 返回顶楼 | |
|
发表时间：2012-01-04
zhxing 写道 引用 2台Tomcat服务器
hibernate貌似自己维护一级缓存，在会话期间多个服务器的一致性估计比较难保证。 一级缓存是存在于一个transaction中的，不知道有没有理解错？这个影响非常小，只是限于你数据库的事务隔离级和你对脏读的容忍度，一般采用数据库默认的就可以。反而二级缓存是个大问题，如果采用ehcache, 是独立在每个tomcat中的cache,当一个更新了就通知另外一个也要更新，就涉及一个广播的问题，现在的ehcache也支持分布式缓存的，不过我是偏向于在apache中设置那个stick参数，使得同一个session一直访问一个tomcat，同时设置cache的超时时间。 另外一个选择就是使用memcached这些单独的cache服务器。2个tomcat都跟这个cache服务器要数据。上面有人提到了，hibernate就关注一个get,一个put接口。 |
| 返回顶楼 | |
