高并发架构的CDN知识介绍

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
.cn 域名,1个 12个月
简介: 本文详细介绍了网络请求过程,特别是大型网站架构中DNS和CDN的作用。通过一张常用架构图,文章解释了从客户端请求到服务器响应的全过程,包括DNS解析、负载均衡、CDN加速等关键环节,帮助读者深入了解高并发架构的设计原理和优化方法。

对一次网络请求过程的了解程度,一是展现你的专业知识;二是深刻的理解,让你在大型网站架构中做出更适合、可靠的架构。而DNS是这一切的出发点,本文结合一张常用架构图,来描述一下这个过程。

部署架构

大型的web服务,我们的部署架构一般如下图。先上图再解释。
image.png

高并发架构的CDN知识介绍

这里来解释下,为什么要这样架构。 首先客户端的请求会通过 DNS 获取到对应的服务器IP(实际上是LB的IP地址),这一层会有 DNS的负载均衡,并且如果是静态站资源会进入到CDN,这里DNS与CDN如何完成接棒的过程,后面会详细解释。 当请求到达LB层的时候(应用层协议是HTTP协议),这一层又会做一次负载均衡(可能用LVS或者Nginx做)。这里我们有两种不同的处理方式,一条路径会进入到代理集群,一条路径直接进入到应用集群。这是为什么?

LB到代理集群

通过最顶层的LB负责均衡后到达代理机器,这里不直接进入到应用集群,还要搞一层代理的目的主要是方便我们在代理集群进行各种高级(骚)操作。

比如:请求日志收集,自定义缓存,自定义的负载均衡,自定义的路由规则制定(跨机房,路由分组)

LB到应用集群

上面到代理层有那么多好处,为什么还有绕过代理层这条路径存在呢?这主要是针对大流量服务。因为代理层因为有很多额外的操作,导致响应会变长,路径增加,到下一个集群多了一次网络传输往返。

所以,一般针对大流量服务,为了防止代理被打满,响应更快,会直接在外网LB上进行负载到应用集群。

通过上面的分割后,最终都会到达应用集群,每一台机器上我们会部署一台 Nginx 来按照域名转到对应服务,当然这里完全也可以不是 Nginx,比如微服务,这里可能是一个 SideCard 代理。这里主要是为了便于说明我们后面全部都是当成Nginx。服务调用 DB Cache 等,都是通过域名,这是为了负载均衡,请求时,会通过内网DNS服务,完成域名解析,然后拿到内网的 LB 的IP。然后再这里进行内网的负载均衡,会根据域名的端口来检查你是写操作、还是读操作返回IP。常规一点会保证是单点写入,多点读取。来完成数据一致性的保障。

整个大体过程如此,接下来我们详细说一下 DNS与CDN相关的工作原理。

DNS如何实现IP查找

为了后面说清楚CDN,这里先介绍DNS的解析过程。当然此类文章网络上已经极多。但是我还是想按照我的理解来说一下DNS是如何工作的。

在整个DNS过程中有四个重要概念,下面解释下。

DNS Resolver - 递归解析器,主要是接收客户端发出的域名解析请求,并发送 DNS query 查询请求。对于客户端来说它不需要任何操劳,等待 DNS Resolver 告诉自己域名转IP的结果就好。

Root Server - 这是转换IP执行的第一步查询,根服务器并不会保存具体的域名IP映射信息。它就像一个索引服务器,会告诉你下一步该去那台 TLD Server 查询。

TLD Server - 这是顶级域名服务器,是执行IP查询的第二步,这里会告诉 DNS Resolver 权威域名服务器的地址。

Authoriative Server - 权威域名服务器就是包含了完整的机器名的域名,例如:www.example.com ,在这台机器上保存了这个具体域名对应的IP地址。

高并发架构的CDN知识介绍

下面根据图中的十个步骤说一下每一步都在干嘛。

1.一个用户在浏览器输入了:example.com,这时会产生一个 DNS 查询,从而进入到 DNS Resolver中;

2.Resolver 会进入到 root server 进行查询;

3.root server 返回了 TLD server 的地址,查询请求转向顶级域名服务,这里是 .com 服务器。

4.递归解析器向 .com 服务器发送一个请求;

5.TLD server 收到请求后会返回 example.com 权威服务器的地址;

6.递归解析器又发了一个向权威服务器查询的请求,至此权威服务器查询自己的映射表拿到IP;

7.返回查询到的IP给了 DNS Resolver;

8.DNS Resolver返回IP给浏览器,浏览器将会用这个IP来建立连接,发起请求;

9.客户端通过这个IP地址,发起一个 HTTP 请求;

10.服务器解析请求,并返回数据到浏览器。

这里需要补充一点是,上面每一步其实都有DNS缓存的设计。比如:

