金融行业开发测试云平台架构方案设计

金融行业开发测试云平台架构方案设计

前言

随着信息技术的飞速发展，云计算技术的应用也越来越广泛。云计算为企业带来了资源快速的交付能力、强大的敏捷性、灵活的横纵向扩展性以及高标准的部署规范性。这些优点在开发测试云计算的运用当中，表现地尤为突出。云计算平台不仅仅是一个统一资源管控平台，更重要的是一个IT服务平台，它将资源抽象化和服务化，极大简化了企业用户的管理和使用，而在云计算中最核心的就是云管平台，一个贴切企业实际需求的云管平台，能够强化企业IT资源的管理能力，提升企业IT资源利用率，满足企业对大规模计算能力的需求，从而进一步推动企业业务的发展。本文旨在探讨如何更好地设计金融行业开发测试云管平台，包括云管平台的需求、定位和设计方案。

开发测试云的需求

在金融行业中，对于开发测试云，通常有以下几点需求：

1.资源整合、大幅提高资源利用率

在开发测试环境，由于环境复杂性、成本、历史等原因，开发测试环境的资源孤岛现象十分常见，资源利用率低但却依旧无可用资源，为了摆脱该痛点，企业都已经开始利用虚拟化技术，进行资源整合和资源共享，摆脱开发测试资源孤岛格局。另外，资源回收也是企业一大痛点，传统环境资源回收过程艰难，不彻底，也没有资源生命周期的概念。这是开发测试云管平台需要考量的要点之一。

2.为敏捷开发提供快速部署的支撑

随着金融行业业务的互联网化，功能的快速开发、测试和上线变得越来越重要，而敏捷开发和测试对资源的需求是极快速的，这里的资源不仅仅包括计算、存储和网络，还包括各类基础软件资源、中间件资源和数据库资源等，所以需要利用云计算快速、自动化软硬件服务编排的功能，提高敏捷开发的能力，大幅缩短开发测试环境部署的时间。这是开发测试云管平台需要考量的要点之二。

3.资源部署策略多样性

云计算资源池可提供各类不同平台、不同性能、不同厂商的资源，为多样性的开发测试提供选择，所以资源的部署策略同样需要多样性，能够根据企业用户设定的不同策略，动态自动化的部署到不同的资源当中。同样，这些策略的设定也需简易和便捷，无需用户了解过多的底层实现。这是开发测试云管平台需要考量的要点之三。

4.资源调配灵活性

资源的调配不局限，需要具有灵活性和动态性，灵活性方面无论是计算资源、存储资源还是软件资源，无论是Scale Up还是Scale Out，甚至需要云管平台能够对接外部的公有云资源，动态调配私有云和公有云的资源，实现混合云的工作负载模式。动态性方面云管平台需要能够实时监控底层资源的使用情况，在触发动态调配阀值时，通知用户或者自动进行资源的在线迁移或者扩展。这是开发测试云管平台需要考量的要点之四。

5.保持开发测试与生产的统一规范

传统开发测试环境和生产环境部署不规范，不统一，造成了很多问题和痛苦，即使制定了相关规范性文档或者实施工艺，但由于人和流程等的因素，往往落地十分困难，形成一纸空文。而在云计算中，由于云管平台的存在，可以将标准的模版、软件和配置规范可以介质的形式存放于云仓库，生产和测试环境只需保

持云仓库的同步即可，这样一来更易于保持生产与开发测试环境的统一和规范，二来由于这些规范随资源部署时自动化落地，规避了人为和流程的因素。这是开发测试云管平台需要考量的要点之五。

6.自动化运维、监控和流程的集成

相较于生产环境，开发测试环境的自动化运维和监控往往就不大重视，然而实际问题却是开发测试环境经常莫名奇妙出现各类问题，各个节点检查后才发现是非常简单的原因造成的，这时简单的监控也变得需要；另外由于开发测试环境节点数规模十分庞大，也不可能指定大量专门的运维团队去维护开发测试环境，所以开发测试环境的自动化运维也变得需要；最后如何实现开发、测试和生产运维流程一体化也是需要考量点之一，让整个IT流程在各个阶段都运转和串联起来。所以开发测试环境的云管平台需要合理的集成自动化运维、监控和流程平台。这是开发测试云管平台需要考量的要点之六。

