金融云平台技术选型架构和难点

谈金融云平台的技术选型、架构和难点

XX企业最初以保险起家，逐渐向银行、投资等金融业务拓展，形成了多元的综合金融服务集团。XX企业科技成立于2008年，前身为XX企业集团下属的IT信息管理中心，负责整体IT基础设施搭建、维护、管理等工作；自2013年XX企业推进互联网战略起，XX企业科技就开始了互联网金融领域的研发工作，XX企业云是XX企业科技推出面向XX企业集团以及外部金融机构的金融云平台。

就XX企业金融云的CaaS服务技术选型，对云平台事业部总经理方国伟进行了采访。此外，方国伟将在CNUTCon全球容器技术大会上分享题为《XX企业金融云之CaaS服务建设和应用》的演讲（容器大会将于下周五在北京举行，欲报从速）。

能否解释下您所理解的CaaS？与其他类的XaaS云服务相比，CaaS有哪些独特之处？在云计算领域，美国国家标准与技术研究院（NIST）曾经对云的服务模型有过专门的定义，不过这个定义中只有SaaS、PaaS和IaaS三大类。其他的各种XaaS 云服务都是大家参考这个定义来命名的，比如DB as a Service，Storage as a Service等。这种命名方式的好处是以一种非常简洁的方式让人一下子抓住服务的重点。CaaS（Container as a Service）指基于容器提供或跟容器密切相关的服务集合。CaaS通常会包括的服务内容有：应用部署、镜像仓库、容器管理等服务。

CaaS比较特别的地方在于它起到一个桥梁作用，比较好地连接了底层基础架构层服务和上面的应用层服务，所以构建这个服务的时候需要非常了解这两个层面的技术，并且最好还能集成开发过程管理的一些工具或平台，这样可以更好的发挥CaaS服务的作用。

可否向我们介绍下XX企业科技的整体技术研发团队和容器研发团队的规模？XX企业科技使用Docker有多久了呢？为什么要研发基于Docker的CaaS金融云呢？

XX企业科技自从2008年成立独立公司以来一直耕耘在金融IT的前沿，近一两年开始从专注于服务XX企业集团向做金融IT产品方向转型。XX企业科技目前的研发内容涵盖投资、保险、银行以及互联网领域，有6000多名研发工程师、互联网技术专家。

我们从2014年开始关注Docker技术，然后从2015年开始投入专人研究容器相关技术并开始构建容器服务。服务容器服务属于XX企业云平台服务的一部分，目前有十几个人参与了容器相关服务的研发工作，另外在公司的研发管理部门还有一个专门的团队在做基于容器服务的持续集成和部署产品研发工作。我们做基于Docker的CaaS主要从用户的需求出发，重点解决部分应用的快速部署和弹性扩展需求。我们希望通过CaaS服务能够缩短应用的上线时间，并能在应用压力上升的时候实现快速扩容。我们构建CaaS服务主要实现两个目标：第一个是提供一个业界通用的CaaS服务，整个服务方式和益处跟外部公有云CaaS服务一样，给用户多一种灵活部署应用的方式；第二个目标是集成公司内部的持续集成和部署平台，这个更偏向于内部应用，让用户直接在开发工具中（比如Eclipse）提交代码后自动化完成应用的编译、打包、验证、部署等步骤。

顺便说一下，XX企业云平台在使用容器技术中并不仅仅使用Docker服务，我们在不同的应用场景中会采用不同的技术，比如我们在一些对稳定性要求更高的NFV服务构建中，我们直接采用了LXC容器技术。

相比于传统行业，金融行业的云服务有哪些业务需求和技术挑战？为此XX企业的金融云采用了什么样的技术栈呢？容器技术的使用是怎样帮助简化问题的呢？

无论是在业务层面还是在信息技术方面，金融行业都是一个高度监管的一个行业。金融行业对服务的可用性以及数据的安全性上要求相对其他行业会更高一些。容器技术的引入对运维工作起到了比较大的推动作用，比如应用环境以及应用的部署时间可以进一步缩短，应用的横向伸缩也可以做得更为敏捷。这些对应用的可用性提升起到了明显作用。

在传统的XX企业环境中，我们有一些应用的部署采用了所谓的大物理机的部署方式，即一台高配置的服务器中部署了多个应用或应用实例，这种部署方式的隔离性不佳。通过采用基于容器的部署方式，我们提升了应用之间的隔离性。在多租户的场景中，为进一步提升隔离性，我们采用了跟亚马逊AWS的ECS容器服务类似的做法，也就是在底层IaaS 之上部署Docker容器的方式。我们多租户的容器服务环境是在Rancher产品基础上客户化构建而成的。在内部隔离性要求不高的场景中，我们直接在物理机上通过MM （Mesos+Marathon）方案提供容器部署服务。

XX企业云采用的是哪种开源云平台呢？为什么做出了这样的选择？

