公司最近要將架構遷到雲上，存儲用S3，服務器用EC2。為了將我們的架構變的具有橫向的伸縮性，我們使用AWS的Load balancing來做負載均衡。簡單來說負載均衡就是講大量的客戶端訪問分發到不同的后端amazon ec2 instances中。
Amazon的Load balancing配置起來也非常簡單，就是將已存在的ec2 instance添加到load balancing中。之后你可以配置端口轉發，即將客戶訪問的端口轉發到合適的后台服務。當然也有些需要注意的地方：
1，從哪里找到Load Balancing的配置頁面
就在你的EC2的Dashboard中就可以找到Load Balancing配置頁面。
2，Port轉發的配置
在使用Load Balancing之前要設置端口的轉發，就在Listeners那個tab中。如果你使用HTTP協議，你就可以選擇HTTP協議。如果你是TCP應用請選擇TCP，看論壇上說可以使用的TCP端口在是從1024起步的。如果你是選了HTTP，有個可能對應用來說比較有用的選項Stickiness，其實就是Load Balancer在HTTP協議上加了一個Cookie，借此來實現Session的功能。
3，Health Check
Load Balancing的另一個功能，或者說Feature就是Load Balancer維護一個ec2 instances pool。通過Health Check的instance會被添加到instances pool中等待load balancer分發過來的connections。如果某個instance通不過health check，那么他會從instances pool刪除，load balancer不會再分發connections到這個instance。但是刪除的instance會繼續做health check當他的再次通過health check的時候會被再次添加到instances pool中。
Health Check分為兩種類型：
1，HTTP應用，那么Health Check就是訪問一個固定位置的URL，如果返回HTTP Status Code為200。那么load balancer就認為通過health check。可以根據你的業務在URL的服務端代碼中做一些服務器的狀態檢查，但是不要太耗時。
2，TCP應用，那么Health Check就是發起一個TCP connections，如果連接成功，那么就認為通過了health check。
這里的Timeout就是訪問URL或TCP連接的最大超時時間，如果在這個時間內(上圖是10s)還是沒有返回，那么就就認為unhealthy。
Interval是多久訪問一次這個URL或發起一個TCP連接。上圖是300s(5min)，這也是容許的最大值。
Unhealthy Threshold是指連續(consecutive)多少次訪問失敗，才把這個instance從instances pool中移除。
Healthy Threshold是指連續多少次成功訪問，才再次把這個instance添加到instances pool中。
4，其他的問題
目前對我們的應用來說比較大的問題是，如何將每個instance生成的文件，正確的上傳到S3的特定位置。這就引申到一個load balancing的本質：在后端是由多台服務器來提供服務。對於某些應用來說這沒有問題，只要后端數據有個統一的訪問接口，這都不是問題。但是對於一些應用還是需要在架構上做些調整來實現load balancing的透明化。切記，透明化才能讓橫向擴展變得容易，這也是用load balancing的初衷。