同盾技术总监张新波：从零打造千万级实时风控云服务的秘籍

盾科技，是由阿里、Paypal反欺诈专家创建的，国内第一家风险控制与反欺诈云服务提供商，其涉及领域包括电商、B2B、互联网金融、游戏等。同盾技术总监张新波在UPYUNOpenTalk第二期“移动时代互联网金融的架构趋势”中阐述了同盾是如何从零开始打造千万级实时风控云服务，具体介绍了同盾系统平台构建过程中主要需要解决的三大难题，以及解决这些问题的具体时实践过程。

同盾的后台系统是一套非常强大的，规则灵活配置的管理系统，搭建这个平台同盾主要面临了以下几个难点：

1. 性能

同盾提供的云服务需要直接嵌入到用户的业务流程中，比如说登录，客户的网站接受用户的登录请求后，客户调用同盾提供的的服务，等我们的服务做出响应后再决定下一步行为。通常情况下，客户给我们的时间是500毫秒左右，除掉网络开销，基本上我们必须在200毫秒内做完所有的数据分析计算，给客户响应。同时每次调用都需实时计算，且参与计算的数据量非常庞大，会涉及大量的指标运算。如何在短时间内完成计算，对整个系统来说是一个较大的挑战。

2. 可用性

和其他云服务商一样，我们提供7×24小时的服务，如果系统挂了，对客户的系统会造成比较大的影响，如果某台服务器挂掉，导致服务不可用或不稳定，这种情况客户也是不可接受的。是否有完善的灾备和紧急备选方案，保证在各种异常情况下，整个系统都可持续使用，这是另一个难点。

3. 可扩展性

同盾是为企业提供服务，很多大的客户接进来数据量可能是上百万的流量，随着客户的增多，对系统要求的处理能力会越来越大，所以我们整个系统架构设计要求具备随时可进行线性扩展的能力，比如说现在能够处理500万，流量增加一倍的话，能够通过简单的加机器可以把处理能力提升到1000万，这也是一个难点。

系统搭建前期工作

这是最开始我们的系统架构。我们做的一些对用户的管理，最主要的是策略配置，比如说我们在针对借贷风险场景做一系列的规则配置，这些配置会直接写到数据库里面。我们提供的API，可以加载一些客户自己定的策略，用户请求的时候可以通过执行策略和规则，得到风险评估的结果。

具体流程见上图，可以看到，这里所有的流程几乎都需要直接和 MySQL 交互，导致MySQL 压力非常大，系统性能一直很差。针对这个问题我们做了两方面的改进。

首先是读优化，通过使用GuavaCache，对用户校验和查找策略做了缓存处理，并在系统启动时预先加载全部用户数据和策略数据，并通过定时刷新缓存，保证请求基本不需要访问mysql，全部在内存中进行计算。

然后是写优化，应用写数据时并不直接操作mysql，而是通过本地任务队列异步保存数据。这里我们使用的本地队列是BerkeleyDB。BerkeleyDB是一个内存数据库。我们用它主要考虑到BerkeleyDB支持持久化，以及本身处理性能高。如果我们写入的数据，消费端没有及时刷新数据库，或者写到其他地方处理完毕，数据将会堆积，如果全放在内存里，会把内存撑爆。BerkeleyDB的持久化性能，刚好可以解决这个问题。

在完成这两项优化后，系统性能已经有了很大提升，但在性能上还是不能满足我们的要求，后面加上了memcached的缓存，将数据通过base64加Gzip进行压缩后存到memcached当中，请求进来后，执行策略需要做指标计算时，可以很快从cache中取到数据，减少与MySQL的交互。因为热点数据比较少，为了提高缓存利用率我们将数据的过期时间从一天提升到一周，这样大部分都可以命中缓存，无需再用MySQL读取，对性能有较大提升。

系统前期处理好后，还存在很多单点问题，为了保证整个系统的可用性，得将所有的单点问题消灭掉，首先做了MySQL主备，主机宕机之后用Keeplived自动切换到备机。另外Memcached也是单点，有些应用出现问题会导致系统无法效应，为了消除单点故障，做了Memcached集群。

在这个过程中还进行了其他优化，主要包括：

• MySQL服务器硬盘从SASRAID5升级到SSDRAID10，保证较快的读写速度。
• 数据库从MySQL5.1系统升级到MySQL5.6，以及对参数进行优化。
• 客户数据记录单表更改为按客户分表，提升读写性能和防止表过度膨胀。
• Apache改成了NGINX，利用它的动态修改upstreamserver的组件，在发布时将机器自动摘除，发布完成之后再加入到处理集群中，避免系统性能抖动问题。
• 另外利用好各种JVM工具，如jstat、jstack、MAT以及BTrace可以方便地进行JVM的问题排查和优化。

灾备和应急方案

应用放在一个地方的话，总是会遇到各种各样的一些问题，所以，为了保障服务的稳定性，我们在阿里云上部署了一套简化版的服务，如果在主机房不能正常提供服务，还有最基本的应急方案。

关于应急方案，我们在最前端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等所有暴露在外部的接口都监控起来。

在完成上面的优化后，承载线上百万级的容量没有太大的问题。但随着业务量的增加，我们首先面临的最大问题是存储的问题，因为MySQL存储有限，在数据增长过快的情况下，分库分表已经不能很好的解决问题，所以我们又对系统架构做了一次调整：

通过引入Cassandra来实现自动水平扩展，整个系统承载能力又得到了一次提升。

最后，从同盾这一年来的经验来说，尽量在选用一些熟悉、成熟和社区活跃的开源技术，在创业初期，以解决业务问题为主，先满足业务需求再做优化。作为第三方云服务商，需要监控报警和应急预案放在非常重要的位置，如果出现问题能做出最快相应。系统的演变迭代是一起复杂的过程，且会遇到很多问题，要搭建真正的能承载大数据访问的系统，还需多实践，在这个过程中不断进行优化。