要设计出一套能支撑几十亿人的系统是很困难的。对于软件架构师来说，这一直是一项很大的挑战，但是，从现在开始，看完我的文章，你就会觉得容易很多了。

下面是我在本文中提到的几个话题：

• 从最简单的开始：万事合一。
• 可扩展性的艺术：纵向扩展，横向扩展。
• 扩展关系型数据库：主-从复制、主-主复制、联合、分片、非规范化和 SQL 调优。
• 使用哪种数据库：NoSQL 还是 SQL？
• 先进概念：缓存、CDN、geoDNS 等。

在这篇文章里，我不打算谈论诸如容错、可靠性、高可用性等高性能计算的通用术语。

废话不多说，言归正传。

从头开始

在下图中，我要先设计一个有一些用户的基本应用。最容易的方式是在一台服务器上部署整个应用。我们中的大部分人可能都是这样开始的。

• 一个网站（包括 API）在 Apache（或 Tomcat）等网络服务器上运行。
• 一个 Oracle（或 MySQL）之类的数据库。

我们在同一台物理机上同时拥有 Web 服务器和数据库服务器。

但是，当前的架构存在下列缺陷：

• 如果数据库出现故障，则系统将失效。
• 一旦网络服务器出现故障，则会导致整个系统的瘫痪。

在这种情况下，我们没有故障转移和冗余。如果一个服务器出现故障，所有的都将会失效。

使用 DNS 服务器来解析主机名和 IP 地址

在上图中，用户（或客户端）连接到 DNS 系统，以获得我们系统所在的服务器的互联网协议（IP）地址。一旦获得 IP 地址，请求就会直接发送到我们的系统。

每次访问网站时，计算机都会执行 DNS 查询。

通常情况下，域名系统（DNS）服务器是作为托管公司提供的付费服务使用的，并不在你自己的服务器上运行。

可扩展性的艺术

由于很多原因，我们的系统可能需要进行扩展，例如数据量的增加、工作量的增加（如事务的数目），以及用户的增加。

可扩展性一般是指添加更多的资源，在不影响用户体验的情况下处理更多的用户、客户机、数据、事务或请求。

我们必须决定怎样才能扩大这个系统的规模。在这种情况下，有以下两种类型的扩展：纵向扩展（scale up） 和横向扩展（scale out）。

纵向扩展 vs 横向扩展

纵向扩展：在现有服务器上增加更多的内存和 CPU

这也被称为“垂直扩展”，是指为了提高系统处理日益增长的负载的能力而使系统能够最大限度地利用资源——例如，通过增加内存和 CPU 来增加服务器的能力。

如果我们运行的服务器有 8G 的内存，那么只要更换或者增加硬件，就可以轻松地提升到 32G，甚至 128G。

有很多方法可以进行纵向扩展，具体如下：

• 通过在 RAID 阵列中增加更多的硬盘来增加 I/O 容量。
• 通过切换到固态硬盘（SSD）来改善 I/O 访问时间。
• 切换到具有更多处理器的服务器。
• 通过升级网络接口或安装额外的网络接口来提高网络吞吐量。
• 通过增加内存来减少 I/O 操作。

对于小型系统来说，纵向扩展是一个很好的选择，可以负担得起硬件升级，但也存在一些严重的限制，具体如下：

• “不可能在一台服务器上增加无限的能力”。这主要取决于操作系统和服务器的内存总线宽度。
• 给系统升级内存时，必须关掉服务器，因此，如果系统只有一台服务器，停机是不可避免的。
• 强大的机器往往要比流行的硬件昂贵很多。

纵向扩展不仅适用于硬件方面，也适用于软件方面，例如，它包括优化查询和应用程序代码。

相比之下，纵向减缩（scale down）是指从现有的服务器中移除现有的资源，如 CPU、内存和磁盘。

您需要多台服务器吗？

当用户数量不断增加时，一台服务器将无法满足需求。我们需要考虑将一台单独的服务器分离到多台服务器上。

当用户数量不断增加时，一台服务器将无法满足需求。

采用该架构有如下优势：

• 可对 Web 服务器进行不同于数据库服务器的调优。
• 网络服务器需要更好的 CPU，而数据库服务器需要更多的内存。
• 为 Web 层和数据层提供单独的服务器，允许它们彼此独立地进行扩展。

横向扩展：添加任意数量的硬件和软件实体

这也被称为“水平扩展”，是指向资源池中添加更多的实体（如机器、服务等）。横向扩展要比纵向扩展更难实现，因为我们必须在建立一个系统之前就把这个问题考虑进去。

