分散負載通過UDP

Question

我嘗試使用下面的場景，以實現一些分散的負載均衡和資源管理的平衡：

• 每個服務器發送一個UDP廣播或多播定期 間隔（例如每分鐘或30秒），讓附近的其他服務器知道它所提供的服務及其健康或負載（例如cpu％，或內存使用情況或網絡流量等） 。

• 具有可用於幫助重載服務器 的資源的服務器可以爲其廣播/多播添加附加服務，因此可以減少過載服務器的負載。

UDP流量的額外開銷會減慢已經繁忙的網絡中的性能嗎？更少的冗餘和更集中的方法會更好嗎？

我打算使用它不僅僅是傳統的負載平衡（例如，在必要時啓動新的雲服務器）。

另一個變化是僅在達到某個負載閾值時進行廣播/多播。

任何意見或其他選項/建議，將不勝感激，特別是關於底層網絡的影響和相關設備等

Answer 1

與服務器的當前使用級別小的UDP數據包是不會打倒一網絡，甚至一個已經很忙的網絡。由於丟包會導致重傳，因此TCP會更好，因此會產生更多的流量，但即使如此，由於幾個原因，這也不會成爲問題。

首先，您的客戶端流量可能通過與您的服務器用於彼此交談的網絡不同的網絡到達。如果願意，您可能會決定創建一個心跳局域網。

即使所有流量都駐留在同一網絡上，客戶端流量也會受到WAN容量的限制，而容量始終低於LAN容量。這意味着你將有局域網容量可用（除非別的東西將流量引入本地網絡）。

我覺得在分散模式具有負載均衡是有趣的，但會帶來一些挑戰，其實無論是可能的，更不用說建議取決於您要負載均衡應用...

我假設你知道正常的負載平衡是如何工作的。試圖在沒有先了解它的替代品的情況下做到這一點意味着你會非常掙扎。

所以作爲第一遍，關鍵在於有一個應用程序可以將它的客戶端發送到另一臺服務器。您所描述的廣播將允許服務器知道是否有其他服務器可以重定向客戶端，如果滿足某些閾值的話。正如你所說，如果一個服務器真的受到攻擊，它可能無法處理它正在接收的數據包。在理想狀態下，服務器會在達到該限制之前將工作交給另一臺服務器，但是您有選擇權，是否希望服務器在100％使用之前開始拒絕連接？不利的一面是，你從來沒有充分利用你的硬件，並且你可以達到所有服務器都拒絕用戶的程度，而你仍然可以使用cpu週期。請記住，即使使用IaaS，如亞馬遜的AWS，也存在一個起飛時間，用戶請求的突然跳躍並不罕見。

您將面臨的另一個重大挑戰是容錯。

首先，如果服務器與實時客戶端一起黑暗，他們聯繫誰，最後一個服務器與他們說話（假設有一個）？如果客戶端離開該服務器的原因是因爲該服務器過載，該怎麼辦？也許他可以用一個非常輕的「給我一個新資源」的要求去他的舊服務器。如果舊服務器的負載已經下降，它可以指定自己，如果沒有，它可以推送給其他人。請記住，雖然所有這些都在發生，但用戶並沒有獲得他們到達的服務。

容錯的第二個方面是保持其他服務器的健康狀態正確。你說你想讓你的服務器進行廣播或組播，他們是健康狀態，有多少錯過的數據包構成了一個停機服務器？網絡一直都在丟包，這就是它們的工作方式，但是如果你將客戶端推送到達夫服務器，只能讓客戶端請求超時，並且它又回到你身上，這對客戶端來說是一種糟糕的服務。如果客戶端和服務器位於同一局域網上，則不會受到太大的影響，但是您將互聯網上的延遲添加到客戶端/服務器通信中，並且用戶可能會很快感到厭倦。

接下來需要克服的問題是，僅僅因爲服務器發出的狀態並不意味着應用程序運行正常。通過集中式SLB，每個服務器都會運行一個測試請求，它會檢查所有應用程序是否正常運行，如果服務器沒有運行，則會將服務器帶出池。我不認爲你會想要每個服務器都在測試其他服務器的健康狀況。這會吸收你的大量資源。我一般不相信服務器能夠提供自己的健康狀態，但是我認爲如果你想做到這一點，你必須在某種程度上做到這一點。儘管如此，你是在燃燒資源來運行查詢，回答它們然後檢查結果。這些都是可以滿足用戶請求的週期。

我能想到的最後一個問題是初始接觸。如果您使用DNS循環，您必須確保這些地址上的服務器健康。您不希望用戶在開始之前不得不等待超時。我不確定寫一個地址列表或DNS主機名到你的客戶端也會有很大的幫助。客戶仍然會按照清單的方式工作，而不是按照他們的要求進行。

這一切都很有意思，我希望它有一些幫助。然而，我要問的是，你想通過分散負載平衡來實現什麼？對於我所提出的所有問題，可能都有解決方案，但如果不知道自己的目標，很難說是否沒有更簡單的解決方案。

不過，希望這有幫助， 亞歷克斯