android x86 支付宝,大机/小机和X86的典型应用对比：工行与支付宝

大机/小机和X86的比较，可以参考两个很典型的应用：工行核心系统(大机/小机)和支付宝交易系统

工行(2012年数据)：日均业务处理量1.7亿笔，峰值业务量超过2.1亿笔，每秒处理5000多笔业务

支付宝(2012年双11当天)：1.58亿笔，第一小时598万笔(每秒1660笔)，第一分钟13.6万笔(每秒2267笔)

两者都属于交易类应用，对数据一致性要求都很高，日常规模可能差距还是很大，但峰值规模在一个数量级上。既然支付宝用X86能行，理论上工行核心系统换成X86应该也可以，但实际上很难，至少在很长的时间内不行。个人认为主要原因有两点：

1、运营理念不同：工行的核心理念是业务连续性、稳定，支付宝当然也有这个要求，但作为互联网运营模式，其是可以试错和迭代的，这方面工行很难。假设工行和支付宝都突然中断服务1天，哪个影响大？工行别说1天，就是1小时都是极其重大的事件。

2、软件的束缚：支付宝用X86，有自主开发的数据库、LB甚至包括操作系统的支撑，当然工行也可以像阿里一样来自研，这样既有时间成本也有资金成本，但最主要的还是风险成本，工行没耐心来试错；或者说，现在市面上还没有成熟的、高可用的基于X86的高性能关系型数据库软件系统及相应的业务软件。对于工行这类企业，是希望能采用成熟的、标准化产品来构建起IT系统，试错的工作由别人来做。

综合这两点来看，要工行从大机/小机切换到X86，难度可想而知。工行很难，是不是银行都不行呢？当然不是，简单的说工行是由于影响范围太大和业务量太大，而一些小的城商行或农商行，完全有可能进行这类的尝试，一些即将成立的民营银行更是有可能都采用X86架构。