引言
作为公司 cdn 小组的一名小码仔，我为写一篇 cdn 的科普文章准备了好一段时间（大概有一个多月没有更新我的社交账号了）。
在我刚进入公司，培训完，进入小组，了解到我们做的是 cdn 相关的工作后，我第一时间就是上网搜关于 CDN 的入门知识。不知道大家有没有做过和我相类似的事情，但是，我想结果都是差不多的：不太能找到一篇符合自己预期的 cdn 入门介绍文章。
作为 IT 行业的从业者，偶希望这文章虽然讲的是入门，但最好又不那么入门，最好能把我们学过的计算机知识串联起来。就是那种，请把我的头发染成黑色，但又不要那么的黑，需要那种五彩斑斓的黑.....
首先我尽力为这篇文章奠定一个大的基调，不知道大家赞不赞同：缓存和递归，是计算机领域最有意思的两个词之二。
大家想一想，计算机自顶向下，是不是多级缓存构建起来的？
计算机最底层的运行命令就那么几条，我们上层应用所有花里胡哨的行为，终究要回归到这几条指令。而这个花里胡哨到简单明了的转化，靠的就是递归呀！
假设您能认同这个观点（解释的角度可以切换，但这篇这么讲比较合适），我们进一步思考：那貌似我们计算机系统设计就离不开缓存和递归思想。
既然计算机离不开缓存与递归，那么，基于计算机，在此之上构建的网络通讯自然也离不开缓存与递归。计算机找 IP，各种寻址，但凡你要是细想，你会发现：龟龟，全是缓存与递归......
扯远了，我们回到工作当中。可以这么说，互联网产品，几乎没有不使用 CDN 网络的，小公司为了加速用户访问产品，不得不上 cdn；成规模的公司基本都有 cdn 小组负责公司的 cdn 解决方案；大公司基本都会构建自己的 cdn 网络，进而对外兜售 cdn 服务。
有了以上铺垫后，各位看官请酝酿一下缓存与递归的思想，听我站在用户的角度讲个故事：
开胃小故事
很久很久以前，我家住在村头，杂货店在村尾，村头和村尾相隔十万八千里，我每次买东西都要跨过山河大海，我非常不爽，因为这非常耗时间。
这个时候村里来了一个中间商，他在村头和村尾之间摆了一个小摊，当我想去买东西的时候就会在村中间遇见他，我问他：你有没有 AD 钙奶。
他说：等我一下。
然后他一个跟斗云翻到了村尾，取了 AD 钙奶，然后又一个跟斗返回他的小摊，他告诉我：AD 钙奶，我给你取回来了。
我很高兴，这次不用走那么远了。
第二天，我又想喝 AD 钙奶，我往村尾的方向走，到了村中间的小摊又遇到了老板。
老板听说我要 AD 钙奶，往下一掏，直接就拿了出来。
我说龟龟，这次怎么这么快？
老板说，你上次来买过一次，我已经记住了，而且我还把 AD 钙奶存到我的小摊里。
我很高兴，这次连等老板取货的时间都省了。
第三天，我想喝 82 年的拉菲了，我又往村尾的杂货店走去，中间又遇到了老板。
老板往下一掏，直接就拿出了一瓶 82 年的拉菲，叫我微信扫码。
我很好奇：我之前没来买过 82 年的拉菲呀！怎么事先就存放在这了呢？
老板说：哦，村尾杂货店知道你们村头人喜欢喝 82 年的拉菲，所以提前把拉菲提前下放到了我的小摊里。
我想：哎哟，这还挺贴心。
第四天，我又想喝 AD 钙奶，而且我在电视广告得知，AD 钙奶出了新品种，我想喝最新的。
于是我再次来到了老板的小摊。
老板又往下一掏。
我说：停停。
AD 钙奶已经更新了，你这不是最新的版本！
老板说：哦？是么？
然后他又一个跟斗云翻回村尾杂货店，取了最新的 AD 钙奶，再一个跟斗云回到小摊。
于是，我喝到了最新的 AD 钙奶。
老司机肯定知道，我上面这小说，已经把 CDN 的基本使用讲完了，接下来，我从内容提供者的角度，用专业术语，重现一次这个过程。
技术名词讲解
我们以访问一张图片为例子，假设我直接基于手边笨重的机器搭建静态文件服务器，把图片寄存到这台机器上，假设我的工作地点在广州，那么这个时候如果有一名北京的用户想访问我的图片资源，就要走很长一段网络链路。
用户加载图片的速度慢，就会不爽，不爽就不会用我们的服务，用户流失严重，我就会被炒掉，所以我要想办法解决这个问题。
于是我联系上海的同事，问他能不能用他们机房的机器做一个缓存节点，把我这机器当作源站，用户取文件的时候先到你那里取，发现没有就到我这取，取完后把图片资源缓存在你们的机器上，这样用户再次访问这张图片的时候，就能从你们那取到了，不用走这么远。
同事说没问题。
但他接着问：哎阿菌，既然你知道用户要访问这张图片，为啥不提前把这张图片预热到我们的缓存节点上呢？你提前把图片发送到我们节点，我们就不需要回源去取了呀！
我恍然大悟：你说的有道理。
同事说，哈哈哈，不过咧取图片倒也不用特别久，因为图片顶多就几个 MB，我们回源取也没问题。但是如果你们以后有一些大文件，比如说十几 GB 的游戏安装包，那提前预热放到我们那，用户的体验是会提高很多的。
我简直不能再同意。
两个星期后，我们产品对那张图片提出了整改要求，要求把图片的背景色改成黑色，但又不要那么黑，改完之后要求我们立刻把图片更新给客户。
我一想，完了，由于加了缓存机制，缓存节点上放的是以前的图片，用户不会直接到我们这儿取最新的图片。
于是我再次打电话给上海的同事，我说，大佬，我们那张图片更新了，你那边可以让缓存在你们节点上的图片失效么，重新来我们这取一张最新的图片。
同事哈哈一笑：当然可以，这种刷新操作我们必然支持。或许我们以后还可以商量加一个功能，添加一个缓存的失效时间。
我说那简直太好了。
一段时间后，我们机房出了一个事故，一只老鼠旋转跳跃的时候扯断了我们机房的一根电线，我们存放图片的机器受到了牵连，机器挂了。
恰好那个时候同事的缓存节点有许多回源请求来我们源站取资源，这些请求全都受到了牵连，用户立马就来投诉，为啥资源迟迟未能加载？
同事说：哎阿菌，要不你们以后多整几个源站吧，这样当我们请求一个源站迟迟未能有响应的时候，就立马切换到下一个源站节点。
我觉得他说得很有道理，便在不同的地方搭建了好几个源站。
这回系统就有意思了。
作为内容提供者，我需要保证的是：我的每一份资源，都要能确保发送到每一个源站站点，要确保每个源站上的资源都是一样的。这里涉及到了分布式系统的一致性问题。
而我的同事，缓存节点的维护者，他们要考虑的是：如何通过合理的负载均衡算法，确保回源请求能正确访问源站节点。
讲到这里，不知道朋友们是否就能将 CDN 和我们所学的各种计算机知识联系起来了呢？
我个人觉得，CDN 的设计和 Web 后端设计是相通的，和我们使用 nginx 在自己的服务器前加一层代理是同类型操作。
感觉这 CDN 服务想要卖钱，首先需要依靠团队扎实的技术基础，另一个更重要的则是公司的基础建设。所以可以大胆预言，CDN 服务最后的胜者不会是这条赛道的先驱，而是基础建设牢固的那些公司们。
但是这世界上终究没有永远的胜者，蛋糕这么大，有人吃肉，有人喝汤嘛。
对于我们这种 CDN 服务的使用者而言，我们只要知道他的原理，并且能好好设计使用方案使用就好了。
授之以渔
假设我是一名读者，读到这里，我肯定会觉得意犹未尽。
所以非常推荐大家动手实际操作，申请一个域名，体验一下整个 cdn 的使用流程。在这个过程中如果遇到了感兴趣的知识点就能深入往下学习啦。
由于工作原因我体验过很多主流厂商的域名申请，但由于没有一家给广告费，我也不知道该用哪家举例子比较好 T_T。
推荐从域名申请开始的原因是：域名申请往往需要和域名配置一起进行，当你进行域名配置的时候，你能从配置中反推很多 cdn 的知识。
比如说：
- 源站配置。当我们配置源站的时候，你需要考虑配多少个源站？缓存节点访问源站用什么协议？访问源站多久算超时？回源的时候要不要带上一些特定的 HTTP 头以达成某种目的？回源的时候要不要进行一些前置配置？
- 缓存配置。我们要缓存哪些请求？GET 请求是要的，其他请求要不要考虑捏？允许哪些协议？请求源站返回错误怎么办，要不要配个默认错误页面？
- 其他配置。被攻击了怎么办，IP白名单可以考虑用起来。cdn 的请求日志要不要开启，获取更多的用户信息就能做更多的定制服务等等......
你可从中看出，其实 cdn 知识和服务器开发知识是紧密关联的。我本人是个初学者，所以放出这些问题和大家一起讨论了。要学的还有很多，共勉～