云管平台的定位

说完了云管平台的需求，再来说说云管平台的定位。由于云计算的层次和概念比较多，各个行业的资源使用情况也不一样，加上各类云计算厂商的宣传和用词，很容易造成用户的概念混淆或者疑惑。我们先来看看目前常见的云计算体系层次架构：

1.商用X86云

商用X86云主要是Vmware技术为主要代表，VCenter虚拟化管理平台相当于资源管理层，Vrealize Automation则为云管理平台层，不仅提供API功能的自服务和统一服务目录，也能支持不同供应商的多套私有云和公有云，还支持对容器的管理等。该云管平台的特色是和Vmware的底层技术紧密结合，通过抽象化底层实现技术，同时提供可视化服务和可拖放的设计画布，将预构建的组件组合为各种应用。

2.开源X86云

开源X86云主要以OpenStack为框架，利用OpenStack的各类组件对接不同的资源，各厂商在公版OpenStack的基础之上，开发各具特色的云管平台，包括统一资源层和服务抽象层，资源层的实现需要

在公版OpenStack各组件上进行改良和优化，而服务抽象层的设计完全就是各组件的API的调用和抽象，将不同的IT服务、编排策略、动态优化策略等翻译成不同组件的API调用组合，另外还需和其他像自动化运维和监控等工具相结合，这就完全考验各厂商或者用户企业的开发实力和对云管平台的理解能力。

3.Power云

Power云很简单，以IBM的PowerVC为目前的最佳选择，PowerVC提供两种版本，一种是PowerVC Standard Edition，提供基本的虚拟化资源管理能力，另一种是Cloud PowerVC Manager，在Standard Edition之上还提供了自服务功能和简单流程审批功能，能够定义各类计算模板和存储模板，自动化按照模板进行计算资源和存储资源的编排。此外，还提供了DRO动态资源优化功能，能够实时监控资源的使用情况，按照设定，提示或者自动化在不同计算节点上均衡工作负载。最后，PowerVC和Power的特性紧密结合是最大特色，比如Remote Restart、LPM、EnterprisePool和PowerHA等等，利用该云管平台能够实现一整套完善的Power高可用体系架构。

4.Power和X86共存云

这是金融行业云计算体系最常见的架构体系，不像纯互联网企业那样，完全是X86，而由于金融行业的特殊性，以追求最大的稳定可靠性为第一目标，所以金融行业的企业目前Power计算资源是必不可少的，至少在今后很长一段时间Power和X86将共存，所以其云计算体系架构是需要考虑如何实现不同平台异构资源的共存，同时还要考虑纯物理计算资源的接管。相较于开源X86云，这类异构资源的统一管理，实现技术为Driver的集成，将PowerVC Adapter、Vcenter甚至Z/VM的Driver集成至云管平台的统一资源层，通过Driver的API间接管理和调度Power和Vmware X86的资源池；至于纯物理计算资源的接管，则是用到了OpenStack裸金属Ironic组件，它提供了一系列常用的Baremetal Server的Driver，并且提供了插件的机制让二次开发的厂商可以开发一些其他Baremetal Server的Driver嵌入其中。最后，对于公有云或者容器云，也是云管平台通过其提供的Restfull API进行对接。

综上四种架构，可以很清楚看到，云计算体系应该包含三层或者四层：资源池层，虚拟化管理平台层，云管平台资源层和云管平台服务层。资源池层，包括各类计算、存储和网络资源，这个资源可以是做了虚拟化技术的，也可以是没做虚拟化技术的物理机；虚拟化管理平台层对各类同构的底层虚拟化资源池统一管理；云管平台资源层实现对所有异构的资源的统一管理；云管平台服务层实现自服务界面，将服务的底层资源实现、部署策略和动态调配实现抽象化，集成各类运维、管理和流程的工具等。实际上，广义上来说，云管平台应该包含统一资源层和服务层，狭义的云管平台只是服务层，这两个层次可以在一套软件中实现，像轻量级IaaS Power云---Cloud PowerVC Manager、其他三方（如EasyStack、东软Saca、云宏和