XX企业云采用的云平台框架是CloudStack，我们在2013年底到2014年初选择云平台框架的时候主要考察了CloudStack和OpenStack。我们最终选择CloudStack的原因主要有几个方面。首先是当时CloudStack比OpenStack要成熟一些，不同版本的API接口也是CloudStack更一致些；其次，CloudStack在架构和易用性上比OpenStack更胜一筹，用户也比较容易上手使用；再次，CloudStack是用Java语言编写的，而我们团队对Java语言是非常擅长的。

OpenStack在过去两年中得到了很大的发展，社区也非常活跃，相反CloudStack由于Citrix的策略和方向问题，其开源之路走的并不好。不过，我们一开始就要设计一个松耦合的架构，并且定下了尽可能少依赖云平台框架的原则，再加上我们自己员工对CloudStack源代码进行了深入研究，因此我们使用CloudStack的整个过程还是比较顺利。我们在CloudStack基础上做了较多的定制化工作来满足我们的需求，所以基本上在向构建一个自己的PAStack方向前进。另外，我们也在消化吸收一些OpenStack中好的设计和模块，比如我们的网络服务平台（NSP）就是参考借鉴了OpenStack的Neutron模块构建的。

最后有一点需要特别指出，经过这两年多的云平台建设实践，我们发现实际上云平台建设的关键不在选用什么样的开源框架，云平台底层的存储服务、网络服务、自动化编排等服务的建设远比采用什么框架更为重要。云平台框架可以让用户快速入门，但是真正云平台的关键还在这些基础服务是否过硬，包括它的稳定性、扩展性等。

关于对象存储，XX企业云采用的是什么技术呢？您是怎么看待不同的存储产品呢？

云平台的存储服务主要可以分为三大类：块存储、对象存储和文件系统服务。对象存储是云平台的一个重要服务，在金融云中也有多种重要的应用场景。我们在考虑建设对象存储的时候是从整个云平台存储服务建设的角度来看的。当时选型的时候我们在思考有没有一种存储技术，它能够提供多种存储服务？这样我们就可以相对容易的整合团队资源。我们对象存储服务一开始是从研究Swift开始的，但是从前面这个原则来考虑对象存储的构建技术的话，我们觉得Ceph可以让我们用一种技术平台同时构建对象存储和块存储服务（我们没有使用Ceph的文件服务，因为那个服务相对不成熟）。

我们对象存储团队对Swift和Ceph都做了大量的测试，觉得Ceph这种基于分布式的数据存储方式能够满足我们对存储服务的一些需求，所以我们基于Ceph构建了XX企业云的对象存储服务(OBS)和块存储服务（EBS）。Ceph这个技术也有一些需要进一步提升的地方，比如它的IO路径比较长，对性能会造成影响；又如它对小文件的处理不擅长，所以我们自己做了一些定制化的改造来优化它。

现在我们基于Ceph的对象存储服务已经运行了将近2年时间，我们把XX企业云的OBS 服务跟外部公有存储服务做过功能比较和性能测试比较，总体上效果达到了我们预期。XX企业云的计算虚拟化怎样实现的呢？当初是怎样在VMware、Xen、KVM和Docker 之中权衡和考量的呢？

我们认为不同的应用有不同的部署环境要求，容器、虚拟机甚至是物理机等部署形式都是需要的。我们在看待这些技术的时候，不认为他们之间是对立或相互矛盾的，相反我们认为他们是互补、可以共存的。在XX企业云平台上，我们实际上也是这么做的，我们给我们的用户提供容器（CaaS）、云主机（ECS）和物理机服务（BMS）三种不同类型的服务。

在我们云平台刚开始的时候，计算虚拟化技术我们主要考察了VMWare的ESX，KVM和XEN三种，Docker技术当时不在这个技术范畴里面。本着“以我为主”的原则，我们整体云平台的技术路线是尽可能走开源和自研结合的路线，所以一开始我们重点考察了KVM 和XEN两种虚拟化技术。

经过考察和测试，我们认为这两种虚拟化技术都已经比较稳定，符合绝大部分应用的生产需求；但是从技术趋势发展的角度，我们觉得KVM的发展势头更猛一些，其社区的活

跃度也更高，所以我们就选择了KVM作为我们主要的虚拟化技术平台。不过我们公司在传统的虚拟化环境中使用了ESX，所以从兼容性考虑出发，在云平台中我们也支持ESX 虚拟化技术，不过我们大部分的云主机都是基于KVM虚拟化技术的。

您怎么看待虚拟机和容器技术这对欢喜冤家？您曾经谈到过“基于虚机的容器vs基于物

理机的容器”，能否对此解释并详细论述？对于现在新兴的超容器您是否有关注呢？

许多人都把容器当成是虚拟机的对立面，实际上我们认为这两个技术的出发点是不一样的。虚拟机一开始就是为了充分利用底层硬件资源并提供一个隔离的完整运行环境，之所以称为虚拟化就是因为这种技术让应用或管理员觉得虚拟机像一台真的服务器一样（包括虚拟现实VR在内的虚拟也是如此）。而Docker容器技术从一开始的关注点是如何快速部署