當我們的程式只部署一套，不再能滿足訪問量（呼叫量）的時候，最簡單的橫向擴容的方法就是部署多套應用環境，負載均衡將使用者（客戶端）的訪問平均地分配到每臺伺服器上，這樣就可以利用多臺機器的資源，增加系統的負載能力。

那麼要做負載均衡，對我們的系統有什麼要求麼？或者說我們的程式碼需要做什麼改造麼？

大部分時候我們的程式碼是不需要改造的，但是也要注意這麼幾點。

我們的服務最好是無狀態的，也就是每一次的呼叫，不依賴於前一次的呼叫結果，如果前後有依賴，則需要後面的請求攜帶著前一次請求的結果，作為引數進行訪問。

除非負載均衡開啟了會話保持，或者透過一些負載均衡路由策略，讓同一個 IP 的請求始終路由到同一臺伺服器上，但是這並不是一個好的解決方案。

通常我們需要保持服務的無狀態性，如果需要做許可權認證的話，建議採用 Token 或使用 Redis 做 Session 共享（推薦使用 Token）。

還有一點，可能不一定必須的，不過我覺得也是個不錯的方案，供大家參考。

假如我們有兩臺應用伺服器 A 和 B，前面掛一臺負載均衡，當我們需要做應用升級的話，通常可以怎麼做？

通常的辦法是停掉伺服器 A，這時候負載均衡會監控到這臺伺服器 A 已經無法使用了（比如監控到埠消失），再來的請求會發送給伺服器 B；

對伺服器 A 升級並啟動，負載均衡監控到 A 恢復了，會將請求傳送給 A 和 B；

對伺服器 B 做相同的操作。

這樣看似沒有問題，因為在伺服器升級的時候，負載均衡不在傳送請求到這臺伺服器上；但是大家仔細想一想這個過程，如果在停伺服器的那一刻，已經有請求進來了並進行處理，但是還沒有返回，這時候停掉伺服器，會導致這部分請求發生異常，那麼這個問題如何解決呢？這就需要對程式進行一定的改造了。

應用提供一個介面，返回一個靜態變數的值，只要 true 或 false 兩個狀態；

負載均衡不再監控埠是否消失，而是監控剪口返回的狀態，返回 true 表示應用正常，false 或沒有返回表示不正常；

每次停服務之前，透過介面修改當前應用靜態變數的值為 false；

負載均衡認為該伺服器狀態不正常，將不再發送請求到這臺伺服器上；

等待幾十秒，這段時間相當於等待當前請求都處理並返回，再停止服務。

“停止服務時，不再接受新的請求，等現有請求都處理完成後再真正停止服務”，這只是一個笨辦法，想要避免以上問題還有更好的辦法，並且對程式碼沒有侵入性；有些中介軟體本身提供了類似的功能，我們只需執行對應的停止服務的命令即可；或者需要在程式碼中新增監聽類，當收到 kill 訊號的時候，拒絕新的請求，等待一段時間，再結束程式等等。

1.確保你的介面無狀態，鑑權可以使用token，redis集中化session

2.確保你的介面冪等性，可以為介面生成請求id，過濾請求id，防重，或者可以使用一次性token。

3.確保你的介面叢集對等，程式碼，資料，都需要對等，通常每臺機器資料來源都是一樣的，程式碼是相同的。同時機器的配置也是相同的。

什麼是負載均衡

負載均衡主要透過專門的硬體裝置或者透過軟體演算法實現。透過硬體裝置實現的負載均衡效果好、效率高、 效能穩定，但是成本比較高。透過軟體實現的負載均衡主要依賴於均衡演算法的選擇和程式的健壯性。均衡 演算法也是多種多樣的，常見的有兩大類：即靜態負載均衡演算法和動態負載均衡演算法。靜態演算法實現比較簡 單，在一般網路環境下也能達到比較好的效果，主要有一般輪詢演算法、基於比率的加權輪詢演算法以及基於 優先順序的加權輪詢演算法等。動態負載均衡演算法在較為複雜的網路環境中適應性更強，效果更好，主要有基 於任務量的最少連線優先演算法、基於效能的最快響應優先演算法、預測演算法及動態效能分配演算法等。

網路負載均衡技術的大致原理是利用一定的分配策略將網路負載平衡地分攤到網路叢集的各個操作單元 上，使得單個重負載任務能夠分擔到多個單元上並行處理，或者使得大量併發訪問或資料 流量分擔到多個 單元上分別處理，從而減少使用者的等待響應時間。

Nginx 伺服器負載均衡配置

Nginx 伺服器實現了靜態的基於優先順序的加權輪詢演算法，主要使用的配置是 proxy_pass 指令和 upstream 指令，這些內容實際上很容易理解，關鍵點在於 Nginx 伺服器的配置靈活多樣，如何在配置負載均衡的同 時合理地整合其他功能，形成一套可以滿足實際需求的配置方案。

配置例項：

在以下例項片段中，backend 伺服器組中所有伺服器的優先順序全部配置為預設的 weight=1，這樣它 們會按照一般輪詢策略依次接收請求任務。該配置是一個最簡單的實現 Nginx 伺服器負載均衡的配置。所 有訪問 www.myweb.name 的請求都會在 backend 伺服器組中實現負載均衡。例項程式碼如下：

...

upstream backend #配置後端伺服器組

{

server 192.168.1.2:80;

server 192.168.1.3:80;

server 192.168.1.4:80; #預設 weight=1

}

server

{

listen 80;

server_name www.myweb.name;

index index.html index.htm;

location / {

proxy_pass http://backend;

prox_set_header Host $host;

}

...

}

由於 Nginx 伺服器的 功能在結構上是增量式的，因此 ，我們可以在這些配置的基礎上繼續新增更多功能，比如 Web 快取等功 能，以及 Gzip 壓縮技術、身份認證、許可權管理等。同時在使用 upstream 指令配置伺服器組時，可以充 分發揮各個指令的功能，配置出滿足需求、高效穩定、功能豐富的 Nginx 伺服器。

程式碼中不能把資料、上傳檔案、日誌等儲存到本地。

建議使用者授權不要用session。可以採用token方式。將使用者資訊加密到token中，每次請求將token透過header post給伺服器，然後再去解密。這樣負載均衡就沒任何問題了。

一般涉及到負載均衡，以下幾種情況必須要注意：

這裡所說的檔案管理是指透過上傳至伺服器的檔案，這就不能再單純地儲存至程式碼所在伺服器上了，必須有專門的檔案伺服器。

單一伺服器一般都是WEB伺服器與資料庫在一起。在負載均衡中，資料庫最好做成讀寫分離。

程式碼需要對SESSION以及快取做處理，保證能夠正常訪問這些共享的資料，建議引入R edis。

日誌也應與檔案管理一樣，有專門的伺服器進行管理。