來源 | 機智的程序員小熊

責編 | 寇雪芹

頭圖 | 下載于視覺中國

事故的發生是量的積累的結果，任何事情都沒有表面看起來那么簡單，在軟件運行的過程中，隨著用戶量的增加，不考慮高可用，遲早有一天會發生故障，不得事先考慮高可用設計，而高可用是一門龐大的學問。

在設計一個高可用系統要考慮哪些內容？

• 考慮方案選型會帶來哪些坑，最差的情況下需要考慮故障發生的緊急解決方案

• 需要監控系統，在故障發生時、發生時有所感知

• 需要自動化恢復方案，自動化提前處理預警方案

• 在代碼層面需要考慮處理速度、代碼性能、報錯處理

• 還要考慮把故障降低到最小：服務降級、限流、熔斷

• 其他

這篇文章主要介紹無狀態服務在架構層面，如何保證可高用。

無狀態服務的高可用旨在任何情況下數據都不丟失，服務都不發生故障，在某些服務發生故障時保證影響最小，并可以快速恢復。

可以從這幾個方面考慮：

• 冗余部署：至少多部署一個節點，避免單點問題

• 垂直擴展：增加單機性能

• 水平擴展：流量激增可快速擴容

? 冗余部署

在單點架構中，隨著數據數據量增加，單點負載壓力過大，容易產生服務崩潰不可用的情形，對于無狀態服務，可以考慮部署多個節點的服務來分散壓力。

對于如何調度來臨的請求，可以參考負載均衡的方式，盡可能的保證充分的利用服務器的資源。

• 無狀態服務：不需要存儲數據的服務，即使節點掛掉再重啟，不會發生數據丟失

• 負載均衡：把大量請求分散到不同節點上的一種算法

? 無狀態服務的負載均衡

可以使用負載均衡中提供的幾種算法：

• 隨機均衡算法：已知后端服務器列表，隨機請求，數據量越大越趨近于均衡

• 輪詢算法：輪流請求后端服務器

前兩種算法存在的問題是后端服務器在負載壓力不同或服務器配置不同時，不能保證壓力小的多分配，壓力大的小分配，于是引入。

• 加權輪循算法：按照后端服務器的抗壓能力，負載情況分配更高的權重，更容易命中，減少宕機風險，按權重順序的分配到后端服務器上

• 加權隨機法：和加權輪訓算法一樣，不同的是分配是按權重隨機的，比如有多臺權重一致的情況，隨機訪問，那就和隨機算法有同樣的問題，數據量大時才趨近于均衡，數據量小時有可能重復訪問同一臺權重一致的機器

• [加權]最小連接數算法：這是最智能的一種算法，根據服務器當前的連接數來選取，更容易命中處理速度快的服務器

上面的算法使用于無狀態應用，假如要保存通信狀態，需要使用

• 源地址哈希算法：對源地址做hash，可以保證相同的請求最終都是落在同一臺機器上，不需要重復建立連接

? 負載均衡算法如何選擇？

首先拋棄隨機算法，最簡單的配置可以使用基本的輪訓算法，它適用于服務器配置一致，比如使用虛擬機，可以動態調整服務器配置的場景，同時要保證專用虛擬機，上面不會部署其他應用的情況。

但是服務器上往往會安裝多個應用，那就要考慮在加權輪訓和最小連接數中做選擇。

加權輪訓適用于短連接場景，比如HTTP服務，在k8s中因為每個pod都是獨立的，默認service策略是非加權輪訓。

• 最小連接數適用于長連接，比如FTP等

如果系統架構中考慮到無cookie功能的場景，可以用源地址hash算法，把源IP一直映射到同一臺rs上，在k8s中叫會話保持模式，每次轉發到同一個pod上。

建議：

• 如果上了容器直接交給k8s來做調度，使用cookie做會話保持，算法使用默認輪訓，具體調度未來k8s文章里會做詳細介紹

• 使用長連接的應用（FTP、socket，或者用于下載連接），選擇加權最小連接數

• 短連接應用（靜態網站、微服務組件等），選擇加權輪訓，用cookie來做會話保持，減少session的設計，不僅會提高代碼復雜度，也會增加服務端負載情況，不利于分布式應用

? 高并發應用的識別

主要指標QPS每秒處理響應數，比如每天有10w的pv

公式?(100000?*?80%)?/?(86400*20%)?=?4.62?QPS（峰值QPS）

公式原理：每天80%的訪問集中在20%的時間里，這20%時間叫做峰值時間。

比如我做的系統托管了最高5w臺機器，每臺機器每次分鐘有一次PV，時間比較均勻那就是：

((60*24)*50000)/(86400)=833?QPS

一般上百的量級就可以叫高并發了，網上查到的資料微博每天1億多pv的系統一般也就1500QPS，5000QPS峰值。

