Load balancer 負載均衡

負載均衡器將傳入的請求分發到應用服務器和數據庫等計算資源。無論哪種情況，負載均衡器將從計算資源來的響應返回給恰當的客戶端。負載均衡器的效用在於:

• 防止請求進入不好的服務器
• 防止資源過載
• 幫助消除單一的故障點

負載均衡器可以通過硬件（昂貴）或 HAProxy 等軟件來實現。 增加的好處包括:

• SSL 終結 ─ 解密傳入的請求並加密服務器響應，這樣的話後端服務器就不必再執行這些潛在高消耗運算了。
  • 不需要再每臺服務器上安裝 X.509 證書。
• Session 留存 ─ 如果 Web 應用程序不追蹤會話，發出 cookie 並將特定客戶端的請求路由到同一實例。

通常會設置採用工作─備用 或 雙工作 模式的多個負載均衡器，以免發生故障。

負載均衡器能基於多種方式來路由流量:

• 隨機
• 最少負載
• Session/cookie
• 輪詢調度或加權輪詢調度算法
• 四層負載均衡
• 七層負載均衡

四層負載均衡

四層負載均衡根據監看傳輸層的信息來決定如何分發請求。通常，這會涉及來源，目標 IP 地址和請求頭中的端口，但不包括數據包（報文）內容。四層負載均衡執行網絡地址轉換（NAT）來向上遊服務器轉發網絡數據包。

七層負載均衡器

七層負載均衡器根據監控應用層來決定怎樣分發請求。這會涉及請求頭的內容，消息和 cookie。七層負載均衡器終結網絡流量，讀取消息，做出負載均衡判定，然後傳送給特定服務器。比如，一個七層負載均衡器能直接將視頻流量連接到託管視頻的服務器，同時將更敏感的用戶賬單流量引導到安全性更強的服務器。

以損失靈活性爲代價，四層負載均衡比七層負載均衡花費更少時間和計算資源，雖然這對現代商用硬件的性能影響甚微。

水平擴展

負載均衡器還能幫助水平擴展，提高性能和可用性。使用商業硬件的性價比更高，並且比在單臺硬件上垂直擴展更貴的硬件具有更高的可用性。相比招聘特定企業系統人才，招聘商業硬件方面的人才更加容易。

缺陷：水平擴展

• 水平擴展引入了複雜度並涉及服務器複製
  • 服務器應該是無狀態的:它們也不該包含像 session 或資料圖片等與用戶關聯的數據。
  • session 可以集中存儲在數據庫或持久化緩存（Redis、Memcached）的數據存儲區中。
• 緩存和數據庫等下游服務器需要隨着上游服務器進行擴展，以處理更多的併發連接。

缺陷：負載均衡器

• 如果沒有足夠的資源配置或配置錯誤，負載均衡器會變成一個性能瓶頸。
• 引入負載均衡器以幫助消除單點故障但導致了額外的複雜性。
• 單個負載均衡器會導致單點故障，但配置多個負載均衡器會進一步增加複雜性。

來源及延伸閱讀

• NGINX 架構
• HAProxy 架構指南
• 可擴展性
• Wikipedia
• 四層負載平衡
• 七層負載平衡
• ELB 監聽器配置

---

Load balancers distribute incoming client requests to computing resources such as application servers and databases. In each case, the load balancer returns the response from the computing resource to the appropriate client. Load balancers are effective at:

• Preventing requests from going to unhealthy servers
• Preventing overloading resources
• Helping eliminate single points of failure

Load balancers can be implemented with hardware (expensive) or with software such as HAProxy.

Additional benefits include:

• SSL termination - Decrypt incoming requests and encrypt server responses so backend servers do not have to perform these potentially expensive operations
  • Removes the need to install X.509 certificates on each server
• Session persistence - Issue cookies and route a specific client's requests to same instance if the web apps do not keep track of sessions

To protect against failures, it's common to set up multiple load balancers, either in active-passive or active-active mode.

Load balancers can route traffic based on various metrics, including:

• Random
• Least loaded
• Session/cookies
• Round robin or weighted round robin
• Layer 4
• Layer 7

Layer 4 load balancing

Layer 4 load balancers look at info at the transport layer to decide how to distribute requests. Generally, this involves the source, destination IP addresses, and ports in the header, but not the contents of the packet. Layer 4 load balancers forward network packets to and from the upstream server, performing Network Address Translation (NAT).

Layer 7 load balancing

Layer 7 load balancers look at the application layer to decide how to distribute requests. This can involve contents of the header, message, and cookies. Layer 7 load balancers terminates network traffic, reads the message, makes a load-balancing decision, then opens a connection to the selected server. For example, a layer 7 load balancer can direct video traffic to servers that host videos while directing more sensitive user billing traffic to security-hardened servers.

At the cost of flexibility, layer 4 load balancing requires less time and computing resources than Layer 7, although the performance impact can be minimal on modern commodity hardware.

Horizontal scaling

Load balancers can also help with horizontal scaling, improving performance and availability. Scaling out using commodity machines is more cost efficient and results in higher availability than scaling up a single server on more expensive hardware, called Vertical Scaling. It is also easier to hire for talent working on commodity hardware than it is for specialized enterprise systems.

Disadvantage(s): horizontal scaling

• Scaling horizontally introduces complexity and involves cloning servers
  • Servers should be stateless: they should not contain any user-related data like sessions or profile pictures
  • Sessions can be stored in a centralized data store such as a database (SQL, NoSQL) or a persistent cache (Redis, Memcached)
• Downstream servers such as caches and databases need to handle more simultaneous connections as upstream servers scale out

Disadvantage(s): load balancer

• The load balancer can become a performance bottleneck if it does not have enough resources or if it is not configured properly.
• Introducing a load balancer to help eliminate single points of failure results in increased complexity.
• A single load balancer is a single point of failure, configuring multiple load balancers further increases complexity.

Source(s) and further reading

• NGINX architecture
• HAProxy architecture guide
• Scalability
• Wikipedia
• Layer 4 load balancing
• Layer 7 load balancing
• ELB listener config

參考資料

https://github.com/to-be-architect/system-design-primer

---

Kotlin開發者社區

專注分享 Java、 Kotlin、Spring/Spring Boot、MySQL、redis、neo4j、NoSQL、Android、JavaScript、React、Node、函數式編程、編程思想、"高可用，高性能，高實時"大型分佈式系統架構設計主題。

High availability, high performance, high real-time large-scale distributed system architecture design。

分佈式框架：Zookeeper、分佈式中間件框架等
分佈式存儲：GridFS、FastDFS、TFS、MemCache、redis等
分佈式數據庫：Cobar、tddl、Amoeba、Mycat
雲計算、大數據、AI算法
虛擬化、雲原生技術
分佈式計算框架：MapReduce、Hadoop、Storm、Flink等
分佈式通信機制：Dubbo、RPC調用、共享遠程數據、消息隊列等
消息隊列MQ：Kafka、MetaQ，RocketMQ
怎樣打造高可用系統：基於硬件、軟件中間件、系統架構等一些典型方案的實現：HAProxy、基於Corosync+Pacemaker的高可用集羣套件中間件系統
Mycat架構分佈式演進
大數據Join背後的難題：數據、網絡、內存和計算能力的矛盾和調和
Java分佈式系統中的高性能難題：AIO，NIO，Netty還是自己開發框架？
高性能事件派發機制：線程池模型、Disruptor模型等等。。。

合抱之木，生於毫末；九層之臺，起於壘土；千里之行，始於足下。不積跬步，無以至千里；不積小流，無以成江河。