拟用EJB3实现一个大型在线支付系统

正在考虑采用EJB3来构建一个大型的在线支付交易系统。特点是无前端界面，只提供服务接口；每日交易量巨大，对TPS（每秒处理的交易数）的指标要求较高。由此带来的技术性要求为：
1. 对大并发的访问压力有足够承受能力；
2. 响应时间必须足够短（3秒以内）；
3. 具有企业级的事务完整要求；
4. 企业级的安全性；
5. 方便实时监控系统运行状态参数，如访问量曲线等；
6. 与银行系统的可靠连接。
采用EJB3，主要是希望利用容器的强大和成熟性，避免重复编写企业级的环境类代码，而将主要精力放在业务实现上。EJB3为本项目至少可以带来对象池的管理、声明式事务支持、透明的集群机制、及其相当程度的安全性。EJB分布式的优点暂时还用不上，准备仅仅使用本地接口的方式，从接入门户系统直接调用。EJB持久层用EJB3.0的JPA。接入系统采用的技术还未深入思考，大致有两种思路：Servlet容器或者自己编写基于javax.concurrent的线程池。
当然，用EJB最担心的还是性能问题，不知道Spring这样的轻量级框架对于这个项目是否就够用了。希望可以通过与大家的讨论，做一次成功的选型。

评论

40 楼 eyejava 2007-01-31  

没用过ejb3做过项目就很难确切的知道有哪些有缺点，只能分析现有的spring,hibernate,jdbc哪些方面会出现问题，这些问题又能通过ejb3来解决吗？
对象池，如果设计好用spring的singleton应该能解决
声明式事务，spring做的很好
集群－没做过
安全性－ejb怎么做到比现有轻量级框架安全的？

39 楼 抛出异常的爱 2007-01-31  

有思想的芦苇 写道

zuly 写道

ejb3无疑是大型应用的首选！

我也有这样的感觉,EJB3不是为中小型应用准备的东西.有空一定要好好学学,领会EJB3的剑道.

错。。。EJB3。0是为了可升级性而使用的。。。。
如果你有ejb2.0项目升到3。0的困难性要比升spring要低的多，
如果以后有EJB4。0了那么你的项目升级的可能性要比spring 有高的
多必竟谁也不知道
如果spring小组的人全食物中毒死了
谁会为下个版本定制的标准。。。

38 楼 popop 2007-01-31  

两位，请不要吵了，都是为中国IT崛起在奋斗的，算是一家人
选型还未结束。正在仔细研究轻量级和重量级的一些差别，待定下来之后在本帖告知。
谢谢回复的人，所有给我帮助的人

37 楼 jackyz 2007-01-30  

zuly 写道

引用

楼主本人的讨论态度我较为认可，大家都是技术人员，就事论事，摆事实将道理，有一说一就是了。
不要象有的人，事实没见说两句，尽是虚东西。上来就扣大帽子？又不是文革！拿大词来唬人？我们都是唬大的？

诚然，我没有银行支付系统的经验，无法就事论事。但是扣大帽子云云...不知道从何说起，楼主开贴本就是拟用EJB3实现一个大型在线支付系统。app/ws -- ejb3 -- db的结构，有何大帽子可言。不懂，真的不懂。即使有人说到分布式，大家又没有说到分布式的原理，谈的都是应用。

ps:论坛，论坛，大家讨论！凡事就拿经验压人干什么。
我是做互联网的，嘴不对蠼，此帖结完就走人！

今天就不信这邪了，别说我太不给你留面子。

zuly 写道

ejb3无疑是大型应用的首选！

如果楼主认为项目的会有大量的业务逻辑，无疑不能选spring,使用spring的话会将事务限制在spring的API里，那样J2ee变成了一张废纸！

大型项目不能只考虑性能，关键是ejb提供的分布式事务管理，这个大型项目所必须的，性能上的一点点差距可以用通过硬件集群来解决，但是裸露的jdbc会绑定软件结构和数据库结构。

