人工智能帮助千万用户完成「隐形征信」计算

「小杨」最近装修房子，准备去银行贷款，但是听说好多人会因为个人征信问题被银行拒绝贷款！于是，他先查了一下自己的央行征信，发现竟然没有自己的征信信息，「小杨」陷入了沉思，自己经常在淘宝、jd 上买东西，也有淘宝花呗和京东白条，怎么会没有征信呢？

其实，还有很多人都像「小杨」一样各项手续备齐了跑去银行贷款，却因为征信问题很不幸地被拒之门外！那么，没有征信信息就没有办法办理贷款了么？

小编打听到，现实中除了央行的征信之外，其实还有很多互联网金融公司可以通过用户日常的网络消费习惯等信息，再通过人工智能进行计算，从而生成一份信用评价。对于「小杨」这类人来说，这无疑是个好消息。

那么问题来了，这些互联网金融公司是如何通过人工智能测算出一个人的隐形征信呢？背后的黑科技到底是什么呢？

今天，小编就带大家走进一家通过微信、手机话费、淘宝或者京东电商账户等第三方信息自动生成信用评价的公司 —— 量化派。

量化派是一家数据驱动的科技金融 Fintech 公司，通过人工智能、大数据机器学习等前沿技术提供消费信贷撮合及消费场景下的白条服务，每年处理*千万级用户信用及信用消费申请*。在 QingCloud Insight 2017「金融云架构与实践」专场中，量化派技术总监周乾，分享了「量化派的云端架构实践」议题，讲述在原有的 IDC 托管服务已经无法满足量化派在基础设施快速扩容、高可用及监控管理等方面的需求时，量化派的解决之道。

流量的入口

先介绍一下量化派的流量大概是怎么接入的？作为一个互联网企业，网站的入口是最为重要的，量化派使用了青云的负载均衡技术，它是一个基于四层网络的负载均衡，自身有非常多的特性，可以方便的搭建企业网站。

量化派是如何使用青云的负载均衡的呢？

第一是加速高层协议，包括七层 HTTP 和 HTTPS 的协议。量化派通过最远端的负载均衡器，先是通过防火墙，一个青松的防护，还有青云提供的 CDN 技术，作为量化派前端的流量平台。通过路由器带领到终端的转发到四层负载均衡器上，四层负载均衡器后面有一层 Nginx 平台，Nginx 平台作为七层的流量服务，就接入到了后面的 Web Server 以及服务器。

为什么这样做？

第一，可以抗高并发。因为许多小企业很难把一个大的流量接入做起来，通过四层的负载均衡器，方便地提升 Nginx Server 的个数，在这里面接入流量还有一个明显的特点，量化派的 Nginx 通过系统 Linux 自带的 rsyslog，通过 UDP 的方式，把日志汇总到目标日志机上，这个目标日志机做了一个类似于流量监听堂路，监听到七层流量堂路后，量化派会监控用户访问的行为，一旦发现有异常的用户，比如说类似爬虫这种，系统就会反馈到七层流量平台上。这个七层流量平台是可以通过 Lua 进行编程的，异常 IP 给封杀掉。

量化派用到的第二个青云的负载均衡器的特性，基于四层做了很多代理，包括消息队列的代理，消息队列集群的代理，包括多个数据库的代理，通过负载均衡器，可以提升后端的数据库以及消息队列的性能，保证并发的数量。

量化派的两朵云

量化派是公有云和私有云混合的。

量化派有若干个网段，第一个种类型的网段是在青云的 VPC 里面，用 256 个机器组成的一个局域网。

第二个，因为量化派是一个基于大数据的互联网金融公司，所以有自己的 HBase 集群，在把 HBase 牵到青云上的时，有一个基本问题，性能问题。为什么呢？青云的硬盘在写的时候是有多重复本，复本加上 HBase 自己设置的复制级个数，类似于当写入一条数据时，如果复制级的个数是 3 的话，在磁盘上就写了 6 次，解决这个问题的根本就是搭建了一个混合云的服务，利用自己的物理机，同时在青云的机房部署服务的机器，把 HBase 迁移过去，让服务器的性能达到我们使用要求。公有云和私有云混合部署的方式，中间通过 GRE 隧道去打通。

量化派的高可用

再说一说量化派的高可用架构方案，首先，因为历史原因，量化派的数据库在自己的 IDC 机房里面，在后来牵到了青云，所以没有用到青云的数据库方案，量化派自己利用 MHA 的架构搭建了一套数据库的集群，做到了高可用。

