在Windows Azure網站中設置網站的多個實例

在 Windows HTTP://www.aliyun.com/zixun/aggregation/13357.html">Azure 網站中設置網站的多個實例是橫向擴展網站的絕佳方式，Azure 最大程度地利用應用程式要求路由 IIS 擴展包以在活動實例之間分配連接到您的網站的使用者。 ARR 通過向連接的使用者提供一個特殊的 Cookie（即關聯 Cookie），因此可以在使用者發出後續請求時知曉其在與哪個伺服器實例通信，從而巧妙地對連接使用者進行跟蹤。 這樣我們即可確保用戶端與特定伺服器實例建立會話後，在會話處於活動狀態時，用戶端始終與同一台伺服器進行通信。 這對使用會話的應用程式（也稱為無狀態應用程式）尤為重要，因為特定于會話的資料自身不會從一台伺服器移動到另一台伺服器。 應用程式可以設計用於執行此操作（通常通過將資料存儲在某種共用存儲中，如 SQL），但大多數應用程式並未這樣做，因此通常我們要使每個使用者連接到指定的伺服器。 如果使用者移動到另一台伺服器，將開始新的會話，並且無論應用程式使用何種會話資料，資料都將丟失（例如，購物車內容）。 下面是此過程的簡短描述：

1. 用戶端連接到 Azure 網站

2. ARR 在前端 Azure 伺服器上運行並接收請求

3. ARR 決定應將要求傳送到哪個可用實例

4. ARR 將請求轉發給所選伺服器，創建 ARRAffinity Cookie 並將其附加到請求

5. 包含 ARRAffinity Cookie 的回應返回到用戶端

6. 用戶端接收回應時，將存儲 Cookie 以供稍後使用（瀏覽器將為從伺服器接收的 Cookie 執行此操作）

7. 當用戶端提交後續請求時，將包括此 Cookie

8. 當 ARR 接收請求時，將查找 Cookie 並對其進行解碼

9. 已解碼的 Cookie 保存了之前使用的實例名稱，以便 ARR 將請求轉發到相同的實例，而非從池中進行選擇

10. 在使用者關閉瀏覽器之前（即清除 Cookie 時），將對相同網站的每個後續請求重複相同的步驟（步驟 7 - 9）

但是，也存在無需保留關聯的情況。 例如，某些使用者未關閉其瀏覽器，並長時間地保持連接狀態。 這種情況下，關聯 Cookie 將保留在瀏覽器中，使使用者保持與伺服器的連接，這可能持續幾小時、幾天甚至更長時間（理論上是無期限的！ ）。 將電腦開著，瀏覽器也開著，這早已司空見慣，很多人都是這樣（特別是工作區的電腦）。 實際上，這將導致每個實例的使用者分配失去平衡（這和超市中某些收銀台被一個使用者佔用，而導致其他使用者的等待時間變長的道理是一樣的）。

根據應用程式及其功能，您可以有選擇性地關注將使用者連接到固定的伺服器。 如果這不是很重要或完全不重要，您可以禁用此關聯以選擇更好的負載平衡，我們已引入了此功能，以便您進行控制。

關聯受關聯 Cookie 控制，因此您僅需確保 Azure 未分發 Cookie 即可禁用關聯。 禁用後，使用者發出的後續請求將視為「新請求」，ARR 將使用普通的負載平衡行為將請求路由到最佳伺服器，而非嘗試將其路由到「自己的」伺服器。

關聯 Cookie 如下所示：

可以通過以下兩種方式禁用關聯：

1. 在應用程式中

2. 在網站配置中

要在應用程式中控制此行為，您需要編寫代碼來發出一個特殊的 HTTP 頭以指示應用程式要求路由器刪除關聯 Cookie。 此頭為 Arr-Disable-Session-Affinity，如果您將其設置為 true，ARR 將剔除 Cookie。 例如，您可以將與此頭類似的行添加到您的應用程式代碼中：

headers. Add("Arr-Disable-Session-Affinity", "True");

* 此示例針對 C#，但使用任何其他語言或平臺也可以輕鬆實現。

如果您想在大多數情況下保持關聯並且僅在特定的應用程式頁面重置關聯，則在應用程式的代碼中設置此頭將非常適合。 但是，如果您想要完全禁用關聯，您可以始終通過將 IIS 自身直接插入該頭使 ARR 刪除 Cookie。 這可以通過 web.config 中的 customHeaders 配置部分實現。 只需將以下內容添加到 web.config，並將 web.config 上傳到網站的根目錄即可：

但是請記住，web.config 中的配置非常敏感，如果檔案格式錯誤，可能會導致網站無法正常運行。 如果您之前沒有使用過 web.config 檔，請閱讀此入門指南。

故障排除

如果您打算實施這一方案，您可能想知道如何確認它的運行情況並進行故障排除。 ARR 關聯 Cookie 正常情況下包含在任何 Azure 網站的第 1 個回應中，隨後包含在用戶端發送的任何請求以及從伺服器接收的回應中。 要查看其是否在運行，您可以使用多種 HTTP 故障排除和診斷工具中的任意一種。 下面列出了一些較為常用的選項：

1. Fiddler

2. HTTPWatc

3. Network Monitor

4. WireShark

5. Firebug

您可以在此處查找關於其他一些工具的資訊。 上面列出的第 1 個工具 Fiddler 是最常用的工具之一，因為它可以與任何瀏覽器交互，並且是免費提供的。 安裝 Fiddler 後，它將記錄您流覽到的任何 URL，然後您可以按一下請求或回應的 Inspector 選項卡來查看詳細資訊。 例如，您可以在下面查看 HTTP Headers 選項卡，其中顯示了伺服器使用 Set-Cookie 頭髮送的關聯 Cookie：

如果您添加 Arr-Disable-Session-Affinity 頭來禁用關聯 Cookie，ARR 將不設置 Cookie，但它也會自行刪除 Arr-Disable-Session-Affinity 頭，因此如果您的進程正常運行 ，您將看不到 Cookie 和頭。 如果您看到 Cookie 和頭，則意味著您設置頭的方式有誤。 可能是頭名稱或頭值的文本出錯了。 如果您只看到 Cookie 而並未看到頭，這可能意味著您對 web.config 的更改無效，或您的頭插入代碼沒有運行，您可以嘗試通過添加其他的無關頭來進行確認。 一般來說，使用 web.config 設置頭要比使用代碼進行設置更加容易，因此，如有疑問，應該先簡化設置以縮小要調查的範圍。

最後，應該指出的是，禁用關聯時不應掉以輕心。 靜態內容很少會出現問題，但是如果您正在運行應用程式，並且這些應用程式不是專門用來處理從一台伺服器跳到另一台伺服器的使用者的，程式可能會失敗。 對於關聯導致失衡的情況，這一新功能無疑是個大好消息。