开始时，为了满足最基本的需求，我们需要更多的服务器，因此横向扩展最初往往花费更多，但是到了最后，我们将获得更多的收益。我们需要权衡利弊。

服务器数量的增长意味着更多的资源需要维护。同时，还必须对系统代码进行修改，以便实现在多台服务器间进行并行和分配工作。

与此相反，横向减缩（Scale in）指的是删除现有服务器的过程。

使用负载均衡器来均衡所有节点上的流量

负载均衡器是一种专门的硬件或软件组件，它可以帮助分散流量到服务器集群，从而改善系统的响应能力和可用性，包括但不限于应用程序、网站或数据库。

使用负载均衡器来均衡所有节点之间的流量。

负载均衡器一般都是在客户端与服务器之间，接受传入的网络及应用程序的流量，并利用各种算法，将流量分配到多个后端服务器。所以，它也可以用于各种场合，比如 Web 服务器与数据库服务器之间，以及客户端和 Web 服务器之间。

HAProxy 和 Nginx 是目前比较受欢迎的开源负载均衡软件。

负载均衡器技术是一种能够改善系统可用性的容错保护方法，具体如下：

• 如果服务器 1 脱机，则所有的流量将被路由到服务器 2 和服务器 3。网站就不会脱机。你还需要在服务器池中添加一个新的健康服务器来均衡负载。
• 当流量快速增长时，你只需要向网站服务器池添加更多的服务器，负载均衡器将为你路由流量。

负载均衡器通过不同的策略和任务分配算法对负载进行了最优分配，具体如下：

• 循环：在这种情况下，每个服务器按顺序接收请求，类似于先进先出（FIFO）。
• 最少的连接数：连接数最少的服务器将被引导到请求。
• 最快的响应时间：具有最快响应时间的服务器（最近或经常）将被引导到请求。
• 加权：较强大的服务器将比较弱的服务器收到更多的请求加权策略。
• IP 哈希：在这种情况下，计算客户的 IP 地址的哈希值，将请求重定向到服务器。

在多个服务器之间均衡请求的最直接方法是使用一个硬件设备。

• 从共享 IP 中添加和删除真正的服务器，将会立即发生。
• 负载均衡可以根据需要进行。

软件负载均衡是硬件负载均衡器的一个廉价替代品。其操作于第 4 层（网络层）和第 7 层（应用层）。

• 第 4 层：负载均衡器使用网络层的 TCP 提供的信息。在这一层，它一般不会查看所请求的内容，而是选择一台服务器。
• 第 7 层：请求可以根据查询字符串、cookies 或我们选择的任何头的信息，以及包括源和目标地址在内的常规层信息进行均衡。

扩展关系数据库

对于一个简单的系统，我们可以通过 RDBMS，如 Oracle 或者 MySQL 来存储数据项。然而，关系数据库系统也存在着一些问题，尤其是在我们需要扩展的时候。

有很多技术可以扩展关系型数据库：主-从复制、主-主复制、联合、分片、非规范化和 SQL 调优。

• 复制通常指的是一种技术，可以让我们在不同的机器上存储同一数据的多个副本。
• 联合（或功能分区）将数据库按功能进行划分。
• 分片是一种与分区相关的数据库架构模式，它将数据的不同部分放到不同的服务器上，不同的用户将访问数据集的不同部分。
• 非规范化试图以牺牲一些写入性能为代价来提高读取性能，将数据写入多个表中以避免昂贵的连接。
• SQL 调优。

主-从复制

主-从复制技术使一个数据库服务器（主服务器）的数据被复制到一个或多个其他数据库服务器（从服务器），如下图所示：

对主服务器进行的所有更新。

• 客户端将连接到主服务器，并更新数据。
• 数据随后会在从服务器上进行传输，直到所有的数据在服务器上都是一致的。

在实践中，还是存在一些瓶颈。

• 如果主服务器由于某种原因宕机了，数据仍然可以通过从服务器获得，但是将无法再进行新的写入。
• 我们还需要一种新的算法，把一台从服务器提升到主服务器。

下面是实现仅一台服务器能处理更新请求的一些解决方案。

• 同步解决方案：只有当所有的服务器都接受了修改数据的事务（分布式事务）之后，才会被提交，因此，当发生故障切换时，数据不会丢失。
• 异步解决方案：提交 → 延迟 → 传播到集群中的其他服务器，因此，当发生故障切换时，某些数据更新会丢失。