SAP等）云管平台，也可以多套软件实现，软件和软件间有API接口实现对接，像Cloud Manager+ICO 的组合、StartCloud+SelectStack的组合、VCenter+Vrealize的组合或者异构软件的组合（如StartCloud+Vrealize/ICO/EasyStack）等等。这些商用云管平台的例子告诉我们，统一资源层和服务层是紧密不可分割的，所以我们在设计云管平台时的定位应该要在广义的角度去统一设计，而不仅仅是从服务层的角度。

云管平台的架构设计

有了前面开发测试云的需求和云管平台定位的简单介绍，现在正式进入开发测试云管平台的设计阶段，主要包括三个部分：统一资源层的设计、服务抽象层的设计和运维管理集成的设计。逻辑架构图如下：

1.统一资源层的设计

云管平台的统一资源层并非是资源的直接提供者，而是资源的管控者或者调度者，对上提供API，供服务抽象层调用，对下集成资源的Driver，承上启下，作为云计算技术的具体实现层，统一资源层的设计需要有“平台”、“分布式”和“动态”的设计理念。

一是资源层能够提供一个资源适配平台，能够适配各类计算资源（异构X86和Power虚拟化、物理机、公有云和容器云），各类网络资源（网络类型：local、Flat、VLAN、VXLAN、GRE；网络机制：LinuxBridge、Openvswitch；网络服务：Router、LoadBalance、Firewall、DHCP等），各类存储资源（LVM，NFS，Ceph，GlusterFS，以及EMC和IBM等商业存储系统），各类软件资源（中间件、工具、数据库和应用等）；

二是资源层的各组件能够按照一定细粒度分布到不同的控制节点中，这样可以提高性能和伸缩性，避免随着资源节点数的增加，造成的瓶颈；

三是资源层的编排是动态和自动化的，在资源层按照过滤规则、策略或者资源模板进行设定后，部署则按照该策略模型就行自动化的编排，并且可以和监控组件（如OpenStack的Ceilometer）相结合，实现动态的迁移、伸缩和扩展资源。整体资源层示意图如下：

“平台”理念：

（1）计算资源

OpenStack作为开放的Infrastracture as a Service云操作系统，支持业界各种优秀的技术，这些技术可能是开源免费的，也可能是商业收费的。这种开放的架构使得OpenStack 保持技术上的先进性，具有很强的竞争力，同时又不会造成厂商锁定（Lock-in）。那OpenStack 的这种开放性体现在哪里呢？一个重要的方面就是采用基于Driver的平台框架。先来看Nova组件：

计算资源分两块，一块是虚拟化资源，一块是物理资源，虚拟化资源又分直接虚拟化资源和间接虚拟化资源，先说直接虚拟化资源，也就是云管平台资源层直接对接虚拟化资源，但是现在市面上有这么多Hypervisor，资源层的Nova又是如何与他们配合的呢？答案是通过Nova-API调用Nova-compute子组件，Nova-compute子组件为Driver 架构，nova-compute 为这些Hypervisor 定义了统一的接口，Hypervisor只需要实现这些接口，就可以Driver 的形式即插即用到OpenStack Nova系统中。下面是Nova Driver的架构示意图，这时的Nova-compute存在于物理计算节点中：

再说间接虚拟化资源，云管平台资源层的Nova-compute集成了虚拟化管理平台的Driver，间接通过虚拟化管理平台管理和调度计算资源，如PowerVC、Vcenter和Z/VM就是这样纳入云管平台的。但是这种方式也有一个弊端，虽然通过Driver可以调用虚拟化管理平台的API获得资源信息和进行操作，但是由于不直接跟Hypervisor通信，一些底层的虚拟化操作是无法被云管接管的，特别是一些特性化的功能，另外API也无法提供所有的操作，依旧需要去虚拟化管理平台进行操作，此外，虚拟化管理平台本身也具备一些编排策略和动态优化规则，而云管平台资源层也设计了相应的策略和规则，间接的接管方式需要考虑这些功能是否可以通过API往统一资源层上集成，再往服务抽象层上集成。

最后是物理资源，Nova-API调用资源层的Nova-compute，Nova-compute再调用Ironic的API来实现对物理资源的管理和控制，可以理解为Nova-compute集成了Ironic的Driver，Ironic可以看成一个Hypervisor Driver来给Nova来用。再者Ironic中也集成了许多Baremetal Server的Driver，并提供了插件的机制让二次开发的厂商可以开发一些其他Baremetal Server的Driver嵌入其中。

