Nginx使用最廣泛的是的負載均衡服務。在實際使用負載均衡服務時需要考慮兩個問題：一、根據負載均衡策略選擇合適的上游服務器。二、檢查上游服務器的健康狀態並將異常的服務器標記爲不可用。
爲了滿足多種場景，Nginx開源版本提供了輪詢、IP哈希和最少連接數等三種負載均衡策略。
輪詢負載均衡策略會將用戶的請求平均的分配給上游服務器的同時考慮權重值，權重值得越高分配的任務越多。
最少連接負載均衡策略會將用戶的請求發送到連接最少的服務器的同時考慮權重值，權重值得越高分配的任務越多。
這兩種方式主要通過上游服務器的負載和權重爲用戶選擇的上游服務器，其結果較爲隨機，需要我們業務支持上游服務器節點間數據同步。
IP哈希負載均衡策略是通過用戶的IP地址計算HASH值來保證用戶同一個地址的請求發送給同一個上游服務器處理。這種負載均衡策略保證了用戶的每次請求都發送給同一個服務器，無需上游服務器之間數據同步，但大量使用NAT上網（同一個來源地址）的場景容易導致上游服務器負載不均衡。
我們可以根據業務場景選擇合適的負載均衡策略。
我就職的公司業務分爲前端和後端。
其中後端業務主要提供無狀態的REST API服務，無需同步上游服務器節點間數據，所以，Nginx提供的三種負載均衡策略均可以使用。爲了減少選擇上游服務器的時間，我們使用最簡單的輪詢策略。
其中前端業務提供有狀態的Web服務，且未對上游服務器節點間數據同步，不能使用輪詢和最少連接的負載均衡策略，且因業務場景中較多用戶使用NAT上網而不能使用IP哈希負載均衡策略。因此，如上三種負載均衡策略不滿足我們的前端的業務場景。Nginx的生態圈提供了第三方模塊Sticky Upstream可以滿足我們前端業務場景。Sticky Upstream模塊通過Cookie信息識別用戶會話並將該會話中的所有請求交給同一個上游服務器處理。
這種方式既保證了用戶每次訪問同一個上游服務器，又解決了IP哈希策略負載不均衡的問題，可以快速的實現橫向擴展上游服務器節點。
爲了避免將用戶的請求發送給故障的上游服務器，Nginx提供了被動健康檢查。Nginx會監視與上游服務器之間的事務發生，並嘗試恢復失敗的連接。如果仍然無法恢復，則Nginx將其標記爲不可用，並暫停向該上游服務器發送請求，直到其標記爲正常。Nginx對上游服務器的健康檢查有效的提高了平臺的可用性。
Nginx提供了高可靠、高性能的反向代理和負載均衡服務，爲了保證業務的穩定性我們需要持續的對其監控與優化。這些內容我們將在後續的博文中更新，歡迎關注。