你好,欢迎进入模块三“高可用架构设计”,这一讲我会和你聊聊云架构高可用原理以及秒杀系统是如何使用云架构的。

我为什么要跟你聊聊云架构呢?

实际上,许多互联网服务都是部署在云上的,这样可以聚焦业务系统的维护,而不用耗费大量精力去维护基础设施的稳定性。比如,我们讲的秒杀系统,可以充分利用云架构的基础设施,提高秒杀服务底层的可用性。

云架构分层设计及其高可用

整个云架构的分层设计如下图所示:

软件 云架构设计 云计算架构设计_架构

总体来说,云架构分为:IDC(Internet Data Center,互联网数据中心) 基础设施层、物理主机层、IaaS 层、PaaS 层、SaaS 层。它们分别提供了 IDC 基础设施高可用、物理主机高可用、虚拟主机高可用、基础组件高可用、应用服务高可用等能力。

接下来我们按照分层设计图从下到上的顺序,了解下云架构每一层是如何实现高可用的。

IDC 基础设施层

IDC 基础设施层主要包括电源、网络、空调、消防等设备,甚至包括 IDC 机房所在的大楼的物理条件。

通常,IDC 机房优先建在地震、洪水、台风等自然灾害发生概率较低的地区,所在的大楼也需要符合一定的抗灾能力,以确保整个 IDC 不因自然灾害而破坏。比如:大楼能抵抗 10 级台风、百年一遇的洪灾、抵抗 6 级地震等。

在机房环境方面,需要配备空调来控制温湿度,并且配备消防设备以防火灾。因为机房中的大量计算机设备会发出较高热量,导致整个机房温度过高而容易发生火灾。另外,湿度过高也容易导致机房内电路漏电,产生火花导致火灾。

电源和网络的高可用是如何做的呢?通常是采用冗余的方案:配备多条线路。

比如:电源同时接入火电网和水电网,并配备 UPS(Uninterruptible Power Supply,不间断电源) 和发电机;

网络出入口同时接入电信、联通和移动等多条线路,以免某条线路因光纤被挖断而断网导致整个机房网络不可用;

网络设备准备多套,比如准备两套交换机和路由器,机器上准备两张网卡接入不同交换机。

电源和网络的拓扑图如下:

软件 云架构设计 云计算架构设计_软件 云架构设计_02

即使机房内基础设施可用性有保障,也有可能因为火灾、地震等因素破坏整个机房。为防万一,这个时候就需要用到多机房部署。我们可以利用 DDNS (Dynamic Domain Name Server,动态域名服务) 通过域名解析将流量调度到多个可用的机房,一旦某个机房有故障,可以从域名解析中移除该机房外网 IP。

物理主机层

早前物理主机存储和计算是一体的,存储的磁盘主要是机械磁盘,长时间运行容易产生磁盘故障,影响计算的稳定性。现在物理主机层通常采用存储和计算分离的方案来部署,这样的好处是能尽量避免因磁盘故障而导致计算能力下降,而且还能降低存储的整体成本。

那存储和计算是如何分离的呢?存储高可用又是怎么做的呢?

为了将存储和计算分离,并提供足够的并发性能,一般采用 NAS(Network Attached Storage:网络附属存储),通过高速网卡和交换机提供高并发和高性能访问能力。

NAS 机器上的磁盘采用 RAID (Redundant Arrays of Independent Disks,磁盘阵列) 提升性能和可用性。如:用两块磁盘组成 RAID 1,其中一块磁盘当作数据镜像磁盘。假如单个磁盘故障率为 0.1%,那么两块磁盘组成 RAID 1 后,整体故障率为 0.0001%。

当存储和计算节点分离后,计算节点高可用又是如何做的呢?通常 IDC 机房会准备一批备用机器,有机器故障的时候,会从负载均衡器里将故障机器摘除,然后将备用机器加进去。

另外,对于同一业务运行中的机器,会采用虚拟 IP 和心跳技术将两台主机做成双机互备模式,如果其中一台机器故障,流量将由另一台机器自动接管,整个过程非常快,上层应用几乎无感知。有关主备切换这项技术,我将会在下一讲给大家详细介绍。

虽然通过上述手段能实现高可用,但是付出的代价是很高的。首先,IDC 运营商需要配备冗余的物理设备来满足高可用,额外投入了很多资源却不一定能带来更多的收入。其次,物理设备的更换维护成本很高,需要运维人员对硬件设备非常熟悉。

那这些问题要如何解决呢?随着虚拟化技术的发展以及在云计算的应用,催生了 IaaS 。

IaaS 层

IaaS 是 “Infrastructure as a Service” 基础设施即服务的缩写,通过虚拟化技术在宿主机上虚拟出多个运行环境,应用部署在虚拟出来的运行环境里。目前比较常用的是主机虚拟化和容器虚拟化。

