1.4 云计算架构

1.4.1 部署架构

我们先从云平台的部署架构角度分析，由于规模等因素的限制，私有云的部署相对公有云要简单很多。中小企业的私有云部署通常采用几百台服务器，通过vlan方式实现网络隔离，较为简单、高效。中型企业的私有云部署，需要考虑多机房网络互连和备份，通过专线互连，跨机房网络VXLAN是一个很好的解决方案。

在公有云中，资源管理按照层级划分，首先是区域（Region），每个区域都是独立的地理位置，并且完全隔离，可以实现一定程度的容错能力和稳定性，而且EC2实例支持跨区域的部署。我们以AWS的云部署为例，分为US-West（美国西部）、US-East（美国东部）、EU-West（欧盟伦敦）、EU-West（欧盟巴黎）等区域。在部署EC2实例时，可以选择区域，从而为使用者提供低延迟的服务。例如，使用你的服务的客户群体都是美国人，你可能会在美国区域内部署服务，这样能保证服务的低延迟，区域到每个用户的延迟一般推荐在100ms以内。那么区域的下一层是可用区（AZ），可用区的设计是为了容灾备份的，每个区域都用独立的电源。通过部署独立可用区内的实例，可以避免单一位置故障的影响。可用区都是独立的，区域内的可用区通过低延迟链接相连，一般建议网络延迟在10ms内，AWS结构如图1-2所示。

还是以AWS为例，美国的东部区域内有两个AZ分别是US-East-1美国东部（弗吉尼亚北部）和US-East-2美国东部（俄亥俄州），命名上是在Region后面加上数字区分，通过浮动IP的切换可以实现服务不间断。假设俄亥俄州地震导致AZ不可用，通过切换浮动IP到弗吉利亚的AZ，仍然可以保证服务的可靠性。2018年9月4日，微软通过Azure状态页面上的一份声明表示：“美国中南部的数据中心附近发生了一起恶劣的天气事件，包括雷击等，导致电源电压升高，影响了散热系统。保护数据和硬件完整性的自动化数据中心程序立即生效，关键硬件进入了有序的断电过程”，这次故障导致服务中断了22个小时。我们可以看到，对于微软等大规模的云服务商来说，要保持数据中心不间断正常运行依然比较困难，闪电、洪水、飓风、大雪和暴雨等都会影响数据中心的可用性。

每个AZ下面有多个数据中心，数据中心的网络延迟就更低了，建议在1ms内。每个数据中心可以部署多个资源池，一个Kubernetes或者一个OpenStack的集群就是一个资源池。每个资源池（集群）又有很多的物理机，物理机上面运行容器或者虚拟机。

1.4.2 架构设计

云的构建需要经历自下而上的过程，如图1-3所示。在IaaS底层技术的支撑下，SaaS服务才能更好落地。在IaaS部分整合了各种资源（计算、存储、网络），通过云操作系统，将多个数据中心的资源整合成一个大的虚拟资源池（一个超大的计算机），从这个角度上说是“合”，但最终每个用户使用的资源并不是CPU或者网卡，而是为每个用户提供多套虚拟机服务、VPC服务、对象存储服务等，从这个角度来说是“分”。通过IaaS资源整“合”再拆“分”，从而提供便于使用的基础服务，就像操作系统把底层硬件的丑陋接口转化为普通开发人员能够接受的API接口一样，IaaS云操作系统也做了类似的工作，将底层的硬件资源抽象成便于使用的云基础服务。

然后，便是平台的构建和数据的整合。PaaS抽象出了更高的服务形态，在数据存储方面，所有的数据将会集中化管理，摆脱数据孤岛，在此之上，结合大数据和人工智能等技术对数据进行分析处理。在服务使用方面，所有的服务都是以地址方式提供，这个地址可能是一个域名，也可能是多个IP。在顶层的SaaS中，达到了对应用的抽象，通过对应用的整合，提供统一的软件服务。传统上，一个公司一套ERP、CRM系统不仅是资源的浪费，而且附带着高昂的购买和维护成本，通过ERP等SaaS云服务，将服务直接提供给终端用户。

除资源管理之外，还需要借助传统的用户权限管理、计量计费、监控和安全等模块的辅助，从而形成一套完善的自助系统。