云计算技术已经兴起了很多年了，但是目前很多中小型金融企业才开始或者将要开始搭建私有云平台，实现私有云落地的方案有很多，阿里巴巴、腾讯、华为、IBM，这些巨头公司都有自己的私有云产品输出。路坦力、青云、深信服等追赶者也有对外输出的私有云产品，那么对于中小金融企业来说（本文所指的中小型金融企业是指除去银行以外的证券、基金、期货、股权、金融租赁等企业），到底该如何进行选型，今天我们就这一问题进行讨论。

中小型金融企业上云要点分析

众所周知，云计算的经典模型里把云计算分为IAAS、PAAS和SAAS层，那么企业的决策者在进行企业上云规划的时候就需要先做好计划，想清楚三个问题。

第一个问题，即目前准备上到哪一层的云。因为每一层的云能实现的服务能力是不同的，对云平台的运维人员要求是不同的，同时对云平台提供者的要求也是不同的。以目前业界知名度很高的阿里巴巴集团为例，阿里云擅长的是IAAS层的能力，而蚂蚁金服则是在金融领域的PAAS层（主要是支付宝和网商银行使用的各类金融场景的中间件）有很深的积累和实践，因此阿里巴巴在对外部金融行业进行上云输出的时候，都会选用阿里云的IAAS加蚂蚁金服的PAAS这样的解决方案。

Iaas层，主要包含计算资源、存储资源、网络资源和安全资源。

云计算的基础是虚拟化技术，虚拟化中大家接触最早的就是vmware为大家提供的虚拟机，这其实就属于iaas层的计算资源的虚拟化。

存储资源，这里主要指的是存储的虚拟化，物理资源能够组成一个资源池，资源池可以横向扩展（理论上无限扩容），并且能同时提供块存储、文件存储和对象存储能力（目前市场上的商用产品不是所有的都能同时提供以上三种能力，这个需要根据业务需求具体评估优先级来选型产品）。

网络资源，主要是指网络服务能力的虚拟化，主要包括虚拟路由器，虚拟交换机，虚拟负载均衡，虚拟dns等，并且虚拟机创建出来以后要能够自动获取ip和mac地址，而不需要手动的修改ip和mac地址。安全资源，主要是指虚拟防火墙（4-7层）、安全组、态势感知和行为分析等能力。除此之外，iaas层平台还应该能提供虚拟机（包含自身数据）的本集群cdp能力以及同城跨机房的cdp能力，以及虚拟机的同城跨机房的热迁移等。

Paas层，在这里主要涉及应用开发框架、中间件、权限管理、代码管理、测试质量、环境初始化、CI/CD等。

开发框架，目前各大主流语言针对应用部署在云环境都有一些较好的开发框架，例如基于java语言的spring boot和spring cloud以及阿里巴巴的dubbo，蚂蚁金服的sofa等，尤其是最近sofa的开源，对给用户多提供了一种金融级开发框架的选择。

中间件，主要包括消息中间件、缓存中间件、数据库中间件、web应用中间件、事务中间件等。消息中间件主要包括kafka、active mq、rocket mq、rabbit mq等，这些消息中间件的选择也需要根据根据具体的应用场景以及本公司是否有相应的技术支持能力来选型，例如规模较小的公司并且没有消息总线的需求，那么选取active mq无论在部署难度还是维护难度上都比kafka容易很多；如果是规模较大的公司，有消息总线需求，并且还有消息回放的需求，研发人员能力较强，那么就比较适合使用kafka；如果还需要基于消息系统实现分布式事务的功能，那么比较推荐使用阿里巴巴开源的rocket mq。缓存中间件主要包括redis、memcache等，这块目前redis已经成为事实的主流了，市面上存在的memcache也是各个公司二次开发过的。数据库中间件这块目前开源领域的cobar、sharding-jdbc、mycat都是目前市面上使用较多的组件，选取思路也是类似消息中间件的选取方式。Web中间件在互联网领域基本被nginx和tomcat占据了80%的份额，部分传统行业还有使用apache和weblogic的。事务中间件目前使用的比较多的是TCC或者基于TCC改的代码实现。

权限管理，主要是指sso以及权限树的管理。

代码管理这块需要在公司内部统一规范的主干与分支代码管理方式，这个需要结合公司的具体情况来落地。

