一个社交App是如何构建高伸缩性的交互式系统
发表于 23:14|
摘要：本文旨在通过一个社交App的成长历程来从技术角度分析如何在云端构建大规模分布式系统，其中包括平台的可伸缩性、网络层面的扩展、数据和业务层面的扩展等。
CSDN移动将持续为您优选移动开发的精华内容，共同探讨移动开发的技术热点话题，涵盖移动应用、开发工具、移动游戏及引擎、智能硬件、物联网等方方面面，如果您有想分享的技术、观点，可通过电子邮件（tangxy#csdn.net，请把#改成@）投稿。第一时间掌握最新移动开发相关信息和技术，请关注mobilehub公众微信号（ID: mobilehub)。一个社交App需实现的功能用户关注的常规社交功能、活动、地理位置、探索功能、新鲜事、视频照片分享等等，需要提供的功能不胜枚举，所以从技术角度来说，开发者需要解决的问题也是异常复杂的。当一款社交App发布之初，用户访问量比较小，使用一台服务器就能够支撑全部的访问压力和数据存储需求，但是互联网应用具有病毒式的传播特点。一款App很可能会面临一夜爆红的现象，访问量和数据量在短时间内呈现爆发式增长，这时候会面临的局面是每天上亿PV、数百万新增用户和活跃用户、流量飙升至每秒数百兆。这些对于一个只部署了简单后端架构的应用来讲是无法支撑的，会直接导致服务器响应缓慢甚至超时，以及在高峰期时服务呈现瘫痪状态，使得后端的服务完全无法使用，用户体验急剧下降。本文将会通过一个真实的案例来分享一个社交应用如何构建一个具备高伸缩性的后端系统。社交App最初部署的后端架构解析社交App在最初的时候，后端架构相对比较简单，最初是部署在基础网络之上。最前面放置一台绑定了公网IP的nginx服务器作负载均衡，后面放置3台应用服务器来负责处理所有业务上的请求，最后面搭建一台MySQL Database数据库。构建私有网络随着产品的不断迭代、用户数的持续增长、数据量的积累，App就需要改进自己的后端架构，即开始构建私有网络。用户可以使用私有网络构建自己的网络拓扑——创建路由器和私有网络，将后续加入的用于运行内部服务的主机放置在私用网络中，可以有效地和云平台其他用户主机，在网络上实现100%二层隔离。主机对外开放的仅仅只有80端口，这样系统安全性上多了一层保障。在上面的架构图中，最前面的是防火墙，后面接负载均衡器，然后接路由器和私有网络，很多互联网应用都存在读多写少的情况，这个比例有时可以达到8:2，所以我们首先通过引入缓存分摊数据库读压力。其次，引入负载均衡器，替换最初架构中的nginx proxy，负责均衡器在这里其主要用于分发请求到后端多台应用服务器，，当其中一台应用服务器挂掉，负载均衡器可以进行自动隔离。业务分区与扩展App随着并发访问量和数据量不断增大，首先想到横向扩容Web服务。水平扩容业务服务器的前提是要保证每台服务器都是无状态的，将session信息下放到缓存或数据库中存储，保证请求被负载到任何一台服务器可以正常处理。从上图中看到，在前一步「构建私有网络」之后，增加了一个新的私有网络来扩展网络层，这里可以利用自有映像功能，将原有的应用服务器制作成模板，后续就可以基于这个模板快速启动新的主机。另外可以利用Auto-scaling（自动横向扩展）功能，根据后端服务器的负载请求，动态调整服务器的数量。一个社交应用的后端会提供很多服务请求接口，比如添加好友、刷新新鲜事、浏览页面等，可以通过日志分析每一个接口的耗时，将耗时长但非重要业务的请求分到单独的Web服务器上进行处理，从而给主Web服务器留出更多资源去处理关键业务的请求。面向服务的架构随着产品功能的不断迭代，业务代码会越来越复杂，出现故障的可能性也在加大，当一个局部功能出现问题时，都会影响整个服务的可用性。此时可以构建面向服务的架构，将一个完整且庞大的服务拆分为一个个的子服务，服务之间通过接口交互。如下图所示：社交App的服务被拆分成了四个子服务——新鲜事（News Feed）、用户资料（Profile）、广告（Ads）和探索（Explore），不同的服务之间通过消息通信框架（例如ZeroMQ）来进行交互。把一个大服务拆分为几个小的子服务的好处不言而喻，主要是：故障隔离：子服务出现故障不会影响全局，比如广告业务出现问题并不会让整个App不能使用，依然可以查看新鲜事等；独立扩展：每一个被拆分出的子服务有着不同的访问压力，比如新鲜事的调用相比一些二级页面的用户资料要高很多，所以前者会被分配更多的Web 服务器；独立部署：一个大服务的配置因功能过多会异常复杂，一旦被拆分就可根据不同的特性需求定制配置项，从而提高可管理性；团队协作开发：开发者都有着自己精通的方向，从而提高开发效率；抽象出数据访问：在后续进行数据层面（数据库、缓存）扩展时，可通过修改子服务的Data Service，实现对下层数据的透明。数据库Replication业务增长也会给数据库带来诸多问题，当最初架构中单台数据库（数据库同时提供读和写）不足已支撑起App访问压力时，首先需要做数据副本Replication。市面上常见的MySQL、MongoDB等数据库都提供Replication功能，以MySQL为例，从高层来看，Replication可分成三步：Master将改变记录到二进制日志（binary log）中（这些记录叫做二进制日志事件，binary log events）；Slave将Master的binary log events拷贝到它的中继日志（relay log）；Slave重做中继日志中的事件，将改变反映它自己的数据。具体实现该过程的第一部分就是Master记录二进制日志。在每个事务更新数据完成之前，Master在二进制日志记录这些改变。MySQL将事务串行的写入二进制日志，即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后，Master通知存储引擎提交事务。下一步就是Slave将Master的binary log拷贝到它自己的中继日志。首先，Slave开始一个工作线程——I/O线程。I/O线程在Master上打开一个普通的连接，然后开始binlog dump process。Binlog dump process从Master的二进制日志中读取事件，如果已经跟上Master，它会睡眠并等待Master产生新的事件。I/O线程将这些事件写入中继日志。SQL slave thread处理该过程的最后一步。SQL线程从中继日志读取事件，更新Slave的数据，使其与Master中的数据一致。只要该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。此外，在Master中也有一个工作线程：和其它MySQL的连接一样，Slave在Master中打开一个连接也会使得Master开始一个线程。复制过程有一个很重要的限制——复制在Slave上是串行化的，也就是说Master上的并行更新操作不能在Slave上并行操作。对于云计算使用者来说，只需要知道数据库的IP和端口即可进行使用。具体实现见下图：第一步要做的是扩充Slave，将单机Master变成Master+3台Slave的架构，而在其中的Slave上搭建一个内网的负载均衡器（Load Balancer），对于最上层的Data Service来说，只要配置一个MySQL Master节点和一个LB节点即可，今后因业务变化进行增减Slave对上层来说完全是透明的。此做法可以带来两个好处，第一是提高可用性，若是一台Master出现错误，则可以提升某一台的Slave作为Master继续提供服务，从而保证数据可用性；第二个是分摊读压力，对于一个社交App来说，读写分离是在数据层优化第一步要做的事情，利用上面的架构可以很轻易地做到将读的请求分担到MySQL Slave上进行查询，而写留给Master。但是读写分离时会有数据库一致性的问题，即在数据写至Master之后同步到Slave有一个延迟的时间，对于社交应用来说，这是可以接受的，只要保证数据的最终一致性即可。在上图的最下面有一个Snapshot，即定期对数据进行冷备份，这不同于单纯对MySQL Master进行复制的Slave，因为线上bug或误操作会删除Master上的数据，这时会立即同步到slave上造成数据丢失这时冷备份Snapshot就会起到数据保护作用。运行过程中肯定需要监控，用户可以利用Linux上的工具进行统计分析top / iotop / df / free / netstat等工具去监控系统里的各个服务和组件是否正常运行，以及通过日志的信息（http access log / application log / database slow log ）分析各个服务的性能瓶颈。数据分区与扩容下一步业务的调整要进行数据库的分区和扩容。第一，构建缓存集群，在开始的架构中引用了Memcached缓存，是单机数据库缓存。当数据量增长，，需要把数据分散到多台缓存服务器上，常用的是HashRing算法，好处在于不管是添加结点还是删除结点时，只会使得少部分数据失效。还可以引用NoSQL数据库，这里用到了Redis把社交数据里对于关系要求不强但对查询效率要求很高的数据从MySQL里拿到Redis里存。Redis尤其适合存储列表类数据，比如好友关系列表、排行榜数据等。除此以外可以考虑做数据分区对于MySQL第一步是垂直拆分，把原来单独的数据库按照功能模块分别拆分成：好友新鲜事、用户资料、广告数据以及探索数据。对于Redis也同样，将原来的单台Redis按照功能模块拆成四个，分别为：排行榜数据、好友、广告数据、探索数据。接下来会遇到的瓶颈是单表过大的问题，这时候我们需要做水平拆分——把一个表拆分成多个表，需要选取一个分区Key，比如对用户表做拆分时，通常选取User ID。分区key的选择主要是看所有的查询语句频繁使用哪个查询字段，就选择那个字段作为分区key这样能保证大部分的查询可以落在单个数据表上，少量没有带分区Key的查询语句，可能要遍历一遍所有切分后的数据表。构建完整的测试环境构建完整测试服务器时需要创建新的路由器和私有网络、独立的网络环境和带宽资源、内网GRE隧道打通路由器、VPN拨入网络和SSH密钥管理。这个过程你可以创建一个包含所有系统服务的all-in-one的环境，将其制作成自有映像。如果后续你的团队来新的人，需要独立的完整开发环境，只需基于自有镜像快速创建主机即可；还可以利用User Data定制化功能，在主机启动执行一段你上传的脚本，来初始化环境。你可以将这两个功能结合起来用，把所有你所需要用的服务全部安装部署完毕后做成映像，并用User Data脚本从代码库里更新代码。因为代码的变动相对于环境的更新更加频繁，不可能每次代码的更新都要构建一个新的自有镜像。通过这种方式构建起一个完整的测试服务器，让每个工程师都可以有自己独立的测试服务器。在App发布上线时需要连到线上环境怎么办？这两个网络本身完全100%隔离，可利用GRE隧道的功能，把两个路由器打通，实现测试环境网络和线上生产环境网络的完全连通。多机房部署与混合组网为了让后端架构更可靠和业务更稳定，就需要实施多机房部署和混合组网。具体原因有以下三点：异地容灾：在复杂的网络环境下，机房可能会出现网络状况，导致一些比较关键性的业务的可用性降低，备份机房后可保证服务不会出现明显的长时间中断；负载分摊：单独一个机房可能不足以支撑全部的请求，这时可以把一部分的请求压力分担到另一个机房；加速区域访问：在国内网络环境下，南方和北方相互之间网络访问时有较高的延迟。通过做多机房部署实现加速区域用户的访问。如上所示，有三个机房，中间是QingCloud北京1区机房，负责主营业务。左边是亚太1区机房，主要服务亚太和海外的客户。这两个机房都使用了QingCloud私有网络部署，利用路由器，通过GRE隧道或者IPsec加密隧道的方式进行互通。如果对数据传输过程的安全性要求较高，可以用IPsec的方式把两个机房相互打通，这时的访问只能通过内网IP进行访问。右边是办公室机房，工程师在这个环境下进行开发。在实现混合组网时，只要机房路由器或者网宽设备支持标准的GRE隧道协议、IP隧道协议，就可以将传统物理世界的机房与路由器连通，并最终打通公有云环境。多机房部署通常见的方案有这些：异地冷备份把主机房全套业务在异地重新构建一遍，且不需要提供线上服务，只有在主机房出现故障的时候才切换到备用机房，部署相对要简单一些。但有两方面缺点，一是成本比较高，需要双倍的费用且只是用来做冷备份，平时完全用不上；另外，当主机房突然挂掉时，备用机房再起动起来提供服务，数据需要预热，这是非常缓慢的过程，可能会出现服务响应慢，甚至不能正常提供服务。异地多活从易到难有三阶段：第一，反向代理，用户请求到第二个机房，但不做任何处理被转向第一个机房这样会对两地的延时有一定的要求。第二，在第二个机房部署应用服务器和缓存，大部分的数据请求可以从缓存中读取，不用进行跨机房请求，但当缓存失效时，依然落到第一个机房的数据库去查询。所以，这个方式不太彻底；第三，全套服务的部署，包括HTTP服务器、业务服务器、缓存和数据库的 slave。此方式使得进入第二个机房的请求，只需要在机房内就可以完成请求处理，速度更快，但会遇到数据一致性和缓存一致性的问题，针对这点也会有一些解决方法。除了数据同步过程中的不一致问题，还需要面对缓存。好的系统架构不是设计出来的，而是进化而来的构建稳定可靠的业务系统需要注意以下这些：分析用户行为，理解你的业务，如社交、电商、视频；不同的业务有不同的行业属性和特点，对于社交来讲，比较典型的特点是数据量庞大、数据查询维度多，比如查询6月11日-7月15日在xx咖啡厅我所有好友里拍过照片的人，查询条件包括好友维度、照片维度、地点维度、隐私状态维度等，这时就需要合理的做数据层面的扩展。电商的特点是定期举办大促销活动，届时会需要大量的计算资源、应用服务器来扛流量峰值，此时可利用云计算平台的弹性实现快速扩展业务，而在自己业务压力、促销来临时调用API接口，及AutoScaling扩展后端计算资源。视频业务有非常明显的流量高峰期和低峰期，流量高峰期通常是白天或者大家晚上下班回家那段时间，晚上2点到早上6点是流量非常低的时候，可利用云计算弹性优势，来调用API方式调整业务带宽资源，从而达到节省成本目的。合理规划系统，预估系统容量，如 10w / 100w / 1000w PV（DAU）：不同的系统容量有可能对应不同架构的部署方式，找到最适合自己的那一个；系统是可横向扩展的 scalable；不遗余力地解决单点问题；为出错而设计design for failure：App的后端架构在开发支出就要为可能出现的各种问题进行准备，比如异地备份等；设计面向服务的架构，拆分子系统，API交互，异步处理；构建无处不在的缓存：页面缓存、接口缓存、对象缓存、数据库缓存；避免过度设计，好的系统架构不是设计出来的，而是进化而来的。本文整理自：【】（点击链接，观看视频），演讲PPT&&。作者简介：王煜，QingCloud研发工程师，负责对象存储系统的研发，对Linux操作系统、计算机网络、分布式系统、云计算等领域有深入的研究。原街旁创始成员，基础架构负责人。
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章1OpenStack自身特点详解&&& OpenStack是什么？如果你是当今的IT技术人员，你说自己不知道OpenStack，保不准有人会在暗地里偷笑你。OpenStack是一个美国国家航空航天局和Rackspace合作研发的，以许可证授权，并且是一个自由和开放源代码项目。
图 OpenStack官网
&&& OpenStack不是一个软件，而是一个云平台管理的项目，它由几个主要的组件组合起来完成一些具体的工作。
图 OpenStack logo
&&& 2011年，OpenStack采用的调查报告中显示：73%的被调查者认为OpenStack部署由节约成本和害怕厂家锁定所。
&&& OpenStack在过去几年的增长迅速，并有了巨大的影响力，将继续支持OpenStack项目，目标是提供客户完整的监控与分析解决方案。很多人会有疑惑，为什么OpenStack会这么火？
&&& 先来了解一下OpenStack自身的特点吧。
&&& OpenStack自身特点详解
　　OpenStack Compute (Nova)是一套控制器，用于为单个用户或使用群组启动实例。它同样能够用于为包含着多个实例的特定项目设置网络。OpenStack Compute在公共云处理方面堪与Amazon EC2相提并论；而在私有云方面也毫不逊色于的产品。在公共云中，这套管理机制将提供预制的镜像或是为用户创建的镜像提供存储机制，这样用户就能够将镜像以虚拟机的形式启动。
　　OpenStack 对象存储(Swift)是一套用于在大规模可扩展系统中通过内置冗余及容错机制实现对象存储的系统。这些对象能够通过一个REST API或是像Cyberduck这样可以对接对象存储API的客户端加以恢复。
　　OpenStack镜像服务 (Glance)是一套虚拟机镜像查找及检索系统。它能够以三种形式加以配置：利用OpenStack对象存储机制来存储镜像；利用Amazon的简单存储解决方案（简称S3）直接存储信息；或者将S3存储与对象存储结合起来，作为S3访问的连接器。OpenStack镜像服务支持多种虚拟机镜像格式，包括VMware（VMDK）、Amazon镜像（AKI、ARI、AMI）以及所支持的各种磁盘格式。镜像元数据的容器格式包括Amazon的AKI、ARI以及AMI信息，标准OVF格式以及二进制大型数据。
　　2OpenStack帮我们做了些什么&&& OpenStack是一个旨在为公共及私有云的建设与管理提供的开源项目。目前，OpenStack的社区拥有超过130家企业及1350位开发者，这些机构与个人都将OpenStack作为基础设施即服务（简称IaaS）资源的通用前端。OpenStack项目的首要任务是简化云的部署过程并为其带来良好的可扩展性。
&&& OpenStack是以Python编程语言编写的，整合Tornado网页服务器、Nebula运算平台，使用Twisted软件框架。在标准上，OpenStack　　遵循Open Virtualization Format、AMQP、SQLAlchemy等标准。器软件支援包括：KVM、Xen、 、QEMU、 LXC等。
&&& OpenStack包含两个主要模块：Nova和Swift，前者是NASA开发的虚拟服务器部署和业务计算模块；后者是 Rackspack开发的分布式云存储模块，两者可以一起用，也可以分开单独用。OpenStack是开源项目，除了有 Rackspace和NASA的大力支持外，后面还有包括 Dell、Citrix、 Cisco、 Canonical这些重量级公司的贡献和支持，发展速度非常快，有取代另一个业界领先开源云平台 Eucalyptus 的态势。
　　那么，OpenStack帮我们做了些什么呢？
　　OpenStack是由Rackspace和NASA共同开发的云计算平台，帮助服务商和企业内部实现类似于Amazon EC2和S3的云基础架构服务(Infrastructure as a Service，IaaS)。OpenStack是IaaS(基础设施即服务)组件，让任何人都可以自行建立和提供云端运算服务。此外，OpenStack也用作建立内的“私有云”（Private Cloud），提供机构或企业内各部门共享资源。
&&& OpenStack第一个受益者当然是NASA。当前，OpenStack已经完成的项目包括，Nova运算项目、Swift面向对象数据存贮项目、Glance虚拟机器磁盘映像档（Virtual Machine Image）传送服务、美国国家航空航天局、加拿大半官方机构CANARIE网络的DAIR（Digital Accelerator for Innovation and Research）项目等，以及向大学与中小型企业提供研究和开发云端运算环境；DAIR用户可以按需要快速建立网络拓扑。
&&& 而且，现在少有哪个IT厂商不支持OpenStack。现时已表示支持OpenStack项目的大型硬件厂商包括：AMD、Intel和戴尔、微软、华为等。2011年2月，思科系统正式加入OpenStack项目，重点研制OpenStack的网络服务。2012年10月，Viacloud互联云平台加入OpenStack项目，研制OpenStack公有云平台和私有云平台。未来，Ubuntu将在堆栈方面的云网络化方案。
　　3OpenStack如何帮你构建私有云&&&&OpenStack如何帮你构建私有云
　　第一步是设置正确的硬件和网络环境。尽管OpenStack允许在一个单一的平面网络上部署一切，从安全的角度来看并不安全。取决于你所使用的管理程序以及虚拟网络接口，它会允许guest嗅探管理流量。建议至少使用两个网络：一个用来管理流量，一个用来进行虚拟机之间的对话。这意味着所有的云计算结点中你需要两个网卡（一个运行实例）和网络管理者。
&&& 这些应该运行在不同的IP范围中。计算结点和实例的网络也需要支持VLAN标记，因为这是在“项目”之间隔绝流量所使用的机制。一个项目等价于你的亚马逊EC2账户，除了你不能按照你所希望的数目创建和分配之外。每一个项目都有自己的管理员和用户，在既定项目中的所有实例可以彼此通信。通过指派每一个项目自己的VLAN以及内部和外部的IP地址池来执行。
　　一旦硬件和网络设置好，下一步就是确定在哪里部署所有的OpenStack组件。标准部署应有一个控制器和一系列计算结点。控制器运行消息服务器，数据库和其他的组件来编排云，同时计算几点运行实例。
&&& 但是你也可以分解控制器为地理的部分，从而改善性能，像把放在不同的物理盒中。对于安全而言，最关键的是确保每一部分都安装在安全的主机上，你只需要将其附加在网络上，让云运转即可。
　　只有两部分需要暴露给外面的世界（即使那只是你的企业网络）：API服务器/Web 控制台（如果开启）和网络管理者。这些服务器需要过硬，你甚至可以使用第三方网络接口来隔离后端管理用户连接产生的流量。
　　如果你遵循默认安装说明书，可能这些部分并不如他们应该的那样安全。下面是一些具体的改变：
　　* MySQL服务器使用指定的用户账户，不是根MySQL管理账户。这个账户和密码将会暴露在每一个云结点上，即使使用基于证书的认证，因此所有结点需要访问这个数据库服务器。
　　* MySQL配置文件中，限制访问服务器，OpenStack用户账户为唯一授权IP地址。
　　* 移除任何不需要的OS组件并确保你所设置的服务器只支持通过SSH的基于密钥的登陆。
　　* 默认MySQL和RabbitMQ（消息服务器）流量不加密。如果你隔离了管理网络和坚固的主机，这就不应该是一个很糟糕的风险。如果你的云网络易于嗅探（例如，它和其他服务器共享网络），你需要加密流量。你可以使用OpenSSL来进行MySQL 和RabbitMQ处理。（我个人还没进行测试，因此配置可能有点难。）
　　下一步，记住如果支持Web管理控制台，默认不适用SSL。4Openstack的优势&&& Openstack的优势到底有哪些？
　　很多人都好奇的询问，说了这么多Openstack功能和结构，以及项目名称。你能总结一下Openstack的优势到底在哪里吗？
&&& 可以，有媒体为Openstack做了一个优势的总结。
&&& 首先，第一个是控制性。开源的平台意味着不会被某个特定的厂商绑定和限制，而且模块化的设计能把遗留的和第三方的技术进行集成，从而来满足自身业务需要。OpenStack项目所提供的云计算，让IT团队可以成为自己的云计算服务厂商，虽然构建和维护一个开源私有云计算并不适合每一家公司；但是如果拥有基础设施和开发人员，OpenStack将是很好的选择。
　　其次是兼容性。OpenStack公共云的兼容性可以使企业在将来很容易的将数据和应用迁移到基于安全策略的、经济的和其他关键商业标准的公共云中。使用亚马逊网络服务及其他云服务的企业，抱怨最多的就是“用户被绑架，无法轻易转移数据”。在云计算社区，有一个流行的概念，即数据是有重量的，一旦将数据存在某个云计算提供商那里，它就变得繁重而难以迁移，作为企业最重要的资源，如果在迁移的过程中不能保护好数据安全，很有可能会给企业带来灭顶之灾，相信没有公司愿意承担这个风险。
　　第三是可扩展性。目前，主流的Linux操作系统，包括Fedora、SUSE等都将支持OpenStack。OpenStack在大规模部署公有云时，在可扩展性上有优势，而且也可用于私有云，一些企业特性也在逐步完善中。随着Ubuntu 12.04 LTS正式全面将Eucalyptus替换成OpenStack，OpenStack将超过Eucalyptus成为云平台基础的第一选择。
　　第四是灵活性。灵活性是OpenStack最大的优点之一，用户可以根据自己的需要建立基础设施，也可以轻松地为自己的集群增加规模。主要用Python编写的OpenStack代码质量相当高，很容易遵循，带有一个完全文档的API，用户可以使用JSON或者XML消息格式的不同组件的代码，这相当有利于项目的发展壮大。此外，OpenStack项目的代码将在极为宽松自由的 2许可下发布，这意味着任何第三方都可以重新发布这些代码，在其基础上开发私有并按照新的许可发布，给众多的云计算企业，留下了的更大的发展空间。
　　第五是行业标准。来自全球十多个国家的60多家领军企业，包括Cisco、Dell、Intel以及微软都参与到了OpenStack的项目中，并且在全球使用OpenStack技术的云平台在不断的上线。云计算领军企业的加入，会无形透露出一个信息，就是OpenStack未来可能会成为一个行业标准，而且OpenStack项目研发的初衷就是制定一套开源软件标准。
　　第六是实践检验。实践是检验真理的唯一标准，OpenStack的云操作系统，已被全球正在运营的大型公有云和私有云技术所验证过，比如，Dell公司已经推出了OpenStack安装程序Crowbar，不仅如此，OpenStack在中国的发展趋势也是非常之好，包括物联网用户、国内高校以及部分大小企业，都开始利用OpenStack建立云计算环境，整合企业架构以及治理公司内部的IT基础架构。
　　小结：在RackSpace宣布推出开源云计算平台OpenStack后，曾经震动了业界。在2010年的10月，微软表示将推动Windows Server 2008 R2和OpenStack的整合。之后不久，思科也宣布加入OpenStack，着重于OpenStack的网络功能并推出了新的NaaS服务(Network as a Service)。2011年7月底，Dell推出了第一套支持OpenStack架构的解决方案，开发了一个OpenStack安装程序Crowbar，可供企业使用Power Edge C服务器来建设一个OpenStack环境。随后HP云服务副总经理Emil Sayegh也在官方BBS上宣布加入OpenStack计划，除了提供赞助外，HP云端开发团队也将参与OpenStack计划的开发。
　　随着云计算创新的步伐不断加快，新一代的技术和成果也在快速增长。但是云计算市场的分散性导致客户难以选择云计算厂商和合作伙伴，一旦做错决定将不得不转移到新的云上进行重新构建。这对于一些大的公司来说，确实是一个挑战。 鉴于上述原因，云需要一个开源的操作系统，开源云可以避免被锁的问题，而OpenStack就是这样一个开源的云操作系统，RackSpace CTO John Engates更将OpenStack的发展比作Linux和。