電商平臺備戰促銷季的運維祕訣——高可用服務層

高可用設計是互聯網系統架構的基礎之一，以天貓雙十二交易數據爲例，支付寶峯值支付次數超過 8 萬筆。你們設想一下，若是這個時候系統出現不可用的狀況，那後果將不可想象。
而解決這個問題的根本就是服務層的高可用。

什麼是服務層

衆所周知，服務層主要用來處理網站業務邏輯的，是大型業務網站的核心。好比下面三個業務系統就是典型的服務層，提供基礎服務功能的聚合

• 用戶中心：主要負責用戶註冊、登陸、獲取用戶用戶信息功能
• 交易中心：主要包括正向訂單生成、逆向訂單、查詢、金額計算等功能
• 支付中心：主要包括訂單支付、收銀臺、對帳等功能

總體架構

業務發展初期主要以業務爲導向，通常採用 「ALL IN ONE」的架構方式來開發產品，這個階段用一句話歸納就是 「糙猛快」。當發展起來以後就會遇到下面這些問題

• 文件大：一個代碼文件出現超過 2000 行以上
• 耦合性嚴重：不相關業務都直接堆積在 Serivce 層中
• 維護代價高：人員離職後，根本沒有人瞭解裏面的業務邏輯
• 牽一髮動全身：改動少許業務邏輯，須要從新把全部依賴包打包併發布

遇到這些問題，主要仍是經過「拆」來解決

具體拆的方式，主要根據業務領域劃分單元，進行垂直拆分。拆分開來的好處很明顯，主要有如下這些：

• 每一個業務一個獨立的業務模塊
• 業務間徹底解耦
• 業務間互不影響
• 業務模塊獨立
• 單獨開發、上線、運維
• 效率高

無狀態設計

對於業務邏輯服務層，通常會設計成無狀態化的服務，無狀態化也就是服務模塊只處理業務邏輯，而無需關心業務請求的上下文信息。因此無狀態化的服務器之間是相互平等且獨立的。

只有服務變爲無狀態的時候，故障轉移纔會變的很輕鬆。一般故障轉移就是在某一個應用服務器不能服務用戶請求的時候，經過負責均衡的方式，轉移用戶請求到其餘應用服務器上來進行業務邏輯處理

超時設置

通常網站服務都會有主調服務和被調服務之分。超時設置就是主調服務在調用被調服務的時候，設置一個超時等待時間 Timeout。主調服務發現超時後，就進入超時處理流程。

1. 主調服務 A 調用被調服務 B 時，設置超時等待時間爲 3 秒，可能因爲 B 服務宕機、網絡狀況很差或程序 BUG 之類，致使 B 服務不能及時響應 A 服務的調用。
2. 此時 A 服務在等待 3 秒後，將觸發超時邏輯而再也不關心 B 服務的回覆狀況。
3. A 服務的超時邏輯能夠依據狀況而定，好比能夠採起重試，對另外一個對等的 B 服務去請求，或直接放棄結束這個請求調用。

超時設置的好處在於當某個服務不可用時，不至於整個系統發生雪崩反應。

異步調用

通常請求調用分爲同步與異步兩種。同步請求就像打電話，須要實時響應，而異步請求就像發送郵件同樣，不須要立刻回覆。

這兩種調用各有優劣，主要看面對哪一種業務場景。好比在面對併發性能要求比較高的場景，異步調用就比同步調用有比較大的優點，這就比如一我的不能同時打多個電話，可是能夠發送不少郵件。

那咱們何時該採用異步調用？

其實主要看業務場景，若是業務容許延遲處理，那就採用異步的方式處理

那咱們該怎麼實現異步調用呢？

一般採用隊列的方式來實現業務上的延遲處理，好比像訂單中心調用配送中心，這種場景下面，業務是能接受延遲處理的。

那消息隊列主要有哪些功能呢？

• 異步處理 - 增長吞吐量
• 削峯填谷 - 提升系統穩定性
• 系統解耦 - 業務邊界隔離
• 數據同步 - 最終一致性保證

那到底有多少種隊列呢？其實主要看處理業務的範圍大小

• 應用內部 - 採用線程池，好比 Java ThreadPool 中 BlockingQueue 來作任務級別的緩衝與處理
• 應用外部 - 好比 RabbitMQ 、ActiveMQ 就是作應用級別的隊列，方便進行業務邊界隔離與提升吞吐量

同時，技術上來說，消息隊列通常分爲兩種模型：Pull VS Push

• Pull 模型：消費者主動請求消息隊列，獲取隊列中的消息。
• Push 模型：消息隊列主動推送消息到消費者

其中 Pull 模式能夠控制消費速度，沒必要擔憂本身處理不了消息，只須要維護隊列中偏移量 Offset。因此對於消費量有限而且推送到隊列的生產者不均勻的狀況下，採用 Pull 模式比較合適。

Push 比較適合實時性要求比較高的狀況，只要生產者消息發送到消息隊列中，隊列就會主動 Push 消息到消費者，不過這種模式對消費者的能力要求就提升不少，若是出現隊列給消費者推送一些不能處理的消息，消費者出現 Exception 狀況下，就會再次入隊列，形成消費堵塞的狀況。

不過互聯網業界比較成熟的隊列主要以採用 Pull 模式爲主，像 Kafka、RabbitMQ（兩種方式都支持）、RocketMQ 等

冪等