对于测试团队，在paas平台上除了需要做功能测试之外，还要重点关注非功能性测试，尤其在云环境下非功能性测试尤为重要，这块会在后面详述。环境初始化，是指操作系统安装好以后，需要根据机器的服务对象和类型，对例如主机名，网络参数，内核参数，基础软件，补丁进行初始化，这里有个取巧的方式就是做成统一的模板，由iaas平台负责生成，然后创建出来后，再对一些个性化的参数进行自动化调整。

CI/CD是paas平台的核心功能，是应用能够达到paas层上云的基础，目前这块各个公司基本都开始使用了或者开始做了，这里就涉及和paas层对接的问题，这个问题开发能力比较强的团队而言可能对接起来问题不大，对于以采购为主的企业，可能需要和厂家谈好明确的需求。

第二个问题，企业建设的云平台准备用在哪些场景。这里的场景主要是指传统的应用系统，还是互联网化的应用。目前根据笔者对同行业的了解和本公司实践，IAAS层可以覆盖传统的应用系统和互联网化的应用，但是PAAS层主要还是覆盖自研为主的互联网应用。场景的变化我相信也会随着云平台在企业的落地进度以及云平台带来的优点而逐步适用于更多的场景。

第三个问题，企业建设的云平台按照什么样的发展路线进行前进。引入任何一项新技术，一般都需要有一个适应水土的过程以及推广前进的过程。大多数企业的做法都是先从开发测试环境切入，推广到非核心的生产系统，再到核心的生产系统这样的一个过程。当然笔者后面还会重点讲另外一种场景需求，在这样的需求下，就需要加速新技术落地到生产环境了。

无论计划上哪一层的云，云平台计划用在哪些场景以及什么样的发展路线，要想有比较好的上云效果，从iaas层到paas层都要把标准化工作做好，只有这样后面你才能更加体会到云计算的各种便捷。现在开始炒作的智能化，其基础也是标准化，这一点后面有机会我们再讨论。

中小型金融企业上云需求分析

中小型金融企业相比于银行而言，在笔者看来最大的差别有以下四点：一是银行IT基础设施投入的预算远高于中小金融，是中小金融行业的几倍甚至十几倍；二是银行IT基础设施buffer容量远高于中小金融企业；三是银行从事IT基础设施工作的人员远高于中小金融企业；四是银行从事IT开发的人员也远高于中小金融企业。这些问题是由银行的体量远大于中小金融企业带来的，因此也会导致中小金融企业在进行上云选择时，就需要考虑以上四点对需求所带来的影响。也是基于以上四点，笔者认为中小金融企业在进行上云选择时一般会有以下一些需求：

一是采购成本需求。根据笔者的了解中小型金融企业每年投入在基础设施建设方面的预算一般只有整体IT预算的三分之一到二分之一之间，IT预算的大头还是会被开发拿走购买外部成品软件或者是支付给项目外包团队。云平台一般又是运维这边负责的，那作为运维的领导就希望自己的项目都能便宜一些，这样才能在有限的预算内做更多的事情。笔者之前和一位同行聊天，同行讲他以前在银行的时候，随便一个项目申请大几百万是很容易的，但是目前在小金融，一个几十万的预算都要经过层层的审批。通过这件事也从侧面反映了中小金融对于成本的敏感度更高，因此对企业云平台的价格希望不要太高。

二是云平台最小化部署需求。我们一般在采购一套软件也好或者采购一个平台也好，都会要求进行poc测试。一般云平台进行poc测试都是需要使用物理机服务器的，那么问题就来了，类似阿里云、腾讯云、华为云这样的大厂品牌，其部署需要十几台或者几十台物理服务器，银行的buffer容量管理做的比较好，同时投入也大，可能能够提供这些物理服务器来进行poc测试。可是让一家中小金融企业一下拿出这么多物理服务器恐怕大多数企业都拿不出来。

因此，中小金融企业在进行云平台选型时，应该需要注意该云平台进行poc测试时最小需要几台物理服务器，在正式的最佳实践部署时又需要多少台物理服务器，包括后续扩容的时候一次需要扩展几台物理服务器等。据笔者所知，现在有很多中小金融企业，在物理机服务器这块是基本没有buffer的，一般都是有项目需求的时候或者虚拟机管理员发现资源达到警戒水位后才进行申请采购的，这样也是有问题的，当遇到紧急项目时会比较被动，因此这块也是需要优化的。

