深刻浅出计算机组成原理学习笔记：第五十一讲

1、原理篇总结回顾

今天是原理篇的最后一篇。过去50讲，咱们一块儿看了抽象概念上的计算机指令，看了这些指令怎么拆解成一个个简单的电路，以及CPU是怎么经过一个一个的电路组成的。咱们还一块儿看了高速缓存、内存、SSD硬盘和机械硬盘，以及这些组件又是怎么经过总线和CPU连在一块儿相互通讯的。

把计算机这一系列组件组合起来，咱们就拿到了一台完整的计算机。如今咱们天天在用的我的PC、智能手机，乃至云上的服务器，都是这样一台计算机。

只有一台计算机要解决的三个问题

可是，一台计算机在数据中里是不够的。由于若是只有一台计算机，咱们会遇到三个核心问题。

第一个核心问题，叫做 垂直扩展和水平扩展的选择问题，

第二问题叫做 如何保持高可用性（High?Availability），

第三个问题叫做 一致性问题（Consistency）。

围绕这三个问题，其实就是咱们今天要讲的主题，分布式计算。固然，短短的一讲确定讲不完这么大一个主题。分布式计算拿出来单开一个专栏也绰绰有余。咱们今天这里讲的目标，

是让你能理解水平扩展、高可用性这两个核心问题。对于分布式系统带来的一致性问题，咱们会留在咱们的实战篇里面，再用案例来为你们分析。

2、从硬件升级到水平扩展

从技术开发的角度来说，想要在2019年创业真的很幸福。

一、创业初期

只要在AWS或者阿里云这样的云服务上注册一个帐号，一个月花上一两百块钱，你就能够有一台在数据中内心面的服务器了。并且这台服务器，能够直接提供给世界各国人民访问。若是你想要作海外市场，你能够把这个服务器放在美国、欧洲、东南亚，任何一个你想要去的市场的数据中内心，而后把本身的网站部署在这台服务器里面就能够了。

固然，这台服务器就是咱们在第34讲里说的虚拟机。不过由于只是个业余时间的小项目，一开始这台服务器的配置也不会过高。我以我如今公司所用的Google Cloud为例。最低的配置差很少是1个CPU核心、3.75G内存以及一块10G的SSD系统盘。这样一台服务器每月的价格差很少是28美圆。

二、访问量上来后到底选择水平扩展仍是垂直扩展

幸运的是，你的网站很受你们欢迎，访问量也上来了。这个时候，这台单核心的服务器的性能有点不够用了。这个时候，你须要升级你的服务器。因而，你就会面临两个选择。

第一个选择是升级如今这台服务器的硬件，变成2个CPU核⼼、7.5G内存。这样的选择咱们称之为 垂直扩展（Scale Up）。

第二个选择则是咱们再租一台和以前同样的服务器。因而，咱们有了2台1个CPU核心、3.75G内存的服务器。这样的选择咱们称之为 水平扩展（Scale Out）。

一、成本上来比没什么差别

从成本上看起来没有什么差别。2核心、7.5G内存的服务器，成本是56.61美圆，而2台1核心、3.75G内存的服务器价格，成本是57美圆，这之间的价格差别不到1%。

不过，垂直扩展和水平扩展看似是两个不一样的选择，可是随着流量不断增长。到最后，只会变成一个选择。那就是既会垂直扩展，又会水平扩展，而且最终依靠水平扩展，来支撑Google、Facebook、阿里、腾讯这样体量的互联网服务。

二、垂直扩展的优点

垂直扩展背后的逻辑和优点都很简单。通常来讲，垂直扩展一般不须要咱们去改造程序，也就是说，咱们 没有研发成本。那为何咱们最终仍是要用水平扩展呢？你能够先本身想想。

三、那为何选择了水平扩展了

一、选择水平扩展的缘由

缘由其实很简单，由于咱们没有办法不停地去作垂直扩展。咱们在Google Cloud上如今可以买到的性能最好的服务器，是96个CPU核心、1.4TB的内存。若是咱们的访问量逐渐增长，一台96核心的服务器也支撑不了了，那么咱们就没有办法再去作垂直扩展了。这个时候，咱们就不得不采用水平扩展的方案了。

96个CPU核心看起来是个很强大的服务器，可是你算一算就知道，其实它的计算资源并无多少。你如今多半在用一台4核心，或者至少也是2核心的CPU。96个CPU也就是30~50台⽇常使用的开发机的计算性能。而咱们今天在互联网上遇到的问题，是天天数亿的访问量，靠30~50台我的电脑的计算能里想要要撑这样的计算需求，可谓是天方夜谭了。

二、水平扩展须要咱们在软件层面进行改善

