CDN网络科普小文(小说版)

引言 作为公司 cdn 小组的一名小码仔,我为写一篇 cdn 的科普文章准备了好一段时间(大概有一个多月没有更新我的社交账号了)。
在我刚进入公司,培训完,进入小组,了解到我们做的是 cdn 相关的工作后,我第一时间就是上网搜关于 CDN 的入门知识。不知道大家有没有做过和我相类似的事情,但是,我想结果都是差不多的:不太能找到一篇符合自己预期的 cdn 入门介绍文章。
作为 IT 行业的从业者,偶希望这文章虽然讲的是入门,但最好又不那么入门,最好能把我们学过的计算机知识串联起来。就是那种,请把我的头发染成黑色,但又不要那么的黑,需要那种五彩斑斓的黑.....
CDN网络科普小文(小说版)
文章图片

首先我尽力为这篇文章奠定一个大的基调,不知道大家赞不赞同:缓存和递归,是计算机领域最有意思的两个词之二。
大家想一想,计算机自顶向下,是不是多级缓存构建起来的?
计算机最底层的运行命令就那么几条,我们上层应用所有花里胡哨的行为,终究要回归到这几条指令。而这个花里胡哨到简单明了的转化,靠的就是递归呀!
假设您能认同这个观点(解释的角度可以切换,但这篇这么讲比较合适),我们进一步思考:那貌似我们计算机系统设计就离不开缓存和递归思想。
既然计算机离不开缓存与递归,那么,基于计算机,在此之上构建的网络通讯自然也离不开缓存与递归。计算机找 IP,各种寻址,但凡你要是细想,你会发现:龟龟,全是缓存与递归......
CDN网络科普小文(小说版)
文章图片

扯远了,我们回到工作当中。可以这么说,互联网产品,几乎没有不使用 CDN 网络的,小公司为了加速用户访问产品,不得不上 cdn;成规模的公司基本都有 cdn 小组负责公司的 cdn 解决方案;大公司基本都会构建自己的 cdn 网络,进而对外兜售 cdn 服务。
有了以上铺垫后,各位看官请酝酿一下缓存与递归的思想,听我站在用户的角度讲个故事:
开胃小故事 很久很久以前,我家住在村头,杂货店在村尾,村头和村尾相隔十万八千里,我每次买东西都要跨过山河大海,我非常不爽,因为这非常耗时间。
这个时候村里来了一个中间商,他在村头和村尾之间摆了一个小摊,当我想去买东西的时候就会在村中间遇见他,我问他:你有没有 AD 钙奶。
他说:等我一下。
然后他一个跟斗云翻到了村尾,取了 AD 钙奶,然后又一个跟斗返回他的小摊,他告诉我:AD 钙奶,我给你取回来了。
我很高兴,这次不用走那么远了。
CDN网络科普小文(小说版)
文章图片

第二天,我又想喝 AD 钙奶,我往村尾的方向走,到了村中间的小摊又遇到了老板。
老板听说我要 AD 钙奶,往下一掏,直接就拿了出来。
我说龟龟,这次怎么这么快?
老板说,你上次来买过一次,我已经记住了,而且我还把 AD 钙奶存到我的小摊里。
我很高兴,这次连等老板取货的时间都省了。
第三天,我想喝 82 年的拉菲了,我又往村尾的杂货店走去,中间又遇到了老板。
老板往下一掏,直接就拿出了一瓶 82 年的拉菲,叫我微信扫码。
我很好奇:我之前没来买过 82 年的拉菲呀!怎么事先就存放在这了呢?
老板说:哦,村尾杂货店知道你们村头人喜欢喝 82 年的拉菲,所以提前把拉菲提前下放到了我的小摊里。
我想:哎哟,这还挺贴心。
CDN网络科普小文(小说版)
文章图片

第四天,我又想喝 AD 钙奶,而且我在电视广告得知,AD 钙奶出了新品种,我想喝最新的。
于是我再次来到了老板的小摊。
老板又往下一掏。
我说:停停。
AD 钙奶已经更新了,你这不是最新的版本!
老板说:哦?是么?
然后他又一个跟斗云翻回村尾杂货店,取了最新的 AD 钙奶,再一个跟斗云回到小摊。
于是,我喝到了最新的 AD 钙奶。

