1. 程式人生 > >高併發實時後臺服務技術架構雜談

高併發實時後臺服務技術架構雜談

高併發實時後臺服務設計雜談

摘要:不管是雙十一剁手節還是新年微信紅包,此時此刻都離不開一個可靠和穩定後臺服務,針對高併發(每秒上萬的QPS),低延遲(毫秒級應答)的業務場景,後臺架構的設計對業務的成敗以及使用者體驗起到了至關重要的作用。根據No Silver Bullet理論,在軟體工程裡是沒有萬能的終極武器,只有將各種方法綜合運用才是王道。本文根據作者的經驗總結一些可參考的實時高併發後臺架構解決方案。

流控

後臺服務可以支撐的最大併發量,雖然理論上可以通過新增節點(機器)的方法橫向擴充套件,即擴容,但考慮到成本通常後臺服務都會存在一個預估的能力上限。開發和運維同學會根據業務預估的請求量和後臺單個節點可以支撐的最大併發量來計算可能需要部署的後臺節點數量。其中,單個後臺節點的處理能力可以通過壓測得到。這裡可能埋藏了一個隱患,因為人的預估都是不準確的,如果不幸後臺服務的最大支撐能力低於了實際使用者的請求量,那麼對後臺系統造成的影響可能就如同DDOS攻擊,嚴重的話整個後臺服務都會出現不可用,那麼對使用者和業務都是不可接受的。

因此,後臺服務首先要把自家大門累紮實,方法就是流控。根據業務場景定製合理的流控策略。比如,60秒內相同的使用者只能訪問5次,否則在最前端直接拒絕,減少對後臺更底層系統的不必要的壓力,從而防止後臺服務的過載。舉個現實中的例子,每逢過年都要在12306上刷火車票,使用者輸入驗證碼的策略除了起到安全鑑權的作用,也是對使用者請求的一種流控。工程中的具體策略有:在入口層新增一層Nginx或者OpenResty閘道器,然後針對請求執行一些最基礎的限流操作,比如,當前支援的最大連線數,超出則返回50x錯誤,由前端根據錯誤碼給用一個友好的提示,請使用者稍後再試。

負載均衡

閘道器層除了流控功能外,還有一個重要的Balance Load的作用。就是將大量使用者的請求通過負載均衡策略(WRR/SP)合理地分發給後端節點。比如,後端有3個節點,通過對每個節點分配不同的權重,每個節點會分發不同的流量,一些高配置的節點可以多處理一些請求。

接入層

通過閘道器層執行一些基礎的流控策略,然後再由閘道器層將請求轉發給後端的接入層。通常接入層由Web服務(比如Apache)的CGI實現,接入層主要實現一些業務層面的基本校驗功能,比如,登入態校驗。從而又可以過濾大部分非法請求,為真正合法的使用者請求留出珍貴有限的後臺資源。通常接入層都是無狀態的,因此可以橫向擴充套件。

邏輯層

根據“前輕後重”的原則,接入層一般只執行一些輕量的業務邏輯,真正核心的業務邏輯放在邏輯層來實現。邏輯層通常由RPC服務來提供和實現,接入層通過邏輯層提供的標準協議(HTTP/PB/MSGPACK等)和RPC呼叫介面來完成通訊。其中,RPC呼叫介面也會提供BL的功能,不需要接入層關心後端的容災切換問題。因為邏輯層是真正核心處理的模組,它的處理能力決定了整個服務的質量,因此邏輯層的設計非常重要。下面羅列一些可以優化整個服務的設計原則:

縮短關鍵業務流程

同步介面數量越多服務一定越差,因為每個介面都會產生時耗,那麼整筆請求的處理時耗也會相應增加。一些不重要但又不能不做的介面可以設計為單獨的流程來處理。比如,使用者搶紅包成功了,紅包有可能並沒有立刻到賬,但是為了不影響使用者體驗,前端會提示使用者紅包可能有延遲到賬等資訊,但不管怎麼樣紅包已經搶到了不影響結果,後臺服務可以通過訊息佇列慢慢(在合理的時間內)處理,使用者也可以接受。

降低單個介面處理時耗

關鍵流程的介面數量已經不能減少了,那麼這時就要優化單個介面的處理時耗。這裡需要根據情況來綜合考慮,有可能是程式碼的問題(比如,系統呼叫太多),也有可能是架構問題(比如,可以通過快取來優化),或者可能是系統部署的問題(比如,沒有就近訪問,跨城訪問從深圳訪問上海)。

同步變非同步

當關鍵流程的介面數量和單個介面的處理時耗都確定後,剩下就是要把同步介面換成非同步介面,這個做法不會降低單筆處理時耗,但是可以保證整個服務吞吐量,不會因為突然某個接口出現異常導致整個服務堵塞。用現實中的例子舉例就是,一條道的公路可能因為某輛汽車出現故障導致後面的汽車也無法通過,而五條道的公路即使一條道出現擁堵也不影響其他道的車輛行駛。工程中的實現方法是:I/O多路複用。

隔離

因為邏輯層可能涉及的業務錯綜複雜,很可能某個業務自己沒做好影響了整體的服務質量,因此邏輯層也要具備業務隔離的能力。工程中實現的方法有:整體隔離,接入層根據業務來進行分發處理;內部隔離,邏輯層為每個業務分配的資源可配置。

儲存層

儲存層主要解決的是資料快速訪問,大資料量如何儲存,以及資料一致性安全問題。對應的解決方案分別是快取,分庫分表,資料如何同步備份。很多大公司都提供了自己的一套解決方案,然後放在雲上售賣,具體的設計可以參考相關的官網說明。

總結

主要根據系統分層設計闡述每一層在高併發設計上的一些考慮點。