昨天，是我們遷入阿里雲后經受高訪問量考驗的第一天，除圖片站點（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圖片加載速度明顯提升。為了達到更滿意的效果，我們正在增加更多的雲服務器。
明確真正要解決的問題、分而治之、跳出當前的視野，這就是我們在這次解決問題中想要分享的。