随着互联网金融的持续火热，越来越多的银行纷纷发布了各自的互联网金融产品。但是互联网产品“高并发、大数据量”的特点却对于银行传统的核心系统架构带来了新的挑战。
1、互联网的核心技术特征
当前互联网的核心技术特征主要可以概括为：分布式，易扩展，大量低端设备，底层开源软件。分布式结构可以通过平行扩展来支撑互联网上蜂拥而至的访问客户。同时，基于客户行为分析的大数据平台也需要分布式系统来完成，其中最典型的就是Hadoop集群。
2、传统银行系统的技术特征
传统银行系统的技术特征主要可以概括为：专用设备、底层闭源软件，成本昂贵，系统稳定。由于金融业对核心系统的稳定性、可靠性和安全性要求极高，目前大部分银行都是采用IBM的整体解决方案，并且几乎没有可替代性，IBM仍然保持着市场垄断地位。
3、挑战主要来自客户体验的升级
随着互联网客户规模的增长，客户行为和系统响应次数也呈现爆发式增长。
传统电子银行提供的是被动服务，产品只提供相应的功能，需要客户自己去查询和操作；而互联网产品更多的是提供主动服务，形象直观的展现客户相关数据信息。这就要求单个客户发起的或者产品自动发起的一次请求响应需要同时与核心系统的多个功能接口进行交互，再考虑互联网客户规模效应，其对系统的压力是非常大的，由此也会带来巨大的风险。
4、产品设计应具备合理性
大多数情况下，核心系统的架构是无法改变的。这就需要我们从产品设计和应用系统上尽量规避高并发交互响应的发生，但这绝不是以牺牲客户体验为代价来完成的。
如果核心系统因为高并发量而出现瓶颈时，首先应当保证应用系统对产品的支撑，至少产品不能出现崩溃和给客户带来超出预期的失落感；其次，产品的异常提示内容也要足够友好，可以减少客户的负面情绪。最后，对发起请求的总量进行控制，可以采用临时输入验证码等方式来降低客户请求的频率。
下面以“宜人贷系统架构”为例，宜人贷架构师孙军着重地分享介绍了宜人贷系统发展过程中遇到的实际问题和解决的办法，并重点介绍宜人贷出借系统和借款系统的高并发解决方案。
二、宜人贷系统版本的迭代
1.0 版本——简单的烦恼
迭代之前宜人贷的系统，其实就是一个前台，一个后台，一个DB，前台采用的是多级部署的方式。
软件也是跟最传统的软件一样分三层，第一层是Controller，第二个是Service，第三层是DB。显然这个系统并不适合互联网，有一些难以避免的问题。首先当用户过万，在线用户上线的时候，这样的部署方式会产生一些瓶颈，包括服务器和数据。第二个就是团队变大，所有开发人员集中针对同一个系统，冲突严重。
1.5版本——“吃大补”试试！
为了上面的问题他们做了一些修改，孙军把它定义成“吃大补”。吃大补通常有一个很明显的特点，就是立马见效，但是副作用也很大。
首先，他们在宜人贷的页面层更加关注性能，比如说浏览器，压缩传输，页面都经过了Yslow的优化，浏览层增加了CDN，做了静态化甚至反向代理，这样可以抵挡80%的流量。
页面层中间加了一个集群，这个集群基本上可以挡掉80%流量，最后系统把它业务垂直拆分成多个系统，比如说APP的后台，Web、信审、抓取、活动、报表等等。数据库也有一些变化，开始只是一台主机，一台数据库，现在变成了主从，一主多从。