最近做了一些AWS和Azure的功課，準備把一些基礎的東西記錄下來。正好前幾天講混合雲提到了架構縱向和橫向的解耦，於是首先理理負載均衡。言者無罪，必有我師，歡迎拍磚。
對於一個應用的架構來說，如果想把業務從單個節點/服務上解耦，負載均衡就是一個不可或缺的組件。負載均衡是做啥的，用wiki來解釋估計好點。
“In computing, load balancing improves the distribution of workloads across multiple computing resources, such as computers, a computer cluster, network links, central processing units, or disk drives.[1] Load balancing aims to optimize resource use, maximize throughput, minimize response time, and avoid overload of any single resource. Using multiple components with load balancing instead of a single component may increase reliability and availability through redundancy. Load balancing usually involves dedicated software or hardware, such as a multilayer switch or a Domain Name System server process.”
——https://en.wikipedia.org/wiki/Load_balancing_(computing)
按照描述，負載均衡用來爲資源分配負載，以達到最優化資源使用、最大化吞吐率、最小化響應時間、同時避免過載的目的。此外，負載均衡其實還可以用來Offload流量，阻斷客戶端到服務端的直接訪問。需要注意的是，客戶端可能是一個使用Web瀏覽器的用戶，也有可能是前端的服務器；服務端可能是數據庫服務器，也有可能是Web服務器。因此，在之前我和NetScaler Team的同事跟用戶聊需求的時候，生造了一個詞，叫“全棧負載均衡”，意思是在整個應用架構中，其實不同的位置都會需要負載均衡。而NetScaler的功能使得它能夠在不同的位置都能工作。
較早的著名的負載均衡的物理形式，我想是都江堰了吧，哈哈。負載均衡所需要的偵聽、規則、流向，基本在這個水利工程上都能體現。分水魚嘴實現的“分四六，平潦旱”、榪槎實現的動態策略調整、寶瓶口實現的監控和防洪/速率控制、飛沙堰實現的策略流量過濾，哈哈哈。古人真的太牛了，有興趣可以訪問：https://zh.wikipedia.org/wiki/%E9%83%BD%E6%B1%9F%E5%A0%B0 膜拜老祖宗。
常見的負載均衡用法很多，按照架構其實有三個維度吧，如果真畫在一張圖上，就變成了南北向，東西向和前後向，分別是從架構層到應用層、服務之間的連接、服務使用和服務提供之間的連接。我想大致可以從入站方向和出站方向進行分類，更加便於整理。以網站電商等來說，可能更加關心用戶如何訪問進來，入站方向可能更爲優先。而企業有數據網絡傳輸的需求的時候，往往需要評估如何傳輸能夠獲得更加穩定高效以及更低的線路成本。
1、入站方向
1.1、DNS引流負載均衡
常見的入站負載均衡，從客戶端開始，由外到裏，首先可以使用DNS解析進行。最早使用的估計是DNS round-robin的做法，讓不同用戶輪流獲得不同的DNS解析，訪問不同的服務地址。DNS服務本身現在也可以結合很多條件，以按照預設給予客戶端符合預期的響應。這部分功能，在Azure被稱爲“流量管理器”，在AWS被稱爲“Route53”。實現原理可以參考下圖：
基本上，基於DNS的負載均衡會考慮到地理區域以實現特定用戶、優先級以實現自由切換、加權以實現灰度遷移、性能以實現自動調整的各種調整方式。需要注意的是，DNS的記錄擴散到最終用戶查詢的DNS（例如寬帶使用的默認運營商DNS）需要時間，因此TTL是需要考慮的參數之一。
從我個人體驗來說，Route53的管理粒度和容易程度好一點。而很多ADC廠商也提供類似的方案，例如NetScaler的GSLB，根據健康度調整DNS響應，引導用戶在不同站點訪問服務。當然，其他廠商也有類似的方案，只是我對Citrix的相對熟悉一點而已。
基於加權、健康度、優先級等方式的流量調節，在流量、四層、七層負載均衡上都有所體現。
1.2、四層負載均衡
對於僅使用IP地址和端口進行負載均衡的，視爲四層負載均衡器。四層負載均衡通常只在L4的TCP/UDP協議進行操作，對於四層以上的應用數據並不相關聯。
Azure的四層負載均衡使用源IP、源端口、目的IP、目的端口和協議五元組進行哈希，決定一個會話會被傳遞給負載均衡後面的哪個地址。當會話重新建立時，從客戶端訪問的源地址或者源端口會出現變化，由此新的會話被分往負載均衡器後面不同的節點。
AWS的四層負載均衡使用基於協議、源 IP 地址、源端口、目標 IP 地址、目標端口和 TCP 序列號的流式哈希算法選擇目標。
使用負載均衡器，就能夠實現端口轉發。例如負載均衡器後的服務器組（稱爲終結點）可能會運行不同的Web服務，使用不同的端口進行偵聽。在負載均衡器上，就可以使用不同地址的默認端口（例如80）轉發到後面終節點的非默認端口（81），從而減少不必要的終結點數量。
另外，AWS和Azure都支持爲終結點啓用可變集合（AWS叫Auto Scaling，Azure叫可用性集） 以充分利用負載均衡自動重新配置的特點。在需要的時候，終結點的數量可以隨負載或者其他要求進行增加減少，同時所有對終結點的訪問由負載均衡器轉發給終結點，從而實現了訪問和服務的解耦。
更重要的是，雲中的負載均衡能夠跨越不同的物理服務器放置位置，例如AWS的可用區（Available Zone）和Azure的容錯域（使用相同物理電源和物理網絡開關）及更新域（使用相同維護計劃） （Azure貌似也開始使用區域了？）。這樣就可以保證在出現電源、更新、網絡設備故障甚至是局部火災等不可控故障時，整個架構的服務不會受到影響。
負載均衡避免不了一種場景，即用戶希望保持相同會話連接到相同終結點上。在四層負載均衡器上，Azure使用源IP、目的IP的二元組，或者源IP、目標IP和端口的三元組，來實現會話粘連（或者叫會話保持、持久連接…）。
在七層負載均衡中，同樣也有這個需求。
1.3、七層負載均衡
每次我講架構session的時候都會來一句，“拋開應用談架構就是耍流氓”。應用是ITaaS棧中最靠近業務的，自底而上終將爲業務服務。因此，越來越多的負載均衡需求從L7提出也就不是一件奇怪的事情了。
Azure用了一張圖來說明流量管理器和應用程序網關配合，把不同類型流量分佈到不同中節點集羣。
而AWS用了一張圖來說明，流量是如何通過不同的偵聽器，匹配到不同的策略/規則，通過檢測終結點健康，把流轉發到可用的終結點的。
因此，七層負載均衡的工作就非常好理解了。根據我們對應用的定義和需求，以HTTP爲例，訪問的資源例如URL到達L7負載均衡後，按照預先設置的偵聽器，匹配協議和端口，在此基礎上，可以根據訪問請求的主機名，或者訪問請求的路徑，進行策略/規則的匹配，轉發往後端指定的終結點。
這樣，也就實現了URL的內容路由。根據請求的URL不同，使用不同的服務器、服務處理不同的流量。對於電商來說，查詢和購買，表現的資源消耗可能是不一樣的，這種方式就能夠把不同的應用需求導流到不同的應用羣集。
對於七層的負載均衡，由於需要精細、效率地控制應用訪問，所以會有很多的功能需求。例如，爲了減輕終結點不必要的，除了滿足業務邏輯之外的計算壓力，通常會把一些工作卸載（Offload）到負載均衡上，例如，SSL的卸載，能夠讓終結點不需要計算驗證密鑰，並且簡化證書的管理；TCP的卸載，能夠讓負載均衡負責建立連接，並且讓多個請求使用一個連接，使得終結點減少建立大量連接消耗的資源。
在七層上同樣也有會話保持、會話粘連或者稱之持久性的需求。比較常見的做法是使用負載均衡替換的cookie，或者會話數據緩存等，每種方式都有其優缺點，需要綜合評估選擇。
Azure和AWS都結合負載均衡提供了一些針對DDoS和應用惡意訪問的防護。AWS的Shield和WAF能過提供DDoS的防護，並且在WAF上能夠實現簡單的連接速率控制。Azure的WAF提供了OWASP核心規則集的2.2.9或者3.0的規則，AWS則提供專門的DDoS響應服務。
我一直認爲不應該讓應用開發的人來解決架構上的安全需求，在DevOps大行其道的今天，架構人員瞭解應用，並且爲應用提供合適的安全防護，應該是職責之內的本份。所以，學習一下WAF並沒有什麼壞處。最常見的WAF需求，例如XSS跨站腳本***、SQL injection查詢注入***等等，都是需要被WAF阻擋在應用終結點之外的。至於防爬、限制惡意訪問、協議***等等，其實都可以通過WAF規則來了解和學習。這部分可以參考Azure的核心規則集：https://docs.microsoft.com/zh-cn/azure/application-gateway/application-gateway-crs-rulegroups-rules
安全的另外一部分是審計。因此Azure和AWS都提供了日誌和監控服務。
2、出站方向
相對入站方向，出站方向的負載均衡需求感覺就簡單多了。最常被提及的需求莫過於把出站的流量分攤到不同的互聯網連接上。對於和入站流量匹配的方式，在四層和七層上分別可以使用源網絡地址翻譯 SNAT和WebSocket等。同樣，都可以使用Azure的網絡安全組 NSG或AWS的安全組 SG來進行限制。
更爲常見的是對不同的連接線路做策略路由。傳統方式可能需要根據目標IP做選路路由，而NetScaler可以把出站規則通過Local DB保存的策略驅動Content Switch來匹配策略路由，從而實現根據來源IP決定選擇哪一條線路。這樣，就能夠同樣的服務根據請求來源的不同使用最爲優質的線路（例如，相同ISP）進行響應。
SD-WAN也可以視爲一種不同的負載均衡，設備將根據線路的質量，例如抖動、時延、丟包等，自動平衡分配流量的去向。同時也提供在線路失效時提供不中斷TCP連接的自動切換。
3、其他
簡單來說，NetScaler作爲專門的ADC，在雲中能做以上的全部負載均衡的工作，並且有更多的功能。在Azure的marketplace（https://azuremarketplace.microsoft.com/zh-cn/marketplace/apps/citrix.netscalervpx-120 ）和AWS的marketplace（https://amazonaws-china.com/marketplace/pp/B00AA01BOE?qid=1516073367752 ）中，都能看到以VPX虛機提供的公有云版本。簡單的描述如下：
當然，雲中用作負載均衡的方法和廠商很多，例如Apache、Nginx以及F5等其他產品，限於個人瞭解的深度和廣度，無法一一列舉。
之所以想起寫下這些學習過程中接觸到的東西，下面這張圖也是原因之一。我們處在一個將各種資源和服務解耦以實現更高利用和更靈活組合的時代。看看Azure和AWS提供的各種服務，用戶也許只需要連接不同的組件，就能夠實現以前複雜架構所提供的資源能力。負載均衡作爲橫向解耦的重要手段，必然在架構中越來越重要。
同時，容器和Serverless的未來，服務乃至微服務之間的東西向解耦連接，也對負載均衡提出了新的要求。我猜Nginx應該也有容器版本了吧，而NetScaler也已經有了容器版本CPX。
未來的檢測、管理、策略什麼的，也會漸漸引入機器學習和AI吧。
對Azure和AWS負載均衡相關的比較關鍵信息引用如下：
Azure 負載均衡器比較
AWS Elastic Load Balancing 比較
參考：
負載均衡Wiki：https://en.wikipedia.org/wiki/Load_balancing_(computing)
Azure-流量管理器：https://docs.microsoft.com/zh-cn/azure/traffic-manager/traffic-manager-overview
AWS-Route53：https://docs.aws.amazon.com/zh_cn/Route53/latest/DeveloperGuide/Welcome.html
Azure-Azure負載均衡器：https://docs.microsoft.com/zh-cn/azure/load-balancer/load-balancer-overview
AWS-網絡負載均衡器：https://docs.aws.amazon.com/zh_cn/elasticloadbalancing/latest/network/introduction.html
Azure-應用程序網關：https://docs.microsoft.com/zh-cn/azure/application-gateway/application-gateway-introduction
AWS-應用程序負載均衡器：https://docs.aws.amazon.com/zh_cn/elasticloadbalancing/latest/application/introduction.html
Azure-Web應用程序防火牆：https://docs.microsoft.com/zh-cn/azure/application-gateway/application-gateway-web-application-firewall-overview
AWS-AWS WAF和AWS Shield：https://docs.aws.amazon.com/zh_cn/waf/latest/developerguide/what-is-aws-waf.html
一篇非常好的blog：https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236