金融上云，这是时下一个非常热门的话题。目前，金融行业主要由传统金融行业和互联网金融组成，这是两类并不相同的用户群体。二者无论是在业务特色、IT 沉淀，还是具体需求上，都有着很大的差别。进而在云计算部署方面需要考虑的问题也不一样。
前段时间在 InfoQ 主办的 QCon 北京 2017 活动中，青云 QingCloud 举办了一场金融云专场，邀请了来自传统金融行业和互联网金融的用户代表，为现场的参会者展现了不同金融用户云计算部署的实践与思考。InfoQ 编辑将其中精彩内容做了整理，希望给更多人提供参考和借鉴。
作为一家互联网金融公司，量化派的主营业务包括现金贷、消费分期、场景消费三种。三种业务场景都由数据驱动，审核和风控都不需要人工。
从企业初创到 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 进行通信。
而具体到防止内部人员泄密问题，量化派自己开发了一套配置中心，把关键配置放到配置中心，服务每次上线的时候从配置中心去调取关键参数，这些参数在传输过程中都是通过非对称加密进行的。
阳光信保是我国首家市场化运营的专业信用保证保险公司。得益于互联网保险的发展，阳光信保近几年业务发展非常飞快，随之而来的是 IT 系统面临的多重压力：潮涌式高并发的压力、资源扩展压力、网络防攻击压力以及快速迭代压力等等。
阳光信保最初考察公有云提供商时，私有云能力是一个重要的考量依据，正是因为这个需求，阳光信保毫不犹豫地选择了青云 QingCloud。
对于阳光信保来说，将 All in one 架构迁移到云计算平台上是一个极大的难题。阳光信保需要将数据库、应用服务器中间件做迁移，数据库要从原本的 Oracle 转向 MySQL。在一个比较典型的部署架构中，阳光信保把中间件做了替换，负载均衡器使用了青云 QingCloud 云平台提供的 Loadbalancer 和 Loadbalancer Cluster 服务，结合 QingStor 对象存储，Redis Cluster 缓存集群和标准 MySQL 数据库三类资源服务。
具体到服务化架构时，需要分层设计，无论是接入层、业务层，还是持久化层，每一层都要分好，并且每一层之间都要相对隔离。服务拆分以后，系统过于分散的问题出现了，这对运营管理是一个考验。架构如何拆分的关键是如何实现对业务更好的支持。阳光信保在做云上微服务部署时，已经把各种服务做了拆分，前面有注册中心、配置管理、加密处理 key，把数据库放在了私有云上。
据阳光信保信息技术部李继斌介绍，云计算在保险行业的应用场景除了作为服务器、基础架构外，还有灾备、大数据分析、云服务平台更好支撑业务应用等多种应用场景。
以云服务平台对业务的支撑来看，最大的便利性就是效率的提升。阳光信保现在增加的服务都是秒级的，应用部署也完全可以复制过来。目前，阳光信保把开发、测试包括生产系统全都部署在了云端，工作效率提升明显，也更容易实现自动化运维。
徽商银行：基于青云 QingCloud 构建混合云 徽商银行是全国首家由城市商业银行与城市信用社联合重组设立的区域性股份制银行。与互联网金融用户不同，徽商银行属于传统金融行业，他们对于云计算的需求自然也不同于互联网金融。
早在 2014，徽商银行便开始全面调研云计算、云管理。徽商银行系统开发部傅伟表示，银行业所关注的重点跟其他很多行业不太相同。银行业更关注数据层的安全，服务层的响应以及成本的控制，因此他们更多考虑如何从这三个方面解决开发环境和运营环境的问题。
正因为这种不同于一般行业的关注点，徽商银行整个开发团队为建设云平台制定出了“三层”建设的计划：第一层先做基础环境的改造；第二层就是将一些基础环境改造完成后的统计管理、检查、审计功能进行云化处理，包括对一些相关应用进行云化；最后一层便是把应用进行模块化，向 SaaS 层转移。
在做测试和开发过程当中，徽商银行开发团队发现业务的发展速度已经远远高于资源部署的速度，挑战之巨大不言而喻。2014 年时整个开发测试环境有 200 多个资源，等到 2016 年年底便发展成为 2000 多个。换言之，业务需求从 2014 年的每年大概 70 个左右，到目前为止已经过了 400 个。这样一个量级上的变化，对于部署资源、响应资源都是一个挑战。经过几年建设，徽商银行在开发环境中率先实现“四朵云”技术。
在选择云供应商的时候，徽商银行比较看重网络安全隔离技术，青云的网络隔离功能可以很方便的实现在大的群体里面实现逻辑化的两个测试区，这样做可以保证测试的数据相对独立完整，并且互相隔离，没有版权影响。
另外，青云 QingCloud 的自动伸缩功能也很有特色。据傅伟介绍，青云 QingCloud 有这样一个技术，允许一台机器在一段时间内根据访问量大小自动复制出一台机器，一并响应所有应用，可以增加对应用的承载能力，系统也可以自动回收机器。这样的一个过程实现了对应用负载能力的自动化响应和边界值的测定。
在虚拟化部分，徽商银行把采购审批和应用部署、应用开发放到更有计划性的过程当中去，提高整个基于 IaaS 层的开发效率，实现秒级应用安装。在从开发向生产交付的过程中，从开发测试云角度来看，傅伟认为青云 QingCloud 安全度比较高，有自保护功能；另外自定义镜像功能可以实现在一台机器上的开发测试镜像到 10 台机器上；第三自动化部署、自动化配置功能也是其他云计算服务商无法提供的。
在云上，徽商银行第一步的考虑是基于公有云和私有云上的混合使用，目前已经实现了（私有云）数据快照，异地备份。接下来要做的是如何利用公有云的低成本磁盘空间去实现；第二步就是混合云的应用，如何利用公有云快速响应的特点，将应用接入服务的公有云部署与数据的私有接入，这是未来徽商银行在混合云方面最关注的问题。
为了更好地展现青云客户在部署云端时实践和思考，青云 QingCloud 解决方案 & 架构部架构师凌辉在活动现场也详细介绍了 QingCloud 在过去一两年面向金融客户提供的公有云和私有云，在设计、研发、服务方面的思考。
凌辉分步骤介绍了青云 QingCloud 智能的 IaaS 基础设施平台；原生、集群化、标准化的 PaaS 平台；融合网络统一管理与跨地域灾备设计这三方面内容。从不同层面向参会者展现了青云 QingCloud 金融行业解决方案。