请记住，如果同步解决方案过慢，那就改成异步解决方案。

主-主复制

每个数据库服务器都可以在其他服务器被当作主服务器的同时充当主服务器。在某个时间点上，所有的这服务器都会同步，以确保它们的数据是正确的、最新的。

所有节点读写所有数据。

以下是主-主复制的一些优势：

• 当一台主服务器发生故障时，其他数据库服务器可以正常运行，并接替其工作。当数据库服务器重新上线时，它将利用复制的方式赶上来。
• 主服务器可以位于几个物理站点，也可以分布在网络上。
• 受限于主服务器处理更新的能力。

联合

联合（或功能分区）将数据库按功能划分。例如，你可以有三个数据库：Forum、users 和 products，而不是一个单一的单体数据库，这样就能降低对各个数据库的读写流量，因此减少了复制滞后。

联合按功能划分数据库。

数据库越小，可以容纳在内存中的数据就越多，这反过来会导致缓存点击率的增加，这是由于缓存命中的改进。因为不需要单一的中央主控器序列化写操作，所以你可以进行并行写入，这样就可以提高吞吐量。

分片

分片（也被称为数据分区），是一种将大数据库分成许多小部分的技术，这样每个数据库只能管理数据的一个子集。

在理想情况下，我们有不同的用户都与不同的数据库节点对话。它有助于提高系统的可管理性、性能、可用性和负载均衡。

• 每个用户只需要和一个服务器对话，所以可以从该服务器得到快速的响应。
• 负载在服务器之间得到了很好的均衡——例如，如果我们有五个服务器，每个服务器只需要处理 20% 的负载。

在实践中，有许多不同的技术可以将一个数据库分解成多个小部分。

水平分区

这种技术是将不同的行放到不同的表中。比如，如果我们在一个表中存储用户资料，我们可以决定将 ID 小于 1000 的用户存储在一个表中，而将 ID 大于 1001 小于 2000 的用户存储在另一个表中。

我们将不同的行放入不同的表中。

垂直分区

在这种情况下，我们对数据进行划分，将与特定特性相关的表存储在它们自己的服务器上。例如，如果我们正在建立一个类似于 Instagram 的系统——需要存储与用户、他们上传的照片以及他们所关注的人有关的数据——我们可以决定将用户的资料信息放在一台数据库服务器上，好友列表放在另一台服务器上，而照片放在第三台服务器上。

我们将数据划分，存储与特定特性相关的表，并将其存储在各自的服务器上。

基于目录的分区

解决这个问题的一个松散耦合的方法，就是创建一个查询服务，它了解你当前的分区模式，并保持每个实体以及存储在哪个数据库分片的映射关系。

当数据存储可能需要扩展到超出单个存储节点的可用资源时，或者通过减少数据存储中的争用来提高性能时，我们可以使用这种方法。但请记住，分片技术存在以下一些常见问题：

• 数据库连接变得更加昂贵，在某些情况下是不可行的。
• 分片会破坏数据库的引用完整性。
• 数据库模式的改变会变得非常昂贵。
• 数据分布不均匀，而且在分片上有大量负载。

非规范化

非规范化的目的是提高读取性能，但却要牺牲一定的写入性能。为了避免昂贵的连接，可以将数据的冗余副本写入到多个表中。

一旦数据通过联合和分片等技术变得分散，管理跨数据中心的连接将会进一步增加复杂性。非规范化可以避免需要如此复杂的连接。

在大多数系统中，读取操作的次数远远多于写入操作，大约是 100:1，甚至是 1000:1。导致读取复杂数据库连接可能会非常昂贵，而且会耗费很多时间在磁盘上。

有些 RDBMS，像 PostgreSQL 和 Oracle 都支持物化视图，它们可以处理存储冗余数据，并使冗余副本保持一致。

Facebook 的 Ryan Mack 在其出色的文章《建立时间表：利用非规范化的力量扩大规模来保存你的生活故事》（Building Timeline: Scaling up to hold your life story）中分享了很多时间表自身的实现故事。

使用哪个数据库？

在数据库领域，主要有两种类型的解决方案。SQL 与 NoSQL。它们的构建方式、存储信息的类型以及存储方式都有所不同。

SQL

关系型数据库以行和列的形式存储数据。每一行包含一个实体的所有信息，每一列包含所有独立的数据点。

目前最受欢迎的关系型数据库是 MySQL、Oracle、MS SQL Server、SQLite、Postgres 和 MariaDB。

NoSQL

