引言

现在我们每天在用的个人 PC、智能手机，乃至云上的服务器，都是这样一台计算机。

但是，一台计算机在数据中心里是不够的。因为如果只有一台计算机，我们会遇到三个核心问题。

第一个核心问题，叫作垂直扩展和水平扩展的选择问题
第二问题叫作如何保持高可用性（High Availability）
第三个问题叫作一致性问题（Consistency）
围绕这三个问题，其实就是我们今天要讲的主题，分布式计算。

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

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

（1）把自己的网站部署在这台服务器:
最低的配置差不多是 1 个 CPU 核心、3.75G 内存以及一块 10G 的 SSD 系统盘。这样一台服务器每个月的价格差不多是 28 美元。

（2）网站很受欢迎，需要升级服务器，两个选择：

第一个选择是升级现在这台服务器的硬件，变成 2 个 CPU 核心、7.5G 内存。这样的选择我们称之为垂直扩展（Scale Up）。
第二个选择则是我们再租用一台和之前一样的服务器。于是，我们有了 2 台 1 个 CPU 核心、3.75G 内存的服务器。这样的选择我们称之为水平扩展（Scale Out）。

在这个阶段，这两个选择，从成本上看起来没有什么差异。2 核心、7.5G 内存的服务器，成本是 56.61 美元，
而 2 台 1核心、3.75G 内存的服务器价格，成本是 57 美元，这之间的价格差异不到 1%。

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

垂直扩展背后的逻辑和优势都很简单。一般来说，垂直扩展通常不需要我们去改造程序，也就是说，我们没有研发成本。那为什么我们最终还是要用水平扩展呢？你可以先自己想一想。

【答案】
原因其实很简单，因为我们没有办法不停地去做垂直扩展。我们在 Google Cloud 上现在能够买到的性能最好的服务器，是 96 个 CPU 核心、1.4TB 的内存。如果我们的访问量逐渐增大，一台 96 核心的服务器也支撑不了了，那么我们就没有办法再去做垂直扩展了。这个时候，我们就不得不采用水平扩展的方案了。

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

（4）改造软件：分布式计算【基于消息传递设计系统】
然而，一旦开始采用水平扩展，我们就会面临在软件层面改造的问题了。也就是我们需要开始进行分布式计算了。我们需要引入负载均衡（Load Balancer）这样的组件，来进行流量分配。我们需要拆分应用服务器和数据库服务器，来进行垂直功能的切分。我们也需要不同的应用之间通过消息队列，来进行异步任务的执行。

在这里插入图片描述所有这些软件层面的改造，其实都是在做分布式计算的一个核心工作，就是通过消息传递（Message Passing）而不是共享内存（Shared Memory）的方式，让多台不同的计算机协作起来共同完成任务。

而因为我们最终必然要进行水平扩展，我们需要在系统设计的早期就基于消息传递而非共享内存来设计系统。即使这些消息只是在同一台服务器上进行传递。

事实上，有不少增长迅猛的公司，早期没有准备好通过水平扩展来支撑访问量的情况，而一味通过提升硬件配置 Scale Up，来支撑更大的访问量，最终影响了公司的存亡。最典型的例子，就是败在 Facebook 手下的MySpace。

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

在这里插入图片描述

三、总结【个人总结的重点】

本文读起来比较容易，大致知道怎么回事儿就行
数据中心的服务器会遇到三个核心问题【对应解决：分布式计算】:
- 垂直扩展和水平扩展的选择问题
- 如何保持高可用性（High Availability）【尽可能排除单点故障+自动化故障转移策略】
- 一致性问题（Consistency）【本节没讲】