共计 2551 个字符，预计需要花费 7 分钟才能阅读完成。
| 导读 | 马上双 11 了，其实双 11 不仅是天猫的双 11，在这个大生态链中，很多应用场景的流量都会增加，很多企业都担心在巨大的流量下能否安然度过。而放眼望去，这种大流量的场景更是比比皆是，流量陡增，资源需求要灵活扩展，单节点，怎样的姿势才是最佳的云计算姿势？ |
前段时间，一家企业的云服务商迁移，引起了行业的轩然大波。同时也揭示用户对于云计算行业的诸多认知误区：
- 云计算产品是否存在着资源共享？
- 用户应该如何选择不同类型的云计算产品来满足应用场景？
- 用了云服务就不用考虑高可用？
那就让我们从这个事件开始来分析云计算产品的台前幕后。
“资源共享，按需使用” 本是公共云计算区别于传统 IT 架构的关键，也是云计算模式最大的优势所在。资源共享意味着用户通过购买公共云计算服务，改变过去购买整套软硬件环境并自己运维的 IT 资源使用模式。公共云服务提供商通过搭建统一集中的云计算服务来面向社会大众提供服务，通过资源共享及规模效应降低了整个社会和单个用户使用计算资源的成本。也正是因为资源共享与规模效应，使公有云服务商能够以远高过物理资源降价的速度一次一次的面向社会降低云服务的价格。使用户能够以越来越低的价格使用到永远最新的软硬件技术所组成的云服务产品。
可以说脱离了共享，就无从谈及云计算，无论是计算，存储，网络，用户享受到的技术及价格红利都离不开共享的作用。拿最通用的阿里云 ECS 举例，云服务提供商将多个用户的计算资源需求调度在一台物理服务器上，根据用户的需求分配特定数量的资源使得用户可以在满足各自使用需求，多个用户共享一台服务器上的计算、存储、网络资源和性能。并拉低用户的平均使用成本。
用户对于云计算产品的了解和选择，业务架构的设计往往也决定着系统的整体稳定性。如果单从云产品的角度，特殊的云产品类型已经能够实现稳定且独享的为客户提供服务。
阿里云针对于不同的业务场景需求实际上是提供了两类产品：共享型产品，独享型产品，可以满足用户不同场景下的使用。
如果用户在云端需要部署的是高稳定性需求业务，例如：企业的核心业务，需要较高的底层硬件稳定性，网络稳定性的业务，云厂商可以提供独享型的产品来满足用户需求，例如：阿里云 ECS 服务器独享型实例。
阿里云 ECS 服务器独享型实例采用系统固定调度 CPU 模式，用户的所有计算，网络资源都为独占，可以保证任何时间能够达到规格指定的计算能力。不会因为其他用户的资源使用繁忙或空闲而产生波动。
当然，由于资源的独享特性，也限制了实例在整体资源充裕的情况下，抢占其他实例资源的可能性。在保证系统资源独占、稳定的前提下，没有对系统资源充分利用。
如果用户希望底层硬件能够弹性灵活，以最低的成本达成最优的使用效率，云厂商可以提供共享型产品，例如阿里云 ECS 服务器，N1，N2，E3 等规格族产品。
与独享型型实例相比，共享型实例系统采用随机的更贪婪的调度 CPU 模式，实例间共享资源将导致实例计算性能在长时间高负载时会出现上下浮动不稳定，但共享型实例的上限计算能力有可能超过同规格的独享性实例。
用户对于云计算的另外一个误区指向云计算的高可用特性，很多用户会认为：只要上云了，高可用都由云服务商提供了，无需设置高可用架构。而实际上，云产品本身只提供有限的高可用特性，而云厂商会向客户建议高可用产品和架构，来实现业务的负载均衡和容灾。
产品层面，云厂商主要提供了负载均衡、弹性扩容两类服务，例如：阿里云的 SLB 和 ESS。SLB 提供 4 层和 7 层上的负载均衡服务，可以有效避免单点故障影响整个应用系统的业务可用性。在应用部署时，通过设置虚拟服务地址（IP），将位于同一地域（Region）的多台云服务器资源虚拟成一个高性能、高可用的应用服务池；根据应用指定的方式，将来自客户端的网络请求分发到云服务器池中。
另一款产品，ESS 弹性伸缩是根据用户的业务需求和策略，自动调整其弹性计算资源的管理服务。用户根据自己的业务需求自动调整其弹性计算资源，在满足业务需求高峰增长时无缝地增加 ECS 实例，并在业务需求下降时自动减少 ECS 实例以节约成本，从而帮助用户实现高可用的部署。
用户通常也非常关注服务的可用性和稳定性，各个厂商实际上都提供了丰富的高可用架构解决方案。目前阿里云能够为用户提供 单地域多可用区容灾、多地域多可用区容高可用灾方案。
阿里云建议的单地域多可用区架构如下图所示，首先，在部署上一定要采用应用服务与数据库服务分离的部署方式，也为日后扩容提供了更灵活的基础，并且应用与数据库一体的部署方式使故障的影响被扩大。在做到应用与数据分离后，为避免单点故障，在前端购买 SLB 进行负载均衡调度，后端挂接业务节点（ECS）至少有两台，这样当后端 ECS 资源使用紧张时可以使用 ESS 进行水平业务扩展，既可以在业务峰值来临时很好地弹性创建资源，又可以在业务节点故障或者健康度低时自动的清除故障节点，恢复业务。这种架构在应对一般的机架级别故障或者可用区故障时是可以起到高可用保护的作用的。
对于一些大型企业或者对业务安全性有极高要求的行业，比如金融业等在数据可靠性、业务安全性和服务可用性方面既要求具备同地域容灾又要求具备多地域容灾时，可以采用多地域多可用区的最高级别的容灾方案，这种方案可以防止单一区域内因为不可预知原因而使所有可用区彻底毁坏的极低概率事件，在极端情况下保障业务的存活性。架构图如下：
对于企业用户如何利用云产品搭建高可用架构，网上技术专家给出了众多的解法，一篇来自微软性能架构师的评论文章《性能架构师看 IT 之家的性能问题及解法》中提到建议企业用户：
- 把 Web 和 Database 部署分离
- 用弹性扩展产品来做扩容缩容
- 采用高可用。
总而言之，对于普通的云计算使用者而言，虽然众多企业已经一轮轮的进行了云计算产品的教育，但是用户对于云计算产品仿佛仍然是雾里看花，对于云计算产品之间仍然存在着非常多的误区。双 11 将近，在诸多大流量的场景前还是要保持一个良好的用云姿势，才能做到心中有数，云上飞驰。
