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

1、谈金融云平台的技术选型、架构和难点XX 企业最初以保险起家，逐渐向银行、投资等金融业务拓展，形成了多元的综合金融服务集团。XX 企业科技成立于 2008 年，前身为 XX 企业集团下属的 IT 信息管理中心，负责整体 IT 基础设施搭建、维护、管理等工作；自 2013 年 XX 企业推进互联网战略起，XX 企业科技就开始了互联网金融领域的研发工作，XX 企业云是 XX 企业科技推出面向XX 企业集团以及外部金融机构的金融云平台。就 XX 企业金融云的 CaaS 服务技术选型，对云平台事业部总经理方国伟进行了采访。此外，方国伟将在 CNUTCon 全球容器技术大会上分享题为 XX 企业金融云之

2、CaaS服务建设和应用的演讲（容器大会将于下周五在北京举行，欲报从速）。能否解释下您所理解的 CaaS？与其他类的 XaaS云服务相比，CaaS 有哪些独特之处？在云计算领域，美国国家标准与技术研究院（NIST）曾经对云的服务模型有过专门的定义，不过这个定义中只有 SaaS、PaaS 和 IaaS 三大类。其他的各种 XaaS 云服务都是大家参考这个定义来命名的，比如 DB as a Service，Storage as a Service 等。这种命名方式的好处是以一种非常简洁的方式让人一下子抓住服务的重点。CaaS（Container as a Service）指基于容器提供或跟容器密切相

3、关的服务集合。CaaS 通常会包括的服务内容有：应用部署、镜像仓库、容器管理等服务。CaaS 比较特别的地方在于它起到一个桥梁作用，比较好地连接了底层基础架构层服务和上面的应用层服务，所以构建这个服务的时候需要非常了解这两个层面的技术，并且最好还能集成开发过程管理的一些工具或平台，这样可以更好的发挥 CaaS 服务的作用。可否向我们介绍下 XX企业科技的整体技术研发团队和容器研发团队的规模？XX 企业科技使用 Docker有多久了呢？为什么要研发基于 Docker的 CaaS金融云呢？XX 企业科技自从 2008 年成立独立公司以来一直耕耘在金融 IT 的前沿，近一两年开始从专注于服务 XX

4、企业集团向做金融 IT 产品方向转型。XX 企业科技目前的研发内容涵盖投资、保险、银行以及互联网领域，有 6000 多名研发工程师、互联网技术专家。我们从 2014 年开始关注 Docker 技术，然后从 2015 年开始投入专人研究容器相关技术并开始构建容器服务。服务容器服务属于 XX 企业云平台服务的一部分，目前有十几个人参与了容器相关服务的研发工作，另外在公司的研发管理部门还有一个专门的团队在做基于容器服务的持续集成和部署产品研发工作。我们做基于 Docker 的 CaaS 主要从用户的需求出发，重点解决部分应用的快速部署和弹性扩展需求。我们希望通过 CaaS服务能够缩短应用的上线时间，

5、并能在应用压力上升的时候实现快速扩容。我们构建CaaS 服务主要实现两个目标：第一个是提供一个业界通用的 CaaS服务，整个服务方式和益处跟外部公有云 CaaS 服务一样，给用户多一种灵活部署应用的方式；第二个目标是集成公司内部的持续集成和部署平台，这个更偏向于内部应用，让用户直接在开发工具中（比如 Eclipse）提交代码后自动化完成应用的编译、打包、验证、部署等步骤。顺便说一下，XX 企业云平台在使用容器技术中并不仅仅使用 Docker 服务，我们在不同的应用场景中会采用不同的技术，比如我们在一些对稳定性要求更高的 NFV 服务构建中，我们直接采用了 LXC 容器技术。相比于传统行业，金融

