【摘抄】

負(fù)載平衡器基礎(chǔ)

AWS有3個(gè)負(fù)載均衡產(chǎn)品 - “經(jīng)典負(fù)載均衡器”（CLB），“應(yīng)用負(fù)載均衡器”（ALB）和“網(wǎng)絡(luò)負(fù)載均衡器”（NLB）。

在引入ALB之前，“經(jīng)典負(fù)載平衡器”被稱為“彈性負(fù)載平衡器”（ELB），所以較舊的文檔，工具和博客帖子可能仍然引用“ELB”。

自2009年以來(lái)，CLB一直存在，2016年有ALB，2017年NLB被添加到AWS。

CLB支持TCP和HTTP負(fù)載平衡。ALB只支持HTTP負(fù)載均衡。NLB支持TCP第4層負(fù)載平衡。

CLB和ALB可以選擇處理單個(gè)SSL證書的終止。

所有人都可以選擇執(zhí)行活動(dòng)的實(shí)例運(yùn)行狀況檢查，如果它們變得不健康，可以將它們從目標(biāo)池中移除。

CLB不支持復(fù)雜/基于規(guī)則的路由。ALB支持（當(dāng)前很小的）一組基于規(guī)則的路由功能。NLB具有最廣泛的路由選擇。

CLB只能將流量轉(zhuǎn)發(fā)到目標(biāo)實(shí)例上的單個(gè)全局配置端口，而ALB則可以轉(zhuǎn)發(fā)到每個(gè)實(shí)例配置的端口，從而更好地支持在具有動(dòng)態(tài)端口分配（如ECS或Mesos）的共享集群上路由到服務(wù)。NLB支持同一IP上的多個(gè)端口; 通過(guò)IP地址注冊(cè)目標(biāo)，包括負(fù)載均衡器的VPC外的目標(biāo); ECS可以選擇未使用的端口來(lái)安排任務(wù)，然后使用此端口注冊(cè)目標(biāo)組。

在EC2 Classic和VPC中支持CLB，而在VPC中僅支持ALB。

ALB可以定位RFC1918范圍內(nèi)的實(shí)例組和基于IP的目標(biāo)組，允許您通過(guò)VPN或Direct Connect在本地目標(biāo)上使用。

負(fù)載平衡器技巧

如果您對(duì)負(fù)載均衡沒(méi)有意見(jiàn)，并且沒(méi)有像請(qǐng)求的特定于應(yīng)用程序的路由那樣的復(fù)雜負(fù)載平衡需求，那么使用CLB或ALB進(jìn)行負(fù)載平衡是合理的。

即使你根本不想考慮負(fù)載均衡，因?yàn)槟愕募軜?gòu)非常簡(jiǎn)單（比如只有一臺(tái)服務(wù)器），無(wú)論如何都要在它前面加一個(gè)負(fù)載平衡器。這樣可以讓您在升級(jí)時(shí)更具靈活性，因?yàn)槟槐馗娜魏蝹鞑ゾ徛腄NS設(shè)置，而且還可以讓您更輕松地完成一些SSL終止操作。

CLB和ALB具有許多IP：在內(nèi)部，AWS負(fù)載均衡器只是EC2內(nèi)部托管的各個(gè)軟件負(fù)載均衡器的集合，其中DNS負(fù)載平衡流量。該池可以包含多個(gè)IP，每個(gè)可用區(qū)至少一個(gè)，并且取決于流量級(jí)別。他們也支持SSL終止，非常方便。

擴(kuò)展：?CLB和ALB可以擴(kuò)展到非常高的吞吐量，但擴(kuò)展并不是即時(shí)的。如果您預(yù)計(jì)會(huì)突然遇到大量流量，那么加載測(cè)試可以提前進(jìn)行擴(kuò)展。您也可以聯(lián)系亞馬遜，讓他們“預(yù)熱”負(fù)載平衡器。

客戶端IP：通常，如果服務(wù)器想要知道真正的客戶端IP地址，負(fù)載平衡器必須以某種方式轉(zhuǎn)發(fā)這些信息。CLB添加標(biāo)準(zhǔn)的X-Forwarded-For標(biāo)題。當(dāng)使用CLB作為HTTP負(fù)載均衡器時(shí)，可以從中獲取客戶端的IP地址。

部署時(shí)使用負(fù)載平衡器：一種常見(jiàn)的模式是在用最新版本轉(zhuǎn)動(dòng)一個(gè)新堆棧之后交換負(fù)載平衡器中的實(shí)例，使舊堆棧保持運(yùn)行一兩個(gè)小時(shí)，并且在出現(xiàn)問(wèn)題時(shí)或者返回到舊堆棧撕下來(lái)。

負(fù)載平衡器陷阱和局限性

