第一次测云服务器地域和时延

前阵子我把一个课程小项目放到了云服务器上，自己在伦敦宿舍打开，感觉挺顺手，图片一刷就出来，页面也几乎是秒开。我挺得意，还把链接发给了国内的朋友，让他帮忙看看效果。结果他回了我一句：你这个网站是不是还没部署好，怎么图片一张一张往外蹦？

我当时第一反应是怀疑自己的代码写得有问题，或者是图片太大了。回去把图片压了压，把没用的脚本也删了，再发给他，情况好了一点，但还是比我在伦敦打开慢不少。直到我去翻云服务器的控制台，才发现一个之前被我直接跳过的选项：地域。

说实话，刚开始上云的时候，我眼里只有 CPU、内存和硬盘。地域这个选项，我当时就是随便选了一个离自己近的，觉得反正都是云，在哪儿不都一样吗？后来才明白，云服务器并不是飘在天上的，它实实在在地放在某个城市的数据中心里。你的请求要从你的电脑出发，经过一串网络节点，跑到那台服务器，再把结果带回来。这一来一回花的时间，就是我们常说的时延。

打个比方就好理解了。地域就像你开店选城市，可用区就像同一个城市里的不同门店。华为云的控制台里，一个地域下面常常有好几个可用区，比如 AZ1、AZ2、AZ3，它们在同一个地域内，彼此之间离得近，但电力和网络是相对独立的。把重要的服务分散放在不同的可用区，一处出了问题，另一处还能顶上，这就是很多人说的同城容灾。

那么，时延到底是怎么影响体验的呢？我自己的体会是，它不像配置那样写在参数表里那么直观，却处处都在。一个页面要加载几十个资源，图片、样式、脚本，每一次请求都要走一趟网络。如果服务器离你很远，每一趟都要多花一点时间，几十个请求累加起来，打开速度的差距就很明显了。反过来，如果服务器就在你所在的城市附近，请求跑的路短，页面自然显得轻快。所以我后来总结了一句大白话：服务器离用户越近，打开通常越快。

为了验证这个想法，我做了一个特别简单的对比。还是同一个小网站，我分别试了试从伦敦访问放在伦敦附近地域的版本，和从伦敦访问放在国内地域的版本。前者打开就是我熟悉的顺手感觉，后者则能明显感觉到顿一下，尤其图片多的时候，那种一张一张往外蹦的感觉又回来了。而国内的朋友那边，情况正好反过来：访问国内地域的版本明显更顺，访问伦敦地域的版本则要多等一会儿。这次对比没有实验室那么严谨，但结论已经够我用了：没有哪个地域对所有人都最快，只有离你的主要用户最近的地域，才是最合适的。

这就引出了选地域时真正该问的第一个问题：你的用户主要在哪儿？如果你的小网站主要是给自己和身边的同学用，选离学校近的地域就好；如果主要是给国内的朋友、老师看，或者以后想给国内用户用，那就优先考虑国内的地域。千万别像我一开始那样，只看自己在哪儿就顺手选了，结果让真正要看网站的人每次都多等一会儿。

第二个要看的是合规和备案的要求。不同的地域，规则可能不一样。有的地域对域名、内容有额外的要求，需要提前准备材料、走流程。如果你做的是课程作业或者纯练手的小项目，这一点可能感觉不到；但如果你打算长期运营一个能公开访问的网站，最好在选地域之前，先把相关要求查清楚，别等到网站搭好了，才发现卡在手续上。

第三个要看的是价格和服务。同一款配置，在不同地域的价格可能不一样，能用的服务和机型也可能有差别。对学生党来说，预算本来就不多，选地域的时候顺手比一下价格，看看自己要用的数据库、对象存储这些服务在那个地域是不是都有，能省下不少冤枉钱。我的做法是，先列出自己一定会用的服务，再去对照地域，一个一个打勾，缺了关键服务的地域，再便宜也不选。

那如果用户两边都有，伦敦和国内都有人看，该怎么办呢？我的体会是，小项目不用一上来就搞两套服务器。更省事的办法，是把思路拆开：动态的页面和数据库放在主要用户集中的地域，图片、视频这些静态资源交给 CDN 去分发。CDN 会把静态文件缓存到离用户近的节点上，用户打开时就不用每次都跑回源站，体验会好很多。等以后访问量真的上来了，再考虑多地域部署，那时候也有了真实的访问数据，决策反而更踏实。