牛云厂商的牛解决方案盘点(1)

当前云计算如火如荼。云计算厂商也如雨后春笋一般冒了出来。林林总总的云计算厂商。作为甲方应该如何选型呢？这些重要的云计算厂商都有哪些牛的解决方案呢？这篇文章中我来给大家一一盘点。

我们对云计算厂商按以下几个维度进行划分。

首先是商业化产品还是开源产品。

商业化的产品的好处是稳定，成熟，性能好，毕竟一个非常大的公司，要靠这件商业化的产品生存，也是一件非常不容易的事情，所以毕竟要有自己的杀手锏，对于在这方面能力一般的甲方来讲，使用商业化的产品是一个不错的选择，例如你搞不定虚拟化的原理，使用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，在一个机房切换到另一个机房。

高可用方案四是异地容灾

当你觉得一个地方两个数据中心还是不保险，例如海啸，地震，原子弹等，则可以在异地修建容灾数据中心。

大问题还是数据的问题，也即生产数据中心的数据如何备份到容灾数据中心，由于异地距离比较远，不可能像双活一样采取近同步的方式，只能通过异步的方式进行同步，也可以预见的是，容灾切换的时候，数据会丢失一部分。

由于容灾数据中心平时是不用的，不会讲所有的业务都进行容灾，否则成本太高。

对于数据的问题比较建议从业务层面进行容灾，由于数据同步会比较慢，可以根据业务需求高优先级同步重要的数据，因而容灾的层次越高越好。

例如有的用户完全不想操心，则使用存储层面的异步复制，对于存储设备来讲，是无法区分放在存储上的虚拟机哪台是重要的，哪台是不重要的，完全根据块进行复制，很可能先复制了不重要的虚拟机。

如果用户想对虚拟机做区分，则可以使用虚拟机层面的异步复制，用户知道哪些虚拟机更重要一些，哪些虚拟机不重要，则可以先同步重要的虚拟机。

如果用户可以根据业务层情况，在更细的粒度上区分哪些对业务来讲是重要的数据，例如交易数据，需要优先同步，哪些对于业务来讲是不重要的数据，例如日志数据。

在有异地容灾的情况下，可以平时进行容灾演练，看容灾数据中心是否能够真正起作用，别容灾了半天，真用上的时候掉链子。

基于上述的同城双活和异地容灾，就形成了的银行所需要的两地三中心的架构。

高可用方案五异地备份

备份是比容灾更加不灵活的一种方式，和容灾的不同是，容灾需要使得虚拟机的资源时刻准备着，等需要切换的时候，马上就用，数据和虚拟机还是热数据。而备份更多的是以冷数据的方式，将虚拟机镜像，数据库镜像等变成文件存放在价格比较便宜的存储上面，成本比容灾要低得多。

存储可以是专门用于备份的存储设备，也可以使用对象存储等大容量而且成本低的存储。

备份往往区分全量备份和差量备份，一般在重要的时间点保存全量备份，然后以后的一段时间保存差量备份，然后再全量备份，再差量备份。

备份恢复的过程也是从近的全量备份开始，逐渐补足差量备份，从而达到接近终状态的数据。

第二：国内私有云华为FusionSphere的电信解决方案解析

在国外私有云有Vmware，在国内私有云比较牛的是华为FusionSphere。华为是一家相当有狼性的公司，眼睛始终盯着业界的，从做交换机开始，就保持着对思科兼容的态度，后来做私有云，所有的功能也和Vmware对齐，并且自己的管理平台是可以兼容Vmware的，也就是说如果你用了Vmware，上了华为的私有云，可以将原来的Vmware统一管理起来，这样就能够一点一点蚕食Vmware的市场份额，现在开始做公有云，当然首先做到的一点是和AWS兼容，管理平台统一管理华为的私有云，公有云和AWS，还是那个策略，从边缘业务切入，通过售前售后服务，以及低价策略，逐渐蚕食。终形成了国内私营企业中在世界五百强中的位置。