?CLB和ALB?沒(méi)有固定的外部IP，所有客戶都能看到。對(duì)于大多數(shù)消費(fèi)者應(yīng)用程序來(lái)說(shuō)，這并不重要，但是您的企業(yè)客戶可能會(huì)想要這樣做。每個(gè)用戶的IP將會(huì)不同，并且隨著時(shí)間的推移（在標(biāo)準(zhǔn)的EC2 IP范圍內(nèi)），單個(gè)客戶端的變化將不可預(yù)測(cè)。同樣，永遠(yuǎn)不要將CLB名稱解析為IP，并將其作為A記錄的值 - 它將工作一段時(shí)間，然后中斷！

?某些Web客戶端或反向代理長(zhǎng)時(shí)間緩存DNS查找，這對(duì)于CLB和ALB是有問(wèn)題的，因?yàn)樗鼈儠?huì)更改IP。這意味著幾分鐘，幾小時(shí)或幾天后，客戶端將停止工作，除非您禁用DNS緩存。注意Java的設(shè)置，并確保正確調(diào)整它們。另一個(gè)例子是nginx作為反向代理，通常只在啟動(dòng)時(shí)解析后端（盡管有辦法解決這個(gè)問(wèn)題）。

without在沒(méi)有漫長(zhǎng)的冷靜期的情況下，客戶之間的知識(shí)產(chǎn)權(quán)回收并不是聞所未聞的。所以作為一個(gè)客戶端，如果你緩存一個(gè)IP而不使用SSL（來(lái)驗(yàn)證服務(wù)器），那么你可能會(huì)得到不僅僅是錯(cuò)誤，而是來(lái)自完全不同的服務(wù)或公司的響應(yīng)！

??作為CLB或ALB背后的服務(wù)運(yùn)營(yíng)商，后一種現(xiàn)象意味著您也可以看到其他公司客戶的疑惑或錯(cuò)誤請(qǐng)求。這對(duì)于使用后端API的客戶端來(lái)說(shuō)是最常見(jiàn)的（因?yàn)榫W(wǎng)頁(yè)瀏覽器通常會(huì)在有限的時(shí)間內(nèi)緩存）。

?CLB和ALB需要一定的時(shí)間來(lái)擴(kuò)大規(guī)模，并不能很好地處理突發(fā)性的交通高峰。因此，如果您預(yù)計(jì)會(huì)出現(xiàn)高峰，則需要通過(guò)逐漸增加流量來(lái)“預(yù)熱”負(fù)載平衡器。

carefully仔細(xì)調(diào)整您的健康檢查 - 如果您在決定何時(shí)刪除某個(gè)實(shí)例以及保守地將其添加回池中時(shí)太積極，則您的負(fù)載平衡器所面臨的服務(wù)可能無(wú)法在幾秒鐘或幾分鐘內(nèi)無(wú)法訪問(wèn)。當(dāng)自動(dòng)調(diào)整程序配置為終止受管理負(fù)載平衡器標(biāo)記為不健康的實(shí)例時(shí)，請(qǐng)?zhí)貏e小心。

?CLBHTTPS偵聽(tīng)器不支持服務(wù)器名稱指示（SNI）。如果您需要SNI，您可以通過(guò)提供具有主題備用名稱（SAN）的證書或通過(guò)使用TCP偵聽(tīng)器并在您的后端終止SSL來(lái)解決此限制。

CLB

CLB基礎(chǔ)知識(shí)

傳統(tǒng)負(fù)載均衡器（以前稱為彈性負(fù)載均衡器）是由Amazon管理和擴(kuò)展的HTTP和TCP負(fù)載均衡器。

CLB提示

最佳實(shí)踐：?如果大量使用CLB，并且具有更多詳細(xì)信息，則必須閱讀本文。

CLB問(wèn)題和局限性

一般來(lái)說(shuō)，CLB并不像一些負(fù)載平衡器那樣“聰明”，并且沒(méi)有傳統(tǒng)的硬件負(fù)載平衡器所提供的奇特功能或精細(xì)控制。對(duì)于大多數(shù)涉及通過(guò)HTTP的會(huì)話應(yīng)用程序或基于cookie的會(huì)話，或者SSL終止的常見(jiàn)情況，它們運(yùn)行良好。

??默認(rèn)情況下，CLB將拒絕將流量從一個(gè)可用區(qū)域（AZ）的負(fù)載均衡器路由到另一個(gè)可用區(qū)域的后端實(shí)例。這將導(dǎo)致503S如果在AZ的最后一個(gè)實(shí)例變得不可用，即使有在其他區(qū)域的健康情況。如果每個(gè)AZ運(yùn)行少于兩個(gè)后端實(shí)例，則幾乎肯定要啟用跨區(qū)域負(fù)載平衡。