什么是主机虚拟化技术呢?主机虚拟化是指利用软件来虚拟整套计算机硬件,也就是 VM (Virtual Machine,虚拟机) 。操作系统可以运行在虚拟机上。

业内比较成熟的方案主要有 VMware、KVM、Xen,配合 OpenStack 之类的云计算管理平台来管理、调度虚拟机。我们经常听到的云主机就是利用了主机虚拟化技术。

虚拟机通常配合 SDN (Software Defined Network,软件定义网络) 和 SDS (Software Defined Storage,软件定义存储) 等技术来使用,用来实现虚拟机的网络高可用和存储高可用。

那么主机虚拟化的主要作用是什么呢?我们一起看两个案例。

案例 1:

A 公司在某云厂商购买了两台云主机,这两台云主机在底层是分布在两台物理机上,但是所在物理机上还运行着 B 公司的云主机。某一天,黑客利用 B 公司软件系统的漏洞侵入了 B 公司的云主机,并执行恶意程序导致 B 公司云主机 CPU 占用达到 100%,导致 B 公司系统无法提供服务。但是 A 公司的系统却丝毫不受影响,这是为什么呢?

案例 2:

X 公司的两台云主机所在的其中一台物理机发生了故障,导致上面的云主机直接挂掉。但是,X 公司在购买云主机的时候购买了云主机热备功能,在毫无感知的情况下恢复了服务,对业务基本没影响。而 Y 公司没有购买主机热备功能,不过虚拟机调度平台检测到了故障,自动将挂掉的云主机迁移到空闲的物理机上运行,但是原先正在处理的请求都被中断了。

我们来分析下这两个案例。

在案例 1 中,虽然黑客入侵了 B 公司的云主机,但由于云主机底层采用虚拟化技术对网络、CPU、内存、磁盘等物理环境进行了隔离,黑客无法侵入到物理机,也无法侵入到同一台物理机上的 A 公司云主机。在这个案例中,云主机解决了物理机时代高可用方面的两个问题:资源隔离和安全

在案例 2 中体现了云主机相比物理机的高可用优势:热迁移和冷迁移

X 公司购买的云主机热备功能,是指利用虚拟机的 RDMA(Remote Direct Memory Access,远程直接数据存取)技术实时同步虚拟机 VM1 的内存数据同步到备用虚拟机 VM2 内,这个高可用技术叫“云主机热备”。

由于两台云主机内存状态是完全一样的,一旦 VM1 出现了故障,可以立即切到 VM2,这个过程可以做到完全自动,而且耗时是秒级别,这个高可用技术叫云主机热迁移。热迁移技术还有个最大的好处,当底层物理机需要关机维护的时候,可以将上面的虚拟机热迁移到新机器上,不会中断正在进行的业务。

Y 公司将已发生故障挂掉的云主机迁移到正常的物理机上重新运行,这个过程叫“云主机冷迁移”。借助 OpenStack 这样的管理平台,运维人员可以在电脑上操作虚拟机,而不需要在机房逐个检查物理机。比如:可以将因物理机故障而挂掉的虚拟机迁移到正常的物理机上运行,可以随时给虚拟机扩容和缩容,可以随时监控集群中的每台物理机和虚拟机的状态。

前面我们了解了主机虚拟化技术,那么容器虚拟化技术又是什么呢?

容器虚拟化技术是指利用 Linux 命名空间技术,在 Linux 系统里划分出多个互相隔离的运行环境,可以为每个运行环境单独分配资源。比如现在比较火的 Docker 便是使用了容器虚拟化技术。

它能解决什么问题呢?

虽然虚拟机有这些好处,但它的程序执行效率要比物理机差,毕竟多了一层指令翻译器用于翻译机器指令。在微服务时代,如果每个微服务都用虚拟机来实现资源隔离,物理机的性能会大打折扣。而容器虚拟化技术很好地解决了这个问题,算是对虚拟机能力的一个补充。

另外, Docker 和 Kubernetes 的出现,则将容器虚拟化技术大规模应用起来了。利用 Kubernetes 强大的调度能力、网络管理能力以及滚动更新机制,IaaS 层的可用性得到进一步提升。

虚拟化技术在云计算中的应用算是一个划时代的里程碑,标志着云计算时代正式来临。

PaaS 层

前面我们了解了 IaaS 层的高可用原理,接下来我们看下 PaaS 层高可用是如何做的。

PaaS 是“Platform as a Service” 平台即服务的缩写,云产商将通用组件打包部署在已有的主机上,并提供访问组件的 SDK 或者 API,开发者修改应用的代码引入 SDK 或者调用 API 来访问云产商提供的通用组件。比如:在阿里云上购买数据库产品,修改应用程序代码访问购买的数据库产品。

PaaS 的出现主要是为了解决 IaaS 上基础组件分发的问题。

