4、架构-透明多级的分流服务

目录

一、透明多级分流系统的概述

二、客户端缓存

1 强制缓存

2 协商缓存

总结

三、域名解析

DNS的基本工作原理

DNS解析的具体步骤

DNS对系统流量的影响

前沿技术

小结

四、传输链路

连接数优化

 传输压缩

 快速UDP网络连接

小结

---

一、透明多级分流系统的概述

        现代的企业级或互联网系统中，“分流”设计是必须考虑的因素。分流手段之多、涉及场景之广，可能连开发者都未必能全部意识到。这听起来似乎并不合理，但恰好体现了优秀架构设计的一种特点：“分布广阔”源于“多级”，“意识不到”谓之“透明”，这也正是“透明多级分流系统”（Transparent Multilevel Diversion System）的由来。

        在用户使用信息系统的过程中，请求从浏览器出发，在域名服务器的指引下找到系统的入口，经过网关、负载均衡器、缓存、服务集群等一系列设施，最终触及末端存储于数据库服务器中的信息，然后逐级返回到用户的浏览器之中。这其中要经过许多技术部件。作为系统的设计者，我们应该意识到不同的设施、部件在系统中有各自不同的价值：

1. 客户端或网络边缘的部件：这些部件能够迅速响应用户的请求，避免给后方的I/O与CPU带来压力，典型如本地缓存、内容分发网络（CDN）、反向代理等。
2. 处理能力能够线性拓展的部件：这些部件易于伸缩，可以使用较小的代价堆叠机器来获得与用户数量相匹配的并发性能，应尽量作为业务逻辑的主要载体，典型如集群中能够自动扩缩的服务节点。
3. 对系统运行有全局性影响的部件：这些部件稳定服务对系统运行至关重要，要时刻保持容错备份，维护高可用性，典型如服务注册中心、配置中心。
4. 天生的单点部件：这些设施只能依靠升级机器本身的网络、存储和运算性能来提升处理能力，如系统入口的路由、网关或者负载均衡器，以及请求调用链末端的传统关系数据库等。

对系统进行流量规划时，我们应该充分理解这些部件的价值差异，有两条简单、普适的原则能指导我们进行设计：

• 减少单点部件：如果某些单点是无可避免的，则应尽最大限度减少到达单点部件的流量。在系统中往往会有多个部件能够处理、响应用户请求，例如要获取一张存储在数据库的用户头像图片，浏览器缓存、CDN、反向代理、Web服务器、文件服务器、数据库都可能提供这张图片。恰如其分地引导请求分流至最合适的组件中，避免绝大多数流量汇集到单点部件，同时依然能够保证处理结果的准确性，使单点系统在出现故障时自动而迅速地实施补救措施，这便是系统架构中多级分流的意义。
• 奥卡姆剃刀原则：作为一名架构设计者，应对多级分流的手段有全面的理解与充分的准备，同时清晰地意识到这些设施并不是越多越好。在实际构建系统时，应当在有明确需求、真正必要的时候再去考虑部署它们。不是每一个系统都要追求高并发、高可用，而是根据系统的用户量、峰值流量和团队本身的技术与运维能力来合理部署这些设施。在能满足需求的前提下，最简单的系统就是最好的系统。

        奥卡姆剃刀原则（Occam's Razor）源自14世纪的哲学家威廉·奥卡姆，原意是“如无必要，勿增实体”（Entities should not be multiplied beyond necessity）。在系统设计和架构中，这一原则被解读为“最简单的解决方案往往是最好的”。

        本章将根据流量从客户端发出到服务端处理这个过程中所流经的与功能无关的技术部件为线索，解析每个部件的透明工作原理与起到的分流作用。下面所讲述的客户端缓存、域名解析、传输链路、内容分发网络、负载均衡、服务端缓存，都是为了达成“透明分流”这个目标所采用的工具与手段，高可用架构、高并发则是通过“透明分流”所获得的价值。

注：透明多级分流系统是笔者自己创造的词汇，业内通常只提“Transparent Multilevel Cache”，但我们这里谈的并不只是缓存。

二、客户端缓存

在分布式系统设计中，客户端缓存机制是提升性能和减少重复数据传输的重要手段。客户端缓存包括强制缓存和协商缓存两种主要机制。

1 强制缓存

强制缓存的原理是基于时间的有效性假设，客户端在特定时间内不需要再次请求服务器即可使用缓存资源。主要通过以下两种HTTP头实现：

