分布式软件架构——域名解析系统

透明多级分流系统的设计原则

用户在使用信息系统的过程中，请求首先是从浏览器出发，在DNS的指引下找到系统的入口，然后经过了网关、负载均衡器、缓存、服务集群等一系列设施，最后接触到了系统末端存储于数据库服务器中的信息，然后再逐级返回到用户的浏览器之中。

这个过程需要经过许许多多的技术部件。那么作为系统的设计者，我们应该意识到不同的设施、部件在系统中，都具有各自不同的价值：

• 有一些部件位于客户端或网络的边缘，能够迅速响应用户的请求，避免给后方的I/O与CPU带来压力，典型的如本地缓存、内容分发网络、反向代理等。

• 有一些部件的处理能力能够线性拓展，易于伸缩，可以通过使用较小的代价堆叠机器，来获得与用户数量相匹配的并发性能，并且应尽量作为业务逻辑的主要载体，典型的如集群中能够自动扩缩的服务节点。

• 有一些部件的稳定服务，对系统运行具有全局性的影响，要时刻保持着容错备份，维护着高可用性，典型的如服务注册中心、配置中心。

• 有一些设施是天生的单点部件，只能依靠升级机器本身网络、存储和运算性能来提升处理能力，比如位于系统入口的路由、网关或者负载均衡器、位于请求调用链末端的传统关系数据库等，都是典型的容易形成单点部件。

所以，在对系统进行流量规划时，我们需要充分理解这些部件的价值差异。这里有两个简单、普适的设计原则：

1. 尽可能减少单点部件，如果某些单点时无可避免的，则应尽最大限度减少到达单点部件的流量。

比如用户要获取存储在数据库的用户头像图片，浏览器缓存、内容分发网络、反向代理、Web服务器、文件服务器、数据库等都可以提供这张照片。所以，恰如其分地引导请求分流至最合适的组件中，避免绝大多数流量汇集到单点部分（如数据库），同时依然能够、或者在绝大多数时候能够保证处理结果的准确性，在单点系统出现故障时，仍能自动而迅速地实施补救措施，这便是系统架构中多级分流的意义。

2. 奥卡姆剃刀原则

Entities should not be multiplied without necessity.
如无必要，勿增实体。
—— Occam’s Razor, William of Ockham

在能满足需求的前提下，最简单的系统就是最好的系统。

DNS工作原理

域名系统（英文：Domain Name System，缩写：DNS）是互联网的一项服务。它作为将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。DNS使用UDP端口53。当前，对于每一级域名长度的限制是63个字符，域名总长度则不能超过253个字符。它的作用时将人类便于理解的域名地址（如www.baidu.com）转换为便于计算机处理的IP地址（如14.119.104.254）。

先看两个名词：

• 权威域名服务器（Authoritative DNS）：负责翻译特定域名的DNS服务器。权威是指服务器决定该域名最终结果。
• 根域名服务器（Root DNS）：是指固定的、无需查询的顶级域名（Top-Level Domain）服务器，可以默认为它们已内置在操作系统代码之中。全世界一共有13组根域名服务器（每一组根域名都通过任播的方式建立了一大群镜像），之所以有13的限制是因为DNS主要采用UDP传输协议来进行数据交换，未分片的UDP数据包在IPV4下最大有效值为512字节，最多可以存放13组地址记录。

DNS解析步骤如下：

1. 客户端检查本地的DNS缓存，查看是否存在并且是存活（根据TTL，Time to Live存活时间判断缓存失效）着该域名的地址记录。
2. 客户端将地址发送给本机操作系统中配置的本地DNS（Local DNS，用户手工设置或DHCP分配时或拨号时从PPP服务器中自动获取）。
3. 本地DNS收到查询请求后，会按照是否有www.baidu.com的权威服务器 ——> 是否有baidu.com的权威服务器 ——> 是否有com的权威服务器的顺序，依次查找自己的地址记录，如果没有查询到，本地DNS就会一直找到最后点号代表的根域名服务器为止。
4. 假设本地DNS是全新的，上面不存在任何域名的权威服务器记录，所以DNS查询请求按步骤3的顺序，一直查到根域名服务器之后，它会得到com的权威服务器记录，然后通过com的权威服务器得到baidu.com的权威服务器地址记录，以此类推，最后找到能够解释www.baidu.com的权威服务器地址。
5. 通过www.baidu.com的权威服务器，查询到其地址记录。这里的地址记录并不一定是指IP地址，在RFC规范中，有定义的地址记录类型多大几十种，比如IPV4下的IP地址为A记录，IPV6下的AAAA记录、主机别名CNAME记录，等等。

DNS系统多级分流的设计，就是为了让DNS系统能够经受住全球网络流量不间断的冲击，但它也并不是没有缺点。典型的问题就是响应速度会受影响。在极端情况下，域名解析可能会导致每个域名都必须递归多次才能查询到结果，显著影响传输的响应速度。
以下图为例，DNS查询耗时约310毫秒，

所以，为了避免这种问题，专门就有一种前端优化手段，叫做DNS预取（DNS Prefetching）：如果网站后续要使用来自于其他域的资源，那就在网页加载时便生成一个link请求，促使浏览器提前对该域名进行预解释，如下所示：

<link rel="dns-prefetch" href="//domain.not-icyfenx.cn">

而另一种可能更严重的缺陷，就是DNS的分级查询意味着每一级都有可能受到中间人攻击的威胁，产生呗劫持的风险。
要攻陷位于递归链条顶层的根域名服务器和链路时非常困难的，它们都有很专业的安全防护措施。但很多位于递归链条底层的、或者来自本地运营商的Local DNS服务器，安全防护相对松懈，甚至不少地区的运营商自己主动劫持，专门返回一个错的IP，通过在这个IP上代理用户请求，以便给特定类型的资源（主要是HTML）注入广告，进行牟利。
针对这种情况，近几年出现了一种新的DNS工作模式：HTTPDNS（也称DNS over HTTPS，DoH）。它把原本的DNS解析服务开放为一个基于HTTPS协议的查询服务，替代基于UDP传输协议的DNS域名解析，通过程序代替操作系统直接从权威DNS，或者可靠Local DNS获取解析数据，从而绕过传统Local DNS。这种做法的好处是避免了“中间商赚差价”的环境，不再惧怕底层的域名劫持，能有效避免Local DNS不可靠导致的域名生效缓慢、来源IP不准确、产生的智能线路切换错误等问题。