三是对企业云平台的非功能性需求。众所周知，对于金融行业来说，平台的高可用、高性能、可扩展、安全、高效都是十分重要的，那么在进行选型的时候就需要从这几个维度进行评估。

高可用即是稳定性，也是放在第一位的，对于生产系统而言，功能不全可以慢慢开发，性能不够好可以逐步提升，但是稳定性一旦出了问题带来的就是生产事故，影响巨大。

高性能方面，现在金融行业的IT系统对性能的要求也是越来越高，例如银行的夜间跑批、券商和基金公司的净值计算、互联网业务面对C端的大促压力等。

可扩展方面，私有企业云平台能够支持横向扩展是最基本的需求，这样企业云平台可以随着业务规模的扩大来对底层平台进行扩容，但是在横向扩容时需要考虑平台数据重构时对平台性能的影响，这点在考察高性能时需要注意的。

安全性方面，企业云平台自身不能存在安全漏洞，或者是能够及时发现漏洞并进行修补，否则一旦企业云平台自身被攻破，那么后果不堪设想。

高效方面主要是针对使用企业云平台的管理员而言的，现在金融企业IT部门也都在搞敏捷开发，这就会在一定程度上倒逼基础设施能够尽快的交付，由原来的T+n交付提升为T+0交付，这也就是所谓的企业云平台的高效需求。

四是对企业云平台的功能性需求。企业云的功能性需求除了前面讲到的iaas层计算、存储、网络、安全几个层面的需求外还有一些其他的功能性需求。

一是关联影响分析，如果一套业务系统由n个节点组成，并且部署在企业云平台上，那么企业云平台应该能够把该业务系统的数据流程拓扑自动生成，并且生成一套流量或者是链接数的基线，当流量异常或者是数据链接数异常的时候能够报警提示。从实现的难易程度上而言，可以先自动生成主机节点级的拓扑，然后再进一步生成进程级别的拓扑。

二是企业云的同城以及异地灾备能力。现在金融企业一般都是会建设同城双活（至少是存储层面）以及异地灾备，那么引入企业云平台以后相应的也就需要企业云平台具备同城双活能力（至少是计算资源层面），否则一方面与企业的基础环境建设思路不一致，另一方面也会对高可用性造成影响。

三是一些定制化的能力，各个企业面临的情况不一样，对产品的需求也是不同的，那么这就需要企业云平台能够快速的影响一些并不是十分复杂的需求，例如某司现在和很多三方机构数据交换都是通过sftp，那么特别需要企业云平台能够一键帮助创建好sftp的用户和目录，而不用我每次手动创建。

五是对企业云平台的维护性需求。这里的维护性主要是指平台升级、补丁修复等。根据笔者所知，中小金融行业在运维方面的人数都是非常少的，70%以上都是个位数，负责云平台的很可能就是1个人，有的甚至还是1个人兼职负责企业云平台的运维，这样现状就决定了企业云平台在维护性方面需要做的更加方便。如果输出企业云的厂商做不到这点，那么就需要厂商能及时快速甚至免费的提供维护性的服务。

六是对企业云平台的开放性需求。一般而言，企业内部都有很多运维类的系统，这些系统主要分为自建的和外购两类。目前的现状是这些系统之间大多是相互独立的，形成了一个个的信息孤岛，但是现在绝大数企业也开始意识到很多数据其实需要联动消费起来才能有更好的效果，才能使这些数据得到更充分的使用，从而产生更大的价值。这就要求以前各个孤立的平台要具备开放性，能够提供丰富多样的api接口来供企业使用，让企业能够基于这些api实现对各个平台的控制，将各个平台串联起来，从而产生更大的价值，实现1+1大于2的效果。

七是对企业云平台的异构性需求。异构性需求这块平时谈论到的并不多，这也是笔者觉得要重点谈下的内容。目前中小金融企业虚拟化平台大多是vmware，有的公司是直接把vmware平台称为是企业私有云平台（在笔者看来，单纯使用虚拟机的vmware平台远远不能算是私有云平台）或者是vmware平台加上一个云管然后称之为私有云平台。这里有一个问题不知道大家有没有考虑到，虽然vmware平台上计算资源具备HA的能力，但是如果vmware平台出了问题怎么办，vmware后面连接的存储（可能是集中式存储也可能是vsan）出了问题怎么办？话句话说，也就是出现了平台级的故障要如何应对？就像2018年8月份腾讯云丢失数据事件，给使用的企业带来了巨大的损失，也就是那时起让很多人意识到多云互备的重要性。