我觉得这位兄弟有点本末倒置，首先楼主描述的就是一个大型应用，项目的关键很可能在于软件本身的质量，无可疑，经量级的架构可以带来短线利益，但是随着用户的业务扩充随时可能需要存变更上大型业务逻辑，轻量级容器为了提高性能会把业务和事务封装在固定的Api里，一旦用户的需要超出其管理的范围，通常设计上都会跳出原先的结构寻找一些系统外的解决办法最后导致软件结构绑定业务逻辑，丧失扩展能力和更多的性能。
举个例子:NotePad的确运行的很快，也很好用，但是人们为什么要去用Word呢？如果你认为这个Project就用NotePad就可以搞定，完全没必要去考虑word.
公司请你们来就是要提供权威的解决方案，不要前怕狼，后怕虎的，ejb设计上的错误后期完全可以修改，不会有很大的影响。这个也是使用ejb的好处之一。

ejb在响应上是有优势的，应为它会和数据层保持连接并且sync。缺点在于并发访问由于容器性能瓶颈。

观点偏离，现在讨论的是业务层上的需求，并非软件需求。考虑的好像有点片面。

看你写的，我感觉银行的业务<10个！业务层关ejb啥事？那你说关谁的事，谁来处理业务层！

我们只是罗列解决方案，大家讨论。没有什么忽悠的吧！
这个挺有意思的!是真的,有点象 －－ 你是你爸爸的儿子！:)

软件结构分层和实际引用本来就不能放在一起谈。正如你所说的
的确js可以搞定的事，但不代表我不能ajax！相反好的vendor会建议使用ajax.同理，你应用种非要把业务层搞的不清不楚我也没办法。

看看在这贴，你都说了些什么有营养价值的话么？

要结贴走人？威胁我啊？我又不是 robbin 说句不好听的，您慢走，不送了。

还倍儿傲，特激昂，整个就一“站在技术制高拿着红蓝铅笔点指点江山”的气势。

做技术的，还是要踏踏实实，别跟 csdn 那帮人学，成天争观点喊口号，空对空瞎吵吵，一帮人自娱自乐还以为挺热闹。

36 楼 zuly 2007-01-30  

引用

楼主本人的讨论态度我较为认可，大家都是技术人员，就事论事，摆事实将道理，有一说一就是了。
不要象有的人，事实没见说两句，尽是虚东西。上来就扣大帽子？又不是文革！拿大词来唬人？我们都是唬大的？

诚然，我没有银行支付系统的经验，无法就事论事。但是扣大帽子云云...不知道从何说起，楼主开贴本就是拟用EJB3实现一个大型在线支付系统。app/ws -- ejb3 -- db的结构，有何大帽子可言。不懂，真的不懂。即使有人说到分布式，大家又没有说到分布式的原理，谈的都是应用。


ps:论坛，论坛，大家讨论！凡事就拿经验压人干什么。
我是做互联网的，嘴不对蠼，此帖结完就走人！

35 楼 jackyz 2007-01-30  

popop 写道

目前的支付网关分为三种类型：
一是网关放在具体银行，分发客户端的签名、支付等模块给商户；
二是网关部署在支付管理商那里，用适配器连接，可以集成多家银行；
三是淘宝的支付宝模式，淘宝建立和管理资金帐户，充当了银行的角色。

我所做的项目属于其中一种，由于商业机密的缘故，比较敏感，先不说具体是谁。但无论哪种模式，交易系统面对的是另一个与用户界面打交道的接入系统，可以认为没有直接界面。

貌似我做过的支付系统属于第一种。
由于商业机密的缘故，比较敏感，也不说具体是哪家了，但无论如何，该巨型互联网公司要关系有关系，要资金有资金，可为啥就没选第二种呢？

如果楼主是做第二种的，呵呵，坦率的说，我可真不敢用。
如今这世道，就连银行我都不相信，要让我的卡号和密码“流经”贵系统，对不起，那我干脆就不支付了。
这大概就是传说中的“中国国情”。