下面我们一一来看FusionSphere的功能。FusionSphere有两个版本，一个是虚拟化版本，对标的就是Vmware。

FusionSphere的虚拟化版本的产品架构如图(来自官方的技术白皮书)

其中的FusionCompute是计算虚拟化的部分(ESX)，FusionStorage是分布式存储(vSAN)，FusionNetwork是虚拟网络(NSX)。

上面有FusionManager，除了管理自己的虚拟化平台，还会兼容第三方的，尤其是Vmware的。

FusionSphere的虚拟机热迁移功能(VMotion)

虚拟机HA功能

同城双活方案

存储层的同步复制基于的是华为自己的存储体系。

容灾方案如下

也是分了几个层次，基于存储层的，基于虚拟机层的。

备份方案如下

是不是发现所有的都很像，当然上述的都是管理层面的，对于虚拟化的底层技术，华为也做了很多的深耕，使得开源的虚拟化技术做了很多的性能增强，也就是华为的统一虚拟化平台UVP。

这就是的22项优化图。

有了这些优化，至少从功能和极限性能角度上，能和Vmware进行PK了。

说到这里还不是华为FusionSphere解决方案的重点，众所周知华为的主要大客户都是在运营商，因而华为有另外一个面向运营商的FusionSphere的版本，也即云数据中心版。

虚拟化版本由于需要统一的分布式文件系统，因而集群规模相对比较小，功能也丰富，所以一般的企业用起来比较顺手，这也是原来很多企业会采购Vmware作为虚拟化平台的原因，因而在企业领域，如果需要和Vmware进行PK，华为一般会拿出FusionSphere的服务器虚拟化版本。

然而到了运营商，情况有所变化，运营商的特点是数据中心多，服务器数目大，而且自己的IT能力比较强，有大量的开发和运维人员，原来的Vmware实在是太贵了，而且存在厂商绑定的问题，运营商在这面大的规模下，当然不希望被一家厂商绑定，于是开源就成了运营商的一个诉求。

后来有了OpenStack，后来经过发展，逐渐成为了私有云开源软件的一个标准，几乎所有的如雷贯耳的IT公司，都会加入到OpenStack的阵营。

华为在OpenStack方面投入非常的大，有大量的core都被挖到了华为，从而使得华为在OpenStack领域的贡献排名非常高。

而且针对运营商，华为基于OpenStack开发了面向运营商领域的解决方案。

如图来自华为的公开演讲。

和服务器虚拟化版本很像的一点是，下面还是FusionCompute，FusionStorage，FusionNetwork。

但是这些组件都提供了OpenStack的插件，分别对接到OpenStack的Nova, Cinder, Neutron，可以归OpenStack进行管理，从而对上提供了统一的开放API。

当然运营商领域的高可用性可以很重要的，所谓的Carrier-Class。

在这一点上，华为的KVM版本和Xen版本都是提供的，Xen版本由于开发时间长，功能丰富，是UVP的版本，但是如果有的运营商指定必须KVM，也是没有问题的。

华为的FusionCompute的Xen版本和Nova集成起来，有一个巨大的优势，就是既能满足运营商开放的技术架构的要求，另外也具备开源OpenStack，或者基于开源OpenStack开发的其他云厂商所不具备的虚拟化的特性，例如FT，HA，VMotion，双活，灾备等等。将两者的优势很好的结合在了一起。

刚才还说了，运营商往往有多个数据中心，需要统一的管理，大部分厂商的方案是统一的云管平台来管理多数据中心，这当然也没有问题。

华为还提出了基于OpenStack级联技术的多云解决方案，这样不但能够多数据中心统一管理，而且还是通过OpenStack API进行管理的，统一管理和开放性又一次结合。

第三：国外公有云AWS的金融解决方案解析

到了公有云，如果你去官网看，会发现和私有云完全不一样的状态。

