大型互联网系统架构是如何设计的？

接下来，我们将看看高阶的权衡和取舍:

• 性能与可扩展性
• 延迟与吞吐量
• 可用性与一致性

记住每个方面都面临取舍和权衡。

然后，我们将深入更具体的主题，如 DNS、CDN 和负载均衡器。

1. 性能与可扩展性

如果服务性能的增长与资源的增加是成比例的，服务就是可扩展的。通常，提高性能意味着服务于更多的工作单元，另一方面，当数据集增长时，同样也可以处理更大的工作单位。1

另一个角度来看待性能与可扩展性:

• 如果你的系统有性能问题，对于单个用户来说是缓慢的。
• 如果你的系统有可扩展性问题，单个用户较快但在高负载下会变慢。

2. 延迟与吞吐量

延迟是执行操作或运算结果所花费的时间。

吞吐量是单位时间内（执行）此类操作或运算的数量。

通常，你应该以可接受级延迟下最大化吞吐量为目标。

3. 可用性与一致性

CAP 理论

在一个分布式计算系统中，只能同时满足下列的两点:

• 一致性 ─ 每次访问都能获得最新数据但可能会收到错误响应
• 可用性 ─ 每次访问都能收到非错响应，但不保证获取到最新数据
• 分区容错性 ─ 在任意分区网络故障的情况下系统仍能继续运行

网络并不可靠，所以你应要支持分区容错性，并需要在软件可用性和一致性间做出取舍。

CP ─ 一致性和分区容错性

等待分区节点的响应可能会导致延时错误。如果你的业务需求需要原子读写，CP 是一个不错的选择。

AP ─ 可用性与分区容错性

响应节点上可用数据的最近版本可能并不是最新的。当分区解析完后，写入（操作）可能需要一些时间来传播。

如果业务需求允许最终一致性，或当有外部故障时要求系统继续运行，AP 是一个不错的选择。

4. 一致性模式

有同一份数据的多份副本，我们面临着怎样同步它们的选择，以便让客户端有一致的显示数据。回想 CAP 理论中的一致性定义 ─ 每次访问都能获得最新数据但可能会收到错误响应

弱一致性

在写入之后，访问可能看到，也可能看不到（写入数据）。尽力优化之让其能访问最新数据。

这种方式可以 memcached 等系统中看到。弱一致性在 VoIP，视频聊天和实时多人游戏等真实用例中表现不错。打个比方，如果你在通话中丢失信号几秒钟时间，当重新连接时你是听不到这几秒钟所说的话的。

最终一致性

在写入后，访问最终能看到写入数据（通常在数毫秒内）。数据被异步复制。

DNS 和 email 等系统使用的是此种方式。最终一致性在高可用性系统中效果不错。

强一致性

在写入后，访问立即可见。数据被同步复制。

文件系统和关系型数据库（RDBMS）中使用的是此种方式。强一致性在需要记录的系统中运作良好。

5. 可用性模式

有两种支持高可用性的模式: 故障切换（fail-over）和复制（replication）。

故障切换

工作到备用切换（Active-passive）

关于工作到备用的故障切换流程是，工作服务器发送周期信号给待机中的备用服务器。如果周期信号中断，备用服务器切换成工作服务器的 IP 地址并恢复服务。

宕机时间取决于备用服务器处于“热”待机状态还是需要从“冷”待机状态进行启动。只有工作服务器处理流量。

工作到备用的故障切换也被称为主从切换。

双工作切换（Active-active）

在双工作切换中，双方都在管控流量，在它们之间分散负载。

如果是外网服务器，DNS 将需要对两方都了解。如果是内网服务器，应用程序逻辑将需要对两方都了解。

双工作切换也可以称为主主切换。

缺陷：故障切换

• 故障切换需要添加额外硬件并增加复杂性。
• 如果新写入数据在能被复制到备用系统之前，工作系统出现了故障，则有可能会丢失数据。

复制

主 ─ 从复制和主 ─ 主复制

这个主题进一步探讨了数据库部分:

• 主 ─ 从复制
• 主 ─ 主复制

6. 域名系统

域名系统是把 www.example.com 等域名转换成 IP 地址。

域名系统是分层次的，一些 DNS 服务器位于顶层。当查询（域名） IP 时，路由或 ISP 提供连接 DNS 服务器的信息。较底层的 DNS 服务器缓存映射，它可能会因为 DNS 传播延时而失效。DNS 结果可以缓存在浏览器或操作系统中一段时间，时间长短取决于存活时间 TTL。