因此，笔者认为企业云建设过程中也应该引入一套异构与vmware的云平台，从计算、存储、网络、安全的层面完全的独立解耦，对于重要的系统应该在vmware和另外异构的云平台上同时部署，这样当发生平台级故障时，就可以避免业务直接挂掉。

有人一定会问数据库层面如何使用异构的底层存储？这确实是一个好问题，因为异构存储无法实现数据一致性，因此在数据库层面笔者的看法是还是主要使用一套底层存储，并且在可能的范围内最大程度的保证主存储的可靠性，然后在另外一套存储上实现备库，通过DG等数据库同步工具进行同步，但是备库不提供服务，一旦真的主存储发生问题，再切到备库上来。当然，异构平台后，关于数据库如何更好的利用异构存储，这块儿笔者也是希望和大家多多讨论，共同提升。

超融合方案概述

建设企业级私有云，底层物理架构可以是X86服务器通过san网络连接到集中式存储的分离式架构，也可以是只使用X86服务器加万兆交换机的超融合架构。

两者相比，后者最明显的优势就是成本低。主要体现在以下几个方面：一是前者需要单独部署一套san网络；二是存储端扩容时还要考虑存储控制器是否需要一起扩容；三是分离式架构部署起来所需的物理空间也大于超融合架构，增加了机柜和电力成本。同时现在随着闪存以及x86服务器价格的进一步下调，超融合架构的整体性能并不会比分离架构差，同等金额投入的情况下，性能还优于分离式架构。另外，超融合架构组成的集群扩容时相当简单，只需要增加x86服务器并连接到交换机，并在集群里调整配置即可。这样的优势看起来特别适合对成本和运维人力敏感的中小金融企业。

下面重点从偏技术的角度来简单介绍下超融合平台。

超融合架构，以虚拟化技术为核心，利用计算服务器虚拟化、存储虚拟化、网络虚拟化、安全虚拟化等组件，将计算、存储、网络等虚拟资源融合到一台标准X86服务器中，形成基准架构单元；并且多套单元设备可以通过网络聚合起来，实现模块化的无缝横向扩展（Scale-Out），形成统一的资源池。下面我们分开逐个进行介绍：

一是计算服务器虚拟化。虚拟化是在底层硬件之上增加了一个Hypervisor层，并且可以在Hypervisor上创建多个虚拟机，虚拟机中又能安装不同的操作系统（Linux/Windows等）承载多个系统，提高物理服务器资源的使用率。

Hypervisor是一种运行在物理服务器和操作系统之间的中间软件层,可允许多个操作系统和应用共享一套基础物理硬件，因此也可以看作是虚拟环境中的“元”操作系统，它可以协调访问服务器上的所有物理设备和虚拟机，也叫虚拟机监视器VMM（Virtual Machine Monitor）。

Hypervisor是所有虚拟化技术的核心。非中断地支持多工作负载迁移的能力是Hypervisor的基本功能。当服务器启动并执行Hypervisor时，它会给每一台虚拟机分配适量的内存、CPU、网络和磁盘，并加载所有虚拟机的客户操作系统。

常见的 Hypervisor 分两类：

1. Type-I（裸金属型）

指 VMM 直接运作在裸机上,使用和管理底层的硬件资源，GuestOS 对真实硬件资源的访问都要通过 VMM 来完成，作为底层硬件的直接操作者，VMM 拥有硬件的驱动程序。裸金属虚拟化中Hypervisor直接管理调用硬件资源，不需要底层操作系统，也可以理解为Hypervisor被做成了一个很薄的操作系统。这种方案的性能处于主机虚拟化与操作系统虚拟化之间；

代表是VMware ESX Server、Citrix XenServer和Microsoft Hyper-V，Linux KVM。

2. Type-II 型（宿主型）

