量化派是一家互联网金融公司，有三条业务线：第一是现金贷，撮合用户跟机构交易，目前拥有千万级的用户量，对系统访问量很大；第二是消费分期，可以分线上和线下，就像美容医疗场景下，量化派给用户提供虚拟额度，用户拿额度到场景里面消费，会被扣用户额度，让用户产生分期；第三是自建场景消费，量化派自建了商城。三种业务场景都由数据驱动，审核和风控都不需要人工。

从企业初创到C轮融资，量化派业务发展很快，其IT架构也经历了由简到繁的过程。仅以现金贷业务为例，用户信息需要经过主逻辑业务进入风控平台，再经过数据筛选决定用户等级。单这个系统就经过了单点服务、集群化服务、负载均衡、ELK集群、微服务等多个架构的演进。当服务呈现爆炸式增长时，很多问题都暴露出来了。

一方面，随着业务量不断增长，量化派对于IT的需求越来越高，实际情况却是原有硬件不能快速扩容，无法支撑起如此高速的发展。以前，量化派在机房都是租机架，主机容量有上限，部署新的机器相当繁琐。由于使用IDC基础架构，一旦原有合作伙伴不再合作，部署新的IDC带来的专线难以打通的问题也困扰着量化派。另一方面，量化派原有的自建高可用方案不能支撑业务持续发展，一旦硬件出现问题，可能会导致数据永久丢失。而对于一家互联网金融企业，数据是核心竞争力，重要性不言而喻。当然，由于业务本身复杂度高，现有IT监控系统也早已不能有效发现系统中存在的问题了。量化派的业务发展对企业的IT提出了全新的要求。

正是由于上面的这些挑战，量化派技术总监周乾经过考察对比，决定将服务从原有的IDC搬到青云QingCloud，打造一个公有云和私有云结合的混合架构。这个工作做起来并没有想象中那么简单，由于涉及到上百台虚拟机，以及十几个数据库规模的微服务，其中需要考虑到的突发情况也不少。

众所周知，迁移MySQL，如果中间走公网，容易出现闪断，因闪断造成数据丢失是量化派不愿意看到的。为了避免这种情况，量化派使用了Canal中间件，把数据扔到MySQL里，MySQL自带的存储特性，直接将数据复制给了异地机房数据库，这个时候便不用担心某个用户借款丢失的情况发生。

对于缓存数据，量化派缓存用的是Redis，用Redis-port工具向Redis Master发送sync，接受RDB文件，再回放RDB文件，复制便能完成。

而对于迁移过程中遇到DNS缓存问题，量化派和青云QingCloud一起找到了两个解决办法。第一个是通过变更域名，这个时候原有DNS缓存会失效，便自然会去访问新的。另一个是不变更域名，这时候就会有大量流量通过互联网访问到老的IDC上，这与他们的初衷是相违背的。这种情况下，量化派将原有IDC的负载均衡器上的服务指向青云QingCloud上的Server，缓存问题迎刃而解。

迁移上百台虚拟机如果纯靠手动完成，工作量太大。为此，量化派自建了自动化发布环境。为了轻量化运维，量化派自己开发了xypb-deploy项目，构建在paramiko库上，直接连到ssh。这个自建项目采用Python Nginx-parser，可以灵活切换流量。

周乾指出青云QingCloud所提供的负载均衡器功能，代理了四层流量。为了增加查询效率，通过负载均衡器代理到存库上，给用户提供连到数据库的机会。再通过很多数据库负载用户查询的流量，以达到效率提高的目的。

对于安全的话题，周乾详解了量化派在青云QingCloud上实现安全的路径。量化派服务采用前后端分离，没有后端渲染，基本上所有开发都是Java，最后部署起来也是單独架包，不存在JSP或PHP等解释执行的脚本；第二采用orm，利用pojo访问数据库，杜绝SQL注入；第三采用https进行通信。而具体到防止内部人员泄密问题，量化派自己开发了一套配置中心，把关键配置放到配置中心，服务每次上线的时候从配置中心去调取关键参数，这些参数在传输过程中都是通过非对称加密进行的。