第7層網路負載平衡器

「負載平衡」中示範了反向代理HTTP服務的負載平衡的實驗。在「什麼是API網關」中提到：

API網關是網路第7層的守門人。他控制有多少網路封包可以通過、能不能通過，通過了又應該再往哪個方向前進。

(圖片來源：https://en.wikipedia.org/wiki/Protocol_stack#/media/File:OSI_Model_v1.svg)

為什麼API網關可以做到這些事情？ 很大的原因是API網關能夠理解第7層應用層的內容，像是HTTP、GraphQL、gRPC等等。拿個之前看過的HTTP例子來看：

因爲理解應用層內容，因此可以做到「健康檢查」、「資料格式轉換」等等能力。Apache APISIX不僅僅只懂HTTP，還了解GraphQL、gRPC、Kafka等。像是支援的Plugin就有degraphql、grpc-transcode、grpc-web、kafka-proxy、mqtt-proxy等等。如果自己有能力，還可以依據xRPC文檔添加更多協議。

第4層網路負載平衡器

Apache APISIX除了能夠提供第7層網路負載平衡，也有能力在第4層網路提供負載平衡。不同於應用層的豐富內容格式，第4層傳輸層專注在的是「應用程式程序間資料的傳輸^1」，主要使用協議有TCP和UDP。

專注在「應用程式程序間資料的傳輸」，也就是在第3層網路層確定來源與目的的IP以後，再確定兩方程序，建立通訊連線。一個連線(Connect)的完整包含：來源IP、來源Port、目的IP、目的Port。第4層網路負載平衡器更專注在於這一部分的轉發。

(圖片來源： API Gateway vs Load Balancer：选择适合你的网络流量管理组件)

在第4層上，還有會話層、表達層和應用層，有時候這三層同被視為應用層。
會話層不一定是同一組連線來保持會話，像是在HTTP/3(QUIC)中使用了一些機制，使得行動網路在切換基地臺、變更來源IP和端口後，仍可以保持會話。

所以一般而言，第4層網路負載平衡：就是專注在負載平衡。但也因此限制較少，可以用來代理更多基於TCP或UDP的協議，比如LDAP、MySQL和RTMP。

選擇適合的網路負載平衡工具

參考API Gateway vs Load Balancer：選擇適合你的網路流量管理組件，Apache APISIX提供第4層負載平衡的能力，其實並不如更專注在這部分的軟體，如：HAProxy。仍應該視自己環境選擇適合的負載平衡工具，甚至使用專用的負載平衡硬體。

又或者像是資料庫的代理，使用ProxySQL代理MySQL或PostgreSQL[^2]、專注於PostgreSQL的pgprox也同樣有負載平衡的效果在，且更能貼近應用情境，做到讀寫分離(讀/寫使用不同的上游節點)。

[^2]: How to Configure ProxySQL for PostgreSQL for the first time

最近還有看到作用在網路第2層(L2)的負載平衡工具--MetalLB[^3]。
但效果似乎其實和Keepalived有點像，但不使用VRRP達成[^4]。

[^3]: MetalLB: K8S 叢集的網路負載平衡器
[^4]: 用MetalLB为K8s集群提供负载均衡服务(L2模式)