如果楼主做的是第三种，那，说到底了还是：支付系统 + 帐户系统。

无论如何，凡是要和银行的钱打交道的，就目前来说，都要走支付系统到银行支付。
至于点卡还是支付宝，这些功能，就拿他当作另外的系统好了。

popop 写道

不要把支付网关想得太简单。诚然业务流程不会太复杂，但，后台的事务可能复杂。

不要把支付网关搞得太复杂，它就负责“与银行通讯及同步订单状态”这一件事情就好了。
这件事可不简单呢，N多个银行，N多套API，N多密钥，还有那么多状态的转换，够忙的了。

后台事务复杂，那是后台事务的事，状态通知麻烦，那也是状态通知要搞定的事，各有各的子系统，为什么要把这些“相对次要”的逻辑全都放到关系重大的银行交易的 Transact 里呢？有个甚么设计原则来着，最小 Transact 原则？再想想？

当然了，这里讲的是纯技术，并不适用“攒方案”。

PS.
楼主本人的讨论态度我较为认可，大家都是技术人员，就事论事，摆事实将道理，有一说一就是了。
不要象有的人，事实没见说两句，尽是虚东西。上来就扣大帽子？又不是文革！拿大词来唬人？我们都是唬大的？

34 楼 daquan198163 2007-01-30  

popop 写道

daquan198163 写道

popop 写道

daquan198163 写道

EJB3刚出来，哪有成熟性可言
建议楼主把《without ejb》仔细看一遍，尤其是关于对象池、集群和持久化的讨论

without ejb我看过。其中好像没有讲到对象池的处理，是否可以认为Apache commons-pooling够用了？

大概在第十章，讲了对于EJB对象池和多线程的一些常见误解
对EJB3不了解，但它之前的ejb1.x和2.x为了获得线程安全性草率的采用了实例池，而事实上，大多数时候一个无状态的组件不会有线程安全问题，又一次典型的二八原则问题

对象池是为了避免频繁创建和销毁对象带来的性能开销，而非线程安全的考虑呀。

单例就可以避免频繁创建和销毁对象，EJB费那么大力气搞个对象池不就是为了实现所谓线程安全的编程么？

33 楼 popop 2007-01-30  

daquan198163 写道

popop 写道

daquan198163 写道

EJB3刚出来，哪有成熟性可言
建议楼主把《without ejb》仔细看一遍，尤其是关于对象池、集群和持久化的讨论

without ejb我看过。其中好像没有讲到对象池的处理，是否可以认为Apache commons-pooling够用了？

大概在第十章，讲了对于EJB对象池和多线程的一些常见误解
对EJB3不了解，但它之前的ejb1.x和2.x为了获得线程安全性草率的采用了实例池，而事实上，大多数时候一个无状态的组件不会有线程安全问题，又一次典型的二八原则问题

对象池是为了避免频繁创建和销毁对象带来的性能开销，而非线程安全的考虑呀。

32 楼 daquan198163 2007-01-29  

popop 写道

daquan198163 写道

EJB3刚出来，哪有成熟性可言
建议楼主把《without ejb》仔细看一遍，尤其是关于对象池、集群和持久化的讨论

without ejb我看过。其中好像没有讲到对象池的处理，是否可以认为Apache commons-pooling够用了？

大概在第十章，讲了对于EJB对象池和多线程的一些常见误解
对EJB3不了解，但它之前的ejb1.x和2.x为了获得线程安全性草率的采用了实例池，而事实上，大多数时候一个无状态的组件不会有线程安全问题，又一次典型的二八原则问题

31 楼 popop 2007-01-29  

因为刚巧正好做过这种系统，所以贸然插两句。