举个例子,假如你要在一百台 IaaS 上部署新版本 MySQL、Redis、MQ,通常有两种做法:

一种是登录到每台机器上挨个执行命令来安装;另一种是制作一个包含新版本基础组件的虚拟机系统镜像,替换现有镜像。

第一种方式不需要重启虚拟机,但工作比较繁重。即使有脚本来运行,但中间可能需要处理更新失败的问题。第二种虽然可以统一更新,但需要重启虚拟机来挂载新的系统镜像,这个过程可能导致业务系统可用性降低。

PaaS 是如何解决这个问题的呢?

PaaS 采用独立的集群来提供这些基础能力,它使用多种技术手段及时发现故障、转移故障、恢复故障,提升集群可用性。如:使用读写分离、一主多从技术提升读写性能,使用主备、哨兵节点提升集群自身可用性。由于采用独立集群,在更新的时候可以独立验证功能稳定性,而不影响业务系统。

不过,业务系统对 PaaS 的性能要求比较高,通常是优先访问同一可用区、同一地区的 PaaS 服务,如果是跨地区访问,会因为网络延迟的原因极大影响业务系统的性能和可用性。

而且,业务系统接入 PaaS 的时候,通常需要引入 PaaS 的 SDK,也就意味着对业务系统的代码来说是侵入性的。如果 SDK 有 Bug,会影响业务系统的稳定性。

那么这个问题该如何解决呢?SaaS 的出现正是为了解决这样的问题。

SaaS 层

SaaS 是“Software as a Service” 软件即服务的缩写,不仅提供软件的后端,还提供软件的前端页面,达到开箱即用的效果。

SaaS 系统可以通过同城双活、异地备份、多云部署等方案来降低单云单机房故障的风险。比如:将系统同时部署在阿里云和 AWS 上,即使 AWS 故障了,也能快速切到阿里云。不同云之间使用专线同步数据。

以上便是云架构各层高可用原理的介绍。目前云架构在云原生的加持下快速发展中,未来还有很大的想象空间,我们可以持续关注。接下来,我们以一个案例来学习下如何基于云来设计高可用架构。

秒杀系统的云架构

先来看一个案例:

假如某电商创业公司,在起步阶段业务 DAU (Daily Active User,日活跃用户) 10 万左右,团队 20 人;发展阶段 DAU 100 万左右,团队 50 人;成熟阶段 DAU 500 万左右,团队 200 人。公司计划在快速发展阶段加入秒杀功能,应该如何基于云架构来设计系统架构呢?

在起步阶段,公司业务用户比较少,系统风险也小。可以考虑在 IaaS 云产商的两个机房分别购买 1 台云主机组成双活来部署业务服务。如果云产商有容器云,可以优先考虑使用容器。业务服务依赖的基础组件可以使用 PaaS,一些云产商会提供免费额度。

到了发展阶段,此时业务处于快速发展时期,通常会引入一些新的营销手段刺激消费,比如秒杀。

由于这个时候用户量已经非常可观,再加上秒杀功能会带来庞大流量,需要注重系统可用性,比如要求系统可用性达到 99.99%。

为了防止单一可用区出现故障,核心业务服务和秒杀系统最好部署在多个可用区,每个可用区部署多个服务器实例,并由 SLB 组件做服务器的负载均衡。那如何防止单一 SLB 实例出现故障呢?通常是采用多个 SLB 实例,并由 DDNS 做 SLB 实例的负载均衡。

另外,在秒杀系统内部做限流的时候,也可以选用云厂商提供的 MQ (Message Queue,消息队列) 组件限制并发流量,以便减少下游系统的压力,提升整体稳定性。

最后是成熟阶段,此时业务核心功能基本稳定,用户量初具规模。如果发生事故,很容易影响公司营收,这也就要求诸如秒杀这类涉及交易流程的系统,具有更高的可用性,比如高达 99.999%。

那么,我们可以做哪些事情呢?这个时候就可以考虑多云架构、异地多活、异地备份等措施避免更极端的故障,比如地震、洪水破坏可用区。

小结

本讲我们介绍了云计算各阶段遇到的问题和解决方案,不知道你是否已经意识到诸如 IDC 基础设施层、物理主机层、IaaS 层、PaaS 层、SaaS 层这些云架构,在高可用性上的作用呢?

业务系统上云,除了能获得云架构提供的基础设施高可用外,还能获得云架构提供的高性能、高并发、高防御等方面的多重保障。这也是最近几年,互联网公司热衷将应用迁移到云上的主要原因。当然,由于人为失误以及不可抗拒的自然灾害等原因,单云可能并不一定能满足要求,也就诞生了多云架构。

思考题:如果让你将系统从本地机房迁移到云上,应该需要做什么工作呢?

这一讲就到这里了,下一讲我会为你分享“如何通过主备切换缩减故障时间”。