J2EE架构的银行核心业务系统

很搞笑。余额缓存下来。

把core banking给换掉，我看是没麻烦想找点麻烦，都用了这么久了，磨合期也过了，现在来说有J2EE的架构，我想还是等着吧。反正我是不敢操这份心

除非系统崩溃了，变成纸糊的了，否则不要想用别的来取代了

用C写就不能跨平台么？至少能跨不同硬件上的UNIX。如果只用ANSI C，跨操作系统也是有可能的。

老银行的核心早已上了ibm这条贼船，很难甩掉的了。

有这样的真实案例

有一个系统，当时走账就是有延迟的

最关键的是测试还没有测出来~

后来上线后，发现这个bug

当时项目负责人死了的心都有~

hehe

性能不是核心问题, 问题是切换的成本.

我在做电信的东西, 一个老系统, 要替换掉原来的系统谈何容易, 以前光bug都修了几万个, 谁一个新的架构能保证cover这些千奇百怪的需求? 读完这些代码就晕菜了

行内账务系统：
包括对公，对私存取款转账业务，计息，重要票据，里面还牵涉到无比多的规章制度，比如801（企业存款）不能转到701（个人存款），计息的时间区间，计算方法的变更（比如收利息税），冲账，轧平。

报表系统： 日报，周报，月报，年报等等汇总报表，某些特定科目的汇总报表。 这些也是非常重要，任何报表的汇总数据必然是一致的，否则后果就很严重，哪怕有一分钱的误差，也得全行业务停摆，大家翻手工账目来检查。

跨行汇兑系统: 包括电子汇兑，汇票。

信用卡大部分在账务系统里了。。

没有想象的神秘，但有大量的业务细节。

没有高深的技术，大部分人都不关心技术。有高手早已把平台层封装好了。

每个人写交易时不用考虑,也不划分业务逻辑层、数据逻辑层。

我想如果有一天用J2EE来架构，开发效率会高很多，项目开发人员会少很多。

但大部分人也不关心开发效率，因为决定系统的是业务，开发效率低些，可以用人海来补上去，只要开发过程和细节能保证就行。

目前银行核心系统虽然有bug但是运行还算稳定，
如果要换核心系统责任谁来承担。
在银行里面做系统责任大于一切，
主机或核心系统如果down掉时间过长的话行长估计都得下台。