云计算之路-入阿里云后：解决images.cnblogs.com响应速度慢的诡异问题

昨天，是我们迁入阿里云后经受高访问量考验的第一天，除图片站点（images.cnblogs.com）之外其他站点的访问速度表现都很不错。

images.cnblogs.com 是我们之前存放上传图片的主要站点，现在用的是 images.cnitblog.com 。images.cnblogs.com 部署在一台阿里云云服务器上，images.cnitblog.com 用的是又拍云（有CDN加速）。images.cnblogs.com 没有使用又拍云是因为让人纠结的Url大小写的问题，详见之前的博文云计算之路：云存储的纠结。

昨天在上班时间的访问高峰期，images.cnblogs.com图片加载速度变得很慢，严重时变得奇慢无比。究竟慢到什么程度，请看下面的截图（这可是304 Not Modified的响应）。很多200响应会超时。

刚开始发现问题时，我们以为是带宽不够，后来把带宽加到绰绰有余，问题依旧。当时还以为是阿里云的问题——带宽没加上去，联系了客服，确认带宽的确加上了。

确认不是带宽的原因后，我们又从磁盘IO入手——图片站点的特点之一就是读磁盘很频繁。但从监测数据看，磁盘IO也在正常范围。

对于图片这样的静态文件站点，影响速度的两个最主要的因素（带宽与磁盘IO）都正常，CPU、内存占用也正常（静态文件站点本来对CPU与内存的资源需求就很小），而访问速度却奇慢，真是一个诡异的问题。

出现问题时，IIS的同时连接在3500左右，这个连接数应该是小意思。以前用自己的服务器，不是静态文件的站点，2万的同时连接数都撑得住。

一直忙到下班时间，都没解决问题。。。。

下班时间之后（访问量降下来了），突然恢复了正常，查看了IIS同时连接数，降到了2000以下。

问题肯定与云服务器的负载有关，负载达到一定程度（我们目前可观察到的指标是IIS同时连接数超过2000），云服务器就会有强烈反应（我们遇到的站点响应速度奇慢就是反应之一）。不管怎么样，这么强烈的反应肯定与对某一个资源的需求得不到及时满足有关，而资源无非就是CPU、内存、硬盘、网卡，前面三个资源通过监测都确认正常，网卡出问题的可能性很小，我们也不知道如何监测。每个部分都是正常的，整体却有问题。诡异问题不是徒有虚名。

对问题的原因我们束手无策，但我们又必须要解决问题，怎么办？

把当前问题（在某种情况下单台云服务器撑不住2000以上的并发连接）当作一个约束条件，在这个约束之下解决真正要解决的问题——让 image.cnblogs.com 恢复正常速度访问。

一下子问题变得简单了，既然单台云服务器撑不住2000以上的并发连接，那就分而治之，将请求分在多台云服务器上，让单台云服务器承受2000以下的并发边接。这样还会带来一个额外的好处，将带宽分在多台云服务器上购买，成本更低。（再次证明了明确真正要解决的问题，问题就解决了一半）

但是这种解决方法引发了另外一个问题，如何分而治之？负载均衡当然是首选，但是阿里云有且只有1个负载均衡器，已经用在了访问量更大的站点上。问题又变成了——如何不用负载均衡器做负载均衡？这时需要跳出当前的视野，来到用户发起请求的第一站——DNS服务器，通过DNS轮询达到负载均衡的效果。在DNS服务器中为 images.cnblogs.com 添加多个IP，每次解析时随机选取一个IP（虽然不是很均衡，但能够解决实际问题）。

今天我们就采用了“DNS轮询+两台云服务器”来验证我们的解决思路，效果很明显，images.cnblogs.com图片加载速度明显提升。为了达到更满意的效果，我们正在增加更多的云服务器。

明确真正要解决的问题、分而治之、跳出当前的视野，这就是我们在这次解决问题中想要分享的。