第二个高可用方案，量化派利用 Zookeeper 一致性的中间件做了高可用方案，它适用的场景是什么呢？因为量化派有很多微服务，这些微服务之间每个可能都有定时任务。定时任务中心会去 Zookeeper 里选取一个主节点，这个主节点会通知各个业务系统，在合适的时间做合适的任务。另外，量化派的 RPC 也是用 Zookeeper 构建起来的，RPC 可以做到各个微服务之间的协调，上线和下线做到非常完备。

第三个高可用技术是 Keepalived，利用的虚拟冗余路由协议，伪造了一个虚 IP，这个场景用到什么情况下呢？Keepalived 在数据库里面，当我们在做 double master 一个架构的时候，其实可以用 Keepalived 让一个数据库一直在线上服务，当他的数据库挂掉，可以迅速切换到第二个服务器上去。在用 MHA 的时候，也用到 Keepalived，MHA 架构只有一个单主机数据库，这个单主机数据库，线上应用一直连到这个数据库，当这个主数据库挂掉，MHA会自动重启另外一个数据库，让从库选取一个新的主，从库就开启一个 Keepalived 结点，线上应用完全可以做到对数据库的切换没有感知。

第四个高可用技术，是 Redis 里面用到 Sentinel Master Slave 这样一种结构， Redis 会去启用一堆监听结点，它会去监控每一个 Redis 结点的存活，当有 Redis 主挂掉的时候，这些监听结点可以选取出一个新的 Redis。

第五个高可用的技术架构是 Hazelcast，它是基于 UDP 广播的形式去做一个服务的发现，目前在 Java 里面很多框架已经有 Hazelcast 的案例了。利用这些高可用的技术架构，就可以保证量化派的服务是稳定可靠的。

量化派的公有云和私有云之间是跨网段的，他们之间会有通信，经常需要大流量的数据传输，我们怎么保证公有云和私有云之间，或与外部的流量接入有序，保证服务是稳定的？

限流以及数据控制

首先我们用到了一些限流技术，主要的限流技术包括哪些呢？第一个我们会利用消息队列缓存消息，避免网络拥塞。举一个典型的例子，量化派有 6 亿的用户数据，这 6 亿的数据构成了一个网络，这些数据是在私有云里面，如果分别将三百个结点的数据库，做成一个用户联系人网络，一定会涉及到数据传输。数据传输，如果在两个服务之间直接调用的话，线上的带宽会都被占满，利用消息队列把数据缓存出来，做了一个限流的传输。在此过程中，消息队列在大量数据情况下，也会有被压崩溃的可能，所有需要用到更多的限流技术，包括利用 amqp API 控制发送速率。

另外在量化派的生产端和服务端，分别用了一些限流的技术，包括利用谷歌的 guava ratelimiter 控制发送和消费的速率。还有包括利用 Nginx 限流插件控制消费速率，这个也可以保证服务器接收到的流量是比较稳定的。最后用到的限流和服务降级是 hystrix，在微服务之间如果调用过量，它可以做到降级以及限制流量的大小。

量化派是一个由很多微服务组成的大型系统，这个系统里面有一个典型的问题，量化派对接了多家的流量，有时对接这些流量的 API 需要知道后台的贷款状态，那怎样让这些公司知道贷款状态呢？这里涉及到一种典型的事件解耦技术，首先业务端不需要知道贷款的变化，当用户在平台贷款发生变化时，数据库会自动增长。

量化派开发了一套基于 canal 的程序，它伪装成数据库的从库，去订阅这个数据库的 binlog，订阅到 binlog 之后，解析到数据库定单的状态发生变更，紧接着就把它发送到队列里，这个队列就会把它广播到各个业务系统，做到典型的业务和业务之间的解耦。那么消费到这个定单状态变更的服务，接着就可以把定单的状态变化发送给第三方公司了。

多角度监控

说说量化派多角度监控，首先收集日志，从数据库里面收集监控的状态，因为这样对系统的负载以及复杂度都会有提升。业务系统会产生日志，通过 File beat 这样一个中间件，把日志的数据送到 Kafka 的集群里去，接着在另外一个集群里，有一堆日志解析器，他们去监听 Kafka 集群，把数据收集出来之后，通过相对平稳的速率，把日志放在搜索引擎中，这个搜索引擎里基本上有一些被检索的数据，开发人员需要在日志里去埋点。

一个典型的例子，比如风控，有些用户的定单会按照一些规则通过，有些回按照一些规则把它拒绝，如果想看每时每刻的通过率和规则情况，开发人员通过 Falcon 这个系统，定时的检索搜索引擎，把关键的字段作为检索项拿出来去和另外的数据进行对比，再产生报表，这个报表里面设定一些监控的准则，把这个监控给做起来。下图是量化派一个典型的监控样例，刚刚讲的是一个业务数据的监控。

