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

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编程?


你可能感兴趣的:(参考资料)