我們的產品中有兩個Module，分別部署在獨立的Linux機器上，Module 1需要向Module 2發起Http請求來獲得服務。由於Module 2有多台，因此我們會在Module 2前部署一台負載均衡器（ELB，Elastic Load Balancer）。我們部署在AWS里，因此使用的是AWS ELB。
AWS ELB同時提供另一個很好的功能，叫做Sticky Session，它的作用是幫你把請求定向到其中一台機器，而非隨機按ELB算法分散到其他機器。這樣功能的好處是，如果我后一個請求依賴前一個請求的處理，那么在這一時間段內，這一系列的請求都會被送到同一台機器處理。
AWS ELB實現這個功能，需要依賴Cookie，在配置時，需要你提供一個Cookie的名字。按道理來講，ELB會根據請求中此Cookie的值，將相同值的請求送到同一台機器。
但是我們測試，發現，情況並不是這樣。Sticky Session沒有起作用。
經過排查，最終我們發現，根本原因是：當我們的Http請求送到Module2，得到Response返回時，我們的程序會在Response Header中加入一個cookie，通過SetCookie，這個cookie是我們在ELB配置的用於Sticky Session的Cookie。但是同時ELB還會再我們的Response Header中加入另外一個cookie，名字叫AWSELB，這個cookie我們沒有處理。
但其實在下次請求時，我們的Module 1除了要帶有自己的cookie，還應該帶有AWS ELB的cookie，這樣ELB的stricky session功能才起作用。請求才會被定向到某一台特定的Module 2機器。
為什么我們之前沒有發現呢？
1. 首先我們沒有在Response Header中SetCookie，因此ELB也不會幫我們再Set AWSELB Cookie。
2. ELB更多用於Browser和Server的通信負載均衡。
AWSELB的cookie，path=/，也就是所有后續請求都應該帶這個cookie。Browser自然懂得其中道理，能夠正確處理。但是對於我們的使用場景，兩個Module，用的是網絡庫，進行http通信，不存在browser這樣的client來處理cookie。所以就需要我們自己處理了。
由此也能看出，AWS ELB的使用場景，更多是為瀏覽器和Server間通信准備。
終於找到了這個問題的原因，希望對你有幫助。
還是應該多思考。
參考文檔：
1. http://docs.amazonaws.cn/en_us/ElasticLoadBalancing/latest/DeveloperGuide/US_StickySessions.html
2. http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html#enable-sticky-sessions-application
Kevin Song
2015年6月18日