跨園區容災，升級不停服——高可用負載均衡集羣實踐

時間 2019-12-19

原文原文鏈接

對於雲計算行業來講，雲服務的可用性和可擴展性是的檢測其服務質量的重要標準，也是最受用戶關注的兩大難題。各雲計算廠商針對容災、升級等需求的解決方案，最可以體現其底層架構的實力。騰訊雲基於基礎架構的優點，爲分期樂、微信紅包等平臺提供技術支持，能夠完美知足以下三點需求：nginx

1. 高可用能力，容災能力強，升級不停服web

2. 可擴展性強，功能豐富，性能超高算法

3. 避免重複造輪子，性價比之王apache

近期，針對一些客戶對騰訊雲產品可用性的問詢，騰訊雲基礎產品團隊對負載均衡產品的原理作出詳細闡述，並但願經過對騰訊負載均衡集羣底層架構的實現的講解分析，揭示其強勁性能、高可用性的根源所在。後端

1、什麼是負載均衡

單臺web服務器如apache、nginx每每受限於自身的可擴展硬件能力。在面對海量的web請求時，須要引入load balance將訪問流量均勻的分發到後端的web集羣，實現接入層的水平擴展。瀏覽器

Tencent全部業務的負載均衡都是基於內部Tencent GateWay實現的，運行在標準x86服務器上，優勢包括：自主研發、代碼可控。Tencent GateWay對外的版本爲Cloud load balance，是多機active部署的，經過BGP發佈VIP、local adress路由、同步DNS信息等，實現集羣負載經過路由OSPF將流量分發到不一樣的服務器上。安全

Load balance做爲IT集羣的出入口、咽喉要塞。開發商使用負載均衡器看中的無非是高可用能力、分發性能以及產品功能的豐富程度，咱先從高可用提及。服務器

2、高可用能力

a. 單集羣容災能力

集羣容災，簡單來講就是一個集羣中一臺服務器倒掉不會影響整個集羣的服務能力。LVS是國內廠商經常使用的開源框架，經常使用Keepalived完成主備模式的容災。有3個主要缺點：微信

一、主備模式利用率低。一個集羣同時只有一半的服務器在工做，另一半的機器處於冷備狀態，主節點不可用以後的切換速度相對較慢；session

二、橫向平行擴展能力差。LVS服務集羣擴展後轉發效率大幅降低；

三、依賴的VRRP協議存在腦裂的風險，需引入第三方仲裁節點，在金融領域、跨園區容災領域備受挑戰。

CLB在設計之初就考慮到這個問題，採用自研的ospf動態路由協議來實現集羣的容災，若一臺機器倒掉，ospf協議能夠保證在10s之內把機器從集羣中剔除。

CLB一個集羣放在兩個接入交換機下，而且保證跨機架的容災，這樣保證在即使有單邊的交換機出故障或者單邊機架掉電時，本集羣的服務不受影響。同事實現了集羣內session鏈接按期同步。這樣在別的服務器接管故障機器的包時，client端的用戶體驗不受影響（如未登陸的帳戶，在電商購物車裏的未付款商品不丟失）

b. 跨園區容災能力

爲了知足金融核心客戶，24小時核心業務持續服務的要求。騰訊雲負載均衡已在各金融專區（region）部署了多可用區（zone）容災套件，從路由器、交換機和服務器以及佈線是全冗餘的，任意一個路由器、交換機或者服務器接口掛掉以後，流量會從冗餘組件提供服務。

當client端請求，通過CLB代理，訪問到後端CVM時，負載均衡的源 ip、目的ip、轉發策略、會話保持機制，健康探測機制等業務配置。會實時的同步到另外一個zone的集羣。當主可用區的機房故障、不可用時，負載均衡仍然有能力在很是短的時間內（小於10s）切換到另一個備可用區的機房恢復服務能力，而業界產品的切換時間通常在分鐘級別。當主可用區恢復時，負載均衡一樣會自動切換到主可用區的機房提供服務。目前包括webank、富途證券等金融開發商已啓用跨園區容災能力。

容災演練實測：
一、協議切換(模擬交換機、CLB集羣任何一層故障致使整個機房外網LB不可用)，切換時間ping丟包不超過1秒，但長連接會瞬斷，結果符合預期

二、在高可用機房的LB外網徹底癱瘓發生切換，恢復後不主動回切，過程當中癱瘓機房的任何操做不該影響另一邊，結果符合預期

三、模擬（與CLB開發商溝通好之後）流量回切操做，流量回切時間ping丟包不超過1秒，但長連接發生瞬斷，結果符合預期

c. 升級不停服

CLB內核升級、Linux內核缺陷、安全漏洞等緣由，免不了要作後端集羣的重啓升級，若是服務器每一年因爲維護等緣由重啓一次，1小時的恢復時間就已經達不到99.99%的可用性了。