在线支付，尤其是和银行接口的部分，主要的工作就是按照不同的银行API搞搞加密解密，然后转到银行页面，据我所知，几乎所有的银行都要求在自己的https界面进行支付（目的是要避免用户在非银行host的界面输入卡号密码），所以，你说这个支付系统“没有界面”，从业务的实现角度，对此，我表示怀疑。

此外，因为大量的计算都是加密解密，在交易处理上，无非就是确认交易身份无误之后，update支付记录中的一个标志而已，并不存在必须要在事务中处理的“复杂操作流程”。而支付系统之外的库存系统只需（而且必须）保证同一笔交易（状态变更事件）的唯一付货行为。这是业务处理逻辑，而不是技术层面需要考虑的问题。

基于上述两点，我认为：

1，为完成交易，此系统很有可能必须要有界面，或者说，web界面。

2，为性能计，此系统更没有ejb的必要。访问量上去了，就整它多个web+单个db来处理，足矣。

目前的支付网关分为三种类型：一是网关放在具体银行，分发客户端的签名、支付等模块给商户；二是网关部署在支付管理商那里，用适配器连接，可以集成多家银行；三是淘宝的支付宝模式，淘宝建立和管理资金帐户，充当了银行的角色。我所做的项目属于其中一种，由于商业机密的缘故，比较敏感，先不说具体是谁。但无论哪种模式，交易系统面对的是另一个与用户界面打交道的接入系统，可以认为没有直接界面。
此外，因为大量的计算都是加密解密，在交易处理上，无非就是确认交易身份无误之后，update支付记录中的一个标志而已，并不存在必须要在事务中处理的“复杂操作流程”

引用

不要把支付网关想得太简单。诚然业务流程不会太复杂，但，后台的事务可能复杂。

30 楼 zuly 2007-01-29  

jackyz 写道

zuly 写道

jackyz 写道

zuly 写道

观点偏离，现在讨论的是业务层上的需求，并非软件需求。考虑的好像有点片面。

业务层的需求关ejb啥事？
有什么业务需求决定了采用什么技术方案，而不是反过来，拿着技术方案去生套业务需求。
先考虑实际业务，再考虑要不要ejb，哪里偏离？如何片面？

看你写的，我感觉银行的业务<10个！业务层关ejb啥事？那你说关谁的事，谁来处理业务层！

看你写的，我差点就要怀疑自己是不是真做过在线支付的“大型系统”了。。。

并不是把业务放到某个p“层”里去才叫做业务层，ok？

打个不甚恰当的比方，本来就是在客户端用javascript就可以搞定的事，你非要搞个服务器端接口，整个ajax来时尚一把。把到网络上跑它几个个来回，美其名曰“业务层”能“分布式”“集群”云云。我 diu ~~~（对不起，不和谐了）。

要是想忽悠甲方，让丫多买一堆机器，多花N倍银子，利润翻它N番，没问题，明说就是了嘛，大家都明了。别拿什么“高性能”“集群”“分布式”“业务层”，这些老掉牙的破烂玩意儿来说事，ok？真好像大家都没玩过似的。

引用

并不是把业务放到某个p“层”里去才叫做业务层，ok？

软件结构分层和实际引用本来就不能放在一起谈。正如你所说的

引用

本来就是在客户端用javascript就可以搞定的事，你非要搞个服务器端接口，整个ajax来时尚一把。

的确js可以搞定的事，但不代表我不能ajax！相反好的vendor会建议使用ajax.同理，你应用种非要把业务层搞的不清不楚我也没办法。

引用