1. Expires

   • Expires头指定资源的绝对过期时间。服务器在响应中返回此头，表示资源在指定时间前有效，客户端可直接使用缓存。
   • 示例：

     HTTP/1.1 200 OK Expires: Wed, 8 Apr 2020 07:28:00 GMT

   • 局限性包括受客户端本地时间影响、无法处理私有资源以及无法描述“不缓存”的语义 。

2. Cache-Control

   • Cache-Control头在HTTP/1.1中定义，提供更丰富的缓存控制参数。
   • 示例：

     HTTP/1.1 200 OK Cache-Control: max-age=600

   • 参数包括：
     • max-age：缓存的最大有效时间（秒）。
     • s-maxage：共享缓存的最大有效时间。
     • public 和 private：指明资源是否可以被代理缓存。
     • no-cache 和 no-store：指定资源不应被缓存或不保存任何形式的缓存 。

2 协商缓存

协商缓存通过检测资源是否发生变化来决定是否使用缓存的副本。主要机制包括：

1. Last-Modified 和 If-Modified-Since

   • Last-Modified：服务器响应头，指明资源的最后修改时间。
   • If-Modified-Since：客户端请求头，携带上次接收到的Last-Modified时间。
   • 如果资源未修改，服务器返回304 Not Modified；否则返回200 OK和最新资源。
   • 示例：

     HTTP/1.1 304 Not Modified Last-Modified: Wed, 8 Apr 2020 15:31:30 GMT

     HTTP/1.1 200 OK Last-Modified: Wed, 8 Apr 2020 15:31:30 GMT Content-Length: 1234

2. ETag 和 If-None-Match

   • ETag：服务器生成的资源唯一标识符。
   • If-None-Match：客户端请求头，携带上次接收到的ETag值。
   • 如果ETag未变，服务器返回304 Not Modified；否则返回200 OK和最新资源 。

总结

客户端缓存机制通过减少重复数据传输，提高了网络性能。强制缓存通过时间有效性假设，协商缓存通过变化检测机制，二者互补，共同实现了HTTP协议下高效的缓存管理。这些缓存机制是透明多级分流系统的一部分，提升了分布式系统的性能和可靠性。

三、域名解析

域名解析（DNS）是互联网系统的基础设施之一，其作用是将便于人类理解的域名地址转换为便于计算机处理的IP地址。虽然看似简单，但DNS的工作原理和在系统架构中的影响非常深远，值得深入了解。

DNS的基本工作原理

1. DNS缓存检查：

   • 客户端首先检查本地DNS缓存，查看是否存在目标域名的有效地址记录。DNS缓存以TTL（Time to Live）来衡量其有效期，缓存超期后需要重新查询。

2. 本地DNS查询：

   • 如果本地缓存没有记录，客户端会将请求发送到配置的本地DNS服务器。这个本地DNS服务器可以是用户手动设置的，也可以是通过DHCP获取的。

3. 递归查询：

   • 本地DNS服务器会按顺序递归查询权威DNS服务器，直到找到目标域名的IP地址。递归过程包括从根域名服务器开始，逐级查询每个域名的权威服务器。

4. 权威DNS服务器：

   • 权威DNS服务器负责特定域名的解析，并返回相应的IP地址或其他记录类型（如CNAME、AAAA等）。

DNS解析的具体步骤

1. 缓存检查：

   • 客户端首先检查本地缓存，查看是否有该域名的有效地址记录。DNS缓存通过TTL值来判断缓存是否有效。

2. 本地DNS请求：

   • 如果缓存中没有记录，客户端向本地DNS服务器发送请求。本地DNS服务器可以是手动配置的，也可以通过DHCP动态获取。

3. 递归查询：

   • 本地DNS服务器根据域名的层级结构，从根域名服务器开始，逐级查询各级权威DNS服务器。例如：
     • 查询根域名服务器，得到“cn”域的权威服务器地址。
     • 查询“cn”域的权威服务器，得到“com.cn”域的权威服务器地址。
     • 最后查询“com.cn”域的权威服务器，得到目标域名的权威服务器地址和IP地址。

4. 权威DNS服务器返回结果：

   • 权威DNS服务器返回目标域名的IP地址，或其他记录类型（如CNAME）。例如：

     icyfenix.cn. IN CNAME icyfenix.cn.cdn.dnsv1.com. icyfenix.cn.cdn.dnsv1.com. IN A 101.71.72.192

DNS对系统流量的影响

