UPYUN Open Talk ：同盾，从零打造千万级实时风控云服务

摘要：同盾技术总监张新波在第二期移动时代互联网金融的架构趋势中阐述了同盾是如何从零开始打造千万级实时风控云服务，具体介绍了同盾系统平台构建过程中主要需要解决的三大难题，以及解决这些问题的具体时实践过程。

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

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

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

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

系统搭建前期工作

这是最开始我们的系统架构。我们做的一些对用户的管理，最主要的是策略配置，比如说我们在针对借贷风险场景做一系列的规则配置，这些配置会直接写到数据库里面。我们提供的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 升级到 SSD RAID10，保证较快的读写速度。
数据库从 MySQL 5.1 系统升级到 MySQL 5.6，以及对参数进行优化 。
客户数据记录单表更改为 按客户分表 ，提升读写性能和防止表过度膨胀。
Apache 改成了 NGINX，利用它的动态修改upstream server的组件，在发布时将机器自动摘除，发布完成之后再加入到处理集群中，避免系统性能抖动问题。
另外利用好各种 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 来实现自动水平扩展，整个系统承载能力又得到了一次提升。

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

UPYUN Open Talk是 UPYUN 发起主办的行业技术沙龙，旨在以邀请各行各业优秀的企业技术负责人分享介绍自己工作过程中的技术架构经验的方式，推动整个移动互联网时代的企业员工的个人技术成长，从“人”这个关键点的个人成长提升去帮助推动企业的快速成长。