业务介绍
随着现金贷业务的如火如荼，各地的现金贷业务平台也如雨后春笋般的冒了出来，现金贷业务开张也简单找一家现金贷平台提供方，再买一个风控产品（如同盾等），找到一个不错的资金渠道，就可以开张了；但平台建起来后如何寻找合适的客户是个问题，于是市场上对于现金贷平台的客户导流形成了又演化了一个次级产品“现金贷超市”。
现金贷超市产品是利用各种渠道的流量，将目标用户引入至自己的产品超市客户端，公众号，客户端（公众号）内页面以下图一中的列表形式展示了大量的现金贷平台产品，对目标用户与现金贷平台进行信息撮合；这样一款产品看起来应该没什么难度？
下一章节对业务初期的架构及后续运营发生的问题做一系列的说明，方便大家了解业务，也便于后来的同学踩坑
初期产品架构
项目初期整个系统架构比较简单，在不同的流量渠道发布不同的安卓包，对于不同的渠道展示的产品内容，顺序也是有所区分的；因此平台提供了一个基本的管理系统用于日常的客户版本，下载地址管理；
在项目初期由于流量引入的乏力，刚开始一天不到200个下载，平台未见任何压力，运转也较正常；
随着流量的引入，老用户的活跃，客户端版本升级等平台开始陆续出现部分时段用户访问慢，服务器负载较高，间接的影响了平台产品运营，造成营收损失；
平台架构第一次调整
随着服务器压力越来越大，我们考虑把一部分前端静态化，文件下载等服务从原来的WEB服务迁移出去，同时增加代理服务器入口带宽；服务器压力暂减，平台恢复正常；
需要强调的是代理服务器、接口服务必须使用内网；（这块由于配置错误，导致流量上升时，两台服务器同时网卡被打满，互相牵扯）
但不到一周我们又遇到了更大的问题；
平台架构第二次调整
网络架构调整不到一周后，平台出现历史上最重大的一次事故，导致业务中断6个小时；事情的起因源于我们的短信验证码接口被黑，任意下行的验证码导致用户投诉使我们的验证码通道当天被封，用户无法正常注册使用产品。恶意的下发也直接导致短信平台账户余额几乎被耗尽。
相关的背景不细说，且说说从平台上我们做了哪些改进。
1、短信通道采用多通道，下发时按权重进行路由，单价低一点的多发点，遇到问题时由平台的短信模块自动更换通道下行；保证验证码短信到达；
2、检查了下这次攻击手段，其采用的是CC攻击；针对这块由于整理攻击量不大，原打算采购阿里阿里的安全策略，但其技术专员给的意见是平台安全策略不一定能防的住；所以我们自己构建了防御体系：
1、Nginx 采用了NginxHttpLimitZoneModule，对于同一IP多次请求的直接拒绝请求；示例如下：
http {
limit_req_zone $binary_remote_addr zone=my_req_zone:10m rate=1r/s;
...
server {
...
location /somedir/ {
limit_req_zone zone= my_req_zone burst=2;
}
2、同一IP单天如果请求频次达到500，则直接使用centos 的IPTABLES禁止其访问；
3、同一号码单天只允许5次。
注：很多人可能会建议说短信验证码的获取可以增加图形验证码；但输入验证码的校验会增加用户交互的步骤，影响转化，我们做过一个测算，如果去掉图形验证码，渠道的用户转化会提升10%左右。
随着产品运营时间增加，流量引入越来越大，服务器又出现了响应慢，影响转化的现象；很快我们又做了第三次调整；
架构第三次调整
随着产品运营的深入对于公众号用户的模板消息推送，短信渠道的营销等引发了平台流量在某个时间点突然上升，对于这种流量在于一个点上的突然上升给我们的系统造成了很大压力，特别是流量方面入口的服务器带宽经常被打满，虽说整个平台基于阿里云，可以通过临时增加带宽解决，但购买大的带宽即浪费费用，而且在流量上升后服务器的负载也会突然上升，每次有大流量时，服务器总会响应特别满，影响流量转化；
针对这种情况我们又对架构做了一次调整；策略如下：
1、彻底将文件下载单独部署服务器，并购买了阿里的CDN缓存；由于渠道包比较多，有时候缓存也会打打串，但后来发现其比重不在，我们把下载服务的带宽就保持在了20M；运营至今没出什么问题；
2、对于接口服务，我们采购了一批轻量的阿里去服务，部署了一堆应用服务器，并且在Nginx上做了软负载策略；（当时考虑如果代理服务也需要保障，就往域名上做。）
3、对于应用端的热点数据我们做了缓存策略，保证对于热点渠道的应用、页面数据全部从缓存经过，这样一来可以降低我们的数据库压力；
总结
由于行业特殊性，整个产品运营周期不长，大概也就几个月，有很多地方还有进一步的优化空间，但在产品初期公司投入不大，所以架构的演进很多时候也是边打边升级；我觉得这次的产品对于很多互联产品，或者小企业来说是有一定的借鉴意义，所以码出来供大家参考；