除了QPS還有服務響應時間、并發用戶數指標可以參考。在服務器負載高的時候，表現在處理速度變慢、網絡斷連、服務處理失敗、異常報錯等問題，具體問題要具體分析，不可一概而論。

可以通過監控，來獲得服務器性能狀態，動態調整、重試，達到服務可用性的保證，減少維護成本，通常單純服務器壓力大的時候可以考慮垂直擴展。

? 垂直擴展

垂直擴展是增加服務器單機的處理能力，主要有三種方式

• 服務器升配：集中在CPU、內存、swap、磁盤容量或者網卡等

• 硬件性能：磁盤SSD、調整系統參數等

• 架構調整：軟件層面使用異步、緩存、無鎖結構等

增強單機性能的方式是最快最容易的方式，但是單機性能之中是存在極限，同時單機部署時如果產生故障，對應用來說打擊是致命的，我們應該保證應用時刻處于可用的狀態，也就是俗話說的保證5個9的可靠性。

? 水平自動伸縮

知道了單機的局限以后，考慮使用水平伸縮的方式。

水平伸縮就是壓力增加的時候，增加新的節點來分擔壓力，但僅僅多點部署還是不夠的，對于持續增長的業務，始終有一天會突破服務的壓力上限，如果遇到流量激增的場景，人工應對肯定會措手不及，所以需要一種自動伸縮的手段。

• 對于私有云部署來說可以手動實現調度器，檢測系統狀態，連通iaas層實現伸縮

• 也可以直接使用云服務器提供的彈性伸縮服務

• 對于容器而言，可以在iaas層彈性伸縮的情況下或者有充足node節點的情況下，配置自動伸縮和調度的策略，預防單機故障

注意：彈性伸縮針對的業務場景是無狀態服務

另外無狀態機器不足以承載請求流量，需要進行水平擴展的閾值一般QPS是千級，同時在這里對數據庫也會有壓力，所以建議水平伸縮的服務器不要部署有狀態服務。

對于有狀態服務壓力分散在后續的文章會有所介紹。

? CDN和OSS

對于一個網站來說，用戶交互頁面，是一個特殊的服務，包含很多靜態資源，比如圖片、視頻、頁面（html/css/js），這些資源在用戶請求的時候需要現場下載，下載速度決定了加載速度，在web服務故障的時候，同樣應該對用戶做出響應。

在這一層面可以考慮使用CDN內容分發網絡的方式，詳見[xxx]，把前端靜態數據緩存到邊緣服務器上。（邊緣服務器（邊緣節點），可以理解為和用戶交互的服務器，也可理解為靠近用戶的服務器節點，因為靠近用戶，減少了網絡傳輸使用的時間）

使用了CDN的web服務，可以把https證書綁定到cdn上，在回源策略可以配置回源超時、回源跟隨301/302狀態碼等配置，還可以智能壓縮網頁、自定義錯誤頁面，非常方便。

oss是一種特殊的存儲方案，以對象的形式進行存儲，理論上可以存儲無限的文件。考慮使用oss對象存儲并結合cdn，把媒體資源存儲在對象存儲上面，也可以把冷數據壓縮歸檔到oss上。常見的視頻網站大多會用到oss，微博n年以前的數據應該就是歸檔到對象存儲中了。

? 總結

本文介紹的無狀態服務常見的高可用架構設計，他們是

• 冗余部署

• 負載均衡的6種算法與算法選擇

• 垂直擴展的好處與弊端

• 水平擴展與水平自動伸縮

• 哪些服務可以使用CDN和OSS

要注意無狀態應用不應該存儲session，也不存儲數據。

本文對負載均衡的6種算法做了介紹，但是沒有介紹每個算法具體的實現方式，這個留給你下來研究，這些方案在實際使用的時候會有一定難度，服務不可用的故障原因任何一門都是博大精深的學問，程序員不僅是寫代碼。

這里也僅僅寫了無狀態服務的部分高可用方案，不管是什么服務還是從代碼層級的設計，你還知道哪些呢？有時候比較苛刻的情況下，沒有更多的服務器資源，如何在有限服務器的情況下提高更多的代碼性能呢？歡迎來評論區討論~

60+專家，13個技術領域，CSDN?《IT 人才成長路線圖》重磅來襲！

直接掃碼或微信搜索「CSDN」公眾號，后臺回復關鍵詞「路線圖」，即可獲取完整路線圖！

更多精彩推薦 ?5G、射頻、奧特曼，這仨有聯系嗎？?再見 Nacos，我要玩 Service Mesh 了！?用根因定位法，讓運維效率再高一點！點分享點收藏點點贊點在看

總結

以上是生活随笔為你收集整理的干货！一文搞懂无状态服务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。