为什么说互联网金融是对传统软件的一种颠覆

http://www.jdon.com/45845

互联网金融时下非常热门，承载着很多人的希望，好处就不多说，想浇两盆冷水。

一盆冷水是一位网友在使用支付宝时，出现了1+42=55元的简单计算错误
另外一盆冷水是今天百度理财发表的声明：
百度理财首款产品今日10时28分准时发售。由于页面访问瞬间并发数巨大，导致部分地区用户登录受到影响。我们将在最快时间内修复。请各位网友放心。感谢大家的耐心和支持！

为什么我认为互联网金融还有一段路要走？问题就在这儿。

首先，互联网与传统金融主要区别是流量大小，也就是说互联网软件的并发读写的机会大大增加，而金融软件的特点首要是安全，由于涉及到金钱，不能多一份钱也不能少一分钱。如果把互联网软件比喻成狂跑，那么金融软件则是安静独守。

那么既然要搞互联网金融，那么肯定需要尊重这两者的规律，你不能为了快，搞得数据丢丢拉拉，你也不能为了安全，算了半天还没有结果。

下面提出的挑战就是如何将两者有机结合在一起，自然无缝的结合，强扭的瓜不甜。

首先，我们看看传统的金融解决方案是否适合互联网大流量系统呢？
传统的金融银行系统大部分使用JavaEE+数据库这样的架构，通过2PC或JTA之类事务完成每一笔业务交易，这些系统操作都是依靠内部柜台人员操作，访问量不大，就是偶尔繁忙，还可以挂出免战牌：今天电脑故障休息。

这样的系统如果直接搬迁到面对成千上万的互联网用户，将这些柜台人员下岗，让普通用户通过网络直接操作自己的帐号，于是就可能出现百度理财的“免战牌”。

有人说，互联网企业分布式技术如此强悍，到处参加各种大会分享他们的“宝贵”经验，难道不能通过分布式解决性能问题吗？

我们知道分布式系统是一种横向水平伸缩(Scalable)方案，业务决定架构，不是所有的业务都能够采取水平伸缩就能解决性能问题的，问题的关键还在于数据之间的关系的强弱。

好了，我们已经谈到问题核心：数据之间的关系的强弱。

数据结构是不是表达数据之间的关系的强弱？

请注意结构这个词语，当你看到建筑结构，看到你的房屋结构时，你对结构一词可能有更深入理解，既然是结构了，默认数据之间已经是一种强关系。

结构化数据和非结构化数据才是完整表达数据之间关系的强弱。

也就是说，水平伸缩方案适合非结构化数据，也就是数据之间是弱关系甚至没有关系，这是很容易理解的；但如果数据之间是一种强烈的结构关系，我们称之为聚合，怎么办呢？

有一条计算机原理：聚合必然引发争夺，道理很简单：僧多粥少，坐地铁人多就要抢位置。

对于争夺，传统软件的思路就是用锁，某个时刻只能允许一个用户操作这个资源，其他用户线程必须等待其操作完成，于是互联网并排欢乐奔跑的用户到这里被迫强行停下来，等待，听从指挥，如果允许，将被唤醒进入操作。

这种人为强制性的管理措施显然带来了很差的用户体验，甚至崩溃，同时也是不尊重底层辛苦劳动的CPU。因为线程是CPU私有财产，你不能将之充公后再进行管理分配，活活地折磨CPU。

当前对于争夺比较优雅的解决方案是Reactive编程，也就是事件驱动编程。

对于有着强烈关系的聚合数据，我们必须将其作为整体对象来处理，当发生多个并发用户操作这个整体对象时，我们也不能使用锁来对用户进行限制。

参考Java的NIO的Reactor原理，以及Node.js的原理，我们为每个聚合对象分配一个专门的守护者，所有有关这个资源的操作都交给这个守护者操作，通过一个无锁的队列进行快速排队与守护者进行交接。

通过Reactive编程，我们还可以避免某个资源的操作占据CPU线程太久，只要做完有关资源争夺的那点事情后就赶快另派线程做剩余的事情。这样将串行顺序操作和并行操作能够有机细腻度的完美结合在一起。

那么性能的扩展如何解决呢？不能通过水平扩展，就只能通过垂直扩展，这里的垂直扩展不一定是向上扩展，比如PC换小型机，而是一种向下扩展，通过增加CPU核数来提升聚合数据的并发处理能力。

总之，互联网金融代表一种海量数据高事务高速处理，类似高频交易，与前期12306 或光大事件一样，对于我们从业务数据分析方法，一直到底层组件代码编程实现，都会提出新的挑战，产生颠覆性编程革命。
对于百度理财来说，10亿元的限额是一个共享聚合数据，是每个并排奔跑进来的用户都必须共同面对一道坎。

如何让每个人购买基金时接受10亿元限额的检查，但是又不能堵塞用户其余的操作，这也是本文提出使用reactive编程的目的所在。

对于12306火车票预售，座位资源是一种共享聚合数据，很容易发生多个用户抢一张火车票，也就是抢一个座位位置的情况。

慎重而且细腻地处理共享的聚合数据，是让软件奔跑起来的关键。

reactive宣言
什么是Reative编程？