松花皮蛋的黑板報
  • 分享在京東工作的技術感悟,還有JAVA技術和業內最佳實踐,大部分都是務實的、能看懂的、可復現的

掃一掃
關注公眾號

程序員都應該了解的運維知識經驗

博客首頁文章列表 松花皮蛋me 2019-07-24 00:06

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


常見的URL格式是http://www.znvxfuqt.icu,由協議+域名+端口號組成,這里涉及到一個不可輕視的知識點,就是跨域,瀏覽器有一個同源策略限制,協議、域名、端口號有一個不同就會發生跨域沖突,從而保證了其他站點不能非法操作正常站點的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.znvxfuqt.icu,那么瀏覽器是怎么知道去哪獲取資源的呢?實際上客戶端必須先通過分布式DNS系統進行本地解析或者權威服務遞歸解析獲取真實IP,然后才能建立連接和獲取響應。為了提高可靠性和吞吐量,一般采用多機房多臺容災部署,統稱多個集群,避免單點故障,那么上線時就需要采用一定機制的發布策略比如滾動發布,減小上線影響范圍,發布時先摘取流量,發布成功后利用本地DNS緩存也就是在/etc/hosts指定映射,進行服務驗證,當無異常時再恢復流量。通常域名證書不會直接配置在后端實例上,所以在綁定hosts的時候無法使用HTTPS訪問,你可能會發現訪問時自動跳轉到HTTPS請求,然后報錯了,背后其實是瀏覽器的HSTS協議,它代表的是HTTPS嚴格傳輸協議,它是一個網絡安全政策機制,當第一次通過HTTPS請求時,服務器響應strict-transport-security: max-age=7776000\r\n頭,其含義是瀏覽器在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.znvxfuqt.icu對應有三臺主機,分別是A、B、C,權重分別為1、2、3,加權輪詢得到的序列順序則為A、B、B、C、C、C,一般用于后端主機配置有較大差異的場景。粘性Session也稱為一致性哈希算法,它將Key和實例標識的值Hash后映射到同一個圓環上,Key所對應的值為順時針查找的第一個Value值,從而保證了相同來源的請求始終會到達相同的后端實例,當有新實例節點增加或者刪除時也只會影響極小部分的請求映射。流量集群帶來的第二個麻煩是如何避免DNS緩存,這里先直接給出解決方案,域名解析到一個主機上,然后通過該主機再轉發到真實的后端實例,每次變更實例狀態或者數量時,只更新轉發映射路由表即可,這個主機稱為Virtual?IP?Address,簡稱VIP


VIP是一個負載均衡器節點,有硬件和軟件之分,硬件的成本比較高,使用率比較低。負載均衡器又分為四層和七層負載均衡器,顧名思義,四層的工作在TCP\IP協議棧上,通過修改請求報文的(源/目的)地址和(源/目的)端口來轉發,比如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性能下降。如果你壓測的場景是大數據,請勿必留意該監控項和網絡流量監控項,重傳發生的次數和時間周期很小時影響才微乎其微,網絡流量入出速率不超過50M\s也不需要過于在意。CPU使用率是單位時間內CPU使用情況的統計,以百分比的方式展示,它表示除了空閑時間外的其他時間占總CPU時間的百分比,日常運行中CPU使用率保持在25%左右,大促運營活動時保持在30%左右會比較好。平均負載描述的是系統的平均活躍進程數,理想情況下它等于邏輯CPU個數,這表示每個CPU都恰好被充分利用。目前主流的技術棧是Java,程序由JVM虛擬機進行翻譯,JVM通常會預先分配好內存,所以在監控平臺看到的內存使用率一般是固定的、偏高,我們可以同時關注下Swap交換分區,它的作用可簡單描述為:當系統的物理內存不夠用的時候,就需要將物理內存中的一部分空間釋放出來,以供當前運行的程序使用。那些被釋放的空間可能來自一些很長時間沒有什么操作的程序,這些空間被臨時保存到Swap空間中,等到那些程序要運行時,再從Swap中恢復保存的數據到內存中

黑龙江6+1开奖结果查询