指 VMM 之下还有一层宿主操作系统，由于 Guest OS 对硬件的访问必须经过宿主操作系统，因而带来了额外的性能开销，但可充分利用宿主操作系统提供的设备驱动和底层服务来进行内存管理、进程调度和资源管理等。主机虚拟化中VM的应用程序调用硬件资源时需要经过:VM内核->Hypervisor->主机内核，导致性能是两种虚拟化技术中较差的；

主机虚拟化技术代表是VMware Server（GSX）、Workstation和Microsoft Virtual PC、Virtual Server等。

一般而言，裸金属型比宿主型性能更好，目前市面上的主流厂商都是基于裸金属型。

二是存储虚拟化。相比于分离式架构，有一个单独的存储设备通过san网络与主机相连接。超融合架构则是使用每台服务器自身所承载的硬盘来存放数据，基于分布式架构的设计理念和多副本的安全保障机制来进行设计。业界典型的分布式存储技术主要有分布式文件系统存储、分布式对象存储和分布式块设备存储等几种形式。分布式存储技术相关产品已经日趋成熟，并在IT行业得到了广泛的使用和验证。分布式存储软件系统具有以下特点：

高性能：数据分散存放，实现全局负载均衡，并且采用分布式缓存技术；

高可靠：采用集群管理方式，不存在单点故障，灵活配置多数据副本，不同数据副本存放在不同的机架、服务器和硬盘上，单个物理设备故障不影响业务的使用，系统检测到设备故障后可以自动重建数据副本；

高扩展：没有集中式存储控制器，支持平滑扩容，容量几乎不受限制；

易管理：存储软件直接部署在服务器上，没有单独的存储专用硬件设备，通过Web 页面的方式进行存储的管理，配置和维护简单。

无论是对象存储还是文件存储，本质上其底层依赖都是块存储，所以块存储更像是古代练武之人的内力，只要先把内力练好了，招式才可以更具有威力。这里就是想让大家知道这三者存在的一些内在联系，而这个内在联系也是非常容易被忽略的地方。

三是网络虚拟化。网络虚拟化是软件定义网络(SDN, Software Defined Network)和网络功能虚拟化(NFV, Network Function Virtualization)和虚拟化技术三者的整合。

SDN和NFV虽然是两个概念，但在虚拟世界里，它们各发挥自己的优势，相辅相成。剥离开SDN谈NFV，无非就是将之前的硬件变成了软件；剥离NFV谈SDN，SDN也只是个光架子，就算能定义流量能控制策略，但缺乏实际网络功能支撑。借用一幅图说明：

SDN是一种创新性的网络架构，它通过标准化技术（比如openflow）实现网络设备的控制层面和数据层面的分离，进而实现对网络流量的灵活化、集中化、细粒度的控制，从而为网络的集中管理和应用的加速创新提供了良好的平台，由此可获得对网络的前所未有的可编程性、自动化和控制能力，使网络很容易适应变化的业务需求，从而建立高度可扩展的弹性网络。

网络功能虚拟化(NFV, Network Function Virtualization) 以开放取代封闭，以通用替代专有——将原本传统的专业网元设备上的网络功能提取出来虚拟化，运行在通用的硬件平台上，业界称这种变化为NFV。

NFV的目标是希望通过广泛采用的硬件承载各种各样的网络软件功能，实现软件的灵活加载，在数据中心、网络节点和用户端等各个位置灵活地配置，加快网络部署和调整的速度，降低业务部署的复杂度及总体投资成本，提高网络设备的统一化、通用化、适配性。

四是安全虚拟化。安全虚拟化也是基于sdn和nfv技术，将常用的安全能力，例如：防火墙（4-7层）、访问控制、安全审计、安全组等融入到超融合系统里，使用x86服务器自身的资源来创建和部署。

中小型金融企业选择超融合厂商时的建议

上一节主要做了分离式架构和集中式架构的对比，并对超融合的技术方案进行了简要介绍。本节笔者将从自己认知的角度来分享下，对于中小型金融企业在选择超融合厂商时应该的注意事项。之所以要注重选择超融合厂商而不是直接说选择超融合产品，笔者是基于以下考虑：

一是中小金融企业由于受限于人力成本，很难自建一个可以用于生产环境的企业私有云平台，因此这就需要找到一个外部的合作伙伴一起来进行设计、实施和维护；

