Twitter在Ruby-to-Java迁移后才在总统大选中活下来

12-11-11 banq
最近看到Ruby社区在抱怨:一些人试图将Ruby变成Java,好像在Ruby程序员眼中Java有多不受人待见。客观地讲,要求一种语言既要讨好程序员,又要讨好CPU,几乎很是难的。

最新的一篇文章,Twitter转移到基于JVM的Scal和普通Java以后,能够抵抗住美国总统大选每分钟接近90万的微博发帖量,这篇文章将其归功于它们的迁移,否则也许后果不堪设想。

英文原文:Twitter survives election after Ruby-to-Java move • The Register

文章大意说:Twitter现在越来越少依赖Ruby了,一些Twitter服务虽然还运行在Ruby, 但是越来越少使用(系统正常演进),现在Twitter重新配置了系统,这样来自于移动设备的流量再也接触不到基于Ruby的软件系统。

Twitter现在使用的Ruby是, 当需要执行长时间批处理任务时,部署代码在定制高度优化的Ruby的runtime上以便更有效了地管理内存。

这个消息对于那些狂热的Ruby开发者并不受欢迎的,他们痴迷于Ruby语言的优雅语法以及开发产品的高效率,但是Ruby也有劣势:整体性能远远落后于其他语言。

[该贴被admin于2012-11-11 18:52修改过]

7
banq
2012-11-11 20:04
Twitter在美国总统大选中没有发生当机或中断现象,而淘宝支付宝却没有抗住光棍节的流量冲击:

淘宝天猫13小时卖出100亿元商品 午夜支付系统瘫痪

淘宝双十一系统瘫痪 官方称恢复正常

虽然支付宝应用和Twitter的特点不一样,前者强调可靠性,但是也许正是因为只看到可靠性,而忽视了从一个更高层面巧妙解决可靠性的可能性,把这篇老文章拿出来再读读,也许有所启示:

弱一致性在现实世界中到处存在

[该贴被banq于2012-11-11 20:09修改过]

lostalien
2012-11-12 10:01
我感觉ruby最尴尬的地方是,语法太灵活,有太多的“魔法”,可是这些特点不适合团队开发,如果用在团队中,必须制定一个规范,用统一的风格去写代码,可是如果这么一限制,那还用ruby干嘛啊? 所以ruby始终还是高手个人的玩具。。。

banq
2012-11-12 21:21
这里是:计算机语言性能基准评比表

下面不谈性能这个老话题,想说一下我的一点思考:

Twitter的业务特点是用户频繁写操作,也就是发出命令事件非常多,如果说一个系统是由人和物组成,Twitter的业务侧重人的动作,而物是短小内容的微博,微博没有复杂的结构关系,那么从这个角度看面向函数无疑合适的。

系统选型大概关系如下:

人:重 物:轻 ==> 例如微博 聊天室,适合采取面向函数FP,支付宝等交易系统也应该属于此类,支付的金额是物,从自己的账户中扣款做个减法而已,高峰时期大量用户频繁提交。

人:轻 物:重 ==> 例如CMS 论坛 博客系统,用户并不频繁发命令,内容很重,有复杂的内容关系,还有企业软件,比如BOM物料结构等等,办公OA系统,物是大量的文档。面向对象OO比较擅长了,Java和Ruby都是可以的。

人:重 物:重 ==> 证券股票交易系统或实时拍卖系统,大量用户频繁交易,物是各种股票或复杂的标的物,LMAX架构比较合适,以事件为主的CQRS架构,面向函数和面向对象两手都要硬。国内12306购票系统也应该属于此类,大家竞购共同资源,而支付宝之类不属于此类原因是,支付扣款不是扣共同资源,而是扣自己账户的钱,自己玩的是自己的东西,不和别人分享抢夺,物不重。

人:轻 物:轻 ==> dBase大概就可以应付。

[该贴被banq于2012-11-12 21:37修改过]

banq
2012-11-14 10:03
我在上文中已经提到,淘宝支付宝在感性的双十一节曾经服务中断,而Twitter可以在全民参与的总统大选中无发生任何意外,将中外技术比较是否有些不公平。

但是我看到有人也进行另外一个不公平的比较,将支付宝和铁路售票系统12306进行比较,这里不公平不是指管理运营机制,无疑支付宝是市场经济的代表,我说的是业务类型的比较。

