当前云计算如火如荼。云计算厂商也如雨后春笋一般冒了出来。林林总总的云计算厂商。作为甲方应该如何选型呢？这些重要的云计算厂商都有哪些牛的解决方案呢？这篇文章中我来给大家一一盘点。
我们对云计算厂商按以下几个维度进行划分。
首先是商业化产品还是开源产品。
商业化的产品的好处是稳定，成熟，性能好，毕竟一个非常大的公司，要靠这件商业化的产品生存，也是一件非常不容易的事情，所以毕竟要有自己的杀手锏，对于在这方面能力一般的甲方来讲，使用商业化的产品是一个不错的选择，例如你搞不定虚拟化的原理，使用vmware，也能获取相对稳定高性能的虚拟化平台，不能把mysql进行优化，则使用Oracle能够取得不错的性能。
当然天下没有免费的午餐，商业化的软件往往成本很高，所以很多公司基于害怕厂商绑定的风险，会选择使用开源产品来替代商业化产品，然而开源产品不相当于免费，这对于甲方的IT能力有非常高的要求，既然是开源产品，往往产品的设计，倾向于满足大部分人的共性需求，倾向于技术先进，而非功能成熟稳定，倾向于尽快推出，而暂且不考虑性能，所以一个开源的产品，往往是没有办法直接应用于生产环境的，这就需要定制化，定制化无论是由厂商来做，还是甲方来做，都需要甲方有一定的把控能力，否则一旦把开源软件定制化为一个私有化软件，则厂商绑定的风险还是存在，根本无法起到使用开源软件的作用。
第二是公有云产品还是私有云产品。
如果仔细观察就会发现，私有云和公有云虽然使用的是类似的技术，但在产品设计上却是完全不同的两种生物。
私有云厂商和公有云厂商也拥有类似的技术，但在产品运营上呈现出完全不同的基因。
私有云厂商是卖资源的，所以往往在卖私有云平台的时候伴随着卖计算、网络、存储设备。在产品设计上，私有云厂商往往会对客户强调其几乎不会使用的计算、网络、存储的技术参数，因为这些参数可以在和友商对标的过程中占尽优势。私有云的厂商几乎没有自己的大规模应用，所以私有云厂商的平台做出来是给别人用的，自己不会大规模使用，所以产品往往围绕资源展开，而不会对应用的部署友好。
公有云的厂商往往都是有自己大规模的应用需要部署，所以其产品的设计可以将常见的应用部署需要的模块作为组件提供出来，用户可以像拼积木一样，拼接一个适用于自己应用的架构。公有云厂商不必关心各种技术参数的 PK，不必关心是否开源，是否兼容各种虚拟化平台，是否兼容各种服务器设备、网络设备、存储设备。你管我用什么，客户部署应用方便就好。
如果你是一家初创公司，或者是初创项目，预算十分有限，你希望自己的技术人员更多的力量应用于应用本身，而非基础设施，那你应该用公有云。
如果你非常有钱，建设了自己的数据中心，系统有合规性要求，作为CIO，你希望增强自己的话语权，将基础设施层的资源也自己招人去管，那你应该用，私有云。
第三是国外厂商还是国内厂商。
至少目前来看，在云计算领域的技术，大多数首先产生于国外的厂商，例如虚拟化的vmware，公有云AWS，容器平台kubernetes等，而国内的厂商总是效仿在后，因而国外厂商有技术先进的优势，随着近年国内厂商技术实力的增强，以及国家自主可控的要求，还有国内厂商服务本地化做得非常好，导致很多甲方除非国内厂商搞不定，例如wmware的稳定性，其他则优先使用国内厂商。
第一：国外私有云Vmware的金融解决方案解析
在私有云方面，Vmware做的比较早，因而比较稳定。
在这里之所以介绍金融解决方案，是因为对于大多数金融公司来讲，稳定首先是第一步，类似银行根本不缺钱，所以即便vmware贵一些，只要足够的稳定，也是可以接受的。目前来讲，vmware依然是很多银行做虚拟化的首选平台，尤其是在相对核心的业务上，更是会优先选择部署在vmware上。当然后来，很多的其他国内厂商也进入银行，但是往往从边角业务切入开始的。在银行，很多情况下，Vmware常常是必然采购的，而其他的部分，才是其它厂商共同竞标招标拼价格的地方。
Vmware的稳定性不但表现在功能上，而是也表现在性能上，也即Vmware给一个安装包，部署完毕后，是什么样就是什么样，到哪里都是这个样，所以有大量的厂商都声称极限性能超越Vmware，这往往是定制化的结果，为了某个测试调整特殊的参数，从而达到这个测试非常高的极限性能，但是同时会牺牲其他方面的功能和性能。然而在真正的生产环境中使用的场景和极限性能的场景还是有差别的，是需要性能，功能，稳定性的权衡的，权衡后的各方面Vmware往往表现更佳。从代码角度来讲，做过开发的可以想象这个场景，如果你把所有的异常判断和分支逻辑都去除，只有主逻辑的话，你的程序将多么的简单，多么的高效啊。
当然Vmware同时的一个缺点就是没有定制化，而且也不会因为客户的需求抢先开发功能。无论甲方多么强势，Vmware是那个软件，还是那个软件，不会多一个功能，不会少一个功能，如果你想说有个功能你需要，国内公司如果发现时间窗口来得及，会逼迫公司的研发加班一个月赶出这个功能来，然而外企往往做不到，中国的销售还做不到说干预研发和产品的功能排期，所以你只能乖乖的等下一个版本，当然就是这点定制化，也使得外企丢了好多的单子。
Vmware基础设施的架构如图所示，首先要有物理的网络连接，统一的存储，以及服务器资源池，在物理服务器上，安装ESX，也即Vmware的虚拟化软件。
在ESX Server上创建虚拟机，虚拟机的硬盘作为文件，保持在统一的分布式文件系统VMFS上。
有一个统一的管理界面Virtual Center管理所有的配置，创建，管理虚拟的计算，网络，存储资源。
基于上述的架构，能实现的第一个功能是VMotion，常称为热迁移。
VMotion可以实现一台虚拟机从一台服务器漂移到另一台服务器，这个过程中，虚拟机里面的服务丝毫不中断。有了这个功能，当一台服务器需要维护的时候，可以将虚拟机迁移走而应用无感知，这是所有的运维十分欢迎的特性。
VMotion完毕后，虚拟机里面的一切都没有变化，包括IP地址。如果做一个实验，在一台虚拟机里面ping一个IP地址，一直ping，然后进行热迁移，当迁移完毕后，会发现这台机器还是在ping。
VMotion要依赖于共享存储，也即两个服务器上都能看到这台虚拟机的硬盘文件，这样才能使得迁移过去的虚拟机的数据都在。硬盘好说，内存难搞，内存需要不断的从源虚拟机拷贝到目标虚拟机，当然可以想象，拷贝的过程中，源虚拟机由于程序还在运行，还是会改变内存里面的数据的，这些改变了的内存页我们称为脏页，虚拟化软件会将脏页标记下来，再将脏页拷贝过去，当然拷贝的过程中还会产生脏页，当脏页的数目足够少的时候，虚拟化软件会暂停一下，然后一把将所有的脏页全部拷贝过去，完成最后的切换，所以还是会中断一点点，但是几乎无感知。
有了VMotion，就有了下面这个功能DRS，也即动态资源调度。
所谓的动态资源调度，就是设置一个阈值，当发现某台服务器过忙的时候，将里面的虚拟机迁移到不太忙的服务器，当发现某几台服务器过闲的时候，将其中的几台服务器的虚拟机聚集在一起。这样一方面可以提高资源利用效率，另一方面可以保证需要高性能的服务得到充分的计算，网络，存储资源。
对于金融企业来讲，高可用非常重要，对于高可用方面，第一个方案就是FT (Fault Tolerance) 双击热备
通过创建与主实例保持虚拟同步的虚拟机，使应用在服务器发生故障的情况下也能够持续可用。
这种方法常通过使主虚拟机 和辅助虚拟机执行相同顺序的 x86指令来完成此过程。主虚拟机捕获所有输入和事件，并在辅助虚拟机上进行重放。
辅助虚拟机执行与主虚拟机相同的指令序列，如果运行主虚拟机的主机或运行辅助虚拟机的主机发生故障，则会发生即时且透明的故障切换。
虽然FT功能很强大，但是在虚拟化中很少用到FT功能，一是对资源浪费比较严重，二是性能下降比较快，由于是指令级别的同步，因而两台虚拟机之间的距离非常近，无法完全达到容灾的目的，三是如果主虚拟机因为执行非法指令蓝屏，则辅助虚拟机也马上就会发生，根本无法保证业务延续性。
高可用方案二是虚拟机HA
虚拟机HA主要指在有一个共享存储池的情况下，当一台物理机挂了，这台物理机上的虚拟机可以迁移到其他物理机的机制。
因为虚拟机是有状态的，因而需要共享存储池来保证状态可以被另外一台物理机读取到。
在HA状态下，虚拟机的恢复时间一般在秒级别，也即当监控探测到物理机挂了之后，可以迅速在空闲的物理机上将虚拟机启动起来。
启动HA的物理机集群可以比较大，可以跨机架，比FT更能起到容灾的目标。
高可用方案三是同城双活
如果一个机架，或者整个机房，甚至整个数据中心着火了，则如何保证业务的连续性呢？
一种常用的机制是同城双活，就是在同一个城市，距离大概30km到100km的两个数据中心之间，通过高速专线互联的方式，让两个数据中心形成一个大二层网络。
同城双活最重要的是数据如何从一个数据中心同步到另一个数据中心，并且在一个数据中心故障的时候，可以实现存储设备的切换，保证状态能够快速切换到另一个数据中心。主流的存储厂商都提供在高速光纤互联情况下，在一定距离之内的两台存储设备的近实时的同步，数据双活是一切双活的基础。
基于双数据中心的数据同步，对上看起来可以形成一个统一的存储池，从而数据库层在共享存储池的情况下可以近实时的切换，例如Oracle RAC。
如图Vmware基于EMC的vplex存储同步复制，形成了统一的存储池。虚拟机在统一的存储池的情况下，也可以实现跨机房的Vmotion和HA，在一个机房切换到另一个机房。
高可用方案四是异地容灾
当你觉得一个地方两个数据中心还是不保险，例如海啸，地震，原子弹等，则可以在异地修建容灾数据中心。
第一大问题还是数据的问题，也即生产数据中心的数据如何备份到容灾数据中心，由于异地距离比较远，不可能像双活一样采取近同步的方式，只能通过异步的方式进行同步，也可以预见的是，容灾切换的时候，数据会丢失一部分。
由于容灾数据中心平时是不用的，不会讲所有的业务都进行容灾，否则成本太高。
对于数据的问题比较建议从业务层面进行容灾，由于数据同步会比较慢，可以根据业务需求高优先级同步重要的数据，因而容灾的层次越高越好。
例如有的用户完全不想操心，则使用存储层面的异步复制，对于存储设备来讲，是无法区分放在存储上的虚拟机哪台是重要的，哪台是不重要的，完全根据块进行复制，很可能先复制了不重要的虚拟机。
