请教道友们一个支付系统的架构选型问题!!!!

08-07-31 greentree
我最近接了一个支付系统的项目,项目中的实体并不多, 和原有系统,网上银行,第三方系统的交互比较多一些,

这次做项目设计和分析使用OO+DDD的方式来做,想请BANQ大哥和广大道友能够多多关注,多提宝贵意见!

目前我正在做该系统的技术架构选型:

我简单的介绍一下我们的需求:

主要是做一套支付卡系统:

业务需求方面分为:

1:功能性需求:

支付卡管理:CRUD 统计分析

充值卡管理:CRUD 统计分析

支付卡积分管理:积分策略设定,调整

接口系统:和原有业务系统的接口,和网银系统的接口

决策分析系统:对系统中的数据进行多维度的分析,提供对公司上层决策

2:非功能性需求:

安全服务: 从项目设计开始就把安全列入了统一过程中去。确保表现层,业务层,持久层的安全。这一块花了很大功夫

业务持续稳定性:最初使用双机热备份。但是要考虑到对集群的支持。要做到保证系统7×24小时业务持续可用

业务响应性能:支持每台每秒200个并发, 要考虑到1-2年后,用户要达到100万的需求。

可扩展性:

软件功能的扩展:

系统要增加新功能的时候,只需要将新的功能文件放入指定位置,然后一经配置,新的功能就增加完毕。

系统并发需求的扩展:

当系统数据量和访问量增大而导致系统配置不能满足要求时,可以通过增加服务器,构成应用集群来满足需求。应用软件设计上对集群有支持。

简单分析一下我们的需求:

1:业务实体不复杂,和其他系统的交互比较复杂

2:对计算和事务的要求比较高,系统的数据量也不小。

我目前做了2个系统架构:

1:使用Struts2 + EJB3.0 + Oracle10G的架构,这样可以很好的支持业务集群,分布式事务和计算。

2:使用Struts2 + Spring+ hibernate + ibatis的架构,然后可以在前端使用F5这样的硬件负载均衡设备来支持集群,用F5来分发业务请求。

以后我会把这个项目进展中的经验和问题一块拿出来和大家分享,还是想请BANQ大哥和广大道友能够多多关注,多提宝贵意见!

    

greentree
2008-07-31 11:20
目前我的疑问是:这两种框架选型哪一种会更好一些呢?其实从我自己的经验来看我更倾向与EJB的选型。还请大家能够帮我分析分析!多谢了!

greentree
2008-07-31 11:31
耐心等待大家的光临和指教!

banq
2008-07-31 11:31
>Struts2 + EJB3.0 + Oracle10

>使用Struts2 + Spring+ Hibernate + ibatis

现在技术竞争大家都已经差不多,尤其Spring2.5这次出来,明显看出在向EJB3靠拢。

从学习成本来说,第一个方案好些,有一本EJB3 in Action之类书籍就能把业务类和持久层都搞定,而第二种方案明显有问题,Hibernate和IBatis都属于持久层技术,混在一起做,多乱,而且增加学习成本。

追求性能的系统,就要去除花哨的灵活性,比如Struts2的灵活性增加就是以性能为代价的,因为其需要解析的很多界面语法,不要让性能输在界面上,输在业务层上才是正道。

greentree
2008-07-31 11:39
<不要让性能输在界面上,输在业务层上才是正道

同意banq大哥的说法,由于以前用struts2用的比较多,而且觉得挺灵活的,所以很自然的在做项目的时候就会想到struts2

猜你喜欢
2Go 1 2 下一页