2015 年 1 月 24 日，又拍云 Open Talk 第二期沙龙《移动时代互联网金融的架构趋势》，邀请到挖财首席架构师王福强、51信用卡 CTO 殷鹏翔、同盾科技技术总监张新波，用崭新的眼光和智慧，带领 120 名开发者一窥移动互联网金融背后的架构趋势，在金融行业洗牌的此时此地极具参考价值。同盾科技联合创始人&技术总监张新波在活动上作了题为《从零打造千万级的实时风控云服务》的演讲，以下是分享实录：
同盾科技，是由阿里、Paypal 反欺诈专家创建的，国内第一家风险控制与反欺诈云服务提供商，其涉及领域包括电商、B2B、互联网金融、游戏等。同盾技术总监张新波在又拍云 Open Talk 第二期《移动时代互联网金融的架构趋势》中阐述了同盾是如何从零开始打造千万级实时风控云服务，具体介绍了同盾系统平台构建过程中主要需要解决的三大难题，以及解决这些问题的具体时实践过程。
同盾的后台系统是一套非常强大的，规则灵活配置的管理系统，搭建这个平台同盾主要面临了以下几个难点：
1、性能
同盾提供的云服务需要直接嵌入到用户的业务流程中，比如说登录，客户的网站接受用户的登录请求后，客户调用同盾提供的的服务，等我们的服务做出响应后再决定下一步行为。通常情况下，客户给我们的时间是500毫秒左右，除掉网络开销，基本上我们必须在200毫秒内做完所有的数据分析计算，给客户响应。同时每次调用都需实时计算，且参与计算的数据量非常庞大，会涉及大量的指标运算。如何在短时间内完成计算，对整个系统来说是一个较大的挑战。
2、可用性
和其他云服务商一样，我们提供7×24小时的服务，如果系统挂了，对客户的系统会造成比较大的影响，如果某台服务器挂掉，导致服务不可用或不稳定，这种情况客户也是不可接受的。是否有完善的灾备和紧急备选方案，保证在各种异常情况下，整个系统都可持续使用，这是另一个难点。
3、可扩展性
同盾是为企业提供服务，很多大的客户接进来数据量可能是上百万的流量，随着客户的增多，对系统要求的处理能力会越来越大，所以我们整个系统架构设计要求具备随时可进行线性扩展的能力，比如说现在能够处理500万，流量增加一倍的话，能够通过简单的加机器可以把处理能力提升到1000万，这也是一个难点。
系统搭建前期工作
这是jiao开始我们的系统架构。我们做的一些对用户的管理，jiao主要的是策略配置，比如说我们在针对借贷风险场景做一系列的规则配置，这些配置会直接写到数据库里面。我们提供的API，可以加载一些客户自己定的策略，用户请求的时候可以通过执行策略和规则，得到风险评估的结果。
具体流程见上图，可以看到，这里所有的流程几乎都需要直接和 mysql 交互，导致 mysql 压力非常大，系统性能一直很差。针对这个问题我们做了两方面的改进。
首先是读优化，通过使用 Guava Cache，对用户校验和查找策略做了缓存处理，并在系统启动时预先加载全部用户数据和策略数据，并通过定时刷新缓存，保证请求基本不需要访问 mysql，全部在内存中进行计算。
然后是写优化，应用写数据时并不直接操作 mysql，而是通过本地任务队列异步保存数据。这里我们使用的本地队列是Berkeley DB。Berkeley DB 是一个内存数据库。我们用它主要考虑到Berkeley DB 支持持久化，以及本身处理性能高。如果我们写入的数据，消费端没有及时刷新数据库，或者写到其他地方处理完毕，数据将会堆积，如果全放在内存里，会把内存撑爆。Berkeley DB 的持久化性能，刚好可以解决这个问题。
在完成这两项优化后，系统性能已经有了很大提升，但在性能上还是不能满足我们的要求，后面加上了 memcached 的缓存，将数据通过 base64 加 Gzip 进行压缩后存到 memcached 当中，请求进来后，执行策略需要做指标计算时，可以很快从cache中取到数据，减少与 MySQL 的交互。因为热点数据比较少，为了提高缓存利用率我们将数据的过期时间从一天提升到一周，这样大部分都可以命中缓存，无需再用 MySQL 读取，对性能有较大提升。
系统前期处理好后，还存在很多单点问题，为了保证整个系统的可用性，得将所有的单点问题消灭掉，首先做了MySQL主备，主机宕机之后用 Keeplived 自动切换到备机。另外Memcached 也是单点，有些应用出现问题会导致系统无法效应，为了消除单点故障，做了Memcached 集群。
在这个过程中还进行了其他优化，主要包括：
MySQL服务器硬盘从 SAS RAID5 升级到 SSDRAID10，保证较快的读写速度。
数据库从 MySQL 5.1 系统升级到 MySQL 5.6，以及对参数进行优化。
客户数据记录单表更改为按客户分表，提升读写性能和防止表过度膨胀。
Apache 改成了 NGINX，利用它的动态修改upstream server的组件，在发布时将机器自动摘除，发布完成之后再加入到处理集群中，避免系统性能抖动问题。
另外利用好各种 JVM 工具，如 jstat、jstack、MAT以及BTrace可以方便地进行JVM的问题排查和优化。
灾备和应急方案
应用放在一个地方的话，总是会遇到各种各样的一些问题，所以，为了保障服务的稳定性，我们在阿里云上部署了一套简化版的服务，如果在主机房不能正常提供服务，还有jiao基本的应急方案。
关于应急方案，我们在jiao前端 Nginx 的 lua 脚本中添加全局开关，如果某个后台应用出现问题，可以立即通过全局开关禁用，以免因为某个服务异常而导致整体响应时间过长。同时也可以针对特定用户设定开关，如果某个用户访问有异常，也可以通过开关直接关掉。通过后台界面和定制脚本，在出现紧急情况时，可以做到一两分钟之内切快速切换开关。
监控报警
为了保障实时了解整个系统线上运行情况，需要一个完善的监控系统。同盾选择了 Zabbix。
Zabbix本身就有很完备的监控体系，并且还支持很多插件，可以较方便的搭建一套完整的监控报警系统。
Zabbix主要从几个基本层面来完善监控报警。硬件层面，通过 Load、Memory、Disk、IO 等来判断。应用层面，每个应用都有一个默认接口，在 Zabbix 上调用，看应用是否正常返回来检测。JVM 层面，通过 Heap 使用情况、GC情况来监控。其他，可以通过 Memecached、Nginx、MySQL 的专有插件，来监控专门的应用，比如 Nginx的 QPS，Memcached 的命中率等。
Zabbix对内部的监控还是很强力的，但外部的，诸如 IP，Zabbix 监控不到。因此在Zabbix的基础上搭配了360 的云监控，对 DNS、公网IP 等所有暴露在外部的接口都监控起来。
在完成上面的优化后，承载线上百万级的容量没有太大的问题。但随着业务量的增加，我们首先面临的jiao大问题是存储的问题，因为 MySQL 存储有限，在数据增长过快的情况下，分库分表已经不能很好的解决问题，所以我们又对系统架构做了一次调整：
通过引入 Cassandra 来实现自动水平扩展，整个系统承载能力又得到了一次提升。
jiao后，从同盾这一年来的经验来说，尽量在选用一些熟悉、成熟和社区活跃的开源技术，在创业初期，以解决业务问题为主，先满足业务需求再做优化。作为第三方云服务商，需要监控报警和应急预案放在非常重要的位置，如果出现问题能做出尽快相应。系统的演变迭代是一起复杂的过程，且会遇到很多问题，要搭建真正的能承载大数据访问的系统，还需多实践，在这个过程中不断进行优化。