说一下量化派并发思想，量化派的自动化部署和编译系统，用的是典型的 Fork join 模型，在线上把代码给编译起来，之后会通过自研的一套平台，去各个机器上拷贝包和部署。这中间其实有一个 Fork join 过程，假如你有一百台机器，基本上会并发上线前 50 台机器，再并发的上线后 50 台机器。

第二个并发思想大量的用到了池化技术，量化派的各服务之间大多没有暴露接口，暴露的是 SDK，比如消息中心，消息中心接了非常多的短信，他们之间通过消息队列去发送消息，消息队列的连接用的池化技术进行包装。还有大量的利用了并行功能，有时候用户下一单，如果希望用户能快速的看到结果，这样用户会去过一下规则引擎，这个规则引擎中间又有模型，又有各种各样的数据，这个数据要做到实时响应就一定要用到并行计算，里面用到的 Java 8 的 Parallel Stream，它会把提取数据的任务首先去塞到 list 里，塞到数组里面去，然后并行地把数据获取出来，这里面关键的思想就是找到数据之间的依赖项，把不依赖的任务尽量的并行化。其次，量化派还利用了异步 IO 技术增加吞吐量。

另外，提升并发的技术是利用消息队列分解我们大事务，量化派会将一些事务送到不同的服务上去执行，这个执行是通过消息队列去完成的，前端直接返回一些伪造的数据。还有一些技术，包括一个单进程里面，希望用户能够尽快的得到响应，有一些事务在单进程里面自己慢慢的消化掉，这里用到了 Spring event，异步内部化的一些事务。

两段历史说安全

安全方面，量化派用的机器是堡垒机，量化派走了两段历史：

第一个是改造一个开源的堡垒机系统，系统中用户的登录、统计、审计等都可以看到。

第二个数据库审计。青云现在已经有了数据库审计，当年我们用青云的时候还没有，所以我们自己改造了一套数据库审计。其基本的原理就是，我们会做一个客户端，这个客户端提供给大家访问，我们解析这个 MySQL 的协议，最后会把谁执行了什么语句，在什么 IP 上，都会进行日志留痕。

对于 B 端的接口，量化派自研了一个安全层，其目的是什么呢？大家去对接第三方接口的时候一直有各种各样的加密标准，并且很多时候研发会把精力集中到安全的标准上面去，这个加密本身也是挺困难的一件事。量化派是怎么做的呢？做了一个七层的代理，这个代理带有安全功能，并且对外分发公钥，去交换公钥。B 端系统通过接入我们安全层，就可以由 B 端自己实现安全，B 端接口数据加密通过安全层把它过滤成一个明文数据，反过来代理到量化派的系统上，这样整个加密规范，最终就是一模一样的。

对安全的考虑，包括一些关键的接口上采用动态密码，避免回放攻击，采用 HTTPS 进行通信，避免劫持以及中间人攻击，另外还采用 orm，利用 pojo 访问数据库，杜绝 SQL 注入等手段。

架构拆分

量化派的架构拆分，服务治理就是利用通信中间件做到的，包括异步的话 MJQ 集群去做通信治理，RPC 调用的话，会用一些 RPC 的技术进行通信。各个服务之间有一个基本的问题就是，用户的状态怎么去考虑？大家都知道，一个用户登录了系统，紧接着跳到支付中心去，支付中心怎么知道这个人是谁？因为是一个异构的系统。量化派中间有两种不同的通过方式，包括服务之间的 Session，以及通过用户系统直接访问 Token 去做安全校验。

「加速助力」AppCenter 2.0 提供包括计费、支付、财务报表、监控告警、工单系统、用户管理等一系列运营管理功能，为合作伙伴提供完善的商业运营支持。借助 AppCenter 2.0 平台，合作伙伴可以直接拥有云计算平台所需各类功能模块，快速便捷地开启商业运营之路。

青云QingCloud AppCenter 是一个生态平台，欢迎更多其它企业服务应用入驻 AppCenter，一起为 QingCloud 逾 8** **万家用户提供优质服务。申请加入：

https://appcenter.qingcloud.com/partnership/index.html

AppCenter 激励计划

一、面向合作伙伴

AppCenter 认证应用服务商奖励计划

应用服务商在 AppCenter 发布应用经 QingCloud 认证后，可获得的奖励额度为 QingCloud 用户通过部署该应用所带来的资源（仅含主机和硬盘）消费的* 10%。*

“平步青云” AppCenter 伙伴计划

企业服务方向的创业项目，经 QingCloud 认证审核后，可获得 2 万元的云服务资源赞助，同时应用可以入驻 AppCenter。了解更多：

https://www.qingcloud.com/promotion/startups

二、面向用户 —— AppCenter 资源优惠计划

公有云用户通过 AppCenter 应用所使用的主机和硬盘资源可享受 10% 的优惠。