摘要：負載均衡器又分為四層和七層負載均衡器，顧名思義，四層的工作在協議棧上，通過修改請求報文的源目的地址和源目的端口來轉發，比如，一個主機對應一個域名，適用于每秒超過一萬的業務。每一次變更都是一次發布，每一次發布都是一個獨立的鏡像啟動

以一個經典問題拋磚引玉，當用戶在瀏覽器中輸入一個URL到底發生了什么？

常見的URL格式是http://www.liangsonghua.me，由協議+域名+端口號組成，這里涉及到一個不可輕視的知識點，就是跨域，瀏覽器有一個同源策略限制，協議、域名、端口號有一個不同就會發生跨域沖突，從而保證了其他站點不能非法操作正常站點的cookie和修改dom元素，重要性不言而喻。當不得已沖突時，可以通過JSONP請求、添加允許跨域響應頭、使用代理轉發的方式獲取資源。不過請記住，盡量不要使用代理轉發的方式，因為它違背了環境標準化準則，我們應該保證擴容新服務器時能取得正確、最新的配置，比如服務日記輸出路徑應該形成一種共識規范，這種稱為”約定大于配置”，它的好處是，除了簡化配置工作外，還可以提高溝通效率，另外標準先行是持續交付和架構改造技術實施的前提條件

WEB系統早已從久遠的單系統發展為多系統，面對眾多的系統，用戶不可能一個一個登錄然后又一個一個地注銷，況且每個系統都重復實現登錄業務和管理用戶實在上浪費成本，統一登錄系統應運而生，假設是plogin.liangsonghua.me，隨著業務的發展，某些業務方想保留自己獨有的域名，假設是plogin.lsh.com，我們當然應該也必須理解和接受這樣的需求，畢竟再小的個體也有自己的品牌，但是同源策略限制了無法下發登錄態cookie，不過可以通過別名CNAME解析處理，也可以將登錄態附到域名的URL上，然后業務方自行適配，比如plogin.lsh.com?sso_ticket=utm_site_www_liangsonghua_me。當客戶端禁用cookie時，也只能選擇后者了

客戶端請求頭部信息一般是固定的，代理服務器一般會將其進行緩存，有緩存的地方就有緩存大小控制的江湖，緩存容量不足時可以進行頁面置換或者直接拋棄，代理服務器選用的是后者，緩沖區大小默認為4*128K，當URI過大或者Htttp Header過大時直接向上拋出400或401錯誤

為了規范化管理，通常會使用不同的根域名區分業務，比如CDN服務類、對外展示類、服務間調用類，或者又比如泰國站、印尼站，或者又比如公網、內網、預發，那么此時你就需要注意是否可以直接復用統一登錄，是否支持在內網環境下通過手機端聯調

或許你剛出于好奇逛了下www.liangsonghua.me，那么瀏覽器是怎么知道去哪獲取資源的呢？實際上客戶端必須先通過分布式DNS系統進行本地解析或者權威服務遞歸解析獲取真實IP，然后才能建立連接和獲取響應。為了提高可靠性和吞吐量，一般采用多機房多臺容災部署，統稱多個集群，避免單點故障，那么上線時就需要采用一定機制的發布策略比如滾動發布，減小上線影響范圍，發布時先摘取流量，發布成功后利用本地DNS緩存也就是在/etc/hosts指定映射，進行服務驗證，當無異常時再恢復流量。通常域名證書不會直接配置在后端實例上，所以在綁定hosts的時候無法使用HTTPS訪問，你可能會發現訪問時自動跳轉到HTTPS請求，然后報錯了，背后其實是瀏覽器的HSTS協議，它代表的是HTTPS嚴格傳輸協議，它是一個網絡安全政策機制，當第一次通過HTTPS請求時，服務器響應strict-transport-security: max-age=7776000rn頭，其含義是瀏覽器在max-age到期前只能通過安全的HTTPS連接與網站交互，避免中間人劫持

域名解析類型常見的有A記錄、AAAA記錄、CNAME、TXT記錄，A記錄又稱IP指向，可以設置子域名并指定到目標主機地址上，AAAA記錄用于IPv6解析，IPv6的設計目的是取代IPv4，從而解決IPv4地址枯竭問題，同時它也在其他方面對于IPv4有許多改進，正常網絡請求下，客戶端會向DNS服務器發起域名A記錄和AAAA記錄的解析請求，獲取到結果后，會同時使用IPv4和IPv6兩種鏈路嘗試建立連接，默認優先使用IPv6鏈路完成后續的網絡請求，當網絡時延比較大時才會使用IPv4地址，也就是說客戶端是處在雙棧環境。另外一個TXT記錄，它一般配合在域名前加上_dnsauth，完成HTTPS驗證