然而，一旦开始采用水平扩展，咱们就会面临在软件层面改造的问题了。也就是咱们须要开始进行 分布式计算了。咱们须要引如 负载均衡（Load?Balancer）这样的组件，来进行流量分配。咱们须要拆分应用服务器和数据库服务器，来进行垂直功能的切分。咱们也须要不一样的应用之间经过消息队列，来进行异步任务的执行。

 

 

 全部这些软件层⾯的改造，其实都是在作分布式计算的⼀个核⼼⼯做，就是经过消息传递（MessagePassing）⽽不是共享内存（Shared?Memory）的⽅式，让多台不一样的计算机协做起来共同完成任务。

⽽由于咱们最终必然要进⾏⽔平扩展，咱们须要在系统设计的早期就基于消息传递⽽⾮共享内存来设计系统。即便这些消息只是在同⼀台服务器上进⾏传递。

事实上，有很多增⻓迅猛的公司，早期没有准备好经过⽔平扩展来⽀撑访问量的状况，⽽⼀味经过提高硬件配置Scale Up，来⽀撑更⼤的访问量，最终影响了公司的存亡。

最典型的例⼦，就是败在Facebook⼿下的MySpace。

3、理解高可用性和单点故障

尽管在1个CPU核⼼的服务器支撑不了咱们的访问量的时候，选择垂直扩展是一个最简单的办法。不过若是是个人话，第一次扩展我会选择水平扩展。

选择水平扩展的一个很好的理由，固然是能够“强迫”从开发的角度，尽早地让系统可以支持水平扩展，避免在真的流量快速增长的时候，垂直扩展的解决方案跟不上趟。不过，其实还有一个更重要的理由，那就是
系统的可用性问题。

一、水平扩展另一个重要的理由就是系统的可用性

上面的1核变2核的垂直扩展的方式，扩展完以后，咱们仍是只有1台服务器。若是这台服务器出现了一点硬件故障，好比，CPU坏了，那咱们的整个系统就坏了，就不可用了。

若是采用了水平扩展，即使有一台服务器的CPU坏了，咱们还有另一台服务器仍然可以提供服务。负载均衡可以经过健康检测（Health Check）发现坏掉的服务器没有响应了，就能够自动把全部的流量切换到第2台服务器上，这个操做就叫做故障转移（Failover），咱们的系统仍然是可用的。

二、什么是系统的可用性？

系统的 可用性（Avaiability）指的就是，咱们的系统能够正常服务的时间占比。不管是由于软硬件故障，仍是须要对系统进行停机升级，都会让咱们损失系统的可用性。可用性一般是一个百分比的数字来表示，比
如99.99%。咱们说，系统每月的可用性要保障在99.99%，也就是意味着一个月里，你的服务宕机的时间不能超过4.32分钟。

有些系统可用性的损失，是在咱们计划内的。好比上面说的停机升级，这个就是所谓的计划内停机时间（Scheduled Downtime）。有些系统可用性的损失，是在咱们计划外的，好比一台服务器的硬盘突然坏
了，这个就是所谓的计划外停机时间（Unscheduled Downtime）。

三、系统的可用性必定不可能作到100%

咱们的系统是必定不可能作到100%可用的，特别是计划外的停机时间。从简单的硬件损坏，到机房停电、光缆被挖断，乃至于各类天然灾害，笔如地震、洪水、海啸，都有可能使得咱们的系统不可用。做为一个工程师和架构师，咱们要作的就是尽量低成本地提升系统的可用性。

一、硬件服务的可用性

我们的专栏是要讲计算机组成原理，那咱们先来看一看硬件服务器的可用性。

如今的服务器的可用性都已经很不错了，一般都能保障99.99%的可用性了。若是咱们有一个小小的三台服务器组成的小系统，一台部署了Nginx来做为负载均衡和反向代理，一台跑了PHP-FPM做为Web应用服务
器，一台用来做为MySQL数据库服务器。每台服务器的可用性都是99.99%。那么咱们整个系统的可用哪性是多少呢？你能够先想想。

答案是：99.99%×99.99%×99.99%=99.97%在这个系统当中，这个数字看起来彷佛没有那么大区别。不过反过来看，咱们是从损失了0.01%的可用性，变成了损失0.03%的可用性，不可用的时间变成了原来的3倍。若是咱们有1000台服务器，那么整个的可用性，就会变成99.99%^1000=90.5%。也就是说，咱们的服务一年里有超过一个月是不可用的。这可怎么办呀？

 

 二、单点故障问题

咱们先来分析一下缘由。之因此会出现这个问题，是由于在这个场景下，任何一台服务器出错了，整个系统就无法用了。这个问题就叫做 单点故障问题（Single Point of Failure，SPOF）。咱们这里的这个假设特别糟糕。咱们假设这1000台服务器，每个都存在单点故障问题。因此，咱们的服务也就特别脆弱，随便哪台出现点风吹草动，整个服务就挂了。

四、如何解决单点故障