会发现服务林林总总，一页根本显示不完，而所有的这些应用，几乎是没有面相与底层技术的，什么CPU核绑定啊，热迁移，机架感知等等，而大多数是面向应用的，这就是前面所说的公有云对应用相对比较友好，它可以让用户像搭积木一样，通过点点鼠标，构建自己的IT架构，所以和私有云不同，在公有云上画出的架构图是下面这个样子。

这是AWS上福米科技的一个架构。

从图中可以看出，客户有国内的IDC，也有国外的IDC，使用了AWS的两个Region，并通过Direct Connect这个服务连接起来，实现了国内和国外的互通。从而使得国外的用户访问国外的Region，国内的用户访问国内的Region，能够就近访问，加快速度。

在每一个Region里面，对于手机上访问的静态资源，例如图片，视频等，可以通过对象存储S3进行下载，通过CDN进行分发，不必走服务器，从而使得资源可以就近加载。

对于动态资源，还是要访问服务器，则首先进入负载均衡器ELB，负载均衡器后端的服务器是跨可用区的，也即一个Region里面有多个AZ，虚拟机是跨AZ部署的。

在访问Tomcat之前，先进入nignx，可能是作为展现层或者API路由的作用，真正的商务逻辑是在Tomcat中实现的。

在高并发应用场景下，往往需要缓存，这里使用了ElasticCache，也会使用消息队列，这里用了SQS。

对于数据存储，这里用了文档数据库MongoDB，也用了跨AZ的Mysql数据库。Mysql是在单独的内网VPC里面的，而Tomcat是在外网VPC里面的，两者隔离，保证了一定的安全性。

IAM是统一的认证，CloudWatch是统一的监控，SNS是消息的发布系统。

如果要自己实现这个架构，在私有云里面，所有的这些组件都需要自己搞定，然而在公有云上，这些组件都放在那里了，可以随你随意组合。

下图是中金在线的一个架构，也是比较经典的。

数据库RDS是跨AZ高可用的，为了高性能前面是ElaticCache作为缓存，EC2的服务器部署应用，这里比较有特点的是使用了Auto Scaling Group，也即EC2是弹性伸缩的，前面使用ELB做负载均衡。

有的时候还需要大数据进行支撑，在公有云上，大数据平台的搭建也是相对简单的，也是组件化的。

如图所示，如果在线的电商系统有新的交易了，可以进行批量离线处理，也可以进行实时在线处理。

如果是在线处理，有个组件叫做kinesis，是一个流式处理，将结果处理完毕后放入DynamoDB中，然后由BI系统可以看到实时的信息。

如果是离线处理，则日志往往会放入S3中，可以启动一个EMR，也即Map-Reduce程序，从S3中读取原始日志进行处理，处理的结果放入Redshift数据仓库，并通过BI进行展现。

第四：国内公有云阿里云的电商解决方案解析

国内公有云则首推阿里云，登陆阿里云的官网，你会发现组件和AWS也是非常的相似。

提到阿里牛的当然是他的电商，所以我们来详细看一下阿里云的电商解决方案。

外层的是VPC，你可以创建自己的虚拟私有网络，实现不同的租户，不同的子用户，不同的组件之间的隔离。VPC和公司的数据中心可以通过VPN连接起来，访问公司内部的ERP系统等。

对于电商系统来讲，安全也是非常重要，你可能会遭遇DDoS攻击，也可能会遭遇异常登陆，机器人刷羊毛，所以外层有安全防护层。

当请求进入了VPC，首先是通过负载均衡器，对流量进行负载均衡，分散到后端的云服务器中。

服务分成好多个层次，有应用层，中台，和数据层。

其中数据层会使用RDS数据库，当然对于大吞吐量来讲，一个RDS肯定是撑不住的，因而需要分库分表，所以前面有分布式数据库DRDS。

在高并发场景下，缓存也是必须的，所以有Memcache这一层，对于文件，图片等数据，是好保存在OSS里面，并通过CDN进行分发。