6、行业的云服务有哪些业务需求和技术挑战？为此 XX企业的金融云采用了什么样的技术栈呢？容器技术的使用是怎样帮助简化问题的呢？无论是在业务层面还是在信息技术方面，金融行业都是一个高度监管的一个行业。金融行业对服务的可用性以及数据的安全性上要求相对其他行业会更高一些。容器技术的引入对运维工作起到了比较大的推动作用，比如应用环境以及应用的部署时间可以进一步缩短，应用的横向伸缩也可以做得更为敏捷。这些对应用的可用性提升起到了明显作用。在传统的 XX 企业环境中，我们有一些应用的部署采用了所谓的大物理机的部署方式，即一台高配置的服务器中部署了多个应用或应用实例，这种部署方式的隔离性不佳。通过采用基于容器的

7、部署方式，我们提升了应用之间的隔离性。在多租户的场景中，为进一步提升隔离性，我们采用了跟亚马逊 AWS 的 ECS 容器服务类似的做法，也就是在底层 IaaS之上部署 Docker容器的方式。我们多租户的容器服务环境是在 Rancher 产品基础上客户化构建而成的。在内部隔离性要求不高的场景中， 我们直接在物理机上通过MM（Mesos+Marathon）方案提供容器部署服务。XX企业云采用的是哪种开源云平台呢？为什么做出了这样的选择？XX 企业云采用的云平台框架是 CloudStack，我们在 2013 年底到 2014 年初选择云平台框架的时候主要考察了 CloudStack 和 OpenS

8、tack。我们最终选择 CloudStack 的原因主要有几个方面。首先是当时 CloudStack 比 OpenStack 要成熟一些，不同版本的 API 接口也是 CloudStack 更一致些；其次，CloudStack 在架构和易用性上比 OpenStack 更胜一筹，用户也比较容易上手使用；再次，CloudStack 是用 Java 语言编写的，而我们团队对 Java 语言是非常擅长的。OpenStack 在过去两年中得到了很大的发展，社区也非常活跃，相反 CloudStack 由于Citrix 的策略和方向问题，其开源之路走的并不好。不过，我们一开始就要设计一个松耦合的架构，并且定

9、下了尽可能少依赖云平台框架的原则，再加上我们自己员工对CloudStack 源代码进行了深入研究，因此我们使用 CloudStack 的整个过程还是比较顺利。我们在 CloudStack 基础上做了较多的定制化工作来满足我们的需求，所以基本上在向构建一个自己的 PAStack 方向前进。另外，我们也在消化吸收一些 OpenStack 中好的设计和模块，比如我们的网络服务平台（NSP）就是参考借鉴了 OpenStack 的Neutron 模块构建的。最后有一点需要特别指出，经过这两年多的云平台建设实践，我们发现实际上云平台建设的关键不在选用什么样的开源框架，云平台底层的存储服务、网络服务、自动化

10、编排等服务的建设远比采用什么框架更为重要。云平台框架可以让用户快速入门，但是真正云平台的关键还在这些基础服务是否过硬，包括它的稳定性、扩展性等。关于对象存储，XX 企业云采用的是什么技术呢？您是怎么看待不同的存储产品呢？云平台的存储服务主要可以分为三大类：块存储、对象存储和文件系统服务。对象存储是云平台的一个重要服务，在金融云中也有多种重要的应用场景。我们在考虑建设对象存储的时候是从整个云平台存储服务建设的角度来看的。当时选型的时候我们在思考有没有一种存储技术，它能够提供多种存储服务？这样我们就可以相对容易的整合团队资源。我们对象存储服务一开始是从研究 Swift 开始的，但是从前面这个原则来

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

12、已经运行了将近 2 年时间，我们把 XX 企业云的OBS 服务跟外部公有存储服务做过功能比较和性能测试比较， 总体上效果达到了我们预期。XX企业云的计算虚拟化怎样实现的呢？当初是怎样在 VMware、Xen、KVM 和 Docker之中权衡和考量的呢？我们认为不同的应用有不同的部署环境要求，容器、虚拟机甚至是物理机等部署形式都是需要的。我们在看待这些技术的时候，不认为他们之间是对立或相互矛盾的，相反我们认为他们是互补、可以共存的。在 XX 企业云平台上，我们实际上也是这么做的，我们给我们的用户提供容器（CaaS）、云主机（ECS）和物理机服务（BMS）三种不同类型的服务。在我们云平台刚开始的时