老司机肯定知道,我上面这小说,已经把 CDN 的基本使用讲完了,接下来,我从内容提供者的角度,用专业术语,重现一次这个过程。
技术名词讲解 我们以访问一张图片为例子,假设我直接基于手边笨重的机器搭建静态文件服务器,把图片寄存到这台机器上,假设我的工作地点在广州,那么这个时候如果有一名北京的用户想访问我的图片资源,就要走很长一段网络链路。
用户加载图片的速度慢,就会不爽,不爽就不会用我们的服务,用户流失严重,我就会被炒掉,所以我要想办法解决这个问题。
于是我联系上海的同事,问他能不能用他们机房的机器做一个缓存节点,把我这机器当作源站,用户取文件的时候先到你那里取,发现没有就到我这取,取完后把图片资源缓存在你们的机器上,这样用户再次访问这张图片的时候,就能从你们那取到了,不用走这么远。
同事说没问题。
但他接着问:哎阿菌,既然你知道用户要访问这张图片,为啥不提前把这张图片预热到我们的缓存节点上呢?你提前把图片发送到我们节点,我们就不需要回源去取了呀!
我恍然大悟:你说的有道理。
同事说,哈哈哈,不过咧取图片倒也不用特别久,因为图片顶多就几个 MB,我们回源取也没问题。但是如果你们以后有一些大文件,比如说十几 GB 的游戏安装包,那提前预热放到我们那,用户的体验是会提高很多的。
我简直不能再同意。
CDN网络科普小文(小说版)
文章图片

两个星期后,我们产品对那张图片提出了整改要求,要求把图片的背景色改成黑色,但又不要那么黑,改完之后要求我们立刻把图片更新给客户。
我一想,完了,由于加了缓存机制,缓存节点上放的是以前的图片,用户不会直接到我们这儿取最新的图片。
于是我再次打电话给上海的同事,我说,大佬,我们那张图片更新了,你那边可以让缓存在你们节点上的图片失效么,重新来我们这取一张最新的图片。
同事哈哈一笑:当然可以,这种刷新操作我们必然支持。或许我们以后还可以商量加一个功能,添加一个缓存的失效时间。
我说那简直太好了。
一段时间后,我们机房出了一个事故,一只老鼠旋转跳跃的时候扯断了我们机房的一根电线,我们存放图片的机器受到了牵连,机器挂了。
恰好那个时候同事的缓存节点有许多回源请求来我们源站取资源,这些请求全都受到了牵连,用户立马就来投诉,为啥资源迟迟未能加载?
同事说:哎阿菌,要不你们以后多整几个源站吧,这样当我们请求一个源站迟迟未能有响应的时候,就立马切换到下一个源站节点。
我觉得他说得很有道理,便在不同的地方搭建了好几个源站。
CDN网络科普小文(小说版)
文章图片

这回系统就有意思了。
作为内容提供者,我需要保证的是:我的每一份资源,都要能确保发送到每一个源站站点,要确保每个源站上的资源都是一样的。这里涉及到了分布式系统的一致性问题。
而我的同事,缓存节点的维护者,他们要考虑的是:如何通过合理的负载均衡算法,确保回源请求能正确访问源站节点。
讲到这里,不知道朋友们是否就能将 CDN 和我们所学的各种计算机知识联系起来了呢?
我个人觉得,CDN 的设计和 Web 后端设计是相通的,和我们使用 nginx 在自己的服务器前加一层代理是同类型操作。
感觉这 CDN 服务想要卖钱,首先需要依靠团队扎实的技术基础,另一个更重要的则是公司的基础建设。所以可以大胆预言,CDN 服务最后的胜者不会是这条赛道的先驱,而是基础建设牢固的那些公司们。
但是这世界上终究没有永远的胜者,蛋糕这么大,有人吃肉,有人喝汤嘛。
对于我们这种 CDN 服务的使用者而言,我们只要知道他的原理,并且能好好设计使用方案使用就好了。
授之以渔 假设我是一名读者,读到这里,我肯定会觉得意犹未尽。
所以非常推荐大家动手实际操作,申请一个域名,体验一下整个 cdn 的使用流程。在这个过程中如果遇到了感兴趣的知识点就能深入往下学习啦。
由于工作原因我体验过很多主流厂商的域名申请,但由于没有一家给广告费,我也不知道该用哪家举例子比较好 T_T
推荐从域名申请开始的原因是:域名申请往往需要和域名配置一起进行,当你进行域名配置的时候,你能从配置中反推很多 cdn 的知识。
比如说:
  1. 源站配置。当我们配置源站的时候,你需要考虑配多少个源站?缓存节点访问源站用什么协议?访问源站多久算超时?回源的时候要不要带上一些特定的 HTTP 头以达成某种目的?回源的时候要不要进行一些前置配置?
  2. 缓存配置。我们要缓存哪些请求?GET 请求是要的,其他请求要不要考虑捏?允许哪些协议?请求源站返回错误怎么办,要不要配个默认错误页面?
  3. 其他配置。被攻击了怎么办,IP白名单可以考虑用起来。cdn 的请求日志要不要开启,获取更多的用户信息就能做更多的定制服务等等......
【CDN网络科普小文(小说版)】你可从中看出,其实 cdn 知识和服务器开发知识是紧密关联的。我本人是个初学者,所以放出这些问题和大家一起讨论了。要学的还有很多,共勉~

    推荐阅读