【618備戰巡禮】“三高”之第一高--如何打造高可用系統 | 京東雲技術團隊

前言

我們經常會說互聯網“三高”,那什麼是三高呢?我們常說的三高,高併發、高可用、高性能,這些技術是構建現代互聯網應用程序所必需的。對於京東618備戰來說,所有的中臺系統服務,無疑都是圍繞着三高來展開的。對於一個程序員,或多或少都能說出一些跟三高系統有關的技術點,而我本篇文章的目的,就是幫大家系統的梳理一下三高系統中的第一高:高可用性。

首先來說,互聯網的業務特點決定了他必須保證“三高”, 同時,高併發,高可用,高性能,這三高之間並不是孤立的,而是強相關。一個高可用的系統,一定也需要應對高併發場景對系統帶來的衝擊,保證系統在高流量訪問情況下,系統的服務的正常運轉。同時,一個能夠支撐高併發的系統也一定要滿足高性能,否則也無法實現高流量的承載。

回到我們本文的主旨,我們這裏所說的高可用性是指,系統在遇到任何困難的情況下仍能正常運行的能力。

在京東618備戰期間,系統的高可用對我們來說至關重要,因爲系統的崩潰,不止帶來直接經濟上的損失,還會導致用戶信任的丟失。接下來我通過一張思維導圖展開我的分享,幫大家梳理一下一個高可用系統所需要考慮的技術點。

開發時

1. 首先技術架構方案選型很重要,切記避免過度設計。

比如我們常說的單體應用架構和微服務架構,兩種架構單純來對比,單體應用架構的可用率要比微服務架構高的。因爲多服務之間的依賴一定會降低系統的可用率,比如一個依賴10個微服務的對外接口,假設每個服務的可用率是99%,那麼這個接口對外提供服務的整體可用率就直接降到了90.4%,這中間還要考慮到服務之間的網絡延遲,數據一致性的問題。

還有例子就是中間件選擇,比如一個緩存業務場景,我可以用內存緩存,也可以使用redis分佈式緩存,那麼使用哪個呢?使用內存緩存系統可用率會高,因爲如果引來redis,系統的可用率又得乘以一個redis的可用率。當然如果我們的業務場景必須使用redis,那麼也是完全可以的,但這裏切記系統的過度設計,也是設計複雜的系統,也需要更多的高可用相關的保證,所付出的資源代價和運維代價也是幾何增長。

2. 其次就是代碼質量。

其實這個可能是很多人忽略的一點,因爲很多人更喜歡高談闊論分佈式,集羣,壓測,故障演練等等,但在我看來,一個代碼開發質量的好壞,或者說一個程序員對代碼的掌控力,對系統可用性起到至關重要的作用。以下舉幾個代碼維度的例子。

第一個就是異常處理。一個代碼質量的好壞,要看他對異常處理能力,一個本科生的課程設計代碼,可能都是主業務邏輯,一條路寫到黑,不考慮任何異常情況,而一個畢業幾年的程序員,經歷過線上業務的拷打,可能會用在代碼裏找到很多的try-catch,用於捕捉各種不確定邏輯,而一個資深程序員,反而他的代碼裏你看不到任何try-catch, 因爲他全部用AOP的方式實現了異常的捕捉。這就是代碼維度的考量,一個優秀的代碼,一定是防禦式編程,同時還會配合單元測試等。

第二個講述一個什麼是對代碼的掌控力。在大廠裏,你更多場景是接手別人的老代碼。想必所有程序員都深有體會,接手別人的老代碼是一件極其痛苦的經歷,尤其是別人寫了一半的代碼。老話前人種樹後人乘涼,但在程序員圈,前人種樹,後人只能涼涼了..... 調侃歸調侃,但有些事情需要面對,前期你需要對業務場景和代碼邏輯進行抽絲剝繭的梳理,這個很重要。如果你無法對老代碼進行充分熟悉,那麼你就不敢去改寫和重構它,如果在不熟悉的前提下貿然修改代碼或者配置,然後上線,那麼很大機率會帶來線上系統問題,影響系統可用率。換一個角度來說,我們寫的代碼未來也可能交接給別人,如何不讓別人痛苦,也是我們的責任。所以合理使用設計模式,遵循代碼規範,書寫代碼架構和設計文檔,這些也是很重要的一點,他的重要可能會關乎系統未來的可用率。

對於代碼開發這塊,京東技術平臺也沉澱了一些自己的經驗。內部有自己的java代碼開發規範說明文檔,也在京英學習平臺上可以進行考試。而京東的coding平臺,可以在你代碼提交時,配置代碼開發規範掃描和代碼安全性掃描,同時,可以配置代碼評審人,這些都可以用來提升我們代碼質量。

部署時

1. 冗餘性和備份

在部署維度,我們首先考慮的是冗餘性和備份設計,這個可能是大家已經很熟悉的情況了,我們可以通過集羣的方式,多個服務器、磁盤或者網絡接口來減少故障點的數量。說到集羣,根據實現方式和目的不同,我幫大家梳理一下集中集羣類型:

(1)高可用集羣。

有多個獨立服務器組成的系統,旨在提高系統可用性,當主節點出現故障時,通過失敗轉移(Failover)讓備用節點自動接管服務。這個我們常見的有zookeeper集羣,etcd集羣等等,這類集羣是基於共識算法實現的, 通過選舉的方式,來保證當主節點故障時,可以有自動備份節點自動接管。

(2)負載均衡集羣。