有IT公知说:支付宝昨日订单数超过一亿,而 12306 最高一天出票量大约是 166 万。电商订单交易复杂度要远超过车票。

如果单从数量上比,支付宝超过车票,但是忽视一个重要的业务类型不同:支付宝交易是每个人自己的账户扣款,没有共同资源需要争夺,而铁路售票则是同时抢位子,大家抢一个,而且抢的人越多,对计算机软硬件要求越高。铁路售票类似淘宝自己有时推出的“秒杀拍卖”。

自己扣自己的钱,如果QQ聊天,Twitter微博一样,他们的交互都是有一个清晰的自我边界,不会象广播机制那样扩散。打个不恰当比喻:有的大城市很大,但是你发现实际是由一个个小城镇社区发展起来的;而有的大城市是在统一规划,统一布局下发展起来的。前者类似支付宝这中业务类型。

好了,以上只是普及贴,下面从逻辑上严肃认证一下。

首先,从业务分析方法四色原型 或UML的用例图来看,四色原型的特点是什么人在什么地方做了什么事情,核心是人做事;而用例图也是一个左边一个角色Role,右边是干什么事。如下图:

两者核心都是操作者角色也就是人(Party)和物(Object)的划分。

一个系统的复杂与否,其实反映在人与物的逻辑交互复杂与否上,当然访问量多少也是一种复杂度拷问,但那只是对性能的考量,而且业务逻辑交互类型不同决定了性能可伸缩性解决方案又不同,也就是说:如果支付宝和铁路售票业务类型不一样,那么其解决性能可伸缩性的技术方案也必然是有所区别的。

关键核心是人与物的业务逻辑的区别上。根据我多年经验和思考,从人与物交互的不同程度上对业务有一个大致的划分:

系统选型大概关系如下,其中重轻的意思是:

人的“重轻”:

“重”表示这个业务系统是跟踪操作者Party的各种操作,比如有各种不同角色的操作者,操作者的操作是否是否相当频繁,注意,这里的人(Party)是一个抽象类型概念,不是实际运营系统的访问用户,其实际用户根据其系统面向用户的广度决定的。当然,如果Party操作频繁,实际用户加上访问量根据频繁。

“轻”表示这个业务系统用户类型比较少,主要是管理者的操作,普通大众用户只能浏览读,无法写入,如发表评论等等,相当于Web 1.0,比如新闻门户网站等等,或广播电视等等。

物的“重轻”:

Party要和Object交互,这个Object物的复杂程度也决定了业务类型,物重,有两点表示:

1. Object自己的对象结构复杂,比如ERP系统的物料,半成品或成品,它们涉及几个采购 销售 生产 财务几个系统,每个子系统都有轻微不同,这就表现为其对象本身的复杂性。

2.Object对象资源的争夺性,这是从Party和Object关系来看的,这个资源相当宝贵,需要合理的分配给不同的用户,比如大牛市大牛股,很多人抢买,以前中国证券在牛市中交易系统也当机过,包括前段时间,Facebook刚上市,买卖量太大,纽约交易所出现故障。

具体分类如下,当然也可能有草率的地方,欢迎讨论:

人重-物轻 :例如微博 聊天室,适合采取面向函数FP,支付宝等交易系统也应该属于此类,支付的金额是物,从自己的账户中扣款做个减法而已,高峰时期大量用户频繁提交。

人轻-物重 : 例如CMS 论坛 博客系统,用户并不频繁发命令,内容很重,有复杂的内容关系,还有企业软件,比如BOM物料结构等等,办公OA系统,物是大量的文档。面向对象OO比较擅长了,Java和Ruby都是可以的。

人重-物重: 证券股票交易系统或实时拍卖系统,大量用户频繁交易,物是各种股票或复杂的标的物,LMAX架构比较合适,以事件为主的CQRS架构,面向函数和面向对象两手都要硬。国内12306购票系统也应该属于此类,大家竞购共同资源,而支付宝之类不属于此类原因是,支付扣款不是扣共同资源,而是扣自己账户的钱,自己玩的是自己的东西,不和别人分享抢夺,物不重。

人轻-物轻: dBase大概就可以应付。

总结:业务类型的区分可以说是软件万里长征方向的第一步,这第一步是向南还是向北,是战略性的,很多人由于细节决定成败的影响,反而迷失在细节之中,如果方向性错误,无论你怎么努力,怎么聪明,怎么强大,必然会范错误,错误的代价和你强大程度是呈正比的。

猜你喜欢