（2）存储资源

OpenStack的存储组件为Cinder，存储节点支持多种Volume Provider，包括LVM, NFS, Ceph, GlusterFS，以及EMC, IBM等商业存储系统。Cinder-volume为这些Volume Provider定义了统一的Driver 接口，Volume Provider只需要实现这些接口，就可以Driver的形式即插即用到OpenStack中。下面是Cinder Driver的架构示意图：

（3）网络资源

Neutron的核心组件包括Core Plugin和Service Plugin，Core Plugin负责管理和维护Neutron的Network, Subnet和Port的状态信息，这些信息是全局的，只需要也只能由一个Core Plugin管理。只使用一个Core Plugin本身没有问题。但问题在于传统的Core Plugin 与Core Plugin Agent是一一对应的。也就是说，如果选择了Linux Bridge Plugin，那么Linux Bridge Agent将是唯一选择，就必须在OpenStack的所有节点上使用Linux Bridge作为虚拟交换机（即Network Provider）。同样的，如果选择Open Vswitch Plugin，所有节点上只能使用Open Vswitch，而不能使用其他的Network Provider。此外，所有传统的Core Plugin都需要编写大量重复和类似的数据库访问的代码，大大增加了Plugin开

发和维护的工作量。到了OpenStack Havana版本时，实现了一个新的Core Plugin，即ML2，ML2作为新一代的Core Plugin，提供了一个框架，允许在OpenStack网络中同时使用多种Layer 2网络技术，不同的计算节点可以使用不同的网络实现机制。如下图所示，采用ML2 Plugin 后，可以在不同节点上分别部署Linux Bridge Agent, Open Vswitch Agent, Hyper-v Agent 以及其他第三方Agent。ML2不但支持异构部署方案，同时能够与现有的Agent无缝集成：以前用的Agent不需要变，只需要将Neutron server上的传统Core plugin替换为ML2。有了ML2，要支持新的Network Provider就变得简单多了：无需从头开发Core Plugin，只需要开发相应的Mechanism Driver，大大减少了要编写和维护的代码。

（4）软件资源

软件也作为一种资源存在于云管的资源层，软件资源的实现有多种方式，一是最简单的镜像模板实现，通过制作安装了特定软件资源的虚拟机，再捕获为镜像模板，存在镜像仓库，部署时克隆一份；二是通过OpenStack HEAT组件实现，OpenStack Heat是一个基于模板来编排复合云应用的服务模板，它的使用简化了复杂基础设施，服务和应用的定义和部署。Heat模板支持丰富的资源类型，实现了对操作系统、应用、中间件、框架和工具等的自动化安装和配置，规范了软件资源的部署。OpenStack Heat提供四种

软件资源编排方式：Heat对软件配置和部署的编排；Heat对负载均衡的编排；Heat对资源自动伸缩的编排；Heat和配置管理工具集成。云管平台在设计时，在服务抽象层存放编排的脚本，服务层在进行翻译时，会将编排的脚本加载至资源层的OpenStack Heat组件中，在其他组件完成硬件资源的部署后，OpenStack Heat运行编排脚本，实现软件资源的部署；三是通过容器编排实现，服务层将需求翻译成资源层的API，再通过云管平台的资源层API调度容器云的编排引擎（Docker Swarm、Kubernetes和Mesos），间接实现容器软件资源部署；四是通过OpenStack的特殊组件实现特殊软件服务，如OpenStack 的Trove组件可以实现DBaaS，OpenStack的Sahara组件可以实现HadoopaaS等。

综上，在设计云管平台资源层时，要以“平台”的理念去长远规划，保证云管平台资源管理的统一性和可扩展性。

“分布式”理念：

OpenStack的开放性除了Driver框架下的平台特性，还在于分布式的特性。所有组件既可以采用

all-in-one的方式存在一个控制节点中，各个组件也可以广泛分布于各个不同的控制节点中，只需保证节点间的通信即可；不仅如此，每种组件中的子组件也可存在多个，进行分布式部署，通过LoadBlance实现负载均衡；另外，对于all-in-one架构的控制节点，也可按照不同功能、分区甚至数据中心进行区分，组成多个全套的控制节点，这多个控制节点通过将Keystone认证信息和EndPoint链接注入至其中一个主控制节点当中，实现在该主控制节点统管所有资源，实际上部署却是分布式的，互不相干的。