• NS 记录（域名服务） ─ 指定解析域名或子域名的 DNS 服务器。
• MX 记录（邮件交换） ─ 指定接收信息的邮件服务器。
• A 记录（地址） ─ 指定域名对应的 IP 地址记录。
• CNAME（规范） ─ 一个域名映射到另一个域名或 CNAME 记录（ example.com 指向 www.example.com ）或映射到一个 A 记录。

CloudFlare 和 Route 53 等平台提供管理 DNS 的功能。某些 DNS 服务通过集中方式来路由流量:

• 加权轮询调度
  • 防止流量进入维护中的服务器
  • 在不同大小集群间负载均衡
  • A/B 测试
• 基于延迟路由
• 基于地理位置路由

缺陷:DNS

• 虽说缓存可以减轻 DNS 延迟，但连接 DNS 服务器还是带来了轻微的延迟。
• 虽然它们通常由政府，网络服务提供商和大公司管理，但 DNS 服务管理仍可能是复杂的。
• DNS 服务最近遭受 DDoS 攻击，阻止不知道 Twtter IP 地址的用户访问 Twiiter。

7. 内容分发网络（CDN）

内容分发网络（CDN）是一个全球性的代理服务器分布式网络，它从靠近用户的位置提供内容。通常，HTML/CSS/JS，图片和视频等静态内容由 CDN 提供，虽然亚马逊 CloudFront 等也支持动态内容。CDN 的 DNS 解析会告知客户端连接哪台服务器。

将内容存储在 CDN 上可以从两个方面来提供性能:

• 从靠近用户的数据中心提供资源
• 通过 CDN 你的服务器不必真的处理请求

CDN 推送（push）

当你服务器上内容发生变动时，推送 CDN 接受新内容。直接推送给 CDN 并重写 URL 地址以指向你的内容的 CDN 地址。你可以配置内容到期时间及何时更新。内容只有在更改或新增是才推送，流量最小化，但储存最大化。

CDN 拉取（pull）

CDN 拉取是当第一个用户请求该资源时，从服务器上拉取资源。你将内容留在自己的服务器上并重写 URL 指向 CDN 地址。直到内容被缓存在 CDN 上为止，这样请求只会更慢，

存活时间（TTL）决定缓存多久时间。CDN 拉取方式最小化 CDN 上的储存空间，但如果过期文件并在实际更改之前被拉取，则会导致冗余的流量。

高流量站点使用 CDN 拉取效果不错，因为只有最近请求的内容保存在 CDN 中，流量才能更平衡地分散。

缺陷：CDN

• CDN 成本可能因流量而异，可能在权衡之后你将不会使用 CDN。
• 如果在 TTL 过期之前更新内容，CDN 缓存内容可能会过时。
• CDN 需要更改静态内容的 URL 地址以指向 CDN。

8. 负载均衡器

负载均衡器将传入的请求分发到应用服务器和数据库等计算资源。无论哪种情况，负载均衡器将从计算资源来的响应返回给恰当的客户端。负载均衡器的效用在于:

• 防止请求进入不好的服务器
• 防止资源过载
• 帮助消除单一的故障点

负载均衡器可以通过硬件（昂贵）或 HAProxy 等软件来实现。 增加的好处包括:

• SSL 终结 ─ 解密传入的请求并加密服务器响应，这样的话后端服务器就不必再执行这些潜在高消耗运算了。
  • 不需要再每台服务器上安装 X.509 证书。
• Session 留存 ─ 如果 Web 应用程序不追踪会话，发出 cookie 并将特定客户端的请求路由到同一实例。

通常会设置采用工作 ─ 备用 或 双工作 模式的多个负载均衡器，以免发生故障。

负载均衡器能基于多种方式来路由流量:

• 随机
• 最少负载
• Session/cookie
• 轮询调度或加权轮询调度算法
• 四层负载均衡
• 七层负载均衡

四层负载均衡

四层负载均衡根据监看传输层的信息来决定如何分发请求。通常，这会涉及来源，目标 IP 地址和请求头中的端口，但不包括数据包（报文）内容。四层负载均衡执行网络地址转换（NAT）来向上游服务器转发网络数据包。

七层负载均衡器

七层负载均衡器根据监控应用层来决定怎样分发请求。这会涉及请求头的内容，消息和 cookie。七层负载均衡器终结网络流量，读取消息，做出负载均衡判定，然后传送给特定服务器。比如，一个七层负载均衡器能直接将视频流量连接到托管视频的服务器，同时将更敏感的用户账单流量引导到安全性更强的服务器。

以损失灵