恶意取款被判无期是中国软件的悲哀

许霆ATM恶意取款被判无期案今日上午在广州市中院重审,关于此事件各种观点讨论纷纷,但是很少有从软件角度来分析。

我个人观点: 恶意取款被判无期是中国软件的悲哀:

1. 从技术上讲:在中国这样大并发访问情况下完全可以做到事务安全性(jdon.com有很多讨论),杜绝软件中数据混乱,所以,从技术上看,中国银行业软件水准比较低,或者是完全西化引进了国外软件,但是没有经过中国这么多人大用户并发访问考验(外国人没有咱们中国人多啊)。

2. 水平低可能不是你的错(也许你尽了努力,现在国内软件水平都彼此彼此),但是依靠强势吓唬人甚至欺负人就不对了。这不是丢我们搞软件人的脸吗?就象我7岁的儿子,下跳棋下不过,就把棋子推了,现在好多了,不推棋了,要按照他的规则来玩,所以,他经常改规则让他赢...

3. 如果依靠强势吓唬人成功,那么就继续保护中国低下劣质的软件水平,导致中国软件水平更加低弱。这也是强弱之道啊。你银行是软件应用老大,不带头严格要求自己,那么底下兄弟不是更浑水摸鱼了?

关于此事件的链接:
http://news.google.cn/news?sourceid=navclient&hl=zh-CN&ie=UTF-8&rlz=1T4GGIJ_zh-CNCN244CN244&q=%E6%81%B6%E6%84%8F%E5%8F%96%E6%AC%BE+&um=1&sa=X&oi=news_result&resnum=1&ct=title


这个事件 和以前本站讨论的两个事件堪称中国软件业三大耻辱:
一个是奥运会门票因访问量太大停止销售:
http://www.jdon.com/jivejdon/thread/32952.html

一个是当初股市刚刚火爆,很多股票交易系统瘫痪致使炒股者无法交易,被证券公司推为不可预测的外力(明明是自己的软件水平不行嘛)。
http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=32922&message=23110999#23110999

软件认识普及率低,连很多程序员自己都不知道什么样的软件叫好软件,很多人都以为只要能运行就是好软件呢,更别说普通老百姓了,这个根本原因就导致了中国软件普通用户太客气,好讲话,容易被忽悠,再加上大棒(判你个无期),简直断送了中国软件的未来啊。。。。。。。

相关帖子:http://www.jdon.com/jivejdon/thread/33712.html
[该贴被admin于2008-03-25 12:15修改过]

深有感触!

我看过一个技术经理收集的系统崩溃的信息。那些公司都是开始规模很小,后来网络推广做的好,慢慢壮大。访问量到了十万,百万,公司正要飞升的时候,系统崩溃。数十个前景美好的项目,都最后消失了。让人触目惊心。中国人就是这样,爱整表面文章。什么东西都是瞬间做出来,挑快的,便宜的捡。不知道危机发生的时候是多么可怕。

为什么不在底层搭一个稳固的平台,分布式来出来。为什么!为什么!


找到那个文章了,贴出来
-=============
《写给WEB2.0的站长 不仅仅是泼冷水》

写给WEB2.0的站长 不仅仅是泼冷水

当互联网吵吵嚷嚷的进入2.0时代,当互联网的技术不再是那么高不可攀,当复制变成家常便饭,互联网热闹起来了

myspace火了,中国冒出更多的myspace

youtube刚刚起来,中国的视频网站就遍地开花

51拔地而起,中国出了无数的SNS

facebook则改变了中国站长的抄袭方式,不再学chianren了,校内火了
..........

当抄袭变成习惯,我想说的是,模仿,站长,你准备好了吗?

如果你打算做垃圾站,或者赚点广告费的网站,请不要点击这篇文章,我从技术角度方面谈谈WEB2.0网站的模仿问题。

当投资和流量都不是问题的时候,我想说的是,您真的一帆风顺吗?

拿SNS网站来说,当匆匆上线的2.0,当一笔笔投资砸进去的时候,当流量上去的时候,您的困惑在什么地方?

我做过多个2.0公司的技术顾问,简单的谈谈2.0公司遇到的问题(涉及隐私,我用A B C D代替),这里就不再赘述大家众所周知的页面静态化,缓存和代码安全等问题了,有点技术的2.0公司的CTO都知道这些东西,我们谈点发展之后的问题

A公司