（1）资源层控制节点的组件all-in-one

云管平台资源层设计为所有OpenStack组件都集中在一个控制节点中，适用于计算节点和存储节点较少的场景，并且并发部署和管理的资源个数不宜太多。另外，由于只有一个控制节点，该节点的高可用也需

要考虑，尤其是控制节点中的数据库，用数据库复制技术也可，还可以用双机软件，搭建Linux操作系统的双机实现高可用，如Keepalive、TSA或者Pacemaker等。

（2）组件或者子组件分布于不同控制节点

云管平台资源层设计为所有不同的组件和子组件均衡分布于不同的控制节点当中，如下图所示为资源层架构样例，相同组件的控制节点通过应用负载节点实现负载均衡（如HAProxy），实现ACTIVE-ACTIVE；RabbitMQ的消息控制节点则可通过自身的集群实现ACTIVE-ACTIVE，所有组件均通过RabbitMQ实现异步通信，同时为保证负载均衡和自动切换，组件配置了RabbitMQ的集群节点列表。数据库节点间可通过高可用软件+数据库复制技术实现ACTIVE-STANDBY，所有数据库的访问请求均通过虚拟服务IP实现。

不仅如此，每个控制节点当中的子组件设计也可以按照“分布式”的理念进行设计，如下图所示，同样是多个相同的子组件通过HAProxy实现负载均衡，组件内部的不同子组件间也均通过RabbitMQ集群进行异步的通信。

整个架构有几下优点：

A.当计算资源不够了无法创建虚机时，可以增加计算节点或者存储节点（增加Nova-Compute、Neutron-Agent和Cinder-Provider）。

B.当客户的请求量太大调度不过来时，可以增加Scheduler或者直接增加控制节点。

C.通过消息组件RabbitMQ的异步通信实现调用，一是可以解耦各子组件和组件，他们不需要知道其他组件在哪里运行，只需要发送消息给消息组件就能完成调用。二是提高了性能，异步调用使得调用者无需等待结果返回。这样可以继续执行更多的工作，提高系统总的吞吐量。三是提高伸缩性，子组件和组件可以根据需要进行扩展，启动更多的控制节点处理更多的请求，在提高可用性的同时也提高了整个系统的伸缩性。而且这种变化不会影响到其他组件，也就是说变化对别人是透明的。

所以，该资源层的架构非常适合大规模和超大规模的云计算。

（3）多个all-in-one的控制节点功能分区

云管平台资源层的单个控制节点五脏俱全，包含了所需的所有组件，但每个控制节点的用途不一样，比如每个网络安全分区一个控制节点或者Power平台一个或多个控制节点，Vmware X86一个或多个控制节点，然后开源X86一个或多个控制节点，然后再搭建一个主控制节点，通过继承其他控制节点的KeyStone 和EndPoint实现资源的接管，在主控制节点的Dashboard上通过切换不同Region实现管理的切换。通常商用私有云管平台喜欢采用这种架构，因为商用产品的软件会做得比较全，按照它的设计理念，面面俱到。但是这样如果部署在一个控制节点上，在资源规模比较大的情况下，不可避免地会产生性能瓶颈，可靠性也存在考验。如果按照不同功能进行分区的方式，则能起到立竿见影的效果，同时也可以实现统一管理的效果。比如下面商用私有云的架构（IBM Cloud Manager+IBM Cloud Orchestrator），不同功能的ICM控制节点分别管理不同的资源池，最后在逻辑上从属于主ICM，主ICM设计为高可用集群架构，其中的部分组件则采用了ACTIVE-ACTIVE的方式，均衡负载请求，实际上这个集群架构则为第二种架构模型，相当于在这个架构模型之上，再来了一层控制节点，增加了一层深度。和第二种架构模型的区别是，第二种架构组件的子组件也可以采用分布式部署方式，而该架构只能是所有组件all-in-one。这种架构由于也是“分布式”，可适用的资源规模也可以非常大，但显然没有第二种架构灵活性高。

