（十七）—— 基于隊(duì)列的負(fù)載均衡模式

云計(jì)算設(shè)計(jì)模式（十七）——基于隊(duì)列的負(fù)載均衡模式

使用隊(duì)列，作為一項(xiàng)任務(wù)，它調(diào)用才能順利間歇重物，可能會以其他方式導(dǎo)致失敗的服務(wù)或任務(wù)超時(shí)服務(wù)之間的緩沖區(qū)。這個(gè)模式可以幫助最小化峰中的可用性和響應(yīng)需求為任務(wù)和服務(wù)的影響。

背景和問題

許多解決方案在云中涉及運(yùn)行調(diào)用服務(wù)的任務(wù)。在這種環(huán)境下，如果一個(gè)服務(wù)進(jìn)行間歇重物，它可能會導(dǎo)致性能或可靠性問題

一個(gè)服務(wù)可以是一個(gè)組件，它是相同的溶液作為利用它的任務(wù)的一部分，或者它可以是第三方服務(wù)提供訪問經(jīng)常使用的資源，如高速緩存或存儲服務(wù)。如果相同的服務(wù)是由多個(gè)同時(shí)運(yùn)行的任務(wù)的使用，它可以是難以預(yù)料到的服務(wù)可能在任何給定時(shí)間點(diǎn)來進(jìn)行請求的數(shù)量。

它可能是一個(gè)服務(wù)可能會遇到在需求高峰，導(dǎo)致它變得過載和不能對及時(shí)響應(yīng)請求。有大量的并發(fā)請求驅(qū)服務(wù)也可能會導(dǎo)致服務(wù)失敗，如果它不能處理的論點(diǎn)，即這些請求可能導(dǎo)致。

解決方案

重構(gòu)的解決方案和介紹的任務(wù)和服務(wù)之間的隊(duì)列。任務(wù)和服務(wù)異步運(yùn)行。任務(wù)帖含有由服務(wù)于一個(gè)隊(duì)列所需要的數(shù)據(jù)的消息。隊(duì)列作為緩沖，存儲該消息，直到它被檢索到的服務(wù)。該服務(wù)從隊(duì)列中檢索消息并進(jìn)行處理。從多個(gè)任務(wù)，它可以在一個(gè)高度可變的速率產(chǎn)生的請求，可以通過同一個(gè)消息隊(duì)列被傳遞給服務(wù)。圖1示出了這種結(jié)構(gòu)。

圖1 - 使用隊(duì)列水平上的服務(wù)的負(fù)載

隊(duì)列有效地從服務(wù)解耦的任務(wù)，并且該服務(wù)可以按自己的速度處理從并行任務(wù)的請求量的信息無關(guān)。此外，不存在延遲到一個(gè)任務(wù)，如果該服務(wù)是不可用的時(shí)候它投遞一個(gè)消息到隊(duì)列中。

這種模式提供了以下好處：

• 它可以幫助最大限度地提高可用性，因?yàn)榉?wù)而產(chǎn)生的延遲將不會對應(yīng)用程序，它可以繼續(xù)發(fā)布消息隊(duì)列，即使該服務(wù)不可用或不正在處理消息的即時(shí)和直接的影響。
• 它可以有助于最大化可擴(kuò)展性，因?yàn)殛?duì)列的數(shù)目和服務(wù)的數(shù)量可以變化，以滿足需求。
• 它可以有助于控制成本，因?yàn)榉?wù)實(shí)例的數(shù)量部署僅需要足以滿足平均負(fù)荷，而不是峰值負(fù)荷。

注意：有些服務(wù)可以實(shí)現(xiàn)節(jié)流，如果需求達(dá)到閾值，超過該系統(tǒng)可能會失敗。節(jié)流可能會降低功能可用。你也許可以實(shí)現(xiàn)與這些服務(wù)負(fù)載均衡，以確保這一閾值沒有達(dá)到。

問題和注意事項(xiàng)

在決定如何實(shí)現(xiàn)這個(gè)模式時(shí)，請考慮以下幾點(diǎn)：

• 來實(shí)現(xiàn)控制的速率服務(wù)處理消息，以避免急劇的目標(biāo)資源的應(yīng)用程序邏輯是必要的。避免將尖峰需求到該系統(tǒng)的下一個(gè)階段。測試系統(tǒng)在負(fù)載下，以確保它提供所需的流平，并調(diào)整隊(duì)列的數(shù)目和處理消息來實(shí)現(xiàn)該服務(wù)實(shí)例的數(shù)量。
• 消息隊(duì)列是一個(gè)單向的溝通機(jī)制。如果一個(gè)任務(wù)期望的服務(wù)的答復(fù)，可能有必要執(zhí)行該服務(wù)可用于發(fā)送的響應(yīng)的機(jī)制。欲了解更多信息，請參閱異步消息底漆。
• 您一定要小心，如果你申請自動縮放到被監(jiān)聽的隊(duì)列中的請求服務(wù)，因?yàn)檫@可能會導(dǎo)致更多的爭奪任何資源，這些服務(wù)的份額，并減少使用隊(duì)列級負(fù)載的有效性。

何時(shí)使用這個(gè)模式

此圖案是非常適合于使用可能會受到重載服務(wù)的任何類型的應(yīng)用程序。

這種模式可能不是合適的，如果該應(yīng)用程序期望以最小延遲的服務(wù)的響應(yīng)。

例子

微軟的 Azure Web 角色存儲數(shù)據(jù)使用單獨(dú)的存儲服務(wù)。如果大量的 Web 角色實(shí)例同時(shí)運(yùn)行，則可能是存儲服務(wù)可以是不堪重負(fù)，無法向請求的速度不夠快，以防止超時(shí)或沒有響應(yīng)這些請求。圖 2 列出了這個(gè)問題。

圖2 - 服務(wù)從一個(gè) Web 角色實(shí)例大量并發(fā)請求正在被壓垮

要解決此問題，可以使用一個(gè)隊(duì)列地級Web角色實(shí)例和存儲服務(wù)之間的負(fù)載。但是，存儲服務(wù)被設(shè)計(jì)為接受同步請求，并且不能很容易地修改，以讀取信息以及管理的吞吐量。因此，可以引入一個(gè)輔助角色作為接收從該隊(duì)列中的請求，并將其轉(zhuǎn)發(fā)到所述存儲服務(wù)的代理服務(wù)。在輔助角色的應(yīng)用程序邏輯可以控制在它傳遞請求到存儲服務(wù)，以防止存儲服務(wù)從被壓垮的速率。圖3示出了這種解決方案。

圖3 - 使用隊(duì)列和輔助角色成水平的幅作用和服務(wù)實(shí)例之間的負(fù)載