13、候，计算虚拟化技术我们主要考察了 VMWare 的 ESX，KVM和 XEN 三种，Docker 技术当时不在这个技术范畴里面。本着“以我为主” 的原则，我们整体云平台的技术路线是尽可能走开源和自研结合的路线，所以一开始我们重点考察了KVM 和 XEN 两种虚拟化技术。经过考察和测试，我们认为这两种虚拟化技术都已经比较稳定，符合绝大部分应用的生产需求；但是从技术趋势发展的角度，我们觉得 KVM 的发展势头更猛一些， 其社区的活跃度也更高，所以我们就选择了 KVM 作为我们主要的虚拟化技术平台。不过我们公司在传统的虚拟化环境中使用了 ESX，所以从兼容性考虑出发，在云平台中我们也支持ESX 虚拟

14、化技术，不过我们大部分的云主机都是基于 KVM 虚拟化技术的。您怎么看待虚拟机和容器技术这对欢喜冤家？您曾经谈到过“基于虚机的容器 vs基于物理机的容器”，能否对此解释并详细论述？对于现在新兴的超容器您是否有关注呢？许多人都把容器当成是虚拟机的对立面，实际上我们认为这两个技术的出发点是不一样的。虚拟机一开始就是为了充分利用底层硬件资源并提供一个隔离的完整运行环境，之所以称为虚拟化就是因为这种技术让应用或管理员觉得虚拟机像一台真的服务器一样（包括虚拟现实 VR 在内的虚拟也是如此）。而 Docker容器技术从一开始的关注点是如何快速部署应用，尽可能的隔离应用对底层环境的依赖。Docker 容器实

15、际上更像是Windows 平台上的应用虚拟化技术，比如 SoftGrid，所以虚机和容器两种技术的定位并不相同。我们对于是否采用 Docker 技术没有任何犹豫，从 2014 年开始就开始跟踪研究。不过，在一开始引入 Docker 的时候，也纠结过是采用基于虚机的容器还是基于物理机的容器。基于物理机构建的观点主要在于少了虚拟化层次可以提升资源使用效率，并在理论上可以提升稳定性因为毕竟少了中间一个层次。但是，对于容器本身隔离性存在一些问题，不能满足我们隔离的要求。因此我们在多租户的环境下我们还是采用基于虚机的方式构建容器服务，从而可以利用上相对成熟的 IaaS 层既有的隔离技术。超容器的概念是非

16、常吸引人的，听上去可以兼有容器的灵便型和虚拟机的隔离性，但是目前还处于比较早的概念阶段，我们对此保持关注。我们会围绕客户的需求，如果确认一个技术有利于我们客户服务，那我们会在这个技术发展到合适的时机把它引入。能否谈谈 XX企业金融云的 VPC专有网络背后的技术？云计算的网络技术包含两个层面：面向实现和面向业务。和传统网络技术不同的地方是，面向业务更为重要，需要把传统的网络能力如 VLAN、子网、路由、FW 、LB 等进行业务抽象，针对这些抽象后的业务需求，再从众多开放性的实现技术中筛选，但筛选后依然会有很多工作要做，因为大多数情况下，任何现成方案都无法满足要求，就比如说网络能力抽象，目前最成熟

17、的开源抽象方案是 OpenStack Neutron，但 Neutron 对于常见的路由交换、高级 FW 和 LB 策略、CDN、IDS 都没有定义，需要我们根据 Neutron 的模型定义方式去扩展很多驱动，走在社区之前有自豪感也充满风险；再比如说 SDN，我们通过 SDN 实现 VPC 的隔离，但是原生 SDN 过于学术化，资源颗粒度过细，带来一些副作用，为此我们对 SDN 也做了大量的简化工作。在具体的实现上，我们基于开放通用的原则选择了 VxLAN+VRF 的方式作为 VPC 骨架，主机 OVS 为脉络，通过传统 L2、SDN 和 EVPN 三种方式实现内部的互联互通，以DFW 和 V