在負載均衡系統中,流量被分散到多個服務器中,每個服務器都獨立地處理請求。當一個服務器負載過高或出現故障時,請求會自動被轉移到其他可用的服務器上,從而保證系統的可用性和性能。負載均衡可以在多個層面上實現,包括應用層、傳輸層和網絡層。在應用層負載均衡中,負載均衡器通常通過HTTP代理來分發請求,並根據請求的特定屬性(例如URL或Cookie)進行路由。在傳輸層負載均衡中,負載均衡器通常在傳輸層(例如TCP或UDP)上運行,並根據端口號或其他特定協議進行路由。在網絡層負載均衡中,負載均衡器通常是一個獨立的網絡設備,用於在不同的服務器之間分發網絡流量。

(3)數據庫集羣。

這裏的數據庫可以理解爲廣義數據庫,就是數據的存儲媒介。對於數據庫的的集羣實現方式,分爲如下幾個:主從複製,複製集,分區。

關於這幾種實現方案,這裏可以elasticsearch舉例說明。ES有分片和副本的概念,所謂的分片,就是將數據水平劃分到多個節點,每個節點存儲部分數據,當查詢數據時,需要在多個節點上進行查詢,最後將結果合併。分區可以實現數據的高可用性和可擴展性,但需要考慮數據一致性問題。

同時ES的每個分片都可以配置多個副本,副本跟主從複製類似,或者說更像一個集羣內的高可用子集,允許多個副本實例同時存在,並支持自動故障轉移和成員選舉,保證了數據的高可用性和負載均衡。

此外,對於集羣方案來說,還要額外考慮多機房部署問題,異地多活。換句話說,我所有服務實例,不能放在一個籃子裏,因爲網絡的抖動和不穩定性,對系統可用性來說是很大的威脅。

2. 發佈檢測

在部署維度,第二個關鍵點是發佈檢測。有統計數據表明,我們大部分的穩定性問題來源於系統變更,也就是系統的發佈上線。那麼如何保證一個平穩的系統上線呢?

首先,要完善自動化測試和單元測試,每次發版前,必迴歸測試,當然這塊如果交給人工來做,費時費力,不一定能起到他的效果,所有說,完善的自動化測試流程,對於系統穩定性部署來說,至關重要。

其次就是做好發佈的自動化,在發版過程中,減少人爲參與,這樣也就減少了出錯的可能性。京東的行雲部署本身就支持部署編排,利用部署編排,可以穩定且高效的實線滾動發版。同時也可以在行雲上的流水線中配置CI/CD流程,實現繼續集成和持續部署的串聯。

最後就是要實現發版的可觀測,可灰度,可回滾。發版前要有checklist,發版時採用灰度發佈驗證的方式,可以降低因爲發版引起的線上故障。最後如果發版發現失敗,可以實現快速的回滾操作。這個就要在發版前的checkList裏,做好回滾流程的備案。

運維時

在運維時,我們的目標是能夠快速止損線上問題,做到問題早發現,快定位,速解決。

1. 系統全鏈路觀測和監控

在互聯網系統中,從用戶請求開始,經過所有的系統組件或服務,直到響應返回給用戶,對整個系統的性能、穩定性和可用性進行全面觀測和監控的過程。這包括了對硬件、網絡、存儲、軟件等方面的觀測,監控。

在京東618備戰期間,所有應用系統都必須完成自建,完善UMP監控埋點,對核心接口方法的可用率,TP99,調用量進行實時監控,同時,也對需要對雲主機,中間件等資源維度,包括CPU,內存,資源佔有率進行實時監控。

此外,針對監控,要做好日誌監控做好採集工作,因爲日誌記錄了系統中各個組件或服務的運行狀態,可以提供豐富的信息用於問題排查和分析。

在京東內部採用logbook進行日誌採集,對於核心業務需要審計留存的,可以單獨搭建ELK,將歷史日誌存入ES中。

2. 值班與報警。

針對618備戰期間,需要額外安排固定人員進行每日值班,做到對線上問題可以及時反饋。

針對報警機制,有一點需要切記,要把握好報警的閾值問題,如果閾值偏低,會導致研發人員頻繁收到報警,導致警惕性降低。而如果閾值偏高,會錯過一些線上問題,導致問題沒有及時發現,致使故障擴大化。

3. 故障演練及應急機制。

京東內部有兩大利器,一個是ForceBot,一個是Chaos Monkey。

前者是做全鏈路軍演壓測用的,一般618大促前要進行三次軍演壓測,通過這些軍演,讓各個應用系統發現系統中的薄弱點,並針對性解決。forcebot是通過部署在全國各地的CDN節點,模擬真實用戶發起的大規模訪問流量,這種接近實戰的壓測,可以讓我們做到防患於未然,同時,通過壓測,可以針對性的優化服務資源,能夠更針對性的進行擴容。

第二個我們有時候會叫猴子搗亂測試,也會叫混沌測試。它能夠通過模擬包括網絡,中間件,流量等在內的各種故障,通過故障的隨機注入,來演練我們對系統故障的反應能力。

這裏就該提到所謂的應急機制。該機制就像一本類似醫院給發的急救指南手冊,需要在日常做到對各種不確定的故障進行反應能力。比如遇到突發高流量,系統出現了熔斷,如何快速擴容雲主機和各類中間件資源;比如網絡突然發生延遲,接口請求超時情況下,如何做好降級方案等等。

總結

本文寫於京東618備戰開門紅前夜值班之時。

以上的所有關於系統高可用的總結,都源於一次次的前人的實踐經驗總結出來的。每次備戰略細節有不同,但大的方向原則是不變的。

祝:京東618 大麥。

作者:京東物流 趙勇萍

來源:京東雲開發者社區

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章