當初遷移至阿里雲遇到的第一個問題是在程序中通過Request.UserHostAddress得到的是負載均衡（SLB）的內網IP，而不是用戶的真實IP。真實IP存儲在服務器變量HTTP_X_Forwarded_For中，后來通過IIS的Url Rewrite Module將HTTP_X_Forwarded_For的值重寫入REMOTE_ADDR解決了問題。
這個問題是由於使用七層負載均衡（ Layers 7 Load Balancing）帶來的，而使用四層負載均衡不會有這個問題。但是如果讓我們選擇，我們寧願選擇七層負載均衡，七層負載均衡有它的缺點，也有它的優勢。欲了解它們的詳細區別，請移步知識庫的一篇文章——四層和七層負載均衡的區別。
我們實測了一下Azure的負載均衡，Request.UserHostAddress直接得到的是用戶的真實IP。由此可以猜測，Azure的負載均衡是四層的。
為了證實我們的猜測，我們在網上找到了一篇文章Introducing the LoadMaster for Azure – A Full Layer 7 Load Balancer/ADC for Azure Deployment，請看文中的表格（見下圖）：
由此可見，Azure內置的負載均衡確實是四層的，但可以借助第三方應用實現七層負載均衡，比如剛剛提到的的LoadMaster，但需要支付額外的費用。
從這個地方可以看出Azure的一個設計策略，只提供基本的功能，高級的功能留給第三方去實現，讓第三方在Azure平台上能夠掙到錢。這也是微軟的拿手本領。
對於之前我們遇到的現有SQL Server數據庫向SQL Azure的兼容性問題，如果需求量大的話，我們想也會有第三方工具出現。