??指導(dǎo)流量的復(fù)雜規(guī)則不受支持。例如，您不能根據(jù)URL中的正則表達(dá)式指定流量，如HAProxy提供。

Apex DNS名稱：曾幾何時(shí)，您無(wú)法將CLB分配給apex DNS記錄（即http://example.com而不是http://foo.example.com），因?yàn)樗枰蔀锳記錄而不是CNAME?，F(xiàn)在可以使用直接指向負(fù)載平衡器的Route 53別名記錄。

??CLB 在內(nèi)部使用HTTP保留。這可能會(huì)導(dǎo)致意想不到的副作用：來(lái)自不同客戶端的請(qǐng)求（每個(gè)客戶端都在它們自己的外部TCP連接中）可能會(huì)在內(nèi)部端的相同TCP連接上結(jié)束。切勿假設(shè)同一個(gè)TCP連接上的多個(gè)請(qǐng)求來(lái)自同一個(gè)客戶端！

??在同一子網(wǎng)內(nèi)的CLB和后端實(shí)例之間的交通將有網(wǎng)絡(luò)ACL計(jì)算（EC2 EC2的交通在同一個(gè)子網(wǎng)不會(huì)有網(wǎng)絡(luò)ACL規(guī)則來(lái)評(píng)估）的規(guī)則。如果從應(yīng)用于子網(wǎng)的網(wǎng)絡(luò)ACL中刪除默認(rèn)的“0.0.0.0/0 ALLOW”規(guī)則，則必須添加允許在運(yùn)行狀況檢查端口和任何偵聽(tīng)器端口上進(jìn)行通信的規(guī)則。

截至2016年12月，VPC推出的CLB不支持IPv6尋址。在EC2-Classic中啟動(dòng)的CLB?通過(guò)“雙?！盌NS名稱支持IPv4和IPv6 。

ALB

ALB基礎(chǔ)

WebSockets和HTTP / 2是現(xiàn)在支持。

??Internet協(xié)議版本6（IPv6）是現(xiàn)在支持。

??通過(guò)IP負(fù)載均衡是現(xiàn)在支持。

對(duì)應(yīng)用負(fù)載平衡器在此之前，你被告知要使用TCP而不是HTTP作為協(xié)議，使其工作（如描述在這里），并用隱晦但有用的代理協(xié)議（更多關(guān)于這個(gè)），以通過(guò)TCP負(fù)載平衡器傳遞客戶端的IP 。

ALB技巧

使用ALB通過(guò)動(dòng)態(tài)端口分配（如ECS或Mesos）路由到托管在共享集群上的服務(wù)。

ALB支持基于HTTP主機(jī)的路由（發(fā)送“api.mydomain.com” - > {target-group-1}，“blog.mydomain.com” - > {target group 2}）的HTTP請(qǐng)求以及HTTP路徑 -基于路由（發(fā)送HTTP請(qǐng)求為“/ API / *” - > {目標(biāo)群-1}，“/博客/ *” - > {目標(biāo)組2}）。

ALB問(wèn)題和局限性

??ALB僅通過(guò)HTTPS支持HTTP / 2（不支持純文本HTTP / 2）。

??ALB只支持外部客戶端的HTTP / 2，而不支持內(nèi)部資源（實(shí)例/容器）。

ALB支持HTTP路由，但不支持基于端口的TCP路由。

ALB目標(biāo)組中的實(shí)例必須具有單個(gè)固定的健康檢查端口（“EC2實(shí)例” - 級(jí)別健康檢查），或者目標(biāo)的健康檢查端口必須與其應(yīng)用程序端口（“應(yīng)用程序?qū)嵗?- 級(jí)別健康檢查）相同， - 您無(wú)法配置與應(yīng)用程序端口不同的每個(gè)目標(biāo)健康檢查端口。

ALB僅限VPC（它們不適用于EC2 Classic）

在目標(biāo)群體中，如果沒(méi)有健康的目標(biāo)，所有的請(qǐng)求都會(huì)被路由到所有目標(biāo)。例如，如果您將偵聽(tīng)程序指向包含具有較長(zhǎng)初始化階段（在此期間運(yùn)行狀況檢查將失?。┑膯蝹€(gè)服務(wù)的目標(biāo)組，則請(qǐng)求將在啟動(dòng)時(shí)到達(dá)該服務(wù)。

??盡管ALB?現(xiàn)在支持SNI，但它們僅支持每個(gè)Load Balancer 25個(gè)HTTPS證書。這個(gè)限制在這里沒(méi)有描述，所以可能會(huì)有所變化。

摘自：https://zhuanlan.zhihu.com/p/31772948