前面說到流量集群，也就是一個域名解析到多臺主機上，隨之而來的麻煩是如何避免數據傾斜，常見的做法是簡單輪詢、加權輪詢、粘性Session、最少連接、隨機算法，將用戶流量轉發到后端，假設域名www.liangsonghua.me對應有三臺主機，分別是A、B、C,權重分別為1、2、3，加權輪詢得到的序列順序則為A、B、B、C、C、C，一般用于后端主機配置有較大差異的場景。粘性Session也稱為一致性哈希算法，它將Key和實例標識的值Hash后映射到同一個圓環上，Key所對應的值為順時針查找的第一個Value值，從而保證了相同來源的請求始終會到達相同的后端實例，當有新實例節點增加或者刪除時也只會影響極小部分的請求映射。流量集群帶來的第二個麻煩是如何避免DNS緩存，這里先直接給出解決方案，域名解析到一個主機上，然后通過該主機再轉發到真實的后端實例，每次變更實例狀態或者數量時，只更新轉發映射路由表即可，這個主機稱為Virtual IP Address，簡稱VIP

VIP是一個負載均衡器節點，有硬件和軟件之分，硬件的成本比較高，使用率比較低。負載均衡器又分為四層和七層負載均衡器，顧名思義，四層的工作在TCPIP協議棧上，通過修改請求報文的(源/目的)地址和(源/目的)端口來轉發，比如LVS，一個VIP主機對應一個域名，適用于每秒QPS超過一萬的業務。七層的工作在應用層，將HTTP請求數據轉發到具體的服務器上，比如Nginx。LVS常見的兩種工作模式是NAT地址轉換和DR直接路由，NAT地址轉換模式下響應會經過VIP，而DR直接路由則不會，另外一種軟件實現Nginx的響應返回也不經過VIP。可以根據成熟度選擇不同的方案，盡量減少VIP的壓力，一般VIP的數量會遠小于后端真實實例，它本身也會出現性能瓶頸

NAT網絡地址轉換常用于將公網和內網進行隔離后進行映射，也就是說在內網線上調用外網服務如微信接口、銀行接口，都是借助的NAT技術，它不是一種安全機制，只是降低了對公網地址的依賴，不過從客觀評價的角度來看NAT技術一定程度下拖慢了IPv6的發展。一般NAT出公網節點數量都比較少，內網線上在沒有申請權限的前提下無法訪問外網是正常的，另外也不推薦在線上訪問公司內部的公網服務

不少公司都是數據驅動型的，首當其沖要解決的其實是大規模數據的存儲問題，幸運的是，我們可以將多個容量較小、相對廉價的磁盤進行有機組合，從而以較低的成本獲得與昂貴大容量磁盤相當的容量、性能、可靠性，這種技術稱為RAID獨立磁盤冗余陣列，可以看作是一種垂直伸縮。常用的RAID技術等級有RAID-0、RAID-1、RAID-10、RAID-5、RAID-6，RAID-0是數據在從內存緩沖區寫入磁盤時，并發寫入N塊磁盤，顯然具有極快的數據讀寫速度，但是數據備份能力極差，只要有一塊磁盤損壞，數據完整性就得不到保證了。RAID-1則是將一份數據同時寫入到兩塊磁盤中，RAID-10充分結合了RAID-0和RAID-1的特點，它將所有磁盤平均分成兩份，數據同時在兩份磁盤中寫入，相當于一半磁盤充當備份。RAID-5和RAID-6則分別可以允許損壞一塊、兩塊磁盤，當磁盤損壞時可以通過其他磁盤上的數據和校驗數據進行恢復。總結一下RAID技術等級的區別，訪問速度：RAID-0>RAID-5>RAID-6>RAID-10>RAID-1,數據可靠性：RAID-1>RAID-10>RAID-6>RAID-5>RAID-0，磁盤利用率：RAID-0>RAID-1>=RAID-0>RAID-5>RAID-6

然而RAID技術不是銀彈，磁盤故障導致服務實例不可用的概率遠比實例本身崩潰死亡的要高，此時人工進行流量切換操作的話相當繁瑣，VIP應該充當一個自動探活的角色，每間隔一段時間進行健康檢查，也就是熔斷，類似家里的電路保險器，當服務連通器異常時將實例標記為不再接收新請求，等待已發送的請求處理完成或者超時后，開始標記為下線，當服務恢復時并且一段時間內都是健康的才重新自動接入流量，實際上業界的負載均衡器都支持這個特性

前面用了很大的篇幅描述了請求的過程，我們將探討點轉移到持續交付的始端，代碼是如何部署到線上的？發布系統一般需要有什么樣的功能？

一個好用的發布系統必須具備易用、快速、穩定、容錯力強，必要時可迅速回滾等特點，變更流程可以抽象為：(1)、通知下游調用方自己現在正在上線;(2)、分發新的版本構建物到服務器上，只修改last版本的軟鏈指向；(3)、運行命令reload變更重啟服務；（4)、驗證服務的健康狀況 ;（5)、通知下游調用方上線已完成。另外，發布系統最好能提供集群分組管理、(實例、主機、分組、全局)靜態配置管理、構建緩存、一鍵重啟服務、按比例分批部署、預熱功能，完善而不失精簡。隨著Docker容器的日益盛行，鏡像發布慢慢開始流行起來，研發將代碼倉庫地址、配置、環境、CPU參數、內存參數、磁盤大小參數封裝成獨立版本的鏡像，然后指定實例數直接發布即可，無須手動申請機器。每一次變更都是一次發布，每一次發布都是一個獨立的鏡像啟動，這種稱為不可變模型，它能讓我們在快速災備、快速恢復系統、增強系統健壯性等場景下收益。不過需要注意鏡像層不能過大，鏡像制作應該易上手，重新發布和異常拉起時容器IP地址無變化