1. 缓存机制：

   • DNS缓存机制能有效减少重复查询，提高解析速度。但缓存的TTL值设置过长可能导致IP变更后无法及时更新，影响系统的可用性和一致性。

2. 解析延迟：

   • 在极端情况下，如果各级服务器均无缓存，域名解析需要多次递归查询，可能导致明显的响应延迟。优化手段包括DNS预取（DNS Prefetching）等。

3. 安全性问题：

   • DNS查询过程中的每一级都可能受到中间人攻击，导致域名劫持。特别是递归链底层或本地DNS服务器的安全防护相对薄弱，可能被攻击者利用。

前沿技术

1. HTTPDNS：
   • HTTPDNS（或DNS over HTTPS, DoH）是一种新的DNS工作模式，通过HTTPS协议进行DNS查询，绕过传统的本地DNS，减少中间人攻击风险，提高解析准确性和速度。

小结

域名解析在现代互联网系统中扮演着关键角色。尽管其存在缓存过期、解析延迟和安全风险等问题，通过合理的缓存策略、前沿技术和优化手段，可以有效提高DNS解析的效率和安全性，确保系统的高可用性和性能​​。

四、传输链路

        经过客户端缓存的节流、DNS服务的解析指引，程序发出的请求流 量便正式离开客户端，踏上以服务器为目的地的旅途了，这个过程就 是本节的主角：传输链路。

        可能不少人的第一直觉会认为传输链路是开发者完全不可控的因 素，网络路由跳点的数量、运营商铺设线路的质量决定了线路带宽的 大小、速率的高低。然而事实并非如此，程序发出的请求能否与应用 层、传输层协议提倡的方式相匹配，也会对传输的效率有极大影响。 最容易体现这点的是那些前端网页的优化技巧，只要简单搜索一下， 就能找到很多以优化链路传输为目的的前端设计原则，譬如经典的雅 虎YSlow-23条规则[1]中与传输相关的内容如下

连接数优化

优化连接数的主要目标是减少请求和响应之间的延迟。以下是一些常见的连接数优化策略：

1. 减少请求数量：

   • 雪碧图（CSS Sprite）：将多个小图标合并成一张大图，通过CSS背景定位技术展示不同部分，从而减少HTTP请求数。
   • CSS和JS文件合并/内联：将多个CSS或JS文件合并成一个文件，或将其直接内联到HTML文档中，减少请求次数。
   • 分段文档（Multipart Document）：将多个资源分段放入一个HTTP响应中。
   • 媒体内联（Data URI）：使用Base64编码将小型媒体文件（如图片、音频）内联到HTML或CSS中。
   • 合并Ajax请求：将多个Ajax请求合并为一个请求，减少通信次数​​。

2. 扩大并发请求数：

   • 域名分片（Domain Sharding）：将资源分布在不同的域名或子域上，以增加并发请求数，现代浏览器通常对每个域名支持6个并发请求，域名分片可以突破这个限制​​。

 传输压缩

传输压缩是提升网络传输效率的重要手段，主要通过以下方式实现：

1. GZip压缩：

   • HTTP协议支持GZip压缩，特别适合于文本数据（如HTML、CSS、JS），启用压缩可以大幅减少传输数据量，通常可降至原数据量的20%左右。
   • 即时压缩（On-The-Fly Compression）：现代Web服务器具备即时压缩功能，在响应过程中动态压缩数据流，提高传输效率和首字节时间（TTFB）​​。

2. HTTP/2压缩：

   • HTTP/2引入了头部压缩和多路复用技术，使得多个小文件的传输更为高效。HTTP/2的帧结构允许更细粒度的数据流控制，提高了整体传输效率​​。

 快速UDP网络连接

传统的HTTP协议是基于TCP传输的，虽然TCP提供了可靠的数据传输，但其连接建立和拥塞控制机制增加了延迟。为解决这些问题，Google推出了QUIC协议，并在IETF标准化为HTTP/3。

1. QUIC协议：
   • QUIC（Quick UDP Internet Connections）是基于UDP的传输协议，具有低延迟、快速连接建立和多路复用等优点。
   • 通过将传输层和应用层集成在一起，QUIC可以更高效地处理连接和数据传输，避免了TCP的队首阻塞问题，提高了整体传输性能。
   • QUIC已被IETF标准化为HTTP/3，逐步成为新一代互联网传输协议​​。

小结

        传输链路的优化是提高系统性能和用户体验的关键。通过连接数优化、传输压缩和采用新的传输协议（如QUIC），可以显著减少延迟和提升数据传输效率。这些优化措施在分布式系统架构中起到至关重要的作用，确保数据在网络中的高效、可靠传输。

