用户可以撑到过户百万，除此之外他们的制约在数据库，两套系统分别挡掉了4/5的流量，整体挡掉后其流量变成了以前的1/25，其实就是数据库并发能力来说扩大了25倍。但是他们的业务发展远远不止25倍，所以数据库依然是一个很大的瓶颈。
再者、第二个问题就是团队划分，其实每个团队都做自己的系统，但是宜人贷仍然使用同一个数据库，这个时候比如说设计和修改数据库的时候，都非常麻烦。每次都要问一下其他团队，我这么改行不行，对你有什么影响等等。
另外、第三个问题也非常棘手，大量使用了缓存，数据的时效性和一致性的问题越来越严重。我记得4月份的时候上了一个理财产品，它的库存多退了一倍，10点钟上线非常准时，但是发现问题之后把它下线，下了半天之后下不了，原因就是有缓存，非常难下。
2.0版本——“开小灶”精细化
为了解决1.5T，孙军他们需要做精细化的优化，他把它定义成开小灶。
首先，合理划分数据归属、优化查询效率、缩短数据库事物时间；其次，分系统，每个系统用固定的表。从每天都在做的事中，让运维找出线上最慢的有哪一些，从而对它们做优化。第三，做去事物，或者尽可能的提升缩短事物的时间。
然后、开始关注代码质量，提高执行效率，并且开始关注并发问题；用户达到这个量的时候，就会有有用户帮他们测试。打一个比方同一个用户用同一个帐户登录了两个客户端，他同时点进去，这个时候如果程序处理的不好，很有可能让他提两次。 最后，要区分强一致与最终一致，合理使用缓存与读写分离来解决这些问题。
2.0性能问题解决很多了，还会带来新的问题——系统越来越多，系统间依赖关系变得复杂；这个时候很容易出现A调B，B调C的循环调用。第二个是系统间互相调用增多，上游系统压垮下游系统；第三个，也是非常头疼的问题，系统很多，查找线上问题变得越来越困难；试想一下当系统部署到很多机器上，想找一个线上的问题，通过查日志的形式非常难查。所以在这个基础上他们做了几件事，一是关于限流，限流通常基于两点：最大活动线程数(高消耗任务)，每秒运行次数(低消耗任务)；
活动最大线程数适合于高消耗的任务，然后每秒运行次数适合于低消耗的任务（这里应该是针对请求接口次数做的限制吧）。 二是一个建议，他建议尽可能统一内部系统间返回值，返回值中一定要记录返回状态（业务正常、业务异常、程序异常）和错误说明；第三个，可配合RPC框架完成限流工作。
再说一下关于查找问题，宜人贷日志系统部署框架，最左侧的是他们的业务系统，在业务系统上把日志搜集到卡夫卡队列，最终采用Kibana和他们自己研发的系统去查看日志，日志到了一个集中点不容易找，而这样就更好找了。
关于软件方面，宜人贷统一使用slf4j+logback输出日志，然后日期系统做到日志串联，所有服务端和客户端之间都隐藏的一些参数，这些参数会随着调用链一步一步往下传，通过AOP来实现，日志串联需要传递哪一些参数，或者日志中到底要打哪一些参数呢？第一个是时间，这个时间应该到毫秒级，第二个是流水号，流水号就是每次请求升华到唯一的一个P值。然后是设备号：时间（到毫秒）、流水号(uuid，每次请求生成唯一值)、用户session、设备号、调用者时间（APP使用手机本地时间）、本机IP、客户端IP、用户真实IP、跨越系统次数——有了这些找问题就非常容易。
做到2.0之后，宜人贷的网站基本上到了中大型的网站，短时间内不会有太多的性能问题了，但是他们肯定还得继续往下走。
3.0版本——拆分做服务化
3.0总结下来就是要做服务化，通俗一点说就是拆分，包括垂直拆分，充值拆分基础上系统之上的水平，那么服务化要怎么做呢。