要解决单点故障问题，第一点就是要移除单点。其实移除单点最典型的场景，在咱们水平扩展应用服务器的时候就已经看到了，那就是让两台服务器提供相同的功能，而后经过负载均衡把流量分发到两台不一样的服务器去。即便一台服务器挂了，还有一台服务器能够正常提供服务。

一、不在一个服务器上、不在一个机架上、不在一个交换机上

不过光用两台服务器是不够的，单点故障其实在数据中内心面无处不在。咱们如今用的是云上的两台虚拟机。若是这两台虚拟机是托管在同一台物理机上的，那这台物理机自己又成为了一个单点。那咱们就须要把
这两台虚拟机分到两台不一样的物理机上。

不过这个仍是不够。若是这两台物理机在同一个机架（Rack）上，那机架上的交换机（Switch）就成了一个单点。即便放到不一样的机架上，仍是有可能出现整个数据中心遭遇意外故障的状况。

二、异地多活

去年我本身就遇到过，部署在Azure上的服务所在的数据中信，由于散热问题触发了整个数据中心全部服务器被关闭的问题。面对这种状况，咱们就须要设计进行 异地多活的系统设计和部署。因此，在现代的云服
务，你在买服务器的时候能够选择服务器的area（地区）和zone（区域），⽽要不要把服务器放在不一样的地区或者区域里，也是避免单点故障的一个重要因素。

只是可以去除单点，其实咱们的可用性问题尚未解决。好比，上面咱们的负载均衡把流量均匀地分发到2台服务器上，当一台应用服务器挂掉的时候，咱们的确还有一台服务器在提供服务。可是负载均衡会把一半的流量发到已经挂掉的服务器上，因此这个时候只能算做一半可用。

三、故障转移机制

想要让整个服务彻底可用，咱们就须要有一套故障转移（Failover）机制。想要进行故障转移，就首先要能发现故障。

以咱们这里的PHP-FPM的Web应用为例，负载均衡一般会定时去请求一个Web应用提供的健康检测（Health?Check）的地址。这个时间间隔多是5秒钟，若是连续2~3次发现健康检测失败，负载均衡就会
自动将这台服务器的流量切换到其余服务器上。因而，咱们就自动地产生了一次故障转移。故障转移的自动化在大型系统中是很重要的，由于服务器越多，出现故障基本就是个必然发生的事情。而自动化的故障转移既可以减小运维的人手需求，也可以缩短从故障发现到问题解决的时间周期，提升可用性。

那么，让咱们算一算，经过水平扩展相同功能的服务器来去掉单点故障，而且经过健康检查机制来触发自动的故障转移，这样的可用性会变成多少呢？你能够拿出纸和笔来试一下。

不知道你想明白应该怎么算了没有，在这种状况下，咱们其实只要有任何一台服务器可以正常运转，就能正常提供服务。那么，咱们的可⽤性就是：

100%-(100%-99.99%)×(100%-99.99%)=99.999999%

能够看出，不能提供服务的时间就减小到了原来的万分之一。

固然，在实际状况中，可用性无法作到那么理想的地步。光从硬件的角度，从服务器到交换机，从网线链接到机房电力，从机房的总体散热到外部的光纤线路等等，可能出现问题的地方太多了。这也是为何，咱们须要从整个系统层面，去设计系统的高可用性。

4、总结延伸

讲到这力里，相信你已经很清楚，为何咱们须要水平扩展了。对于怎么去设计整个硬件的部署，来保障高可用性，你应该也有了一个清晰的认识。这两点也是分布式计算在实践中很是重要的应用场景。

不过，光有这两点仍是不够的。一旦系统⾥⾯有了不少台服务器。特别是，为了保障可用性，对于一样功能的、有状态的数据库进行了水平的扩展，咱们就会面临一个新的挑战，那就是分区一致性问题。不过，这个问题更多的是一个软件设计问题，我把它留在后面的实战篇再进行讲解。

咱们下面来回顾一下这一讲的内容。咱们讲了经过升级硬件规格来提高服务能能的垂直扩展。除此以外，也能够经过增长服务器数量来提高服务能力。不过归根到底，咱们必定要走上水平扩展的路径。

一方面是由于垂直扩展不可持续；另外一方面，则是只有水平扩展才能保障高可用性。而经过水平扩展保障高

可用性，则须要咱们作三件事情。第一个是理解可用性是怎么计算的。服务器硬件的损坏只是可能致使可用性损失的因素之一，机房内的电路、散热、交换机、网络线路，都有可能致使可用性损失。而外部的光缆、天然灾害，也都有可能形成咱们整个系统的不可用。

因此，在分析设计系统的时候，咱们须要尽量地排除单点故障。进一步地，对于硬件的故障，咱们还要有自动化的故障转移策略。在这些策略都齐全以后，咱们才能真的长舒一口气，在海量的负载和流量下安心睡个好觉。