什麼是冪等設計呢？

其實很簡單，就是一次請求和多個請求的做用是同樣的。用數學上的術語，便是 f(x) = f(f(x))。

那咱們爲何要作冪等性的設計呢？主要是由於如今的系統都是採用分佈式的方式設計系統，在分佈式系統中調用通常分爲 3 個狀態：成功、失敗、超時。

若是調用是成功或者失敗都沒關係，由於狀態是明確和清晰，可是若是出現超時的狀況，就不知道請求是成功仍是失敗的。

若是出現這種狀況，咱們該怎麼辦呢？通常採起重試的操做，從新請求對應接口。若是請求接口是 Get 操做的話，那到還好，由於請求屢次的效果是同樣的。可是若是是 Post 、Put 操做的話，就會形成數據不一致，甚至數據覆蓋等問題。

舉個例子：在支付收銀臺頁面進行支付的時候，由於網絡超時的問題致使支付失敗，這個時候咱們都會再進行一次支付操做，可是當支付成功後，發現你的帳戶餘額被減了 2 次，這個時候內心確定很不爽，內心都要開始罵娘了...

形成這個問題的關鍵是：網絡超時後，不知道支付是什麼狀態？成功仍是失敗呢？因此說冪等性設計是必須的，尤爲在電商、金融、銀行等對數據要求比較高的行業中。

通常在這種場景下咱們該怎麼解決呢？

1. 請求方通常會生產一個惟一性 ID 標識，這個標識能夠具備業務同樣，好比訂單號或者支付流水號，在發起請求時候帶上惟一性 ID。
2. 接收者在收到請求後，第一步經過獲取惟一性 ID 來查詢接收端是否有對應的記錄，若是有的話，就直接將上次請求的結果返回，若是沒有的話，就進行操做，並在操做完成後記錄到對應的表裏

服務降級

服務降級主要解決資源不足和訪問量過大的問題，好比電商平臺在雙11、618 等高峯時候採用部分服務不提供訪問，減小對系統的影響。

那降級的方式有哪些呢？

• 延遲服務：好比春晚，微信發紅包就出現搶到紅包，可是帳號餘額並無增長，要過幾天才能加上去。其實這是微信內部採用延遲服務的方式來保證服務的穩定，經過隊列實現記錄流水帳單
• 功能降級：中止不重要的功能是很是有用的方式，把相對不重要的功能暫停掉，讓系統釋放更多的資源。好比關閉相關文章的推薦、用戶的評論功能等等，等高峯過去以後，在把服務恢復回來。
• 下降數據一致性：在大促的時候，咱們發現頁面上不顯示真實庫存的數據，只顯示到底有仍是沒有庫存這兩種狀態。

剛剛說了降級的方式，那咱們操做降級的時候有哪些注意點呢？

1. 清晰定義降級級別： 好比出現吞吐量超過 X，單位時間內響應時間超過 Y 秒、失敗次數超過 Z 次等，這些閾值須要在準備的時候，經過壓測的方式來肯定。
2. 梳理業務級別：降級以前，首先須要肯定哪些業務是必須有，哪些業務是能夠有的，哪些業務是無關緊要的。
3. 降級開關：能夠經過接入配置中心（好比攜程 Apollo、百度 Disconf ）的方式直接後臺降級。可是若是公司沒有配置中心的話，能夠封裝一個 API 接口來切分，不過該 API 接口要作成冪等的方式，同時須要作一些簡單的簽名，來保證其必定的安全性。

總結

總結一下今天分享的主要內容

• 總體架構：根據業務屬性進行垂直拆分，減小項目依賴，單獨開發、上線、運維
• 無狀態設計：應用服務中不能保存用戶狀態數據，若是有狀態就會出現難以擴容、單點等問題
• 超時設置：當某個服務不可用時，不至於整個系統發生連鎖反應
• 異步調用：同步調用改爲異步調用，解決遠程調用故障或調用超時對系統的影響
• 服務降級：犧牲非核心業務，保證核心業務的高可用

全部好的架構設計首要的原則並非追求先進，而是合理性，要與公司的業務規模和發展趨勢相匹配，任何一個公司，哪怕是如今看來規模很是大的公司，好比 BAT 之類，在一開始，其系統架構也應簡單和清晰的。

但隨着業務範圍不斷擴充，業務規模不斷擴大，系統漸進複雜和龐大，讓全部系統都遇到高可用的問題。那咱們該如何避免相似的問題，構建高可用系統呢？

爲此我特地寫了一個專欄《帶你玩轉高可用》，將多年來在百度和滬江的架構設計實戰經驗，集結成這個專欄。

本專欄總共包含 15 篇文章，分紅三大模塊詳細解釋高可用架構的相關知識：

• 概念篇：介紹高可用架構理論與演進，這塊比較偏理論。不過對於咱們理解整套體系仍是有必須的。
• 工程篇：介紹常見互聯網分層中每一層高可用是怎麼作的，包含 DNS、服務層、緩存層、數據層等
• 問題篇：介紹怎麼排查線上經常使用的故障，包括機器、應用層等維度故障定位

專欄每週都會更新，持續 64 天。在這將近 2 個月內，我會帶着你們去全面瞭解高可用架構的方方面面，同時會將遇到的這些問題和對應的解決方案拋出來，但願你們不要重複我遇到過的坑。同時也期待你們提出有意思的問題。

專欄地址：帶你玩轉高可用