A公司做的是SNS网站,程序是两个毛头小伙子做的,目标直指51,程序开发是一帆风顺,功能也比51牛多了,推广也是一帆风顺(A公司有自己独到的推广方式。但是当ALEXA到2W的时候问题出来了,每天下午4点左右,网站速度慢的惊人,基本上打不开,公司三台服务器CPU100%,让人郁闷的是公司的网络配置方式,居然是双WEB的集群,而单独一台DB数据库。整个瓶颈在数据库,于是我建议做DB的集群,分析了一下数据结构,MD,典型的WEB程序员的作品,没有一点数据库设计规范,功能实现是可以,如果要扩展,不可能,集群基本上是不可能的,怎么办?不能办,于是,一个月的时间修改程序,数据结构基本上换了一遍 前期砸进去的几十万打了水飘,用户走光了。

结论:WEB2.0前期设计的时候不应该只考虑功能,应该认真考虑一下底层和数据结构了。

B公司

B公司也是做的SNS网站,程序是3个人开发的,CEO是某名牌大学的经济学硕士,有点知己网的味道,又有一些特色出来,说实话,公司的潜力不错,CEO 有很强的运作能力,感觉前景不错。系统架构还行,但是---但是系统崩溃了,why?系统没有考虑到用户有个海量的说法,文件也有个海量的说法,用户的相册,图片全部存贮在WEB服务器的一个分区上,每个用户一个目录,而打开性能监视器,磁盘的IO高的惊人,基本上无暇响应。众所周知,文件系统也是一个数据库,单独大文件无所谓,关键是整个是300多个G的零碎文件,大量的读写操作,系统崩溃,数据丢失,文件系统的一个链断了,用户数据全部丢失!!!这是一个非常沉重的问题,系统整整停了一个月来做数据恢复(单独文件很容易,但是海量文件目前还没有一个软件能组织起来软件架构)。解决方案:修改程序架构,做分布式文件存贮(程序修改用了8天,但是文件转移却又用去了将近一个月),20万用户损失殆尽

结论:WEB2.0前期的设计应该有应付海量存贮的考虑,整个涉及了程序架构的修改,前期规划不好的话基本上思路一条。

C公司

C公司是一个值得尊敬的公司,CEO技术出身,和比尔盖茨一样,大学未毕业出来做网络,01到03年做短信狠赚了一笔,后来做的小项目也小有所成,说实话,我很佩服。公司做的是校友方面,但是更偏重myspace风格,注重个人主页,推广方面也下了大手笔。系统崩溃的原因其实很简单,由于采用的是微软的 SqlServer,而微软直接就告诉了我们,SQLSERVER不支持集群,他们的数据库超负载,100%就没有下去过,只能横向增加配置,采用了4路 4核CPU系统,但是系统还是崩溃了... 高互动注定了高负载。解决方案:现从基本入手,解决掉几个程序耗能大户,对数据库采用横向切割,将用户每10万进行分组,同时对数据库系统进行散列,将多个表垂直分割,同时进行文件分组,解决问题. 因为修改了数据结构,程序也基本上大动了一下。 好在系统没有出大错,损失不算很大,不过对用户体验造成了很坏的影响。

结论:WEB2.0前期设计应该有良好的散列考虑,程序应该能有配合的扩充性,符合数据库的扩充

D公司

D公司是一个各个方面做的比较好的公司,做了CDN加速,图片也独立分出了N个服务器,数据库不错的一个,(CTO是个数据库专家),系统崩溃的原因在于 WEB,按道理说WEB很容易做集群的,但是发现集群并解决不掉问题,他们的集群只允许做4台的WEB集群,但是4台都当掉了。仔细分析,找到原因,我估计整个也是大部分CTO最容易犯的一个错误,或者说他们根本就想不到的问题,就是WEB上传的问题,上传的时候由于时间的原因,线程是保持链接的,300 个线程就可以把一个WEB Server当掉了。解决方案:这个最简单,把上传和其他耗能大户分离出独立出来。程序改动不是很大,但是之前半个月速度满对用户体验的损失也不可小视。

结论:没有什么结论了,毕竟有海量访问经验的CTO不多,也就是那几个大站的。

总结:不是泼冷水,模仿其实是很容易的,随便找几个WEB程序员就能做到,并且很简单,速度可能还很高效,因为WEB2.0无非就是跟数据库打交道,会操作数据库就会做。但是真正做大并不容易,因为能应付海量访问的程序并不简单,现在的程序员都太自命不凡,其实真正有经验的并不多,不要相信一个月薪5K- -10K的程序员能给你多大的惊喜,能应付海量访问的程序员不是那个价格。如果您想做2.0,想做大,有几个个建议:

一.找DBMS的专家设计好数据库,大部分程序员都不知道分区视图,数据散列,数据组的概念

二.设计好程序架构(这个其实不难,有个高人指导就行了),保持良好的扩展性,成本考虑可以找兼职的系统架构设计师做好系统架构,确定将来的发展瓶颈。

三.考虑好文件存贮的问题。文件存贮的技术含量看起来很低,其实是很高的,可以考虑反向代理的方案。文件存贮出问题了,站点基本上就完蛋了,不仅仅是RAID的问题和存贮服务器的问题,不过道理倒是一点就破的

四.中国国情考虑,这个最致命,需要考虑电信和网通的问题,CDN并不能解决所有问题。互动性的东西并CDN并不是很有效。最关键的是,现有的双线机房遇到DDOS攻击基本上都会当掉,原因很简单,双线机房都是私人机房,本身就不会有太高的带宽,随便攻击一下就可以D掉(顺带提一个笑话,我知道一个双线机房的老总总共1G的带宽却买了4G的金盾墙,很简单800M的攻击就可以搞定)。

五.网络延迟的问题,这是分布式系统必须要考虑的,程序要能容忍0到100秒的数据延迟的功能,也就是同步的问题。不要小看这几十秒,问题很大的,如果你的站点有交互式功能,比如即时聊天,你可以想象一下是个什么结果。对于即时聊天的东西,可以用反向代理来解决(成本较高)。但是对于留言和评论的影响不大,但是如果系统为了健壮做了缓存和静态化的时候,这个东西可能就是灾难性的了。

六.分散你的程序,如果你没有太多的资金构筑动辄百万的服务器,建议把功能分散开来,比如相册一台服务器,留言一台服务器

七.看好你的程序员,如果没有很好的激励措施的话你的程序员很容易写出敷衍性的代码,而这个可能就是将来的大患,程序架构定下来后要修改可能就要费牛劲了。最好你的CTO能对你100%的衷心,100%的负责。

八.文件同步的问题,这个问题可能你觉得没有必要,如果你看一下网通和电信的TTL就明白了,同步要支持续传,并且不能是持续的,否则你的成本会高出N倍,不要期望能通过你的软件实现,交给你的程序员吧,把上面的话告诉他他就知道怎么做了。

九.最狠的一个问题了,也是吃亏最大的问题,不管您跟网警的关系多好,看好你的用户,审核好你的东西,一被停机可能就致命,本人就吃过N次亏。

十.最后,祝各位站长一番风顺,大展宏图。

=====================
[该贴被goddie于2008-02-25 11:48修改过]

web2.0文章转贴不错,其中提到DB集群,也就是数据库集群,还有Linux集群,操作系统集群,还有Web集群。

我想说明一点的,这些集群都没有业务Bean集群精确,业务Bean集群属于精确制导,可以精确针对性解决那些负载大的具体的业务功能类,因为一个软件系统不可能所有的功能都很繁忙,DB集群和操作系统集群和Web集群只能从一个软件系统外部整体解决所有功能的负载,精确性不够;

目前实现业务Bean集群有两个技术:EJB和分布式缓存(适合Spring或Jdon这样POJO架构),当然这两个集群技术前提就是,你必须有业务Bean,必须有专门的业务层,也就是必须有分层架构,也就是必须有针对业务的分析,如Evans DDD。

精确的业务对象分析+业务Bean集群 是解决目前大多数业务软件系统巨量处理能力的正确方向(也是性价比最高)。

当然,这其中没有涉及保证一致性和完整性的分布式事务,这些都是银行ATM等关键业务必须的,他们又要面对象Web2.0网站那样巨量访问,也要保证在这些巨量并发下,数据操作完整性(web 2.0网站目前还不必关心这些),否则就会出现那个用户银行帐号有1亿存款。

所以,中国银行的软件是分布式计算+分布式事务,Web2.0网站是分布式计算。Web 2.0技术还是性能第一,搞过Web 2.0去开发银行软件,还需要再补分布式事务的课,而搞银行软件的人去办web2.0网站,要少些保守数据安全的考虑,多些高性能。

其实高性能和高事务可靠性是一对矛盾,没有最好,只有更好。

[该贴被banq于2008-02-25 12:42修改过]
[该贴被admin于2008-02-25 14:02修改过]

banq所言真是大快人心,一针见血地说出了问题。像如此思维清晰的人,我不知道其他真论帖的人在跟你争什么。。。我用过工商银行网银,一直就是java技术的,非常爽。如此说来,banq完全可以去给那些大系统做系统评估,何必搞DDD培训赚钱。

哈哈,多谢,事情越辩越明,通过争论和事实分析也是普及软件思想的好方式,只有大家统一了对软件的认识,这个市场才培育起来,这时才可以谈商业。

看到这些触目惊心的前车之鉴,我现在着手一个SNS网站,有点恐慌。技术也不是非常熟悉,经验也不足。又不想在发展之前直接使用EJB架构(开发进度的要求),我使用的是Hibernate+spring+struts的架构(实在没有精力再去学习jdonframework的EventModel了 @_@),请问,如果我的系统要求越来越高,目前这个分层到时候能和平过渡到EJB吗。是不是把DAO层的实现全部改为事务Bean就行了,还是说又是一次重新编码,设计的过程。

刚刚冲费成了VIP下载您的代码来学习,上天保佑我能学到有帮助的 . >,<
[该贴被goddie于2008-02-25 19:01修改过]

看到一句 “Spring 不支持 session” ! 我靠,不用了。

>Spring 不支持 session
2.0以后支持了,以前1.X没有支持,偏偏很多人捧1.x臭脚,所以说,软件领域有时象网站互联网行业,有时泡沫是被吹起来的,善于利用的人就像当初张朝阳办搜狐一样,不管有没有,先打出名气,有了融资,再慢慢做好就行,有钱好办事。

>又不想在发展之前直接使用EJB架构
web 2.0不适合EJB,EJB是高性能和高事务可靠的中间妥协产物,而Web 2.0侧重于高性能;EJB适合银行业,但是深入应用,也绝不是那么简单。

无论中国的银行软件 还是你的SNS网站,深入下去,都不能使用通用的解决方案,需要有自己的特色架构设计,就象eBay,它的技术架构已经成为它的核心竞争力之一。

[该贴被banq于2008-02-27 09:16修改过]

最近TSS有一篇Load-balancing Tomcat with Apache,谈如何使用apache+tomcat实现Web集群,或者严格说是负载平衡,该文中还对比了负载平衡(Load-balancing )和集群(Clustering)的区别,很多初学者总是以为负载平衡就是集群,其实这两个概念还是有区别的。

几个重要概念:
Load balancing负载平衡 – 客户端请求由服务器群中多个服务器平等处理。这样可分担大负载的访问。

Server affinity (sticky session) Session跟踪– 使用server affinity能够让一个客户端发出的多个请求始终由一台服务器来完成。

Transparent failover(透明失败恢复 高可靠性) – 在这种策略下,客户端并不知道一台服务器崩溃(一台服务器崩溃并不会导致整个软件系统崩溃),这是一个请求request或session级别的策略, 这个策略能被集群服务器实现,如果只有负载平衡,一台服务器崩溃,那么客户端必须重新登录(也就是不能实现可靠的单点登录SSO),这是集群和负载平衡的一个区别。

Server Cluster 服务器集群– 一群服务器作为一个整体一台服务器面向客户端访问,用户的数据缓存在集群环境的所有服务器中(根据集群策略不同,不一定保存所有服务器,集群可以认为Transparent failover + Load balancing banq注)。

Scalability 可伸缩性– 软件系统在不降低响应时间的情况下的处理能力衡量标准

英文原文:
http://www.theserverside.com/tt/knowledgecenter/knowledgecenter.tss?l=LoadBalancingTomcatApache


服务器群的几个策略,从简单到高级
1.人为划分服务器 :大多数采取的,包括游戏网站,必须由用户自己选择哪个服务器,这是最低级朴素的。
2.负载平衡
3.集群

[该贴被banq于2008-02-27 09:38修改过]

分析角度独特,分析思路透彻,分析方法幽默,分析力度深刻!

这次银行事件,我倒认为并非软件方的问题,而是需求方的问题!

为什么电脑中输入1块,会吐出来一张100元的?肯定是银行应用人员设置的啊,1对应100,他本应该设置100对应100的。

为什么会有这个功能?还不是有需求才有开发吗?难道开发这套程序的人故意画蛇添足,增加这么一个容易导致人为犯错的功能?增加软件应用中意外情况发生的可能性?

也许真的象楼主说的那样,这套软件是从国外引进的,所以国外开发人员在考虑全世界通用的前提下做了这么个功能,ATM中的货币单位在中国以100¥/张为单位,在美国也许是1$/张,而在日本又可能是1000日元/张。

所以我认为之所以导致这种现象的发生并非开发人员的问题,而是应用者的悲哀!太自以为是,认为我懂这个、我也懂那个,我这么做没错,所以导致这些问题的发生;

作为一个软件开发人员,即使你做了很人性化的提示、用鲜红的文字做了说明,使用者未必去看,在我们周围这样让大家无奈的事还少吗?

比如我们给一个对刀工不熟的人一把削铁如泥王麻子菜刀,这个人却非要耍一些花样以表示自己配的上这把刀,却不小心切了自己的手指头,我们能说是刀的错误吗?

同样软件也只不过是一个工具,太迷信工具,和太不了解工具,或想当然的应用工具所造成的损失肯定不是工具的错误!
[该贴被huzj于2008-03-01 14:51修改过]

楼上结论严重错误。 如果软件是好的,只是应用者设置错了,那每个人去取钱都是会出来100倍的,而不单单只是许霆一个人。为什么是许霆一个人碰到这种好事,是软件在一个特定条件下发生了错误。是设计问题。

编程编傻了是吧,外国也出现过恶意取款的事例
别动不动就说中国什么什么不行了
这和中国没关系