它也被称为非关系型数据库。这些数据库一般分为五大类别：Key-Value、Graph、Column、Document 和 Blob 存储。

键值存储

数据被存储在一个键值对的数组中。key（键）是一个与 value（值）相连的属性名称。

知名的键值存储有 Redis、Voldemort 和 Dynamo。

文档数据库

在这些数据库中，数据被存储在文档中（而不是表格中的行和列），这些文档被分组在集合中。每个文档都可能是截然不同的结构。

文档数据库包括 CouchDB 和 MongoDB。

宽列式数据库

在列式数据库中，我们没有“表”，而是有列族，它们是行的容器。与关系型数据库不同，我们不必事先了解所有的列，也不必要求每一行的列数目都相同。

列式数据库最适合分析大型数据集，著名的有 Cassandra 和 HBase。

图数据库

这些数据库用于存储数据，其关系最好用图来表示。数据被保存在带有节点（实体）、属性（关于实体的信息）和线（实体之间的连接）的图结构中。

图数据库的例子包括 Neo4J 和 InfiniteGraph。

Blob 数据库

Blob 更像是文件的键/值存储，可以通过 Amazon S3、Windows Azure Blob Storage、Google Cloud Storage、Rackspace Cloud Files 或 OpenStack Swift 等 API 访问。

如何选择要使用的数据库？

当涉及数据库技术时，没有放之四海而皆准的解决方案。这就是为什么许多企业同时依赖 SQL 和 NoSQL 数据库来满足不同的需求。

请看下面我画的思维导图！

使用哪个数据库？

横向扩展 Web 层

我们已经扩展了数据层，现在我们也需要扩展 Web 层。为了做到这一点，我们需要将用户会话的数据（状态）移出 Web 层，将其存储在数据库中，如关系型数据库或 NoSQL。这也被称为无状态架构。

无状态系统很简单。

不要使用有状态架构。

由于状态的实现会限制可扩展性。降低可用性和提高成本，所以我们需要尽可能地选择无状态架构。

在上面的场景中，由于可以为最优的请求处理选择任意服务器，因此负载均衡器能够可以达到最高的效率。

先进概念

缓存

负载均衡能够帮助你横向扩展越来越多的服务器，但缓存可以让你更好地利用现有的资源，从而更快速地向下一个请求提供数据。

如果数据不在缓存中，就从数据库中获取，然后保存到缓存中，再从缓存中读取。

我们可以在服务器中添加缓存，避免从服务器中直接读取网页或数据，从而降低了服务器的响应时间及负载。这使得我们的应用程序更加易于扩展。

缓存可以被用于许多层，例如数据库层、Web 服务器层和网络层。

内容分发网络 (CDN )

CDN 服务器保存内容（如图像、网页等）的缓存副本，并从最近的位置提供服务。

CDN 的使用可以提高用户的页面加载时间，因为数据是在离它最近的地方检索的。这也有助于提高内容的可用性，因为它被存储在多个地点。

使用 CDN 改善了用户的页面加载时间，因为数据是在最接近它的地方被检索到的。

CDN 服务器向我们的网络服务器发出请求，以验证被缓存的内容，并在需要时更新它们。被缓存的内容通常是静态的，如 HTML 页面、图像、JavaScript 文件、CSS 文件等。

走向全球

随着你的应用程序在全球范围内推广，你将会在全球范围内建立和运营数据中心，使你的产品每天 24 小时、每周 7 天保持运行。收到的请求将被路由到基于 GeoDNS 的“最佳”数据中心。

当你的应用程序走向全球时……

GeoDNS 是一项 DNS 服务，它可以将一个域名按照用户所在的位置解析为 IP 地址。来自亚洲的客户端可以得到与来自欧洲客户端的不同 IP 地址。

把它整合在一起

通过迭代应用所有这些技术，我们可以轻松地将系统扩展到 1 亿多用户，如无状态架构、应用负载均衡器、尽可能多地使用缓存数据、支持多个数据中心、在 CDN 上托管静态资产、通过分片扩展你的数据层，诸如此类。

扩展是一个迭代的过程。

后面会讨论哪些话题？

有很多方法可以提高可扩展性和高性能，如下所示：

• 分片和复制技术相结合。
• 长轮询 vs Websockets vs 服务器发送事件。
• 索引和代理。
• SQL 调优。
• 弹性计算。

很简单，对吗？

作者介绍：

写手，主要涉及商业、艺术和科技领域。

原文链接：

How to design a system to scale to your first 100 million users