.浏览器会缓存DNS的结果,(chrome://net-internals/#dns)

.操作系统的DNS模块会缓存

.后面的每一层级也都有缓存

所以很多时候,我们的解析过程并不是要顺序执行完这8个步骤。这就跟我们自己开发的应用服务一样,层层缓存,有缓存就读取缓存结果,缓存实现就执行完整流程。

DNS的解析分类

DNS有多种解析记录可以设置,我这里介绍三个很常用的记录。

A记录 - 被称为IP指向,用户设置自己域名指到对应的IP主机上。如果想要利用A记录实现负载均衡需要主机商的支持。

CNAME记录 - 它相当于为一个主机名设置一个别名,而且该记录不能直接使用IP,只能是另一个主机的别名。CDN主要就是利用该记录来完成的。如果有A记录与CNAME记录同时存在,A记录会被优先使用,换句话说CNAME记录不会生效。

NS记录 - 用来设置一个域名的权威服务器路径,该记录只会对子域名生效。这个地方可以设置IP也可以设置另外一个权威服务器的域名。需要重点指出的是它的优先级高于A记录,并且它在DNS解析过程中,会跳过2,3,4,5步。

了解完了DNS的步骤,接下来就进入到CDN部分的分析。

CDN访问加速度

高并发架构的CDN知识介绍

什么是CDN呢?中文翻译过来就是内容分发网络。看张图。

没有CDN的时候,不管哪里的用户访问我们的站点,都需要到我们数据中心来获取数据(单纯的DNS过程)。而有了CDN之后,用户根据自己的地理位置会选择距离自己最近的缓存数据中心来获取数据。不会每次都到源站(应用服务器)来获取数据。为了理解这个过程,我们是如果在完整的DNS过程中,实现CDN的呢?

接下来我们需要回答两个问题。

1.CDN带来了什么好处。

2.如何解析到CDN。

CDN带来的好处

了解一个东西之前最好知道它能干什么,带来的好处是什么。然后我们再去看它的运行原理。对于CDN有以下几个方面的好处。

提高页面加载速度

这是最显而易见的一个优势,通过上面的图,大家也可以直观感受下,用户访问距离自己最近的机器,速度肯定是最快的。并且网站的加载速度越快那么用户体验越优秀,你的网站更会受到对应用户的喜爱。至于如何实现就近访问的,后面原理部分介绍。

增加内容的冗余

CDN是一个典型的分布式架构,它通过增加数据的冗余,一方面保障在大流量面前有多台服务器能够提供相同的数据;另一方面当部分机器出现故障时,可以进行故障转移。

节省带宽

如果大家自己买过云服务就知道,带宽每增加一点价格就飙升。使用CDN后,由于流量被分流了,那么原机器带宽要求自然就降低了。当然带宽费用降低了,你还需要为CDN付费。

保障服务安全

CDN可防止的攻击:DDOS攻击,该攻击就是通过巨大流量打满你的带宽,让你丧失服务能力。那么由于CDN的存在,它将巨大的流量进行了分流。那么源站压力自然小了。这其实也是高并发需要考虑的。

CDN目前不仅仅是只能缓存静态的HTML、CSS、JS、VIDEO,现在还有能够缓存动态接口内容的CDN,这为我们在架构高并发的服务时,提供了更多的手段进行选择。

CDN工作原理

在介绍DNS的时候,介绍了客户端是如何获取到IP地址的。那么有了CDN之后,这个过程该怎么处理呢?

CDN其实就是放在应用服务器与用户之间的一层缓存。所以如果使用DNS的时候,返回给客户端的是CDN机器的IP而不是应用的IP,那么自然就走到了CDN机器上。

为了实现上述目的,我们会为该域名配置一个 CNAME(大家注意上面提到的CNAME与A记录的优先级),那么这个CNAME是最终如何解析到对应的CDN机器呢?其实流程与DNS解析是一样的。当发现一个域名设置了CNAME时,DNS解析器会继续解析这个CNAME别名(其实就是另一个域名)。对这个CNAME解析的时候会用到全局负载DNS解析,它会根据访问者的地理位置信息返回对应的IP(CDN机器的IP)。因此客户端实际上得到的是距离它最近的CDN机器的IP地址。

如果说用户访问CDN,但是CDN上没有对应内容会怎么办?此时CDN机器其实会根据自身专用的DNS解析服务,根据域名得到源站的IP,然后向源站发送请求获取数据,并把这些数据缓存到本地,方便后续使用;同时返回本次结果,完成本次请求的访问。

需要说一下的是,CDN其实也是分层的。距离用户最近的称之为边缘节点。而CDN的中心服务器集群被称为二级缓存。在上面就是应用部署的源站。一般边缘节点没数据就去找二级缓存,二级缓存没数据就去找源站(被称为回源)。

目录
相关文章
|
23天前
|
消息中间件 架构师 数据库
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
45岁资深架构师尼恩分享了一篇关于分布式事务的文章,详细解析了如何在10Wqps高并发场景下实现分布式事务。文章从传统单体架构到微服务架构下分布式事务的需求背景出发,介绍了Seata这一开源分布式事务解决方案及其AT和TCC两种模式。随后,文章深入探讨了经典ebay本地消息表方案,以及如何使用RocketMQ消息队列替代数据库表来提高性能和可靠性。尼恩还分享了如何结合延迟消息进行事务数据的定时对账,确保最终一致性。最后,尼恩强调了高端面试中需要准备“高大上”的答案,并提供了多个技术领域的深度学习资料,帮助读者提升技术水平,顺利通过面试。
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
|
1月前
|
缓存 关系型数据库 MySQL
高并发架构系列:数据库主从同步的 3 种方案
本文详解高并发场景下数据库主从同步的三种解决方案:数据主从同步、数据库半同步复制、数据库中间件同步和缓存记录写key同步,旨在帮助解决数据一致性问题。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
高并发架构系列:数据库主从同步的 3 种方案
|
2月前
|
缓存 NoSQL Java
秒杀圣经:10Wqps高并发秒杀,16大架构杀招,帮你秒变架构师 (1)
高并发下,如何设计秒杀系统?这是一个高频面试题。40岁老架构师尼恩的读者交流群中,近期有小伙伴在面试Shopee时遇到了这个问题,未能很好地回答,导致面试失败。为此,尼恩进行了系统化、体系化的梳理,帮助大家提升“技术肌肉”,让面试官刮目相看。秒杀系统设计涉及16个架构要点,涵盖业务架构、流量架构、异步架构、分层架构、缓存架构、库存扣减、MQ异步处理、限流、熔断、降级、存储架构等多个方面。掌握这些要点,可以有效应对高并发场景下的秒杀系统设计挑战。
秒杀圣经:10Wqps高并发秒杀,16大架构杀招,帮你秒变架构师 (1)
|
2月前
|
缓存 前端开发 JavaScript
前端架构思考:代码复用带来的隐形耦合,可能让大模型造轮子是更好的选择-从 CDN 依赖包被删导致个站打不开到数年前因11 行代码导致上千项目崩溃谈谈npm黑洞 - 统计下你的项目有多少个依赖吧!
最近,我的个人网站因免费CDN上的Vue.js包路径变更导致无法访问,引发了我对前端依赖管理的深刻反思。文章探讨了NPM依赖陷阱、开源库所有权与维护压力、NPM生态问题,并提出减少不必要的依赖、重视模块设计等建议,以提升前端项目的稳定性和可控性。通过“left_pad”事件及个人经历,强调了依赖管理的重要性和让大模型代替人造轮子的潜在收益
|
4月前
|
存储 缓存 负载均衡
高并发系统架构的设计挑战与应对策略
【8月更文挑战第18天】高并发系统架构设计是一项复杂而重要的任务。面对性能瓶颈、稳定性与可靠性、并发控制和可扩展性等挑战,开发人员需要采取一系列有效的策略和技术手段来应对。通过负载均衡、缓存技术、数据库优化、异步处理、并发控制、弹性设计及监控与调优等手段,可以设计出高性能、高可用和高可扩展性的高并发系统架构,为用户提供优质的服务体验。
|
5月前
|
开发者 Sentinel 微服务
高并发架构设计三大利器:缓存、限流和降级问题之降级策略中的有限状态机的三种状态切换的问题如何解决
高并发架构设计三大利器:缓存、限流和降级问题之降级策略中的有限状态机的三种状态切换的问题如何解决
|
5月前
|
监控 应用服务中间件 nginx
高并发架构设计三大利器:缓存、限流和降级问题之Nginx的并发连接数计数的问题如何解决
高并发架构设计三大利器:缓存、限流和降级问题之Nginx的并发连接数计数的问题如何解决
|
5月前
|
应用服务中间件 nginx 缓存
高并发架构设计三大利器:缓存、限流和降级问题之Nginx作为前置网关进行限流问题如何解决
高并发架构设计三大利器:缓存、限流和降级问题之Nginx作为前置网关进行限流问题如何解决
|
5月前
|
监控 算法 Java
高并发架构设计三大利器:缓存、限流和降级问题之配置Sentinel的流量控制规则问题如何解决
高并发架构设计三大利器:缓存、限流和降级问题之配置Sentinel的流量控制规则问题如何解决
|
5月前
|
监控 Sentinel 缓存
高并发架构设计三大利器:缓存、限流和降级问题之RateLimiter的acquire()方法有什么作用
高并发架构设计三大利器:缓存、限流和降级问题之RateLimiter的acquire()方法有什么作用