搬到阿里雲上，對我們來說是重要的一步。雖然會遇到很多問題，但我們有信心解決這些問題！將遇到的實際問題與大家分享，也是一件很有價值的事。
這次遇到的問題涉及到IIS與阿里雲負載均衡所用的Tengine（阿里的開源Web服務器）。
我們的RSS站點遷移至阿里雲之后，發現http動態內容壓縮沒有生效（也就是下圖中的 Content-Encoding: gzip 沒出現）。
RSS站點使用了阿里雲的負載均衡，用戶請求先到達負載均衡（SLB），再到達IIS；響應從IIS發出，經由SLB到達最終用戶。所以，要么是IIS的問題，要么是SLB的問題，要么兩者都有問題。
我們先從IIS入手，IIS是根據Content Type決定是否啟用http動態壓縮，RSS站點用到了三種Content Type——application/atom+xml;application/rss+xml;application/xml，這三種Content Type的壓縮並不被IIS默認支持，IIS默認支持的是text/xml。
怎么辦？在IIS配置中加上這三種Content Type即可，具體操作方法詳見之前的博文——遷入阿里雲后：解決了一個IIS動態內容壓縮的問題，添加之后的效果見下圖：
解決了IIS的問題之后，我們發現用戶得到的最終響應內容還是沒有被壓縮，見下圖（未出現Content-Encoding: gzip）：
我們由此推斷可能Tengine也要針對這三種Content Type進行設置（用戶瀏覽器與我們的IIS之間隔着Tengine），於是我們向阿里雲發起了工單。。。阿里雲客服讓我們確認一下IIS是否收到了來自Tengine的gzip header（也就是在http請求頭中是否包含了 Accept-Encoding: gzip, deflate）。
於是，問題就變成了我們如何用數據證明問題出在Tengine？如果我們可以操控Tengine，可以跳過這個步驟，根據直覺或自己的判斷，直接對Tengine下手。但現在僅僅有直覺是不夠的，還要用數據證明你的直覺或者用說服力讓對方相信你的直覺。
我們選擇了用數據來證明，通過一個IIS工具——Advanced Logging for IIS，讓我們對Tengine的懷疑變成了鐵證如山。
下面是Advanced Logging for IIS的具體操作步驟：
1、准備工作：IIS需要安裝HTTP Logging組件
2、下載安裝Advanced Logging for IIS：下載地址
3、安裝成功之后，你會在IIS管理器中看到它：
4、添加我們要跟蹤的Accept-Encoding請求頭：打開Advanced Logging，點擊右側的Edit Logging Fields，然后Add Field，填寫的內容如下圖：
5、添加日志定義：選擇相應的Web站點，進入Advanced Logging，點擊右側的Add Log Definition，添加如下圖所示的內容：
6、取證：通過Advanced Logging的日志文件，取到了Tengine沒有發送 Accept-Encoding: gzip, deflate 請求頭的證據。
7、將證據反饋給阿里雲之后，問題很快就得到了解決。
