敏捷快发分布式-简述

最新推荐文章于 2025-04-03 19:46:43 发布

原创

最新推荐文章于 2025-04-03 19:46:43 发布 · 485 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#敏捷 #hibernate #spring #webservice #struts #tomcat

本文分享了作者在敏捷开发背景下，面对高度扩展和分布式需求的项目实践。选择了RMI作为通信方式，搭配Hibernate、Spring和Struts，以快速开发和高效通信为目标。在面对千万级并发和分布式挑战时，通过RMI实现高效传输，Hibernate简化数据访问层，Spring解决单点故障。在实际应用中，注意避免大数据传输和过度依赖延迟加载，以提高性能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

今天中午闲来无事看了看传智播客的视频，讲的还是很精细的。就忽然想起来自己之前写的敏捷开发之rmi负载了。当时是项目的变态需要所以才这样搭建的架构，在快发过程中出现了各种各样的问题，网上查找解决方法。中文的一篇没有，国外的也是星星点点的。当然现在项目基本上所有问题都已经解决了，现在就有空时，多多和大家分享一下。

今天我只叙述一下分布式的一些看法，如果读者有不同意见望能心平气和的讨论。

本项目有几点需要(‘总’的要求很幼稚很无理)：1.高度扩展但是不要用一些前沿技术，因为公司现有框架是10年前的。2.要求能像现有框架一样支持千万级并发(我的天啊，我从来都没有听说过那么NB的框架。我的回答是单台Tomcat并发600-800)。3.支持分布式，通信效率一定是最好的(公司只用TOMCAT又要求效率高，所以我一开始就放弃了openEJB和webservice)。

技术选型时，首先考虑了两点：开发快、通信效率高。因为TNND一个人2个月做完这个实在是...。所以满足分布式这个硬性要求的角度，我选择了RMI。从开发速度的角度考虑，毫无疑问使用ORM框架，首选hibernate是最方便的。没有选择hession的原因就是因为分布式通信时传递复杂大对象的数据RMI比hession快很多。虽然数据访问层的开发量因为hibernate的存在减少了，但是RMI的开发也是很麻烦，所以又加入了spring，而且clustor4spring又可以很好的解决单点故障，所以加上spring是势在必行的。struts2.1只是因为使用习惯了所以才用。