五、内容分发网络

        前面几节介绍了客户端缓存、域名解析、链路优化，这节我们来 讨论它们的一个经典的综合运用案例：内容分发网络（Content Distribution Network，CDN，也有写作Content Delivery Network）。

        内容分发网络是一种十分古老的应用，相信大部分读者都或多或 少对其有一定了解，至少听过它的名字。如果把某个互联网系统比喻 为一家企业，那内容分发网络就是它遍布世界各地的分支销售机构。 假设现在有客户要买一块CPU，那么订机票飞到美国加州Intel总部肯 定是不合适的，到本地电脑城找个装机铺才是通常的做法，在此场景 中，内容分发网络就相当于电脑城里的本地经销商。

如果抛却其他影响服务质量的因素，仅从网络传输的角度看，一 个互联网系统的速度取决于以下四个因素。 

• 网站服务器接入网络运营商的链路所能提供的出口带宽。
• 、用户客户端接入网络运营商的链路所能提供的入口带宽。
• 从网站到用户经过的不同运营商之间的互联节点的带宽，一般 来说两个运营商之间只有固定的若干个点是互通的，所有跨运营商之 间的交互都要经过这些点。 ·从网站到用户的物理链路传输时延。爱打游戏的读者应该都清 楚，延迟（Ping值）比带宽更重要。

        举个例 子，如果不是有遍布全国乃至全世界的阿里云CDN网络支持，哪怕把整 个杭州所有市民上网的权力都剥夺了，把带宽全部让给淘宝的机房， 恐怕也撑不住全国乃至全球用户在双十一期间的疯狂“围殴”。

        内容分发网络的工作过程，主要涉及路由解析、内容分发、负载 均衡和CDN应用四个方面，由于下一节会专门讨论负载均衡的内容，所 以这部分在本节暂不涉及，下面我们来逐一了解其余三个方面。

1、路由解析

DNS域名解析基础

DNS（Domain Name System）是将域名转换为IP地址的系统。传统的DNS解析过程如下：

1. 用户在浏览器中输入网址。
2. 浏览器向本地DNS服务器发送查询请求。
3. 本地DNS服务器逐级查询域名的权威DNS服务器，直到获得最终的IP地址。
4. 浏览器使用该IP地址访问目标服务器。

路由解析过程

有内容分发网络参与的路由解析过程相比传统的DNS解析更为复杂，主要增加了内容分发网络的调度。具体步骤如下：

1. CNAME记录解析：

   • 用户访问域名（例如 icyfenix.cn）。
   • 域名服务商解析该域名，返回一个CNAME记录（例如 icyfenix.cn.cdn.dnsv1.com）。
   • 本地DNS继续解析该CNAME记录，最终得到多个分布在不同地域的A记录，即CDN节点的IP地址。

2. 内容分发网络调度：

   • 本地DNS根据CNAME记录，查询CDN服务商的权威DNS服务器。
   • CDN权威DNS服务器根据地理位置、网络状况、缓存状态等因素，选择一个最优的CDN节点，并返回该节点的IP地址给本地DNS。

3. 浏览器访问CDN节点：

   • 浏览器从本地DNS获取CDN节点的IP地址，将其当作源站服务器进行访问。
   • 如果该CDN节点上已经缓存了用户请求的资源，则直接返回；如果没有缓存，则从源站拉取资源，再返回给用户。

2、内容分发网络

        内容分发网络（CDN）在用户和服务器之间的工作可以完全透明。这意味着在用户和服务器都不知情的情况下，CDN的缓存节点会接管用户向服务器发出的资源请求。然而，这需要缓存节点中有用户请求的资源副本，这涉及两个子问题：“如何获取源站资源”和“如何管理（更新）资源”。以下是CDN内容分发的两种主流方式：

1. 主动分发（Push）

        主动分发是由源站主动发起的，将内容从源站或其他资源库推送到各个CDN缓存节点上。这个过程没有统一的业界标准，可以选择任何传输方式（如HTTP、FTP、P2P等）和任何推送策略（如满足特定条件、定时、人工等），只要与后续的更新策略相匹配即可。由于主动分发需要源站和CDN服务双方在程序API接口层面的配合，所以对源站并不透明，只对用户透明。主动分发通常用于需要预载大量资源的场景。例如，在双十一之前，淘宝、京东等网络商城会将活动所需的资源推送到CDN缓存节点中。