目前CLB已能作到客戶無感知的，完成服務器升級。升級時會選取集羣一半負載均衡器，停掉OSPF協議，實行「溫暖關機」。將其權重設置爲0，從而保證數據包不會在通過這幾臺LB。另外一半LB集羣會接管預備關機LB的流量，集羣內鏈接同步，負責接管的LB上具備全量的鏈接信息，鏈接不會中斷。升級完成後的LB將從新啓動ospf，加入集羣，正常服務。

3、高可擴展性

a. 性能強勁

1）流量分發

騰訊雲負載均衡內部實現，利用了intel DPDK提供的高性能多核開發框架、hugepage內存管理及ring buffer共享隊列方案，CLB團隊將DPDK常見的邏輯設計框架run-to-completion與pipeline結合。極大提高了流量分發的效率。

2017年1月28日，微信公佈了用戶在除夕當天收發微信紅包的數量：142億個，而其收發峯值也已達到76萬每秒。面對億級的用戶數及百億級的紅包，系統的性能相當重要。而承載新年紅包的手機QQ和微信都接入了騰訊雲負載均衡集羣，獲得了有效的性能保障。CLB單集羣可承受的TCP最大併發鏈接數超過1.2億，處理峯值40Gb/s的流量，每秒處理包量（QPS）可達600萬。爲廣大用戶提供了流暢、愉快的搶紅包體驗，實現了除夕夜系統零故障。

2）Https加速

CLB性能上最大的一個難題是如何提高HTTPS的效率。一樣的物理設備下cpu滿負載，nginx SSL徹底握手的性能不到普通HTTP性能的10%，若是說HTTP的性能是QPS 1萬，HTTPS可能只有幾百。爲何會這麼低呢？

一、主要是RSA算法，它對性能的影響佔了75%左右；

二、ECC橢圓曲線若是使用最經常使用的ECDHE算法，這部分約佔總體計算量的7%；

三、對稱加解密和MAC計算，它們對性能影響比較小，是微秒級別的。

有了這些分析結論，優化的方向就很明確了：

一、減小徹底握手（採用分佈式session cache、全局Session ticket、自定義session ticket）

二、RSA異步代理計算

三、對稱加密優化

通過以上努力CLB團隊經過異步代理、減小徹底握手等方式，釋放了CPU負載，。通過優化後，https請求的訪問時延與http請求相差無幾。單集羣的單臺雲服務器徹底握手性能可達到65000QPS，長鏈接時單臺服務器性能能夠達到300000QPS。完美的支撐了紅包業務對SSL卸載的性能要求

b. 均衡能力豐富

咱們來看看另外一個case。分期樂一家專一於大學生分期購物的在線商城及金融服務提供商，提供分期貸款和還款服務。原分期樂（fenqile.com）的電商門戶，有三十多個業務模塊，經過多個二級域名、公網IP來分隔業務模塊。門戶的日PV超過億次，峯值帶寬超過5GB。

隨着訪問量的增多，其自建的nginx負載均衡集羣已沒法承載海量的請求，頻繁出現丟包、SSL卸載慢等額問題。爲了保證其業務在九月開學大促、雙十一大促中平穩運行，分期樂引導部分流量到雲端架構中，經過負載均衡進行業務整合：

1）Content base的流量轉發

爲了實現業務分離，分期樂使用七層負載均衡獲取HTTP/HTTPS頭部信息，並根據企業業務的實際須要，將請求路由到不一樣的後端服務器集羣，從而讓負載均衡基於內容進行路由轉發。此外，採用了細緻到轉發組級別的健康檢查，具備更強靈活性，知足更多業務場景。

分期樂業務架構中，經過自定義域名/URL，實現了基於內容的路由轉發。根據業務類型，分期樂配置了a.fenqile.com/image 和a.fenqile.com/text 兩個URL路徑。經過識別請求內容，將後綴帶有/image的請求轉發到後端服務器羣組1，並將後綴帶有/text的請求轉發到後端服務器羣組2，從而保證了流量分發到不一樣的服務器羣組中，減輕單個節點的負載。原來以上配置都須要在自建的nginx location中配置完成，轉發請求時消耗大量的cpu資源，如今交給CLB就行了。

CLB同時提供多元化的重定向能力，能夠知足電商的兩種場景：A.瀏覽器發起的http請求，強制轉換爲https請求，加密更可靠。B.電商中商品更替、庫存售罄、後端某服務器負載太高（限制鏈接數、請求）等場景，常見的作法是直接拉黑頁面，給client端返回40四、503。但這種體驗太差了，CLB支持智能重定向，將超負載的請求，轉發到其它頁面，如門戶首頁。