n******1
发帖数: 3756 | 1 最近做一个实习项目，想在cloud， 比如google app或者ec2上面实现银行的模拟交易
，并且最大可能程度模拟真实的压力，用java做
但是问题是我对现有的银行系统不是太了解，我主要关心一些核心的操作：查询，存款
，取款，转账
性能和数据一致性是主要关注点
我只大概了解到银行是在mainframes上实现的
1.我的理解mainframes只是硬件，和实现没有直接关系？
2.这些功能模块是用什么语言实现呢？ 我理解是会C或者Cobol，如果我用java实现这
个转换有会有什么不同，目前有用java做的吗？
3.通账户并发和数据一致性是通过这个系统保证吗？ 还是通过外围系统实现？如果我
用java是不是应该用java的多线程来处理并发，一致性应该怎么保证呢
3.这个核心系统和外部系统的交互是怎么样的呢？ 我的理解应该是这个核心系统需要
对外提供一些接口可以调用，我理解银行上层的业务系统，比如一些J2ee的系统是需要
这个系统打交道，比如平时用到的网上银行
4.还有个并发处理的排队，可能也是个问题
由于缺乏一些基本的知识，提的问题可能不大正确，可以给些启发吗？谢谢 |
n******1
发帖数: 3756 | 2 今晚再做了一些资料搜索，发现CISC这个中间件，但是不敢确定，是不是我想移植的功
能，就是CISC的核心？ |
z*******3
发帖数: 13709 | 3 你通过cloud来simulate银行的业务？
你太看明白你们想做什么 |
J*******n
发帖数: 2901 | 4 不懂，google app是指google app engine吗？
既然把你的系统deploy在cloud，那硬件就不在你掌控之内了吧 |
n******1
发帖数: 3756 | 5 是的，就是这个
【在 z*******3 的大作中提到】
: 你通过cloud来simulate银行的业务？
: 你太看明白你们想做什么
|
n******1
发帖数: 3756 | 6 Sorry,可能我表达不清，是指google app engin
是的，我不关心硬件，我也不打算掌握，我只是想simulate
但是我要考虑将来的scale，我的理解是原来的银行系统应该是可以通过硬件扩容，模
块的扩容来达到增加能力，我在cloud上面是不是也需要考虑我怎么扩容，是不是我写
一些软件模块出来，假如我不断的买cloud的资源，就可以达到原来硬件扩容的效果
【在 J*******n 的大作中提到】
: 不懂，google app是指google app engine吗？
: 既然把你的系统deploy在cloud，那硬件就不在你掌控之内了吧
|
n******1
发帖数: 3756 | 7 理论上我们可以做最简单的实现，就是写几个模拟操作，这样就和网上一般java快速入
门的项目没有很大区别，但是我们想尽可能模拟到真实的情况，比如
1.每秒的transaction数以千计，这是性能
2.同一个账号同时被操作，这是一致性
我相信目前银行已经有很成熟的解决方案，但我不知道他们怎么实现的
我想将这些迁移到cloud上，用java实现，并且可以保证性能和一致性，还有
deployment scalable（我不知道这个需要我做，还是cloud可以帮我处理）
【在 z*******3 的大作中提到】
: 你通过cloud来simulate银行的业务？
: 你太看明白你们想做什么
|
g*****g
发帖数: 34805 | 8 I don't know what's the point of your project. But you are probably better
served with AWS for your use case.
【在 n******1 的大作中提到】
: 理论上我们可以做最简单的实现，就是写几个模拟操作，这样就和网上一般java快速入
: 门的项目没有很大区别，但是我们想尽可能模拟到真实的情况，比如
: 1.每秒的transaction数以千计，这是性能
: 2.同一个账号同时被操作，这是一致性
: 我相信目前银行已经有很成熟的解决方案，但我不知道他们怎么实现的
: 我想将这些迁移到cloud上，用java实现，并且可以保证性能和一致性，还有
: deployment scalable（我不知道这个需要我做，还是cloud可以帮我处理）
|
n******1
发帖数: 3756 | 9 可以说一下原因吗？我们也在对比google App engine 和AWS 实现的不同，但是首先我
想了解下现有系统是如何实现的，我才知道哪个更好，AWS是有带数据库操作的，需要
实现一个tier去操作数据库，google app engine是nosql，不需要自己实现
这个project想回答一个问题：如果银行想将核心交易迁移到cloud上面，可行吗？如果
行，架构应该是怎么样，如果不行，为什么。首先考虑性能和数据一致性，至于安全和
备份，冗余都不考虑
【在 g*****g 的大作中提到】
: I don't know what's the point of your project. But you are probably better
: served with AWS for your use case.
|
c*********e
发帖数: 16335 | 10 mainframe是不一样的，还是找个知道的内行给你介绍一下吧。
【在 n******1 的大作中提到】
: 最近做一个实习项目，想在cloud， 比如google app或者ec2上面实现银行的模拟交易
: ，并且最大可能程度模拟真实的压力，用java做
: 但是问题是我对现有的银行系统不是太了解，我主要关心一些核心的操作：查询，存款
: ，取款，转账
: 性能和数据一致性是主要关注点
: 我只大概了解到银行是在mainframes上实现的
: 1.我的理解mainframes只是硬件，和实现没有直接关系？
: 2.这些功能模块是用什么语言实现呢？ 我理解是会C或者Cobol，如果我用java实现这
: 个转换有会有什么不同，目前有用java做的吗？
: 3.通账户并发和数据一致性是通过这个系统保证吗？ 还是通过外围系统实现？如果我
|
|
|
n******1
发帖数: 3756 | 11 我现在的理解核心应该CICS这一块的东西，mainframe（system z)应该只是硬件
了解的人应该比较容易说清楚
【在 c*********e 的大作中提到】
: mainframe是不一样的，还是找个知道的内行给你介绍一下吧。
|
J*******n
发帖数: 2901 | 12 google app engine和 AWS 太不一样了，你可能需要做点homework看看哪个更适合你。
我个人感觉AWS适合，因为google app engine的限制太多了，首先它只支持Java和
python，其次，你貌似只能用他家的数据库，基本上如果你有一天要把系统从google
app engine migrate到其他平台上几乎要把系统后台重写一遍。AWS给你VM，你有很大
的自由，就好像你自己在local搭建的VM一样
【在 n******1 的大作中提到】
: 可以说一下原因吗？我们也在对比google App engine 和AWS 实现的不同，但是首先我
: 想了解下现有系统是如何实现的，我才知道哪个更好，AWS是有带数据库操作的，需要
: 实现一个tier去操作数据库，google app engine是nosql，不需要自己实现
: 这个project想回答一个问题：如果银行想将核心交易迁移到cloud上面，可行吗？如果
: 行，架构应该是怎么样，如果不行，为什么。首先考虑性能和数据一致性，至于安全和
: 备份，冗余都不考虑
|
n******1
发帖数: 3756 | 13 谢谢你的解释，你说的这个区别，我有所了解
【在 J*******n 的大作中提到】
: google app engine和 AWS 太不一样了，你可能需要做点homework看看哪个更适合你。
: 我个人感觉AWS适合，因为google app engine的限制太多了，首先它只支持Java和
: python，其次，你貌似只能用他家的数据库，基本上如果你有一天要把系统从google
: app engine migrate到其他平台上几乎要把系统后台重写一遍。AWS给你VM，你有很大
: 的自由，就好像你自己在local搭建的VM一样
|
g*****g
发帖数: 34805 | 14 Most NoSQL DB is not a good fit for financial transaction support. Actually
I don't know any that's a good fit.
Your best bet is RDS (MySQL) on AWS. But it may have scalability issue on
highly write intensive application. It is definitely harder to scale up than
in data center. Their biggest VM is still nothing compared to the best
server hardware you can buy on the market. Also pay attention to RDS
documentation on node failure, check the read/write downtime when master
node fails.
That being said, if your app doesn't need scale at high level, say, >10K
write per second, and you don't need some fancy features of Oracle. It can
work.
I would take a timing on your average write on RDS for proof of concept.
【在 n******1 的大作中提到】
: 可以说一下原因吗？我们也在对比google App engine 和AWS 实现的不同，但是首先我
: 想了解下现有系统是如何实现的，我才知道哪个更好，AWS是有带数据库操作的，需要
: 实现一个tier去操作数据库，google app engine是nosql，不需要自己实现
: 这个project想回答一个问题：如果银行想将核心交易迁移到cloud上面，可行吗？如果
: 行，架构应该是怎么样，如果不行，为什么。首先考虑性能和数据一致性，至于安全和
: 备份，冗余都不考虑
|
t***a
发帖数: 416 | 15 严重同意，nosql的transaction一般都实现的比较简陋，mongodb只能把对一个single
data item的操作作为一个原子操作，你要同时update两个item, 就瞎了。。。这方面
随便找个关系型数据库都能搞得不错
Actually
than
【在 g*****g 的大作中提到】
: Most NoSQL DB is not a good fit for financial transaction support. Actually
: I don't know any that's a good fit.
: Your best bet is RDS (MySQL) on AWS. But it may have scalability issue on
: highly write intensive application. It is definitely harder to scale up than
: in data center. Their biggest VM is still nothing compared to the best
: server hardware you can buy on the market. Also pay attention to RDS
: documentation on node failure, check the read/write downtime when master
: node fails.
: That being said, if your app doesn't need scale at high level, say, >10K
: write per second, and you don't need some fancy features of Oracle. It can
|
n******1
发帖数: 3756 | 16 我想google app engine的Nosql操作和你提到的例子是不是不大一样？
我理解的google app engine的操作对象是entity object，所以不需要自己写SQL
等于将持久层的映射这一层已经实现了，
当然我还没开始了解得很清楚，现在我还没到这一步，怎么设计entity object是个问题
谢谢你们的提醒
single
【在 t***a 的大作中提到】
: 严重同意，nosql的transaction一般都实现的比较简陋，mongodb只能把对一个single
: data item的操作作为一个原子操作，你要同时update两个item, 就瞎了。。。这方面
: 随便找个关系型数据库都能搞得不错
:
: Actually
: than
|
J*******n
发帖数: 2901 | 17 this may be not entirely true....
https://developers.google.com/appengine/docs/java/datastore/overview#
Transactions
single
【在 t***a 的大作中提到】
: 严重同意，nosql的transaction一般都实现的比较简陋，mongodb只能把对一个single
: data item的操作作为一个原子操作，你要同时update两个item, 就瞎了。。。这方面
: 随便找个关系型数据库都能搞得不错
:
: Actually
: than
|
t***a
发帖数: 416 | 18 好吧。。。你们是对的，gae搞得不错，虽然有一点限制，但是在nosql世界已经很不容
易了
【在 J*******n 的大作中提到】
: this may be not entirely true....
: https://developers.google.com/appengine/docs/java/datastore/overview#
: Transactions
:
: single
|
r*****s
发帖数: 985 | 19 听上去像是学校的project吧？
除非google开银行，
我很难想象那个银行会把这个“核心”系统放到GAE上，
甚至放到AWS上也是离谱的事，
非要凑cloud这个词的话，
那就private cloud吧。
问题
【在 n******1 的大作中提到】
: 我想google app engine的Nosql操作和你提到的例子是不是不大一样？
: 我理解的google app engine的操作对象是entity object，所以不需要自己写SQL
: 等于将持久层的映射这一层已经实现了，
: 当然我还没开始了解得很清楚，现在我还没到这一步，怎么设计entity object是个问题
: 谢谢你们的提醒
:
: single
|
n******1
发帖数: 3756 | 20 你可以这样理解，至于怎么放是另一回事，我对于cloud的扩展也是很困惑
AWS说自己是auto scale
【在 r*****s 的大作中提到】
: 听上去像是学校的project吧？
: 除非google开银行，
: 我很难想象那个银行会把这个“核心”系统放到GAE上，
: 甚至放到AWS上也是离谱的事，
: 非要凑cloud这个词的话，
: 那就private cloud吧。
:
: 问题
|
|
|
g*****g
发帖数: 34805 | 21 App server can auto-scale. It's always about DB.
Consistency and availability can not be achieved at the same time.
Banking solution typically uses a relational DB.
【在 n******1 的大作中提到】
: 你可以这样理解，至于怎么放是另一回事，我对于cloud的扩展也是很困惑
: AWS说自己是auto scale
|
r*****s
发帖数: 985 | 22 no magic here.
AWS "autoscales" the underlying infrastructure,
not your running services and its architecture.
it's a little misleading.
【在 n******1 的大作中提到】
: 你可以这样理解，至于怎么放是另一回事，我对于cloud的扩展也是很困惑
: AWS说自己是auto scale
|
n******1
发帖数: 3756 | 23 我也是这样理解，但是在云的环境下，我应该怎么设计我的系统使它最优化呢
我还需要分布式么，如果是分布式，又如何分布，因为我理解底层已经做了
【在 r*****s 的大作中提到】
: no magic here.
: AWS "autoscales" the underlying infrastructure,
: not your running services and its architecture.
: it's a little misleading.
|
g**e
发帖数: 6127 | 24 RDS/mysql跟普通的mysql没什么太大区别，就是帮你自动备份，patch，可以简单的更
换server类型etc，简单来说RDS是帮你做了很多operation的工作。
具体到scalability，跟普通mysql没任何分别
Actually
than
先我
需要
如果
全和
【在 g*****g 的大作中提到】
: Most NoSQL DB is not a good fit for financial transaction support. Actually
: I don't know any that's a good fit.
: Your best bet is RDS (MySQL) on AWS. But it may have scalability issue on
: highly write intensive application. It is definitely harder to scale up than
: in data center. Their biggest VM is still nothing compared to the best
: server hardware you can buy on the market. Also pay attention to RDS
: documentation on node failure, check the read/write downtime when master
: node fails.
: That being said, if your app doesn't need scale at high level, say, >10K
: write per second, and you don't need some fancy features of Oracle. It can
|
g**e
发帖数: 6127 | 25 同意。这几天在想如何在dynamodb上实现atomic update两个表的item，搞来搞去最后
还是只有做自己的journal system.
single
on
can
【在 t***a 的大作中提到】
: 严重同意，nosql的transaction一般都实现的比较简陋，mongodb只能把对一个single
: data item的操作作为一个原子操作，你要同时update两个item, 就瞎了。。。这方面
: 随便找个关系型数据库都能搞得不错
:
: Actually
: than
|
n******1
发帖数: 3756 | 26 可不可以先不讨论存储问题呢
大家说说如果用java实现，应该做成什么样子呢 |
J*******n
发帖数: 2901 | 27 这个文章挺有意思，也是用的AWS EC2
http://www.williamhertling.com/2012/02/scaling-web-app-1000x-in
你是还没开始写production code了吗？别管三七二十一先搞出一个版本吧（用web
service应该是最快的），然后benchmark，做load testing，再继续优化呗
【在 n******1 的大作中提到】
: 可不可以先不讨论存储问题呢
: 大家说说如果用java实现，应该做成什么样子呢
|
g*****g
发帖数: 34805 | 28 我前面说过了，区别就在于硬件上限比较低。真的写流量很大可能搞不定。
mysql性能也不如Oracle。
【在 g**e 的大作中提到】
: RDS/mysql跟普通的mysql没什么太大区别，就是帮你自动备份，patch，可以简单的更
: 换server类型etc，简单来说RDS是帮你做了很多operation的工作。
: 具体到scalability，跟普通mysql没任何分别
:
: Actually
: than
: 先我
: 需要
: 如果
: 全和
|
g*****g
发帖数: 34805 | 29 It does scale up/down new instances according to the policy you set up.
【在 r*****s 的大作中提到】
: no magic here.
: AWS "autoscales" the underlying infrastructure,
: not your running services and its architecture.
: it's a little misleading.
|
n******1
发帖数: 3756 | 30 还没开始，还在搜集信息阶段，想看看框架是大概怎么样
经过这两天主要想到要实现什么，但是怎么实现还没谱，谢谢你的链接
【在 J*******n 的大作中提到】
: 这个文章挺有意思，也是用的AWS EC2
: http://www.williamhertling.com/2012/02/scaling-web-app-1000x-in
: 你是还没开始写production code了吗？别管三七二十一先搞出一个版本吧（用web
: service应该是最快的），然后benchmark，做load testing，再继续优化呗
|
|
|
b*******n
发帖数: 449 | 31 银行系统跟用不用云关系没有什么关系。
银行系统的重点是正确性，其次才是运算能力。
云提供的不过是可管理的可动态分配的硬件资源（计算能力等），软件该干的事还是由
软件去干。
搞清楚你是要玩云还是玩银行系统，在考虑是不是要上云吧。
【在 n******1 的大作中提到】
: 还没开始，还在搜集信息阶段，想看看框架是大概怎么样
: 经过这两天主要想到要实现什么，但是怎么实现还没谱，谢谢你的链接
|
n******1
发帖数: 3756 | 32 现在就是要在cloud上面模拟银行transaction系统，这是需求
不过经过这两天，我觉得重点还是在transaction系统，我现在也不纠结于云的环境下
的限制和扩展，有谁用过jee下的transaction的API没呢，这个和transaction 系统有
直接关系吗？
【在 b*******n 的大作中提到】
: 银行系统跟用不用云关系没有什么关系。
: 银行系统的重点是正确性，其次才是运算能力。
: 云提供的不过是可管理的可动态分配的硬件资源（计算能力等），软件该干的事还是由
: 软件去干。
: 搞清楚你是要玩云还是玩银行系统，在考虑是不是要上云吧。
|
t*******e
发帖数: 684 | 33 Local transaction实现靠data source driver (JDBC Driver)本身。XA的话还要有个
transaction manager协调。JEE下即可以用local transaction, 也可以用JTA
transaction manager.
【在 n******1 的大作中提到】
: 现在就是要在cloud上面模拟银行transaction系统，这是需求
: 不过经过这两天，我觉得重点还是在transaction系统，我现在也不纠结于云的环境下
: 的限制和扩展，有谁用过jee下的transaction的API没呢，这个和transaction 系统有
: 直接关系吗？
|
t*******e
发帖数: 684 | 34 Neo4j怎么样，看上去对JTA完全支持。
single
【在 t***a 的大作中提到】
: 严重同意，nosql的transaction一般都实现的比较简陋，mongodb只能把对一个single
: data item的操作作为一个原子操作，你要同时update两个item, 就瞎了。。。这方面
: 随便找个关系型数据库都能搞得不错
:
: Actually
: than
|
n******1
发帖数: 3756 | 35 对， 我在了解transaction manager怎么用
谢谢你的确认
【在 t*******e 的大作中提到】
: Local transaction实现靠data source driver (JDBC Driver)本身。XA的话还要有个
: transaction manager协调。JEE下即可以用local transaction, 也可以用JTA
: transaction manager.
|
t***a
发帖数: 416 | 36 你说这个我没研究过。。。。。。要做肯定能做，不过现在几个常用的nosql都不是往
这方面发力的，所以就做的不好。我记得几年前有两个加拿大教授回国做了个数据库，
具体名字忘了，他们就一门心思搞rollback，结果rollback的性能比oracle还快不少。
【在 t*******e 的大作中提到】
: Neo4j怎么样，看上去对JTA完全支持。
:
: single
|
t***a
发帖数: 416 | 37 spring的transaction manager其实就是个可配置的aop加try catch, 它具体操作比如
commit和rollback都是调用jdbc(如果你用的是jdbc transaction), 而jdbc是薄薄的一
层，它只是去调用数据库的transaction的那几条语句而已
【在 n******1 的大作中提到】
: 对， 我在了解transaction manager怎么用
: 谢谢你的确认
|
t*******e
发帖数: 684 | 38 Neo4j是graph database, 借用了JPA/Hibernate相当多的概念，看上去非常不错。我也
是刚开始看，不过对比其他NoSQL技术，他的特点优点很突出。
【在 t***a 的大作中提到】
: 你说这个我没研究过。。。。。。要做肯定能做，不过现在几个常用的nosql都不是往
: 这方面发力的，所以就做的不好。我记得几年前有两个加拿大教授回国做了个数据库，
: 具体名字忘了，他们就一门心思搞rollback，结果rollback的性能比oracle还快不少。
|