要是想忽悠甲方，让丫多买一堆机器，多花N倍银子，利润翻它N番，没问题，明说就是了嘛，大家都明了。别拿什么“高性能”“集群”“分布式”“业务层”，这些老掉牙的破烂玩意儿来说事，ok？真好像大家都没玩过似的。[/

。。。。。。。。。

29 楼 jackyz 2007-01-29  

zuly 写道

jackyz 写道

zuly 写道

观点偏离，现在讨论的是业务层上的需求，并非软件需求。考虑的好像有点片面。

业务层的需求关ejb啥事？
有什么业务需求决定了采用什么技术方案，而不是反过来，拿着技术方案去生套业务需求。
先考虑实际业务，再考虑要不要ejb，哪里偏离？如何片面？

看你写的，我感觉银行的业务<10个！业务层关ejb啥事？那你说关谁的事，谁来处理业务层！

看你写的，我差点就要怀疑自己是不是真做过在线支付的“大型系统”了。。。

并不是把业务放到某个p“层”里去才叫做业务层，ok？

打个不甚恰当的比方，本来就是在客户端用javascript就可以搞定的事，你非要搞个服务器端接口，整个ajax来时尚一把。把到网络上跑它几个个来回，美其名曰“业务层”能“分布式”“集群”云云。我 diu ~~~（对不起，不和谐了）。

要是想忽悠甲方，让丫多买一堆机器，多花N倍银子，利润翻它N番，没问题，明说就是了嘛，大家都明了。别拿什么“高性能”“集群”“分布式”“业务层”，这些老掉牙的破烂玩意儿来说事，ok？真好像大家都没玩过似的。

28 楼 zuly 2007-01-29  

dennis_zane 写道

一听见大型应用这几个字，我只看见一部分人已经开始两眼放光，没有调查，没有犹豫，大声喊出他们心中的那几个“大词”——EJB、分布式。这样的现象很奇怪，EJB充其量只不过是远程调用的方案之一，JPA也只是hibernate的子集，一味地神化，玩概念，忽悠人，没什么意义吧。说了几句，得罪莫怪。

我们只是罗列解决方案，大家讨论。没有什么忽悠的吧！

引用

EJB充其量只不过是远程调用的方案之一

......

引用

JPA也只是hibernate的子集

这个挺有意思的!是真的,有点象 －－ 你是你爸爸的儿子！:)

27 楼 zuly 2007-01-29  

jackyz 写道

zuly 写道

观点偏离，现在讨论的是业务层上的需求，并非软件需求。考虑的好像有点片面。

业务层的需求关ejb啥事？

有什么业务需求决定了采用什么技术方案，而不是反过来，拿着技术方案去生套业务需求。

先考虑实际业务，再考虑要不要ejb，哪里偏离？如何片面？

看你写的，我感觉银行的业务<10个！业务层关ejb啥事？那你说关谁的事，谁来处理业务层！

26 楼 jackyz 2007-01-29  

zuly 写道

观点偏离，现在讨论的是业务层上的需求，并非软件需求。考虑的好像有点片面。

业务层的需求关ejb啥事？

有什么业务需求决定了采用什么技术方案，而不是反过来，拿着技术方案去生套业务需求。

先考虑实际业务，再考虑要不要ejb，哪里偏离？如何片面？

25 楼 dennis_zane 2007-01-29  

一听见大型应用这几个字，我只看见一部分人已经开始两眼放光，没有调查，没有犹豫，大声喊出他们心中的那几个“大词”——EJB、分布式。这样的现象很奇怪，EJB充其量只不过是远程调用的方案之一，JPA也只是hibernate的子集，一味地神化，玩概念，忽悠人，没什么意义吧。说了几句，得罪莫怪。

24 楼 zuly 2007-01-29  

jackyz 写道

因为刚巧正好做过这种系统，所以贸然插两句。

在线支付，尤其是和银行接口的部分，主要的工作就是按照不同的银行API搞搞加密解密，然后转到银行页面，据我所知，几乎所有的银行都要求在自己的https界面进行支付（目的是要避免用户在非银行host的界面输入卡号密码），所以，你说这个支付系统“没有界面”，从业务的实现角度，对此，我表示怀疑。

此外，因为大量的计算都是加密解密，在交易处理上，无非就是确认交易身份无误之后，update支付记录中的一个标志而已，并不存在必须要在事务中处理的“复杂操作流程”。而支付系统之外的库存系统只需（而且必须）保证同一笔交易（状态变更事件）的唯一付货行为。这是业务处理逻辑，而不是技术层面需要考虑的问题。