18、FW 实现 VPC 访问控制，我们自研的 LVX 系统是业界领先的容器化 NFV 负载均衡方案，基于 OpenStack Neutron 开发实现了网络业务编排系统，将底层的技术实现、业务生命周期、资源管理有机地串联起来，为业务提供统一的服务入口。在网络层面，我们做了较多创新探索，共递交 10 余项专利申请。有人说“搭建基于 Docker的 CaaS是为了让开发和运维都可以开心”。可否分享下，这个金融云平台是怎样影响了你们的开发和运维工作呢？为了实现 CaaS，你们团队内部都做了哪些技术和组织层面的调整呢？对目前的金融云平台运维是否满意？虽然我们 XX 企业云是从私有云开始建设的，但是我们从一

19、开始就以公有云的多租户方式来设计整个平台，并且以客户为中心的方式来提供各种服务。所以，对我们云平台而言，除了外部客户外，公司里面的开发和应用运营也都是我们的客户。他们的满意和开心是最为重要的，云平台自身的产品研发和运维工作都是围绕整个目标展开的。从我们公司内部来说，XX 企业云对开发的帮助还是挺显著的，其中最为直接的就是现在应用环境的申请基本都是通过云门户以自助的方式就可以完成。除了基础系统环境外，我们还提供常见中间件、数据库服务，从而大大降低开发人员对开发环境和测试环境的部署门槛。对于一些需要快速响应市场变化、面向互联网的应用，通过 XX 企业云平台，他们可以更好的实践 DevOps 一体化

20、的开发运维方式。在我们云平台内部，我们产品自身建设也在尝试 DevOps 方式。我们的产品建设和运维团队基本是一体化的，比如 CaaS 服务的构建和运维都是由一个团队负责。这个跟传统IT 产品的运维方式不一样，其主要原因是云平台产品还在不断发展变化中，产品开发和运维放在一起可以加快响应速度，提升运维效率。XX 企业云正在构建自己的运维体系，我们称为 AlphaOps。我们在参考了传统的 ITIL 运维流程，学习谷歌的 SRE 理念的基础上，并融入了 XX 企业云的一些个性化要求，构建了 AlphaOps 运维体系。我们运维目标就是是构建满足 XX 企业云需求的智能化运维。我们在今年初启动Alp

21、haOps 项目来构建智能化运维平台，目前第一个版本已经上线。我们相信 智能化运维是我们运维工作的发展方向，相信通过 AlphaOps 可以解放我们运维团队并提升运维服务质量。相对于其他类的 XaaS，您怎么看待 CaaS的未来发展？在云计算的 SPI 服务模型中，我们可以发现 SaaS 由于跟应用直接相关，所以不具有平台的特征，也就是说基本上每个 SaaS 服务只能解决一类问题，而且不同 SaaS 服务之间差别也比较大。从平台的角度来看，主要是 IaaS 和 PaaS 两大类。到目前为至，我们可以看到，IaaS 发展最快，技术相对成熟，用户接受度最高，而 PaaS 看上去很美，但是成功的例子

22、不多。PaaS 的接受度不高的一个重要原因是因为 PaaS 对用户应用的要求比较高，不够灵活，从而导致 PaaS 的兼容性降低，增加了用户接受的门槛。IaaS 接受度高也是因为通过云主机的方式对应用的兼容性比较高，从而用户容易接受。从服务层次来看，我们认为 CaaS是一种间于 IaaS和 PaaS层之间的服务。这么讲的原因是 CaaS 一方面具有类似 IaaS 的兼容性，另一方面也像 PaaS 那样对开发者比较友好。如果容器技术在安全隔离性上没有大的突破，在多租户场景中，CaaS 替代 IaaS 是比较困难的。PaaS 的一个重要目标是让底层环境对开发者透明，应用可以根据负载弹性伸缩。目前来看，CaaS 在一定程度上是可以满足开发人员的这些需求的。如果 CaaS 服务做得逐渐完善，许多本来需要通过 PaaS 来实现的需求实际上可以通过CaaS 就能满足。当然从另外一个角度，PaaS 平台可以在 CaaS 服务的基础上进行构建，通过这种方式，无论是 A-PaaS 还是 I-PaaS 的构建难度都可以大大降低。可以看到，Docker 起源于 dotCloud 不是没有原因的。