二是企业私有云平台对每个企业而言多多少少都会有些定制化的需求，这些需求通常也不是标准产品能够提供的，都需要做个性化的开发；

三是目前建设企业私有云可选的开源框架只有openstack，但是openstack经过实际检验，并不是足够稳定，潜在的和暴露的问题特别多，笔者也通过很多渠道了解到了openstack给企业带来的痛苦。

基于以上原因，笔者认为中小型金融企业在进行超融合厂商选择时，应该重点从以下几个方面考虑：

一是较为成熟的案例。这一条应该是最基本的要求，作为一个具有一定实力的云计算平台提供商，成熟的案例意味着已经得到了客户一定程度的认可。这里所谓的成熟案例，不是指签了多大的合同或者部署了多大的规模，而是首先要看案例使用在什么行业，不同行业对云平台稳定性、性能和功能的要求是不同的，其次是场景，要看案例是用该平台做生产环境还是开发测试环境，不同的场景对云平台的要求也是完全不同的，最后是看规模，云平台部署规模不同遇到的技术难点也是不同的，但是对规模也没必要过度追求，不能要求每个厂商都像阿里云一样的部署规模才可以接受。

二是公司具有一定的实力或者规模。既然是选择一个合作伙伴，而不是做一锤子的买卖，不能说还没过几天这个公司倒闭了。如果出现了这样的情况，那么之前在这个平台上的投入都相当于是石沉大海了，这对于大多数中小型金融行业是不能接受的，相关领导可能也会被批评。那么什么样的公司算是有实力的公司呢？这是个仁者见仁智者见智的问题，笔者浅见世界500强、上市公司（国外以及A股）、业界运营10年以上口碑还不错的公司都能算是有实力的公司。

三是在产品层面云平台是该公司的主要战略方向。这一条其实和第二条是有一定的关联性的，如果这家企业是符合条件二的，但是这家企业的产品里没有私有云平台或者是产品里有私有云平台，但是战略规划里没有私有云平台那么你在选择的时候就不能单纯的认为这家企业有实力，你就去选择。毕竟不在战略规划的里的产品，一方面得不到公司级资源的支持，另一方面也可能有被裁掉的风险。

四是合作态度积极。这里的合作态度积极不是指厂商积极的把产品卖给客户，而是认同前文所述能够积极的和客户一起建设属于客户的企业级私有云平台，在此前提下，合作态度积极还应该包括：首先，愿意听取客户的来自一线的真实需求，了解客户的痛点；其次，对于客户提出的关于云平台方面的问题能够快速的响应；再次，云平台在测试或者使用过程中如遇到问题，厂商的工程师能够第一时间到达现场或者远程处理（根据具体的情况）；最后，厂商能够定期举行交流活动，进一步收集用户对云平台的使用情况。

五是POC测试能够满足需求。前面说了那么多，如果在POC测试环节不能满足客户需求，那么就没有什么好说的了，相当于不及格。简单说下笔者认为POC测试应该关注些什么，对于金融行业而言，基础设施类最需要关注的就是稳定性（不允许丢数据、不允许经常的不能对外提供服务）和性能（批量预算场景较多），然后才是功能。对于企业私有云平台而言，稳定性测试除了比较暴力的，拔出磁盘、机器断电、机器关机等，还需要承载业务跑一段时间，至少是3个月。性能测试则用通用的性能压测工具就可以。功能测试有一点容易被遗漏，就是平台提供的api接口是否好用，是否稳定。

六是最小化部署的规模。对于中小型金融企业而言，机房容量有限，空闲的备机有限，那么在进行poc测试的时候就需要关注该企业级私有云平台部署起来最小需要多少个物理节点，是否是本企业能够承受的。另外，如果最小化部署节点数较少，即使后面使用过程中出现了大问题，计划停止该私有云平台的使用，那么也不会造成太大的物理资源浪费，这些物理机资源可以在其他场合再次使用。

总结

本文简要分享了中小型金融企业基于超融合技术建设私有云的思路，技术和需求都是在不断的更新和变化中，但是思路变化的频率却低很多，找到适合自己企业的建设思路，才能更好的驾驭技术，最优的实现需求。

标签：存储,虚拟化,私有,平台,融合,中小型,服务器,企业,金融
来源： https://blog.51cto.com/u_15127572/2726218