關於雲上負載均衡的使用
摘要：對於http負載均衡，往往有超時限制；對於tcp負載均衡，往往不做源地址轉換（無法通過配置的方式設定為需要源地址轉換），對於如下部署方式：
APP如果呼叫自己的話，可能伺服器A發起請求，經過負載均衡後，又落到了伺服器A自身，這是，由於負載均衡沒有做源地址轉換，所以，A的回包是發現目的地址就...
對於http負載均衡，往往有超時限制；對於tcp負載均衡，往往不做源地址轉換（無法通過配置的方式設定為需要源地址轉換），對於如下部署方式：
APP如果呼叫自己的話，可能伺服器A發起請求，經過負載均衡後，又落到了伺服器A自身，這是，由於負載均衡沒有做源地址轉換，所以，A的回包是發現目的地址就是自己，就不需要離開本機了，然而這種沒有經過源地址轉換的回包是不會被認可的，所以，這種部署方式存在較大弊端，尤其是一個伺服器上部署多個應用時，應用之間的頻繁呼叫就必然會遇到這個問題。
改進方案：
如果請求發起總是在APP上，則上述模式工作的會比較好；
但是，還有情況需要考慮，nginx做內部重定向的情況也是非常常見的，當訪問a.i.phpor.net 時，很可能需要nginx直接內部轉發到b.i.phpor.net ，這是，請求發起者是nginx，為了節省資源，b.i.phpor.net 也是使用的同樣的負載均衡和nginx，於是，又出現了前面所討論的問題。
再次改進，確保nginx不會重定向請求到負載均衡，畢竟還是要回來，索性在nginx上稍微麻煩一些，直接轉發到自己，或者nginx上將所有自己能提供的服務的域名都解析到127.0.0.1