说完了数据层，我们再来看应用层，一般的应用层只有一层，而这里的架构分中台和业务应用层两层，这是我们经常提倡的一个架构，就是整个公司应该有自己共享的服务中心，一些公共的服务，如会员，订单，支付，都应该有统一的服务进行管理，而非分散到多个系统。这样一方面的好处是数据能够打通，无论你从电商上购买的数据，还是你娱乐玩游戏的数据，你乘公交车打卡的数据，你在超市购买支付的数据，在电商平台来看，都是一个统一的用户，放在一个统一的会员中心，这样就能够形成统一的用户画像，方便进行数字化运营，和精准营销。

另外一个方面，有了统一的企业中台，可以使得能力得到复用，不必要每产生一个新的系统，都要开发自己的会员中心，支付中心等，而是直接调用服务就可以了，这就是所谓的大中台，薄应用，这样推出新的应用的开发速度就会非常的快，企业创新的速度也会非常的快。

应用之间如何互相访问，这就是的EDAS系统。

基本上实现一个微服务的大部分功能都在这个框架中被涵盖。

微服务的优势在于管理变更，微服务化在于将经常需要变和遭遇性能瓶颈的部分剥离出来。然而变更意味着风险，如何保证变更后的代码质量，如何保证变更后功能保持不变，如何保证变更后不引入新的Bug，是微服务化是否成功的基本问题。不进行工程化和持续集成的微服务化，就像建立地基不稳的高楼，会使得整个工程时刻面临崩溃的风险。

所以首先微服务的基石是持续集成。

在不使用容器的情况下，持续集成流程就应该运行起来，在容器化之后，应该在持续集成流程中加入容器，这样能够使得环境在开发，测试，生产的一致性，极大的提高迭代效率，实现DevOps。

当应用容器化之后，不应该再手动的进行容器部署，而是应该通过容器平台将应用管理起来，则容器的调度，自修复，自发现，弹性伸缩，网络的配置，存储的配置等全部交给容器平台，简化容器的运维。

所以对于容器镜像，基于容器的持续集成，以及容器平台Swarm和Kubernetes的支持是必须的。

当单体应用不能满足快速变更和高并发请求的时候，可以开始进行服务拆分。服务的边界划分，调用约定，接口更新，依赖管理，切换和引流，服务拆分后是否分层，拆分后命名约定，分层调用规则，调用的全链路管理，数据库是否拆分，如何拆分，如何处理分布式事务等都是需要考虑的。

服务发现有各种方法，例如DNS，DNS+VIP，客户端服务发现，服务端服务发现，Dubbo，SpringCloud + Eureka，SpringCloud + consul等，都可以实现服务监控，负载均衡，容错功能等

在高并发场景下，当请求太多服务响应不过来的时候，需要通过服务降级，牺牲部分次要功能来保证主要功能的稳定性和可用性。

必须要对应用进行压力测试，并且根据压力测试的结果，评估系统的承受能力，并在大促的时候，做到心中有数，提前进行资源准备，保证系统顺利通过大促。当压力测试测到运营估计到的量，今年的业绩目标按照这个量走，基本上就能完成，谢天谢地拜神灵，心就不要这么贪，超出这个预估量的咱就缓缓伺候，所以一般都会限流，对外层就有个统一的限流层，内部应用之间也有客户端限流和服务端限流，保证服务本身不会挂掉。

说完了业务架构，接下来说的是数据架构。

在电商交易过程中，往往会产生三方面的数据，一个是结构化数据，如下单支付，二个是浏览的数据，例如打开了哪个页面，跳转到哪个页面，第三个是客服的数据.

这些数据都会放在数据层，或是在数据库里面，或是在对象存储里面，可以通过大数据平台MaxCompute或者E-MapReduce进行处理，处理的结果用于精准营销，推荐引擎，或者BI数据可视化。

这就是整个电商的架构。

这是部分，介绍了主要的几个厂商，后面还有大数据的厂商，开源的厂商，容器的厂商的解决方案，后面会解析。