金融行业可以说是企业IT市场的风向标，因为它本身体量很大，对IT的投入和建设标准也冠绝其他行业。任何IT技术和产品，可以说只有经过金融行业的检验，才可以真正得到市场普遍的认可。金融行业对于IT服务有着极为严格的要求，涉及业务的系统，对于数据丢失、业务中断几乎是零容忍。任何IT技术和产品如果在可用性方面达不到要求，基本上不会被金融行业普遍采用。那么，云计算可以很好的融入金融行业，并改变金融行业的IT架构吗？回答这个问题，就需要清晰的了解金融行业对IT服务的需求，以及云计算技术是否可以满足这些需求甚至超出预期。
金融行业对IT服务的需求和期望，归纳起来主要如下：
- 支撑业务稳定运营。金融行业对业务稳定性的要求异常苛刻，业务中断不仅会对金融机构的收入和形象带来直接的负面影响，甚至可能影响到其它行业和社会的方方面面。因此金融监管部门对于金融机构的业务中断事件有严格的监管要求。以银行为例，银监会认定业务中断时间超过半小时，影响范围超过一个省(含自治区、直辖市)的事件，就是重大中断事件。这类事件必须上报银监会并接受银监会的审查。业务和监管对稳定运营的压力，传导到银行科技部门，就会要求科技部门在使用任何IT技术和服务时，都要首先确保它的稳定性和可靠性。
- 支撑业务快速创新。传统金融机构不仅面临着同行间激烈竞争，也面临着来自互联网金融的竞争压力。这就要求传统金融机构在业务方面能够快速创新。任何金融业务都要依托于IT系统来运行，金融和IT的结合已经密不可分，因此就要求支撑业务的IT系统能够适应并帮助业务的快速创新。比如传统的银行ATM系统，功能相对固定和简单，交易量也相对波动不大，这样可能一个季度发一次版本就可以满足需求，也不需要快速的扩容能力。但是对于手机银行系统，新的需求在不断增加，交易量的波动可能也会比较大，就需要IT系统能够支撑快速迭代、快速上线、弹性扩容。
- 降本增效。金融行业目前已经进入一个平稳发展期。当高速增长不在，竞争压力增大的清空下，金融机构也需要更多的考虑通过降低成本来增加利润。对应到IT服务和产品，就是在保持服务质量不变，甚至要求更高的情况下，要压缩IT成本。比如把昂贵的小型机替换为X86服务器，用国产品牌替代国外品牌，通过虚拟化提升资源使用效率等等。
接下来我们看看云计算能否满足这些需求，首先来看能否支撑业务的稳定运营。金融机构IT系统的稳定运营依托于数十年来积累的基于成熟产品的开发、运营体系和经验。大家熟知的IOE架构就是其中之一，只是现在的I正逐渐被X86服务器替代，E也正在被更多其它品牌（尤其是国产品牌）所稀释。这些变化并不是架构层面的变化，仅仅是产品层面的变化，仍然适用于传统的开发、运营体系。云计算对这种架构形成了挑战，云计算一开始就倾向基于分布式技术发展，因为分布式技术可以更好的形成大规模的资源池，并且对于单节点的可靠性不会要求那么高，非常符合云计算大规模、低成本扩展的需求。云计算催生了很多分布式技术、如分布式存储、分布式消息中间件、分布式数据库、分布式软件防火墙等，甚者它初始的设计目标就是仅仅支持分布式应用。一个典型的例子是很多分布式存储都不提供块存储共享功能，原因仅仅是分布式应用不需要共享存储。金融机构在应用层面应该说已经大部分完成了分布式改造，符合经典云计算对云原生应用的需求。困难的地方在于数据库层面，云计算提供的主要服务于分布式应用的基础架构，无法满足数据库对基础资源的需求。比如传统Oracle、DB2数据库服务器需要共享存储，并且对存储的性能和容灾能力要求很高，原生的云计算分布式存储就无法满足需求。但是云计算技术也不是包打天下，能够满足很大一部分场景的需求就已经不错了。其它一些暂时无法满足的需求，也可以通过将经典云计算技术和传统技术混合管理编排的方式，通过云服务的方式统一呈现。
支撑业务快速创新这一块，应该是云计算的优势。相对传统的资源供给方式，云计算在供给的效率上可以实现数量级的下降，比如从1周降低到1小时。除了提高资源供给效率，云计算还应该在提升产品迭代效率和质量、优化运营效率和质量方面做出贡献，这样才能给金融创新提供更好的支持。提升产品迭代效率和质量，就是要实现DevOps和微服务，实现高效的持续集成(CI)和持续发布(CD)，并支持灰度发布。优化运营效率和质量，就是要通过工具帮助应用系统快速探测故障并快速自愈，支持业务系统快速弹性扩容缩容。
降本增效，就是希望通过云计算技术提升资源使用效率，提升自动化程度，提升工作效率，并对资源使用情况做出精确的计量。这些也是云计算设计的初衷，因此是可以满足需求的。
从上面的分析来看，云计算应该是可以很好的满足金融行业需求的，但是怎样使用云计算技术，使用什么样的云计算技术，对于金融机构来说，还是一个微妙的选择题。自从AWS于2006年开始推出商用的云服务产品以来，云计算技术一直在快速演进。旧的技术消亡、新的技术崛起。开源领域，2012年起OpenStack蔚然成风，到2016年又开始面临容器技术的挑战。选择什么样的技术路线对企业的决策者也是一个很大的挑战。笔者根据自己的从业经验，总结出如下原则供参考：
- 选择的技术路线首先必须可以对当前架构体系产生有益补充，而不是完全颠覆。所谓有益补充，就是在不影响现有稳定架构的情况下，对于业务系统的创新和稳定运营有更大的帮助。比如采用云计算技术之前，金融机构已经普遍采用VMware虚拟机承载应用。如果一个云计算技术上来就说不支持纳管VMware，而是推倒重来使用KVM替代VMware，那么它对业务系统基本就没有帮助，甚至会因为使用KVM降低业务系统的可用性。当然，如果哪一天KVM的可用性已经超过VMware，采用KVM就是正确的选择。
- 选择的技术路线必须经过实际生产环境大规模的检验。比如Kubernetes，在开源前已经在谷歌数据中心经历了长达10年的大规模实际生产检验，这无疑要比类似CloudFoundry这样没有经过实际生产环境大规模检验的PaaS技术要靠普很多。
- 选择的技术路线必须是主流中的主流。主流意味使用的人多，这项技术的生态会更丰富、产品迭代会更快。这个选择对于想先吃螃蟹的人会比较困难，因为你做出选择的时候这项技术可能还没有成为主流，只是备选之一。这时候只能凭借个人的眼光和运气了。如果实在拿捏不定，不如再等等看，同时通过更深入的学习拓宽自己的眼界。