|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-01-04
hibernate的缓存确实不爽，想知道楼主这个项目如何运作？
|
| 返回顶楼 | |
|
发表时间：2012-01-04
onecan 写道 osacar 写道 到底大型体现在哪?说点核心的东西吧。别光堆框架。
大型系统却不是很好去定义，是由功能去定义还是访问量去定义呢？就说一下我们这边的情况 第一，我们的目标很远大，是要做"java 商城"里面的数一数二的能和目前php商城抗衡的经典之作，因此我们对代码规范和质量上要下狠功夫。 第二，我希望我们的系统能部分使用J2EE的最优实践，能给大家带来技术上的帮助和启发，这个影响也是挺大的。 第三，我们确实是实现了一个java商城的功能，已经包括B2C商城的基本功能，包括支付宝的直接/担保支付，货到付款功能都已经上去，是Java商城中功能比较全的一个。 第四，我们同时支持B2C/C2C，甚至观望B2B2C的功能，我不是做一个技术框架DEMO，而是一个可以实战使用的，并且已经使用中的商城。可以弥补java商城的空白部分，我们的任务就是要使用适合的开发模式降低Java商城的开发成本而已。 虽然目前还不是很完善，但是google/baidu “java 商城”前面3页还是有我们的连接的。 所以说，把标题中的“大型”去掉可能会更贴切些。 你所列的这些框架平常我做个普通网站也是用这些。 我相信，如果一个能叫得上大型的系统，肯定有它一些独特技术架构和业务处理。而大家想知道的也正是这些。 |
| 返回顶楼 | |
|
发表时间：2012-01-04
velocity和freemarker的功能是jsp不能比的 建议你深入研究一个替换掉jsp
|
| 返回顶楼 | |
|
发表时间：2012-01-04
推销下guzz替代hibernate，可以看看，更适合商城类应用。
模板方面可以用guzz标签加velocity模板解决，通过上层自定义查询条件解析或自动分库分表（通过商家信息），解决不同商家之家的数据权限或性能问题，把数据的读取交给模板自定义查询语句即可。 |
| 返回顶楼 | |
|
发表时间：2012-01-04
myreligion 写道 推销下guzz替代hibernate，可以看看，更适合商城类应用。
模板方面可以用guzz标签加velocity模板解决，通过上层自定义查询条件解析或自动分库分表（通过商家信息），解决不同商家之家的数据权限或性能问题，把数据的读取交给模板自定义查询语句即可。 帮你顶下。 |
| 返回顶楼 | |
|
发表时间：2012-01-04
guyuanwuxin 写道 1 spring mvc vs struts2
采用Spring MVC没错，有点比较容易扩展。集群时做cookie base on session 比较容易。 2. hibernate va jpa ibatis 应该采用ibatis，因为到后期数据库垂直水平切分比较容易，另外SQL调整控制权比较大。 3. DWR vs Jquery 不是很了解，但根据经验建议使用Jquery 4. spring 3.1 cache + ehcache/memcached 无论扩展还是性能，memcached才是王道。 5. JSP vs freemarker velocity 静态化不仅仅是JSP，里面的CSS+IMAGE等都需要做静态资源服务的，故直接采用模板就比较合适。另外，静态化最重要需要考虑的是IMAGE等资源，切记。 6. apache tiles vs sitemesh 无建议 7. 其余几个就没什么悬念了， 由于现在免费的jsp空间比较多的支持mysql和tomcat, 所以这2个是我们要优先支持的，虽然我们也支持oracle等。 只要SQL不是很BT，基本迁移起来没什么大事儿的。 8.重启中断服务 在阿里或淘宝，采用的是Half的方式进行服务的启动，前段采用F5进行负载均衡。具体做法是。比如，10台机器，先停掉5台，然后发布新程序，然后启动，F5连接有效后，循环做另外的部分。这种方式一般通过F5脚本进行操作，这样只会让用户觉得慢不会有无法访问的情况。所以，不停服务更新程序，在你没有能力购买F5前，是不能平滑解决的。 这位朋友提出了一些很中肯的意见，有些问题还可以再探讨深入一些的 2.数据库垂直水平切分,这个还没有做过，可能项目还没有达到那个级别或者别人做了我不知道的，还有数据量达到什么程度才会需要这么分？有多少行业和企业能到这个数据量级别的还有待考察。 但我们总是要未这些需求作考虑，例如我们dao层都是采用接口方式编程，如果把hibernate的实现换成jdbc或者myibatis的实现，理论上对service层毫无影响。 另外我们每个表一个entity，一个xml配置文件，一个dao,dao可以有多个实现，并且给service层提供服务。数据库垂直水平切分比较容易，另外SQL调整控制权比较大？倒是如何说法？ 3. DWR貌似不发展了，但是我们已经使用了他暂时没有发现什么问题，可以将就用着，如果是新系统将会全部采用jquery 4.我建议单机采用ehcache,集群方式采用memcached,单个memcached的性能是要ehcache要查的，因为memcached是独立部署在tomcat之外的，远程调用即使用socket调用也不如内部API来得快吧，但是那个是毫秒级的，对单个页面调用来说可以忽略不计。 8.用apache + 2台tomcat，我先停一台，停机部署，所有请求自动专向另外一台tomcat, 重启又可以提供服务，另外一台如法炮制。但是在改动数据库的情况下，如果更新了数据库可能会导致正在运行的那台出问题。不知道此法可行不？ |
| 返回顶楼 | |
|
发表时间：2012-01-04
evanzzy 写道 onecan 写道 我也参与过金融类的大型项目开发，整个项目架构是spring + hibernate,外加jdbc，这个项目不可谓小，在eclipse中project都达到接近100个，100号人在维护和开发，hibernate那层是有专门的专家去评审的，你可以提出申请需要增加一个表，但是要得到DBA组人员的审核。 如果用好了，对开发上也能节省不少时间，用不好就是自伤了。另外一个以前我是比较崇尚一个hibernate的超级DAO的，如果项目简单的话连DAO层都省掉了，不过项目大了之后就不好维护了，大家都乱调用，没有章节。evanzzy,我在hibernate上也没有深究，所以才会每一个表就一个Dao,一个service,一个controoler,这样会比较清晰。service层是所有逻辑的入口点。 对于你在hibernate上遇到的问题，也可以拿出来探讨一下，共同进步。 咱们都是做技术的，不客气。不过恕我直言，100个project由100号人开发维护——这是谁让这么干的？哪个技术负责人能够掌控整个项目？ Hibernate层有人专门评审，这就是效率降低而不用Hibernate的原因之一——写程序省的时间被评审之间的互相沟通消耗掉了。你用jdbc Template或者ibatis去做，就不需要有人评审Hibernate层。此为原因之一也。 Hibernate的一、二级缓存可以提高效率，但是涉及到资金处理，就要出大问题。电子商务网站要处理资金问题，Hibernate不合适。 另外，项目中如果没有涉及到分表、分库、数据库集群、应用服务器集群、缓存服务器集群及相关负载均衡和失败转移问题的解决，甚至引入NoSql数据库，是谈不上大型项目的。我说不用Hibernate，就是在以上这些应用中不用它。你用Hibernate做Dao层，是否考虑了以上这些问题的解决方案了呢。是否可以分享一下？ 实话实说，我就是因为用Hibernate解决不了这些问题，所以才放弃使用，并不是说我对这个东西有什么偏见。 100个project中要分为几块，有些是ear,web,ejb,utility，基本每个组会看几个project.并且每个组都会交流，对其他project也会熟悉，基本没有人能够掌控整个项目。 处理资金问题是要处理的transaction的commit和rollback问题，缓存为了提高页面显示速度，减少数据库压力而作的，一般都是load数据的动作。 对于update和save的动作是不会有缓存的，敏感数据是要先加锁再读写的，数据库行锁也可以，java 的synchroinzed也有用，所以掌握多线程编程比掌握框架的用法还要关键。另外我还没有见过整个都是hibernate的系统，一般都会jdbc配合使用。 |
| 返回顶楼 | |
|
发表时间：2012-01-04
onecan 写道 hawaii162162 写道 先做出东西来才是王道 其他都是浮云
这个很符合我的性格。我也不是对空放炮，光是讨论技术架构而已 磨刀不误砍材攻。 |
| 返回顶楼 | |
|
发表时间：2012-01-04
george_space 写道 george_space 写道 look12345 写道 shine0181 写道 orm层直接 用 hibernate就可以了，，，，
没必要再加个ibatis了， 有求高的就hibernate直接调用jdbc语句(相当于ibatis的功能了)， 不会造成缓存不同步的问题吗？我一直担心hibernate的这个问题。 最不想看到和听到的，就是通过Hibernate执行原生SQL语句。 这样做的话，你会发现你的 系统中夹杂的SQL越来越多，最后以至于实际上都跟Hibernate一点关系都没有了，但是你还是在兴高采烈地认为这一切都是Hibernate的无敌力量，然后对Hibernate三拜五叩。 如果你为了适应Hibernate而去干涉数据库表结构设计，甚至干涉项目需求的设计，那么我只能说，你为了Hibernate，付出太多了。 见过有些人为了Hibernate而不停的改动数据库表结构，造成的连锁反应是，表结构变到最后，项目的原始需求都给人家扭曲了，扭曲就扭曲吧，还美其名曰：数据库本来就应该这样设计。 我想说的是：软件是为人服务的，不是人为了软件而东奔西走。 为了一个Hibernate，竟然连项目需求都给人家浅浅地偷梁换柱，而且还把自己忙得不亦乐乎，我想说，你为软件付出太多了，相反，你喜欢的软件，除了把你折腾得四脚朝天，也把老板气的七窍生烟，这就是典型的“软件把人真疼疯了”，而不是“软件为人服务”。 一般我们都是根据需求来定义数据库，根据数据库生成entity和hibernate的配置，为了hibernate而改需求是什么场景？ 对于缓存的话如果采用实时更新缓存机制是基本不会有不同步问题的，而且缓存都是基于查询用的，偶然有不同步现象也可以接受吧？对于频繁修改或者对事务敏感的情况，建议不要用缓存。如果是集群环境可以使用ehcached,ehcache也可以广播方式作分布式缓存，要不给一些不重要的数据设2-3分钟缓存时间，把不同步控制在改动后的2-3分钟内。 |
| 返回顶楼 | |
|
发表时间：2012-01-04
myreligion 写道 推销下guzz替代hibernate，可以看看，更适合商城类应用。
模板方面可以用guzz标签加velocity模板解决，通过上层自定义查询条件解析或自动分库分表（通过商家信息），解决不同商家之家的数据权限或性能问题，把数据的读取交给模板自定义查询语句即可。 恕我孤陋寡闻，这个guzz没有听说过哦，在没有大量案例，没有书籍，没有文档的情况下那敢用啊，不过好的东西确实会慢慢被人接受，但那个也许要一个过程。 |
| 返回顶楼 | |
