如需转载请联系听云College团队成员小尹 邮箱：yinhy#tingyun.com
中国应用性能管理行业盛宴——2016中国应用性能管理大会（简称APMCon 2016）于8月18日至19日在北京新云南皇冠假日酒店隆重召开。APMCon由听云、极客邦和InfoQ联合主办的作为国内APM领域最具影响力的技术大会，首次举办的APMCon以“驱动应用架构优化与创新”为主题，致力于推动APM在国内的成长与发展。
麻袋理财研发高级经理 邰祺超于性能可视化专场发表了题为《互联网金融的性能微创新》的演讲，现场解读了在性能调整和优化方面的一系列微创新实践：比如抢标、高并发、前端优化、实时数据监控等。
以下为演讲实录：
邰祺超：我先做一下自我介绍，我叫邰祺超，来自麻袋理财，负责P2P系统的架构和研发工作。之前主要从事互联网，包括电商一些系统的开发。
我今天的分享主题是《互联网金融的性能微创新》，今天将会以四大块开始我今天的分享。首先允许我在这里简单介绍一下麻袋理财，麻袋理财是中信产业基金投资控股的互联网金融服务平台，中信产业基金不仅投资了滴滴出行，还包括饿了么等。我们麻袋理财是产业基金投资的唯一一家互联网金融服务平台。我们平台是在2014年12月8号上线，不到两年，非常年轻的团队。在2016年3月25号，有幸成为中国互联网金融学会的首批会员单位。2016年5月份，我们获得了中国社科院网贷综合评级A类，排名前5。截止到目前为止，帮助投资人实现了收益超过1个亿，可以看到我们也取得了小小的成绩，在短短的不到两年里。
一、业务快速发展的挑战
所以从刚才的介绍可以看到，我们的业务是在快速发展的，上图左边这个柱形图我做了一个对比：在2015年上半年和2016年的上半年，累计撮合的交易金额同比增长了131.24%，可以看到增长是非常快速的。面临快速的增长，我们的系统必然会遇到一些挑战，比如说我们遇到最大的问题是高并发，为什么说高并发？因为我们的标基本上都是秒标，刚才在场下跟阿里的陈老师讨论，他也在尝试着买我们的产品，他发现不好买，买不到，因为我们的优质资产是有限的，经常出现秒杀的情况。
所以对于我们的系统来讲是会遇到瞬时的高并发状况，而且我们的业务不断往上快速迭代，每天都有小版本发布，每周一个大版本。在快速迭代过程中可能有些地方没有考虑全面，会有一些小错误，那么我们的系统怎么去容错？业务增长的同时我们的系统怎么能够快速的支撑业务的增长，能够横向的扩展，包括我们的产品越来越多的丰富，系统架构怎么能够快速的适应一个新的产品？这些对我们来讲都是一个很大的挑战。
二、互联网金融的技术挑战
我们是一家互联网金融平台，互联网金融平台会有哪些技术挑战？我这里简单的总结了以下几点：
首先，它的投资门槛非常低。如果你去银行理财，银行可能要求你5万起投，但我们不一样，100元起投。这100元起投意味着什么样的问题？假如说你要借5万块钱，如果每一个出资人给你投100块钱，需要500个人给你投才能投满，这样就意味着你中间要跟很多投资人中间发生关系，他们中间会牵扯到大规模交易处理。
我们是一个在线的平台，我们需要提供给用户的7乘24小时自助服务，用户可以很清晰的看到他的收益情况，我们的收益要实时的给用户展现出来，这意味着我们的系统每次发布的时候要考虑到一个问题，怎么去平滑的发布，包括接口，数据库、表升级，怎么能够让用户无感知？这都是我们要面临的一些挑战。
一个接入系统用户来这里理财，他希望看到每笔投资每个月什么时候回款，它的本金回了多少，利息收了多少，如果债权转让，服务费多少，你要有一个金融体系清晰的账户，你要有科目，让用户看到发生在哪里，能看得到这些交易明细。
最后一点是资金安全。我们所有的交易都是在线上完成的，用户的充值提现都需要我们保证在数据传输中进行加密，包括核心的数据落地以后也要进行加密处理。我们也在业务上设计一些安全的措施，比如说同卡进出，假如说用A卡充值了5万块钱，投资了某一款产品，当你提现的时候，A卡只能提现5万，从哪里进来的钱只能回到哪张卡里面去，也是保证了资金的安全。
除此之外我们还有一个是复杂的产品业务，介绍这张图之前我先简单说一下传统P2P的玩法，假如说10万块钱你想理财，在我们这个平台上看到有张三、李四、王五他们都要借钱，一人借3万块钱，你会怎么去投资？举个例子，相当于这里有一筐鸡蛋，怎么能不让碎掉？把鸡蛋放在不同的篮子里面，投资也是同样的道理。我把10万块钱分散的投资到不同人身上，哪怕这个人不还钱，还有另外两个人，不至于所有的鸡蛋都碎掉了，这是分散。这款产品从某种层面上来讲，就是做这件事情。用户买了我们产品以后，系统会帮他分散到不同的借款人身上去，每个月有相应的本金和利息的回收，我们为了提高资金利用率，我们也会进行复投。
三、麻袋系统的演进
面对快速增长的业务以及不断丰富的产品，我们的系统也在短短的不到两年里发生了一些演进，主要归结为三个阶段，第一个阶段是MVP的阶段。像很多互联网公司一样，MVP是最小可行性的产品，我们更注重于核心的模型建立，包括核心接待模型的建立还有一些最基础的业务搭建，比如说用户能够来我们这里注册，进行实名认证、投资，有收益以后进行提现等。
这一时期我们的产品也是非常单一的，而且我们的终端也非常单一，只有PC站和M站。后来我们也有了移动支付，我们的产品也变得越来越丰富，产品丰富就意味着我们进行了模型的优化，能够快速的支持产品。随着用户的增多我们流量也不断的增加，我们的核心路径也进行了一些优化。在去年10月份，我们有一次在搞秒标的过程中系统就DOWN掉了。从那以后也吸取了很多教训，对系统进行了优化。
到了3.0我称为微服务也就是我们现在正在做的事情，我们想把这个系统按照业务拆分出来，让专人专事，让小团队去负责他更专注的事情。在操作过程中发现一些功能的服务，想让它下沉，提供一些基础的服务。在这个时期我们也开始关注各个指标，包括我们系统的CPU、内存等这些情况，我们也在做一些监控，包括一些慢服务。
四、遇到的挑战
刚才讲了我们的产品基本上都是秒光的，基本上是每天上午10点，下午4点和晚上8点放出来用户会在同一个时间点抢购我们的产品，这意味着这个时期我们的系统会超负荷的运转，接收到很大的流量。
所以抢标会遇到哪些挑战？首先第一个就是超卖的问题，所谓超卖就是你卖多了，有些人会想到一些其他的办法比如说做一些工具，去网上搜某某平台抢标工具，他会想办法作弊，为了抢到更多更优质的资产。毋庸置疑，抢标性能肯定是非常热点的问题。假设你的系统不能接受更多的服务，系统要能够过载保护，我们也依赖第三方的系统，比如说发送短信、还有支付这一块。
接下来我会逐个展开来讲。
1、超卖
第一个问题是超卖，我这边举了一个案例，玩过电商的人应该都知道什么叫超卖。比如说有一个标的需要融资5万块钱，在抢购的最后一刻还剩下1万，这个时候如果张三和李四同时看到了，分别投入了1万块钱，你会发现这个标的融资金额变成了6万，多了1万块钱，这1万块钱怎么办呢？这就是超卖。超卖会有张表，有当前剩余金额，用户买完产品以后，会更新当前剩余的金额，设置当前的金额为当前剩余金额减去当前这个人投资的金额，如果判断更新成功，这个时候用户就买成功了。如果更新失败了，用户就买失败了。很显然，并发之后会成为负的，发现了问题以后查了一些资料，发现可以通过悲观锁的机制解决这个问题，试过之后发现悲观锁在没有太多用户的情况下能解决这个问题。那能不能再优化一下，使用数据库的隐式锁，当Update大于等于当前投资金额这就用到了数据库的隐私锁，经过这样三个阶段发现好像没有什么问题了，把这个程序又交给测试后就有了下面这张图，随着并发数的增加，数据库的TPS不断下降，大家有没有想过为什么？数据库在高并发情况下会有很多死锁的检测，抢标过程中，不仅仅要处理库存的问题，还要处理查询操作，还有登录、注册，这些插入的操作，数据库非常的繁忙。
我们怎么去优化？首先我们想到的是能不能让这些查询操作不走数据库了，把一些产品不变的信息、配置信息都放到缓存里面，缓存设两个小时过期，好像看起来很完美。但你有没有发现一个问题？我们系统基本上每天10点、4点、8点这些时间段会是高峰，如果说很多用户同时过来，这个缓存会怎么样？如果恰巧没有赶到两个小时，所有流量就压到数据库里。所以为了提高缓存的命中率写了一些工具，模拟用户真实请求，提前对缓存进行预热，对一些接口进行调用，在真正用户过来的时候，基本上走的都是缓存的数据库，数据库会减轻很多查询压力。
分析抢标购买接口过程中，合同的生成、回款计划表的生成都是非常不核心，不关键的步骤，这些东西要通过消息的方式异步化做，有效减少购买时间。
最后一点把库存写到Redis里面去，它本身有原子加减的命令，让它做擅长的事情。
2、过载
假设这个系统依赖了某一个子系统，中间出了一些问题，比如打开APP，首页可能需要用一到两个子系统，假设由于某种原因不能接受更多响应，怎么保护它？第一个就是服务降级。在服务不能提供响应的时候，我会用它两个小时之前，半个小时之前可用的数据，放在本地，当它不能提供服务的时候，我用本地的Mock数据给前端反馈数据。用户看到Banner是两个小时前数据的也没有关系，他没有感受到系统出了问题。
第二个方法就是熔断，小时候家里面如果用高频率的电流设备时，保险丝会断掉，熔断器就是这样一个原理。当某一个服务不能提供更多请求的时候，出错达到50%时要进入一个熔断模式。熔断以后会有一个返回的过程，通过本地的Mock数据做。保险丝断了以后需要买一个新的装回来，需要人工做。系统的话总不能说断了以后我们自己再接回来，熔断以后能自我恢复，比如说每隔几秒钟，向后端服务发送一些测试流量过去，发现是OK的以后再把熔断器打开。
最后一个是限流，相当于我限制你访问的频率，常见的限流手段可以通过信号量、线程池。信号量是什么概念？调用某个接口，限制最大并发比如说20个，调用之前加1，调用完减1，当我发现当天计数器大于20就拒绝掉。还有线程池，让每个接口单独用一个线程池，通过线程池隔离它。
3、第三方瓶颈
我们系统里面会用到第三方的支付公司服务，比如说用户的充值和提现，对第三方系统会有一些依赖，为了解决这个问题我们也是从系统设计上。流通上来讲，引导用户提前进入充值，这样就不至于说在抢标那一瞬间再重置。抢到标的以后一步是支付，瞬间大家都在支付的话，如果后端只有一家支付公司有可能会被冲垮。我们现在基本上是引导用户，先去充值，把钱充到账户余额里再去购买。假设你的支付渠道就是有问题，怎么办？就只能多接几家支付渠道作为备份，当然也可以基于银行进行路由去分流。
4、作弊
还是有很多人抢不到标怎么办？我们设计了预约功能，让提前预约的人能够买到这个产品。如果买不到的话他会想一些办法，比如在网上搜某某平台的自动投标工具，我们怎么防止这种作弊呢？比如说可以通过验证码，我们发现一个用户如果同一时间多次购买，我们会让他输一个验证码，验证码也增加了复杂度，让字母与字母之间更黏一些，包括字体随机的去换，四五种字体去换，增加破解难度。如果这也不能完全防得住我可以通过IP去限制你，如果同一个IP频繁调用接口，就直接把你加到黑名单，限制你的调用次数。最后如果发现某一个人频繁的扫接口就会把他加入到黑名单，这个时候他的账户会被冻结不能进行任何交易。
五、大型交易的挑战
刚才讲了关于100块钱起投的问题，意味着一个借款人可能会跟多个投资人之间发生关系，就像下面左边的图描绘的一样，一个借款人会有多个投资人给他出资，一笔借款最多的可以达到6000个人给他投资。如果借款人一旦还款了，这个时候我们系统需要处理6000多笔的交易，每笔交易用户都能在账户里面实时看到。假设借一笔钱分为48个月去还，这个时候如果有6000个人给你出资，意味着我要给每个出资人有一个回款计划表，它的数量就是28万8的数量，一个借款的标的就会生成28万8的数据，这个数据可想而知。如果用一张单表怎么去支持它的扩展？这也是一个问题。包括我们这些借贷关系，我们需要对外披露，网贷之家、零壹财经，他们要定期弄数据。
下面以还款来讲，一个借款人对应6000个出资人，我们可能一开始没有考虑到这种场景，一个事务里面把所有6000个人的回款情况，6000笔交易全部做完了，这样数据库负载非常高，后来怎么优化？我们把大数拆很成小数，让还款变相处理，每一个投资人的还款动作放到一个事物里去做，最终处理完以后才算还款成功。假设如果每个事物处理失败了，我们设置了补偿金，他会去重新尝试。刚才讲了回款计划表，一个借款标的会生成28万8的数据量，我们对这张表进行了分表处理，查询的时候，告诉我当时你怎么分片的，我就会再去找回来这个数据。
六、首屏时间
接下来是我们前端的优化，将要讲到我们PC端首屏的时间。很多用户说我们PC端慢，打开首页需要4、5秒的时间才能加载下来整个网页。下图左边是第一版的情况，第一版是是单页的应用，浏览器向服务端发出请求，服务端只是返回了HTML元素，客户端解析后发现需要请求服务端的数据，需要发一个价值流到服务端，服务端再给它数据，随后在客户端进行数据渲染，最后交浏览器去解析，你会发现这个过程中有很多的请求发到服务端。大家知道浏览器会有并发的限制，所以我们后来优化了一个版本，还是回到传统方式，比如说用Java，包括一些服务端渲染的技术，我们这里选择NodeJS去做，客户端向服务端发出请求，服务端直接返回已经组装好的HTML，客户端直接解析就可以了。
下图是我们发现优化过以后的效果，这个数据也是通过听云的工具监测出来的，大家可以看到有很大的性能提升。
七、协议优化
协议优化这里主要想讲一下移动端这一块，下图右边这个表格，它是在按照不同网络类型，上行宽带、下行宽带，还有延迟时间统计的，你会发现两级网络延迟非常长。
移动网络会有什么问题？它在空气中进行传播，比如说有高楼会阻挡这个信号，所以会有很多不稳定性。我们也在尝试研究包括HTTP2.0的东西，我们主要看中了2.0的哪些特点？第一个是二进制格式的传输，传统的HTTP1.0是文本传输格式，2.0可以去扩展。还有一个是请求头的压缩，再回到表格，上行带宽和下行带宽不成正比，上行远远低于下行。假设APP向服务端发送一个请求，这时候会让服务端把你的信息传过去，由于上行带宽比较低，携带了很多多余的东西过去，这会导致传输率非常低，HTTP2有10比1的压缩比，可以大大减低大小。还有一个多路复用，2.0也是跟服务端建立一个链接，但是可以同时向服务端发送多个请求，提高了网络利用率。
八、总结
最后在这里做一下总结，刚才我们说到将大事物进行拆分，分析当前接口，哪些功能是非核心的把它异步化。
还有就是并行处理，当然在做并行处理之前，建议先去优化原来的串行处理，已经优化到不能再优化的时候再想并行处理，因为并行处理远远比串行处理复杂。
我们系统在不断做拆分，也会有一些分布式事务的问题，我们会设计一些补偿机制。拆分多了以后，要求服务力度不能太细，建议一个服务就是做一件事情，在复用性和性能之间做好权衡。
最后非常重要的一点就是监控的可视化，我们去年也在做鹰眼监控，这是给老板看的，老板办公室有一个电视机，他可以从业务去看我们当前有多少人注册，投资的情况，每个人投了多少钱，他都可以一目了然。包括系统层面的慢服务、CPU这些服务都可以做到可视化，包括听云的产品我们也在尝试着用。我今天的分享就到这里，谢谢大家！
APMCon2016 演讲PPT合集下载
链接: http://pan.baidu.com/s/1mhFwaZQ 密码: bezk
分享到微信
分享到微博