2. 被动回源（Pull）

        被动回源是由用户访问触发的自动化、双向透明的资源缓存过程。当某个资源首次被用户请求时，若CDN缓存节点没有该资源，就会实时从源站获取。资源的响应时间可认为是从源站到CDN缓存节点的时间加上从CDN发送到用户的时间之和。因此，被动回源的首次访问通常比较慢，不适合大数据量的资源。但由于CDN的网络条件通常优于普通用户网络，这种方式不一定比用户直接访问源站更慢。被动回源的优点是完全双向透明，不需要源站在程序上做任何配合，使用起来方便。小型站点使用CDN服务通常选择这种方式，如阿里云、腾讯云的CDN服务。

CDN资源管理和更新

        CDN如何管理和更新资源没有统一的标准。尽管HTTP协议中有关于缓存的Header定义（如Cache-Control的s-maxage），但是否遵循取决于CDN的实现策略。由于大多数网站开发和运维人员对HTTP缓存机制了解不足，若CDN完全按照HTTP Header来控制缓存失效和更新，效果可能很差，甚至引发问题。因此，CDN缓存管理没有通用准则。

目前最常见的做法是超时被动失效与手工主动失效相结合。超时被动失效是指给予缓存资源一定的生存期，超过生存期后在下次请求时重新被动回源。而手工主动失效是指CDN服务商提供失效缓存的接口，网站更新时，通过持续集成流水线自动调用该接口实现缓存更新。例如，“icyfenix.cn”通过Travis-CI的持续集成服务触发CDN失效和重新预热。

总结起来，CDN的内容分发和资源管理涉及多种方式和策略，选择哪种方式取决于具体需求和场景。

3、CDN的应用

CDN 最初是为了快速分发静态资源而设计的，但随着技术的发展，CDN 的功能已经远远超越了最初的目标。以下是现在 CDN 所能提供的一些功能和服务：

1. 加速静态资源分发

这是 CDN 的本职工作。通过将静态资源缓存到靠近用户的节点，减少用户请求资源的时间。

2. 安全防御

CDN 可以作为网站的堡垒机，源站只对 CDN 提供服务，由 CDN 来对外提供服务，从而减少恶意攻击者直接威胁源站的机会。CDN 对某些攻击手段的防御（如 DDoS 攻击）尤其有效。但需注意，将所有安全措施都依赖于 CDN 是不安全的，一旦源站真实 IP 被泄漏，就会面临风险。

3. 协议升级

许多 CDN 提供商都同时提供 SSL 证书服务，可以实现源站使用 HTTP 协议，但对外的网站使用 HTTPS 协议。同理，可以实现源站与 CDN 之间使用 HTTP/1.x 协议，而 CDN 对外提供 HTTP/2 或 HTTP/3 协议服务；实现源站基于 IPv4 网络，而 CDN 对外提供 IPv6 网络支持等。

4. 状态缓存

CDN 不仅可以缓存源站的资源，还可以缓存源站的状态。例如，可以通过 CDN 缓存源站的 301/302 状态码，让客户端直接跳转，也可以通过 CDN 开启 HSTS，进行 OCSP 装订加速 SSL 证书访问等。在某些情况下，甚至可以配置 CDN 对任意状态码（如 404）进行一定时间的缓存，以减轻源站压力，但这种操作应慎重，且在网站状态发生变化时要及时刷新缓存。

5. 修改资源

CDN 可以在返回资源给用户时修改资源的任何内容。例如，可以对源站未压缩的资源自动压缩并修改 Content-Encoding 以节省用户的带宽消耗，可以对源站未启用客户端缓存的内容加上缓存 Header 以自动启用客户端缓存，可以修改 CORS 相关 Header 为源站不支持跨域的资源提供跨域能力等。

6. 访问控制

CDN 可以实现 IP 黑/白名单功能，如根据不同的来访 IP 提供不同的响应结果，根据 IP 的访问流量来实现 QoS 控制，根据 HTTP 的 Referer 实现防盗链等。

7. 注入功能

CDN 可以在不修改源站代码的前提下，为源站注入各种功能。例如，CloudFlare 提供的 Google Analytics、PACE、Hardenize 等第三方应用，原本需要在源站中注入代码才能使用，但通过 CDN，这些应用可以无须修改源站代码即可实现。

通过上述功能，CDN 不仅提升了资源分发的效率，还增强了网站的安全性、灵活性和可管理性，成为现代互联网不可或缺的一部分。