Kirill Sh@Unsplash
高可用架构设计最核心的就是两点：解耦和冗余。解耦包括业务状态分离（无状态架构设计）、分库分表等。冗余包括缓存、CDN、主从备份、主主备份、GeoDNS 等。一个好的架构设计需要在产品迭代的不同阶段选择合适的技术，从而既能在合理的成本条件下有效保障当前的业务需求，又能考虑到业务下一步发展的可能性。
对于软件架构师来说，设计一个支持数亿用户的系统是一个巨大的挑战（不过在读了这篇文章后，也许就没那么难了 ）。
以下是本文涉及的一些主题：
- 从最简单的开始： 单体架构
- 可伸缩性的艺术： 水平扩展（scaling out），纵向扩展（scaling up）
- 关系型数据库的可扩展性： 主从备份、主主备份、联合、分片、去规范化和 SQL 调优
- 数据库选型： NoSQL 还是 SQL?
- 高级概念： 缓存、CDN、GeoDNS 等
我们暂时不讨论高性能计算中的其他常用术语，比如容错、可靠性、高可用性等。
让我们平静一下，旅程即将开始！
从 0 开始
我们先从设计一个仅支持少量用户的基本应用程序开始。最简单的方法就是将整个应用程序部署到单个服务器上，这可能也是大多数人开始的方式。如下图所示：
- 一个网站（包括 API）运行在类似 Apache¹（或 Tomcat²）这样的 Web 服务器上。
- 一个 Oracle³（或 MySQL⁴）这样的数据库。
在同一台物理服务器上部署 Web 服务器和数据库服务器
但目前的架构有如下缺陷：
- 如果发生数据库故障，则会导致系统故障。
- 如果 Web 服务器出现故障，也会导致整个系统故障。
在本例中，我们没有做故障恢复和冗余。如果一个服务器宕机，意味着所有服务都会挂掉。
DNS 服务器解析主机名和 IP 地址
在上图中，用户（或客户端）连接到 DNS⁵以获得我们的系统所在服务器的 IP 地址。一旦获得了 IP 地址，请求就直接发送到我们的系统。
每当你访问一个网站，你的电脑将会执行一次 DNS 查寻。
通常，DNS 以付费服务的形式由服务器托管公司提供，并不需要在我们自己的服务器上运行。
可伸缩性的艺术
由于许多原因，例如数据量的增加、业务的增加（例如事务数量）和用户的增长，我们的系统可能不得不进行扩展。
可伸缩性通常意味着能够处理更多的用户、客户、数据、事务或请求，可以动态增加更多资源而不会影响用户体验。
我们必须决定如何扩大这个系统的规模。在本例中，有以下两种类型的扩展：垂直扩展（scale-up）和水平扩展（scale-out）。
scale up vs scale out
Scaling up：向现有服务器添加更多内存和 CPU
Scaling up（也被称为 vertical scaling），指的是使系统的资源最大化，以扩展其处理不断增加的负载的能力——例如，我们通过增加内存和 CPU 来增加服务器的处理能力。
如果我们服务器的内存为 8GB，那么只需要更换或添加硬件就可以很容易地升级到 32GB 甚至 128GB。
有很多方法可以实现垂直扩展，如下所示：
- 通过增加 RAID 中的硬盘，增加 I/O 容量。
- 通过切换到固态驱动器（SSD）来改善 I/O 访问时间。
- 切换到具有更多处理器的服务器。
- 通过升级网络接口或安装额外的网络接口，提高网络吞吐量。
- 通过增加内存来减少 I/O 操作。
如果可以负担硬件升级的成本，垂直扩展对于小型系统来说是一个不错的选择，但它也有以下严重的限制：
- “不可能无限制的给一台服务器增加硬件”。能够增加多少硬件主要取决于操作系统和服务器的内存总线宽度。
- 当我们增加内存或者其他硬件时，必须关闭服务器，因此，如果系统只有一台服务器，停机是不可避免的。
- 功能强大的机器通常比流行的硬件贵很多。
扩展不仅适用于硬件，也适用于软件，例如，它包括优化数据库查询和优化应用程序代码。
我们是否需要多个服务器?
随着用户数量的增长，一台服务器是远远不够的。我们需要考虑将一个服务器拆分为多个服务器。
随着用户数量的增长，一台服务器远远不够
这种架构有如下优点：
- Web 服务器与数据库服务器的调优方式不同。
- Web 服务器需要更好的 CPU，而数据库服务器需要更多内存。
- 为 Web 层和数据层使用独立的服务器可以让它们独立扩展。
Scaling out：添加任意数量的硬件和应用实例
Scaling out（也被称为“horizontal scaling”），指的是向资源池中添加更多的实体（机器、服务）。水平扩展比垂直扩展更难实现，需要我们在构建系统之前就考虑好。
因为需要更多的服务器来进行最基本的扩展，所以支持水平扩展通常会在业务初期增加更多的成本，但在后期会获得回报，因此我们需要权衡利弊。
-
增加服务器数量意味着需要维护更多的资源。
-
系统的代码也需要更改，从而支持并行处理，以及在多个服务器之间分配工作。
使用负载均衡器分发流量
负载均衡器是一种专门的硬件或软件组件，帮助将流量均匀的分发到服务器集群中，以提高系统（包括但不限于应用程序、网站或数据库）的响应性和可用性。
使用负载均衡器分发流量
通常，负载均衡器位于客户端和服务器之间，接收网络和应用程序流量，并使用各种算法将流量均匀分发到多个后端服务器。它也可以部署在各种环境中，例如：在 Web 服务器和数据库服务器之间，或者在客户端和 Web 服务器之间。
HAProxy 和 Nginx 是两个流行的开源负载均衡软件。
负载均衡是一种容错保证技术，可提高系统可用性，如下所示：
- 如果服务器 1 下线，所有流量将路由到服务器 2 和服务器 3，因此网站服务不会下线。我们需要向服务器池中添加一个新的健康服务器，以平衡负载。
- 当流量快速增长时，只需要向 Web 服务器池中添加更多的服务器，负载均衡器就会自动路由流量。
负载均衡器采用各种策略和算法来优化负载分配，如下所示：
- 轮询（Round robin） ：每个服务器按照类似先进先出（FIFO）的顺序接收请求。
- 最少连接数（Least number of connections） ：将请求路由到连接数最少的服务器。
- 最快响应时间（Fastest response time） ：将请求路由到响应时间最快（通过最近一段时间采样或统计最多次数）的服务器。
- 加权（Weighted） ：更强大的服务器将比较弱的服务器接收到更多的请求。
- IP 哈希（IP Hash） ：计算客户端的 IP 地址的哈希值，将请求重定向到服务器。
在多个服务器之间均衡分发请求的最直接的方法是使用硬件设备。
- 可以在共享 IP 池中添加和删除服务器，立即生效。
- 负载均衡可以按设计需求进行。
软件负载均衡器是硬件负载平衡器的廉价替代品，工作在 4 层（网络层）和 7 层（应用层）协议栈上。
- L4 负载均衡器 ：基于 TCP 在网络层提供的信息，通常不查看请求的内容就选择服务器。
- L7 负载均衡器 ：请求可以基于查询字符串、cookie 或我们选择的任何报头中的信息，以及包括源和目的地址等常规信息进行负载均衡。
关系型数据库的可扩展性
对于一个简单的系统，我们可以使用像 Oracle 或 MySQL 这样的 RDBMS 来保存数据。但是当我们需要扩展容量的时候，关系型数据库系统也面临挑战。
有许多技术可以用来扩展关系型数据库：主从备份（master-slave replication）、主主备份（master-master replication）、联合（federation）、分片（sharding）、去规格化（denormalization）和 SQL 调优。
- 备份（Replication ） 通常指的是一种允许我们在不同的机器上存储相同数据的多个副本的技术。
- 联合（Federation） （或功能分区）按功能对数据库进行分割。
- 分片（Sharding） 是一种与分区相关的数据库架构模式，将数据的不同部分放到不同的服务器上，不同的用户将访问数据的不同部分。
- 去规格化（Denormalization） 试图以牺牲部分写性能为代价来提高读性能，通过在多个表中写入数据来避免昂贵的数据 joins 操作。
- SQL 调优（SQL tuning）
Federation 是数据库垂直分库，根据业务逻辑，将原本耦合在一起的数据库划分出多个不同的数据。Sharding 是数据库水平分库，以某个字段（比方说用户 id）为 key，将一张大表切割成多个小表，每个用户的数据可以通过访问不同的小表获取。Denormalization 通过冗余数据减少数据查询开销。
主从备份（master-slave replication）
主从备份允许将一个数据库服务器（主服务器）的数据复制到一个或多个其他数据库服务器（从服务器），如下图所示。
所有变更提交到主服务器
- 客户端连接到主服务器并更新数据。
- 数据将同步到从服务器，直到所有数据在所有服务器上保持一致。
实践中仍然存在一些瓶颈：
- 如果主服务器由于某种原因宕机，数据仍然可以通过从服务器获取，但是不能进行新的写操作。
- 需要额外的算法将从服务器切换为主服务器。
对于只有一个服务器可以处理更新请求的实现，下面是一些解决方案：
- 同步解决方案（Synchronous solutions） ：只有在所有服务器都接受之后，才正式提交数据修改事务（分布式事务），因此故障恢复的时候不会丢失数据。
- 异步解决方案（Asynchronous solutions） ：提交->延迟->扩散到集群中的其他服务器，因此一些数据更新可能在故障恢复时丢失。
请记住，如果同步解决方案太慢，请更改为异步解决方案。
主主备份（master-master replication）
每个数据库服务器都可以充当主服务器，同时其他服务器也被视为主服务器。所有主服务器在某个时间点同步数据，从而确保它们都有正确的和最新的数据。
所有节点读写所有数据
主主备份的优点：
- 如果一台主服务器出现故障，其他数据库服务器可以正常运行并填补漏洞。当失效的数据库服务器重新上线时，它将复制最新的数据从而和其他服务器同步。
- 主服务器可以位于多个不同的物理位置，可以分布在整个网络中。
- 受限于主服务器处理数据更新的能力。
联合（Federation）
联合（或功能分区）按功能对数据库进行分割。例如，可以使用三个数据库：论坛、用户和产品，而不是单一的、整体的数据库，从而减少对每个数据库的读写流量，从而减少备份延迟。
Federation 根据功能对数据库进行分割
更小的数据库会产生更多的数据，这些数据可以放入内存中，而这又会由于缓存局部性的改善而导致更多的缓存命中。由于不需要单独的中心化主服务器进行序列化写操作，我们可以并行地进行写操作，从而提高吞吐量。
分片（Sharding）
分片（也称为数据分区）是一种将大数据库分解为许多较小部分的技术，这样每个数据库只管理数据的一个子集。
理想情况下，我们让不同的用户与不同的数据库节点通信。它有助于提高系统的可管理性、性能、可用性和负载均衡。
- 每个用户只需要与一个服务器通信，因此可以从该服务器获得快速响应。
- 负载可以在服务器之间很好地平衡——例如，如果我们有 5 台服务器，每个服务器只需要处理 20%的负载。
实践中有许多不同的技术可以将数据库分解为多个更小的部分。
水平分片（Horizontal partitioning）
在这种技术中，我们将不同的行放入不同的表中。例如，如果我们将用户概要文件存储在一个表中，我们可以决定 id 小于 1000 的用户存储在一个表中，id 大于 1001 且小于 2000 的用户存储在另一个表中。
把不同的行放到不同的表中
垂直分片（Vertical partitioning）
在本例中，我们将数据划分为与特定特性相关的表存储在它们自己的服务器中。例如，如果我们正在构建一个类似 instagram 的系统——我们需要存储与用户、他们上传的照片和他们关注的人相关的数据——我们可以决定将用户的个人资料放在一个数据库服务器上，朋友列表放在另一个服务器上，照片放在第三个服务器上。
将数据划分为与特定特性相关的表存储在各自的服务器上
基于目录的分区
应用怎么知道数据储存在哪个数据库里呢？创建一个查找服务可以以一种松耦合的方式解决问题，该服务知道当前的分区模式，并保存每个实体的以及存储在哪个数据库分片上的映射。
请记住，分片技术存在以下一些常见问题：
- 在某些情况下，数据库 joins 操作变得更加昂贵，甚至是不可行的。
- 分片会损害数据库的引用完整性。
- 数据库 schema 的更改可能会非常昂贵。
- 数据分布可能不均匀，一个分片上可能有过多负载。
去规格化（Denormalization）
去规格化试图以牺牲部分写性能为代价来提高读性能，数据的冗余副本被写入多个表中，以避免昂贵的 joins 操作。
一旦数据通过联合和分片等技术分布，管理跨数据中心的 joins 操作将进一步增加复杂性。去规格化可以避免对这种复杂 joins 操作的需要。
大多数系统中，读操作的数量可能远远超过写操作，达到 100:1，甚至 1000:1。导致依赖于复杂数据库 joins 操作的读操作会非常昂贵，需要在磁盘操作上花费大量时间。
一些 RDBMS，如 PostgreSQL 和 Oracle，支持 Materialized 视图来处理存储冗余信息和保持冗余副本一致的工作。
Facebook 的 Ryan Mack 在他的一篇精彩文章中分享了不少 Timeline 利用去规格化技术实施数据库优化的故事：Building Timeline: Scaling up to hold your life story⁶。
数据库选型
当前有两种主要类型的数据库解决方案：SQL 和 NoSQL。它们在构建方式、存储的信息类型和使用的存储方法上都有所不同。
SQL
关系型数据库以行和列的形式存储数据。每一行包含关于一个实体的所有信息，每一列包含所有独立的数据点。
当前最流行的关系型数据库是 MySQL, Oracle, MS SQL Server, SQLite, Postgres 和 MariaDB。
NoSQL
也被称为非关系型数据库。这些数据库通常分为五个主要类别：键值、图、列、文档和 Blob 存储。
键值存储（Key-Value stores)
数据存储在键值对数组中。' key '是一个链接到' value '的属性名。
知名的键值存储数据库包括 Redis、Voldemort 和 Dynamo。
文档型数据库（Document databases）
数据存储在文档中（而不是表中的行和列），这些文档在集合中组合在一起。每个文档可以有完全不同的结构。
文档数据库包括 CouchDB 和 MongoDB。
宽列数据库（Wide-column databases）
在列式数据库中，以列族（column families）存储数据，而不是'表'，列族是行的容器。与关系数据库不同，我们不需要预先知道所有的列，每一行也不需要有相同的列数。
列式数据库最适合分析大型数据集，著名的有 Cassandra 和 HBase。
图数据库（Graph databases）
如果数据之间的关系最适合用图的形式表现，那么图数据库是最好的选择。数据在图数据库中保存在带有节点（实体）、属性（关于实体的信息）和线（实体之间的连接）的图结构中。
图数据库的例子包括 Neo4J 和 InfiniteGraph。
Blog 数据库（Blob databases）
Blob 更像是文件的键/值存储，可以通过 Amazon S3、Windows Azure Blob Storage、谷歌 Cloud Storage、Rackspace Cloud Files 或 OpenStack Swift 等 API 访问。
如何选择使用哪个数据库?
谈到数据库技术，没有一刀切的解决方案。这就是为什么许多企业同时依赖 SQL 和 NosQL 数据库来满足不同的需求。
看看下面的指导吧!
用哪个数据库?
Web 层水平缩放
我们已经扩展了数据层，现在我们还需要扩展 Web 层。为此，我们需要将用户会话（状态）数据从 Web 层移出，将它们存储在数据库中（关系型数据库或 NoSQL）。这也被称为无状态架构。
简单的无状态系统
不要使用有状态架构。必须尽可能选择无状态架构，因为状态的实现限制了可伸缩性，降低了可用性，并增加了成本。
在上面的场景中，负载均衡器可以选择任意服务器进行最优的请求处理，从而达到最大的效率。
高级概念
缓存
负载均衡可以帮助我们在不断增加的服务器数量上进行水平扩展，但缓存将使我们能够更好地利用已有资源，以便在后续请求期间更快地提供数据。
如果数据不在缓存中，从数据库中获取数据，然后将其保存到缓存中并从中读取。
通过添加缓存，我们可以避免直接从服务器读取网页或数据，从而减少服务器的响应时间和负载，这有助于提高应用程序的可伸缩性。
缓存可以应用于多个层次，如数据库层、Web 服务器层和网络层。
内容分发网络（CDN）
CDN 服务器保存静态内容（如图像、网页等）的缓存副本，并从最近的位置提供服务。
因为数据可以在最接近用户的位置获取，因此使用 CDN 可以减少用户页面加载时间。另外，因为内容被存储在多个节点上，也有助于增强内容的可用性。
因为数据是在最接近它的位置检索的，因此使用 CDN 减少了用户页面加载时间。
CDN 服务器向我们的 Web 服务器发出请求，以验证缓存的内容并在需要时更新它们。缓存的通常都是静态内容的，如 HTML 页面、图像、JavaScript 文件、CSS 文件等。
全球化
当我们的应用面向全球用户，我们将有机会拥有并运营世界各地的数据中心，以保证产品 7×24 运行。访问请求将被路由到基于 GeoDNS 选择的“最佳”数据中心进行处理。
应用服务全球用户
GeoDNS 是一种可以根据用户的位置将域名解析为 IP 地址的 DNS 服务，来自亚洲的客户端连接到的 IP 地址可能与来自欧洲的客户端连接到的 IP 地址不同。
总结
在产品迭代的不同阶段应用所有这些技术（无状态架构，负载均衡器，缓存，多数据中心，CDN，数据分片等），可以帮助我们很容易地将系统扩展到支持超过 1 亿用户的规模。
扩容是一个逐步迭代的过程
还有哪些需要考虑的技术？
有很多方法可以提高可伸缩性和系统性能：
- 数据分片和备份的融合
- 长轮询 vs WebSockets VS 服务器事件
- 索引和代理
- SQL 调优
- 弹性计算
很简单，不是么？
Reference:
[1] https://httpd.apache.org/
[2] http://tomcat.apache.org/
[3] https://www.oracle.com/database/
[4] https://www.mysql.com
[5] https://en.wikipedia.org/wiki/Domain_Name_System
[6] https://www.facebook.com/note.php?note_id=10150468255628920
原文链接：https://mp.weixin.qq.com/s?__biz=MzU2MTgxODgwNA==&mid=2247483868&idx=1&sn=c4cdc23292b76c8e4feb9aee4f4f2558&chksm=fc73bc07cb04351155e6116ef53f09b0b0f22dd6836b04602f452c35312a3ecd7eee6a079d60&token=2025