“动态”理念：

部署策略：顾名思议，在资源部署时能够按照不同的模板或者策略，自动地或者可选择地部署到不同的资源当中。先说部署模板，在OpenStack里面叫做Flavor，定义了VCPU，RAM，DISK，Metadata四类，Scheduler会按照flavor去选择合适的计算节点；在PowerVC里面叫做Templete，有Compute Templete和Storage Templete，按照Templete去计算节点中部署资源。再说策略，策略在OpenStack 中叫做Filter，也就是过滤规则，在部署时，按照规则的设定过滤一遍，最终选择合适的目标计算节点进行部署。比如RetryFilter（刷掉之前已经调度过的节点）、ServerGroupAntiAffinityFilter（可以尽量将Instance 分散部署到不同的节点上）、ComputeCapabilitiesFilter（根据计算节点的特性来筛选）、AvailabilityZoneFilter（为提高容灾性和提供隔离服务，可以将计算节点划分到不同的Availability Zone 中）等等，并且能够支持第三方Scheduler，按照Driver的框架，配置Scheduler_driver 即可。最后说下策略继承，云管平台的资源层由于是异构的资源层，包含了Power、商用X86、开源X86、容器、公有云，甚至Z/VM，采用的资源接管方式也不一样，有的是直接管理，有的是间接管理，直接管理可以采用云管资源层自身设定的部署策略，而间接管理由于资源池层也存在部署策略（如PowerVC、VC、公有云、容器云）则需要考虑能否将这些部署策略通过API集成过来，或者是不去集成这些策略，直接读取过来，亦或是不去管理这些策略。因为云管资源层的开发者或者厂商和间接管理的这些资源池层厂商不是同一家，相互间的配合和协同，或者一些API并不开放等，所以这一块，为了简便，直接采取不去管理这些策略，一来必要性也不是那么高，二来节约了成本。

动态优化规则：动态优化规则是通过一定的监控手段，采集资源使用情况，当触发优化规则时，通过事件通知用户，或者直接执行动作去在线迁移资源或者横纵向扩展资源。这里有两种方式来实现，一是通过Nova组件协同Ceilometer来实现。Ceilometer对底层资源使用实时采集和监控，当触发动态优化规则时，如计算节点CPU使用率、内存使用率、使用率连续3次超过所设定的阀值，则开始执行动作，按照虚拟机的权重，迁移该计算节点上的权重较低的部分虚拟机至资源池的其他计算节点当中。二是通过Heat

组件协同Ceilometer来实现，同样Ceilometer对资源使用进行采集，当触发告警阈值时，通知Heat 调度编排脚本，自动横向部署一个新的虚拟机供业务使用。Heat对资源的伸缩编排如下图所示：

2.服务抽象层的设计

云管平台的服务抽象层建立在资源层之上，也就是前面所说的狭义云管平台，官方的定义基本都是这种：Gartner 对CMP 的定义---CMP (Cloud management platforms，云管理平台)是一种管理公有云、私有云和混合云环境的整合性产品，其最小的功能范围应该包括自服务界面(self-service interfaces)、创建系统镜像(provision system images)、监控和账单(metering and billing)，以及基于策略的一定程度的负载优化(workload optimization)等。高级的功能还包括整合外部已有的企业管理系统，包括服务目录(service catalogs)、存储和网络资源配置，更高级的资源管理和监控，比如客户机性能和可用性监控等。具体见下图：

狭义云管平台本身来说，并不具备能够独立完成这些能力，而是基于对底层资源层API和企业IT管理平台API的抽象整合去实现这些能力，技术实现真正是在资源层完成的，下面这张图则是OpenStack官方核心组件的整体架构图，做了些许微调。

图中明确地指出了管理OpenStack的三种方法：Command-line interfaces（命令行界面）、GUI Tools （类似于Horizon的Dashboard图形界面工具)、Cloud Management Tools（Rightscale, Enstratius,etc)。显然，在大规模的云计算运维中，使用Command-line interfaces（命令行界面）去执行运维活动是不切实际的。使用OpenStack Horizon的Dashboard图形界面工具，其有限的功能对大规模的云计算环境而言同样是不完备的。OpenStack的Horizon并不是完整意义上的CMP，作为