在去年9月份，AWS釋出了託管的網路負載均衡器服務Network Load Balancer，NLB是繼Classic Load Balancer，Application Load Balancer之後，AWS釋出的第三款負載均衡器服務，本文將著重介紹NLB的工作原理，特點以及在使用配置上的注意事項，幫助讀者更好地在自己的業務場景中運用NLB服務。

NLB能夠在極低的延遲下，支援每秒數千萬的請求，在API上相容現有的ALB應用負載均衡器，下面是NLB的一些主要功能和特點：

• 靜態IP地址

每個NLB在每個可用區中提供單個靜態IP地址，使用者端發往該IP地址的流量會被負載分發到同可用區內的多個後端例項上，使用者可以為NLB在每個可用區中分配固定的彈性IP，如此設計使得NLB能夠被納入企業現有的防火牆安全策略中，並且能夠避免DNS快取帶來的問題。

• 同可用區內分發流量

客戶端的流量到達NLB在某個可用區提供的IP後，NLB會向相同可用區內的後端例項分發流量，通過避免跨可用區的流量分發能夠獲得更好的延遲效能。

• 源地址保留

NLB在轉發流量的同時，並不會修改資料包的源IP地址，後端例項無需支援諸如X-Forward-For，proxy協議，就能夠直接從資料包的包頭獲取客戶端的IP，從而很方便地分析客戶端的地理位置等資訊。

• 長連線支援

NLB內建的容錯機制能夠保證長連線應用的穩定執行，從而更好的貼合諸如IoT，遊戲，訊息應用等業務場景。

• 故障切換

利用Route 53的健康檢查，NLB支援在一個區域內及跨區域和本地站點實現故障切換。

下面我們來看一下如何在AWS控制檯建立NLB，可以看到，客戶在建立負載均衡器頁面中，目前可以有三種負載均衡器可選，我們選擇NLB。

NLB和其他AWS提供的負載均衡器一樣，支援建立面向internet及internal兩種場景，除此之外，使用者需要配置NLB監聽的埠及所處的子網，如果建立面向internet的NLB，需要注意將NLB放到公有子網中。

考慮NLB本身的冗餘，建議至少選擇2個可用區，同時使用者可以根據需要為NLB在每個可用區繫結彈性IP。

後續的配置與ALB的配置十分類似，使用者需要配置目標組，目標組監聽的協議、埠以及健康檢查等相關配置，目前無論ALB還是NLB都支援將EC2例項及某個IP作為目標，前者實現VPC內部的負載均衡，後者通過IP可以為本地站點的例項提供負載均衡。

這裡選擇例項型別的目標型別，之後需要選擇註冊的例項。

需要注意的是，為了能夠接受外部客戶端的訪問以及健康檢查流量，建議後端例項的安全組做如下設定，如果使用者覺得健康檢查源地址設定VPC CIDR過於寬泛的話，建議可以設定為NLB的私有IP，NLB的私有IP可以在ENI介面通過NLB名字搜尋到相關NLB的ENI來獲取。

除了安全組設定上的考慮，對於面向internet的NLB來說，後端例項收到的流量的源IP地址是處於公網的客戶端IP，對於接收internet流量的這部分後端例項，建議放到公有子網中，即預設路由指向IGW，如果使用者不希望後端例項能夠被外界直接訪問，可以在將後端例項放入公有子網的同時，選擇不分配公網IP，從而保證外界只能通過NLB來訪問到後端例項。

選擇完後端例項後，就可以完成NLB的建立。

NLB對外提供的是一個域名，客戶端通過訪問該域名將流量發給NLB，使用者可以通過設定DNS CNAME記錄來方便客戶端通過自定義的域名來訪問使用者的後端系統。

以上介紹了面向internet的NLB的配置方法，對於面向internal的NLB，使用者可以做類似的配置，這裡不做過多的介紹，只是如果NLB後端對接的是容器業務，並且網路模式是bridge模式，需要做額外的考慮。

這裡先給出結論再解釋相關的原理，對於兩個需要通過NLB互訪的內部容器應用，建議將這兩個應用的容器排程到不同的EC2節點上，對於AWS ECS，使用者可以通過為兩個應用建立不同的ECS Cluster或者在一個ECS Cluster內通過親和性排程演算法實現。

為什麼需要做上述的設定呢？下面解釋下如果將這兩個應用排程到相同的ECS Cluster上會出現什麼問題。

在上面這個場景中，App1和App2使用容器部署在EC2中，App1需要通過NLB來訪問App2，如果網路模式使用bridge，App1的流量在發出所在EC2例項的時候，源IP地址會從App1的容器IP轉換成EC2的IP，如果NLB通過負載分發演算法將流量發往處於相同EC2上的App2容器，NLB會將目的IP轉換成相同的EC2的IP地址，流量到達EC2後，EC2會將目的IP轉換成App2的容器IP，問題在於App2回包的時候，當流量到達EC2 OS層，OS通過查詢路由表發現目的地址是自己，會在OS層面直接處理流量，而不會將流量返回給NLB，導致App1訪問App2失敗。

這個問題是由於NLB的工作原理導致的，NLB在接收到流量後，保持源IP地址不變，通過負載均衡演算法選擇後端例項，並將目的IP轉換成後端例項的IP地址進行流量分發，我們需要在設計上避免上述問題，將App1和App2的容器排程到不同的EC2例項上，從而在根本上避免App1訪問App2的流量的發起和終止在同一臺EC2例項上。

以上我們的介紹了NLB的主要特點，配置方法及常見的配置注意事項，讀者如果感興趣的話，可以通過下面的連結來進一步學習NLB的相關內容：

作者介紹

餘駿，AWS解決方案架構師，負責基於AWS的雲端計算方案架構的諮詢和設計，同時致力於AWS雲服務在國內的應用和推廣。在加入AWS之前，在思科中國擔任系統工程師，負責方案諮詢和架構設計，在企業私有云和基礎網路方面有豐富經驗。