上下游應用關聯信息一般由CMDB功能模塊負責。在標準化建設時，需要對關鍵的對象進行拓撲關系識別，形成標準后進行固化到某個信息管理平臺中，也就是CMDB。信息固化不是目的，也沒有價值，只有對信息動態流轉起來才有價值，我們可以基于應用這一層做彈性擴縮容、穩定性平臺、成本控制等等。其他工具也可以借鑒CMDB理念，比如歸屬權限管理、用戶反饋信息定位到具體業務然后定位到具體的人、測試數據模塊化管理

發布結束并不代表一個交付的結束，發布往往是事故的開端，所以需要對發布質量進行監控，確保所做的更改不會產生負面影響，不要等到用戶來反饋錯誤，可以結合以下五大類監控快速發現發布應用的異常表現，包括：(1)、用戶側監控，關注的是用戶真正感受到的訪問速度和性能；(2)、業務監控，關注的是核心業務指標的波動；(3)、應用監控，即服務調用的監控; (4)、系統監控，即基礎設施、虛擬機及操作系統的監控；(5)、網絡監控，即CDN與核心網絡的監控

服務上線或者應對大促運營活動時，都需要考慮容量規劃，容量規劃離不開壓力測試。壓力測試就是對不同場景進行模擬，然后驗證系統容量和性能是否可以滿足某些極端情況，驗證系統性能優化的有效性。壓力測試從場景角度可劃分為六個緯度，分別為一般測試、負載測試、壓力測試、大數據量測試、穩定性測試、配置測試、可恢復性測試。一般測試就是驗證在正常情況下，是否能滿足性能指標要求，比如持續30分鐘不失敗并且耗時在一定范圍內。負載測試就是利用日常統計數據然后不斷按比例新增用戶操作，直至系統性能出現拐點，此時長時間運行，觀察系統是否正常。壓力測試就是在系統負載運行的情況下，繼續增加壓力，觀察系統是否出現內存泄漏或者Core Dump。大數據量測試主要是針對數據庫有特殊要求的系統進行測試，檢查累積或者瞬間大量數據時，系統是否能穩定運行，實時計算模塊是否能正常運轉。穩定性測試，則是系統在滿足性能指標的要求下，進行長時間的運行，觀察是否能一直正常工作。配置測試，則是在不同的軟硬件配置環境下，進行測試以找到最優分配原則。可恢復性測試，則是關閉、重啟服務，觀察過程中是否有失敗邏輯，還可以驗證服務是否具備冪等性。壓力測試從落地角度又可分為單機單應用壓力測試、單鏈路壓力測試、全鏈路壓力測試、線上流量回放、線上流量引流、流量模擬、數據讀寫施壓。容量壓測的技術方案整體來說還是比較復雜的，施壓時還需要關聯監控，避免過多的錯誤異常，對性能結果造成干擾

壓測過程中我們會關注基礎監控，比如TCP重傳、CPU使用率、平均負載、內存、SWAP、網絡流量。主機報文重傳是TCP最基本的錯誤恢復功能，它的目的是防止報文丟失,報文丟失的可能因素有很多種，包括但不限于網絡設備或線路異常、數據路徑上的流量突發導致鏈路擁塞、網卡故障、服務端性能下降、代理節點或者VIP性能下降。如果你壓測的場景是大數據，請勿必留意該監控項和網絡流量監控項，重傳發生的次數和時間周期很小時影響才微乎其微，網絡流量入出速率不超過50Ms時也不需要過于在意。CPU使用率是單位時間內CPU使用情況的統計，以百分比的方式展示，它表示除了空閑時間外的其他時間占總CPU時間的百分比，日常運行中CPU使用率保持在25%左右，大促運營活動時保持在30%左右會比較好。平均負載描述的是系統的平均活躍進程數，理想情況下它等于邏輯CPU個數，這表示每個CPU都恰好被充分利用。目前主流的技術棧是Java，程序由JVM虛擬機進行翻譯，JVM通常會預先分配好內存，所以在監控平臺看到的內存使用率一般是固定的、偏高，我們可以同時關注下Swap交換分區，它的作用可簡單描述為：當系統的物理內存不夠用的時候，就需要將物理內存中的一部分空間釋放出來，以供當前運行的程序使用。那些被釋放的空間可能來自一些很長時間沒有什么操作的程序，這些空間被臨時保存到Swap空間中，等到那些程序要運行時，再從Swap中恢復保存的數據到內存中

文章來源：www.liangsonghua.me

作者介紹：京東資深工程師-梁松華，長期關注穩定性保障、敏捷開發、JAVA高級、微服務架構