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

《谈金融云平台的技术选型、架构和难点》由会员分享，可在线阅读，更多相关《谈金融云平台的技术选型、架构和难点（10页珍藏版）》请在金锄头文库上搜索。

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 年成立独立公司以来一直耕耘在金融

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

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

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

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

8、tack，我们在 2013 年底到 2014 年初选择云平台 框架的时候主要考察了 CloudStack 和 OpenStack。我们最终选择 CloudStack 的原因主 要有几个方面。首先是当时 CloudStack 比 OpenStack 要成熟一些，不同版本的 API 接 口也是 CloudStack 更一致些；其次，CloudStack 在架构和易用性上比 OpenStack 更胜 一筹，用户也比较容易上手使用；再次，CloudStack 是用 Java 语言编写的，而我们团 队对 Java 语言是非常擅长的。 OpenStack 在过去两年中得到了很大的发展，社区也非常活跃，相反

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

10、后有一点需要特别指出，经过这两年多的云平台建设实践，我们发现实际上云平台建 设的关键不在选用什么样的开源框架，云平台底层的存储服务、网络服务、自动化编排 等服务的建设远比采用什么框架更为重要。云平台框架可以让用户快速入门，但是真正 云平台的关键还在这些基础服务是否过硬，包括它的稳定性、扩展性等。 关于对象存储，XX 企业云采用的是什么技术呢？您是怎么看待不同的存储产品呢？ 云平台的存储服务主要可以分为三大类：块存储、对象存储和文件系统服务。对象存储 是云平台的一个重要服务，在金融云中也有多种重要的应用场景。我们在考虑建设对象 存储的时候是从整个云平台存储服务建设的角度来看的。当时选型的时候我们

11、在思考有 没有一种存储技术，它能够提供多种存储服务？这样我们就可以相对容易的整合团队资 源。我们对象存储服务一开始是从研究 Swift 开始的，但是从前面这个原则来考虑对象 存储的构建技术的话，我们觉得 Ceph 可以让我们用一种技术平台同时构建对象存储和 块存储服务（我们没有使用 Ceph 的文件服务，因为那个服务相对不成熟）。 我们对象存储团队对 Swift 和 Ceph 都做了大量的测试，觉得 Ceph 这种基于分布式的数 据存储方式能够满足我们对存储服务的一些需求，所以我们基于 Ceph 构建了 XX 企业 云的对象存储服务(OBS)和块存储服务（EBS）。Ceph 这个技术也有一些需

12、要进一步提 升的地方，比如它的 IO 路径比较长，对性能会造成影响；又如它对小文件的处理不擅长， 所以我们自己做了一些定制化的改造来优化它。 现在我们基于 Ceph 的对象存储服务已经运行了将近 2 年时间，我们把 XX 企业云的 OBS 服务跟外部公有存储服务做过功能比较和性能测试比较， 总体上效果达到了我们 预期。 XX 企业云的计算虚拟化怎样实现的呢？当初是怎样在 VMware、Xen、KVM 和 Docker 之中权衡和考量的呢？ 我们认为不同的应用有不同的部署环境要求，容器、虚拟机甚至是物理机等部署形式都 是需要的。我们在看待这些技术的时候，不认为他们之间是对立或相互矛盾的，相反我

13、们认为他们是互补、可以共存的。在 XX 企业云平台上，我们实际上也是这么做的，我 们给我们的用户提供容器（CaaS）、云主机（ECS）和物理机服务（BMS）三种不同 类型的服务。 在我们云平台刚开始的时候，计算虚拟化技术我们主要考察了 VMWare 的 ESX，KVM 和 XEN 三种，Docker 技术当时不在这个技术范畴里面。本着“以我为主”的原则，我们整 体云平台的技术路线是尽可能走开源和自研结合的路线，所以一开始我们重点考察了 KVM 和 XEN 两种虚拟化技术。 经过考察和测试，我们认为这两种虚拟化技术都已经比较稳定，符合绝大部分应用的生 产需求；但是从技术趋势发展的角度，我们觉得

14、KVM 的发展势头更猛一些， 其社区的 活跃度也更高，所以我们就选择了 KVM 作为我们主要的虚拟化技术平台。不过我们公 司在传统的虚拟化环境中使用了 ESX，所以从兼容性考虑出发，在云平台中我们也支持 ESX 虚拟化技术，不过我们大部分的云主机都是基于 KVM 虚拟化技术的。 您怎么看待虚拟机和容器技术这对欢喜冤家？您曾经谈到过“基于虚机的容器 vs 基于物 理机的容器”，能否对此解释并详细论述？对于现在新兴的超容器您是否有关注呢？ 许多人都把容器当成是虚拟机的对立面，实际上我们认为这两个技术的出发点是不一样 的。虚拟机一开始就是为了充分利用底层硬件资源并提供一个隔离的完整运行环境，之 所以

15、称为虚拟化就是因为这种技术让应用或管理员觉得虚拟机像一台真的服务器一样 （包括虚拟现实 VR 在内的虚拟也是如此）。而 Docker 容器技术从一开始的关注点是 如何快速部署应用，尽可能的隔离应用对底层环境的依赖。Docker 容器实际上更像是 Windows 平台上的应用虚拟化技术，比如 SoftGrid，所以虚机和容器两种技术的定位并 不相同。 我们对于是否采用 Docker 技术没有任何犹豫，从 2014 年开始就开始跟踪研究。不过， 在一开始引入 Docker 的时候，也纠结过是采用基于虚机的容器还是基于物理机的容器。 基于物理机构建的观点主要在于少了虚拟化层次可以提升资源使用效率，并

16、在理论上可 以提升稳定性因为毕竟少了中间一个层次。但是，对于容器本身隔离性存在一些问题， 不能满足我们隔离的要求。因此我们在多租户的环境下我们还是采用基于虚机的方式构 建容器服务，从而可以利用上相对成熟的 IaaS 层既有的隔离技术。 超容器的概念是非常吸引人的，听上去可以兼有容器的灵便型和虚拟机的隔离性，但是 目前还处于比较早的概念阶段，我们对此保持关注。我们会围绕客户的需求，如果确认 一个技术有利于我们客户服务，那我们会在这个技术发展到合适的时机把它引入。 能否谈谈 XX 企业金融云的 VPC 专有网络背后的技术？ 云计算的网络技术包含两个层面：面向实现和面向业务。和传统网络技术不同的地方是， 面向业务更为重要，需要把传统的网络能力如 VLAN、子网、路由、FW、LB 等进行业 务抽象，针对这些抽象后的业务需求，再从众多开放性的实现技术中筛选，但筛选后依 然会有很多工作要做，因为大多数情况下，任何现成方案都无法满足要求，就比如说网 络能力抽象，目前最成熟的开源抽象方案是 OpenStack Neutron，但 Neutron 对于常见 的路由交换、高级 FW 和 LB 策略、C