基于上述两点，我认为：

1，为完成交易，此系统很有可能必须要有界面，或者说，web界面。

2，为性能计，此系统更没有ejb的必要。访问量上去了，就整它多个web+单个db来处理，足矣。

观点偏离，现在讨论的是业务层上的需求，并非软件需求。考虑的好像有点片面。

23 楼 zuly 2007-01-29  

popop 写道

Lucas Lee 写道

为什么怀疑EJB存在性能问题呢？
那你觉得Entity Bean，EJB集群是用来干什么的？

如果你觉得在低端配置的机器，或者单台机器上的性能不如轻量级框架，那还可以理解。

EJB的性能问题，在我看来存在两点：一是每次调用，都会穿过重量级容器，引起性能不可忽视的损失；二是设计得不好的话，远程调用带来的网络和序列化开销。这个应用对响应速度的要求很高，提高硬件配置倒是没问题，甲方有钱；但我的感觉是在这个项目上相比软件架构，硬件并不起决定性作用。Entity Bean不在视线范围内，只打算用JPA。

我觉得这位兄弟有点本末倒置，首先楼主描述的就是一个大型应用，项目的关键很可能在于软件本身的质量，无可疑，经量级的架构可以带来短线利益，但是随着用户的业务扩充随时可能需要存变更上大型业务逻辑，轻量级容器为了提高性能会把业务和事务封装在固定的Api里，一旦用户的需要超出其管理的范围，通常设计上都会跳出原先的结构寻找一些系统外的解决办法最后导致软件结构绑定业务逻辑，丧失扩展能力和更多的性能。

引用

一是每次调用，都会穿过重量级容器，引起性能不可忽视的损失

举个例子:NotePad的确运行的很快，也很好用，但是人们为什么要去用Word呢？如果你认为这个Project就用NotePad就可以搞定，完全没必要去考虑word.

引用

二是设计得不好的话，远程调用带来的网络和序列化开销

公司请你们来就是要提供权威的解决方案，不要前怕狼，后怕虎的，ejb设计上的错误后期完全可以修改，不会有很大的影响。这个也是使用ejb的好处之一。

引用

这个应用对响应速度的要求很高

ejb在响应上是有优势的，应为它会和数据层保持连接并且sync。缺点在于并发访问由于容器性能瓶颈。

22 楼 jackyz 2007-01-29  

因为刚巧正好做过这种系统，所以贸然插两句。

在线支付，尤其是和银行接口的部分，主要的工作就是按照不同的银行API搞搞加密解密，然后转到银行页面，据我所知，几乎所有的银行都要求在自己的https界面进行支付（目的是要避免用户在非银行host的界面输入卡号密码），所以，你说这个支付系统“没有界面”，从业务的实现角度，对此，我表示怀疑。

此外，因为大量的计算都是加密解密，在交易处理上，无非就是确认交易身份无误之后，update支付记录中的一个标志而已，并不存在必须要在事务中处理的“复杂操作流程”。而支付系统之外的库存系统只需（而且必须）保证同一笔交易（状态变更事件）的唯一付货行为。这是业务处理逻辑，而不是技术层面需要考虑的问题。

基于上述两点，我认为：

1，为完成交易，此系统很有可能必须要有界面，或者说，web界面。

2，为性能计，此系统更没有ejb的必要。访问量上去了，就整它多个web+单个db来处理，足矣。

21 楼 popop 2007-01-29  

其实这个问题还是归集到without EJB的论点：是否轻量级framework在我的项目的要求范围内能完全覆盖EJB容器带来的一切？尤其是集群、事务、线程池和对象池？ 此外有没有人知道EJB规范和容器的将来发展趋势，它能够带来什么额外的企业级好处呢？ 架构本来就是不易改变的抉择，一旦架构定下来，将来要迁移的话会比较痛苦的。