億級流量架構之服務器擴容思路及問題分析

爲什麼要擴容

說人話就是, 無論如何優化性能, 能達到的最大值是一定的, 對於一個用戶量大的應用, 可以對服務器進行各種優化, 諸如‍限流‍、資源隔離, 但是上限還是在那裏, 這時候就應該改變我們的硬件, 例如使用更強的 CPU、更大的內存, 在前文中舉了一個學生食堂打飯的例子, 如果學生多了, 可以通過令牌桶算法優先給高三學生令牌打飯, 但是如果高三的學生還是很多呢? 那就只有增加窗口或者食堂的數量, 也就是硬件上的擴容。

擴容策略

擴容策略可以分爲兩種, 一種是對單機整體擴容, 也就是機器內部包含 CPU、內存、存儲設備等, 另一種是擴容對應的組件, 例如擴內存、擴磁盤、擴 CPU。

整機硬件

整機擴容的好處是, 有很多專業的服務器硬件供應商, 例如 IBM、浪潮、DELL、HP 等, 專業的硬件供應商, 他們組裝以及搭配方面可能經驗更加豐富, 另外有些公司會對組件進行一些優化, 從而服務器更加穩定, 可以類比爲買電腦, 有的人可能選擇買淘寶賣家已經組裝好的臺式, 有的人可能自己買各種硬件自己回家組裝, 對於一般人而言, 選擇前者是較爲靠譜的選擇, 因爲你即使懂硬件的一些參數, 也難保自己搭配的機器是否能發揮各個部件最大性能。

組件

對於一些技術能力強悍的公司, 更多的是自己買各種組件組裝, 這樣成本更低, 因爲節省了組裝等費用, 並且可以根據業務個性化定製, 例如有的公司是計算密集型的, 那麼主要是更換更強的 CPU, 有的 IO 密集型, 那麼擴容的應該是內存等, 有的公司需要存儲大量的數據, 那麼可能擴容的是硬盤等存儲設備。

組件包含:

cpu

Intel、Amd , 參考頻率、線程數等

網卡

百兆 -> 千兆 -> 萬兆

內存

ECC 校驗

磁盤

SCSI HDD（機械）、HHD（混合）、SATA SSD、PCI-e SSD、 MVMe SSD

AKF 拆分原則

在 Redis 集羣拆分原則之 AKF 中, 詳細介紹了 AKF 拆分原則的詳情, 這兒簡單回顧一下:

對於一個應用, 如果單機不足以支撐服務請求, 那麼可以建立諸如主主、主從等模式的集羣:

這個叫 AKF 原則 X 軸擴展, 目的是將請求分流在多臺機器上, 但是多臺機器中間要解決數據同步性的問題, 越多的機器數據不同步的可能性越大, 這也就意味着沒法無限整體複製擴容。所以可以整理蒐集服務器內熱點的業務請求, 將業務分離出來, 只對熱點業務進行擴容, 這就是 AKF 原則的 Y 軸拆分:

對業務拆分之後, 某個業務還可能太熱點, 也就是 Y 軸拆分後水平復制還是不足以支撐數據請求, 那麼可以將業務的數據進行拆分, 具體來說就是, 某個業務的數據, 可以放在多個地方, 例如在湖北、北京、上海部署機房, 各地的人們需要請求數據時, 由離得近的服務器提供服務。

拆分擴容後存在的問題

隨着業務的增長，系統變得越來越龐大, 根據系統功能拆分成獨立而又互通的項目, 比如交易系統、財務系統、生產流程系統、物流系統、網站系統等等, 但是分佈式結構會存在很多問題。對於這些問題每一個都值得深入探討, 這兒簡單的提一下, 後面再開篇幅。

  1. 數據共享問題
    所有的服務之間數據如何共享同步, 這是一個需要考慮的問題, 微服務架構中, 數據不可能只有一份, 沒法避免機器損壞等原因造成的數據丟失, 多份數據之間如何同步? 目前可供參考的解決思路是建立數據中心、搭建數據庫集羣。

  2. 接口調用問題
    不同的服務器之間進行調用遵循遠程調用協議 RPC

    JAVA RMI：Java 遠程方法調用，即 Java RMI（Java Remote Method Invocation）是 Java 編程語言裏，一種用於實現遠程過程調用的應用程序編程接口。它使客戶機上運行的程序可以調用遠程服務器上的對象。

    dubbo: 提供了面向接口代理的高性能 RPC 調用

  3. 持久化數據雪崩問題
    數據庫分庫分表, 參考: MySQL 調優之分區表。
    資源隔離, 參考: 億級流量架構之資源隔離思路與方法。
    緩存設定數據持久化策略: Redis 持久化之 RDB 和 AOF。

  4. 高併發問題

    緩存: 諸如緩存擊穿、穿透、雪崩等, 參考 Redis 擊穿、穿透、雪崩產生原因以及解決思路。

    數據閉環: 爲了便於理解, 舉個例子, 對於淘寶而言, 有網頁版、IOS 版、安卓版、還有什麼一淘等等, 雖然客戶端不一樣, 但是展示的商品信息是相同的, 也就是一件商品, 無論是哪個端用的數據是一樣的, 需要一套方案來解決併發下根據相同數據在不同端進行不同展示的問題, 這就叫數據閉環。

  5. 數據一致性問題

    這是一個難點, 大意就是多個服務器之間數據如何保證一致性, 同樣的商品在不同客戶端服務端端價格應該是一樣的, 通常使用分佈式鎖。

數據庫擴容: 集羣

先簡單說一下分佈式與集羣的區別, 這兩個詞兒經常一起出現, 但是意義卻有所不同, 分佈式會縮短單個任務的執行時間來提升工作效率，而集羣強調的是提高單位時間內執行操作數的增加來提高效率。更簡單的來說，分佈式是將步驟分到每臺電腦上，不考慮依賴關係，集羣方案是指幾個任務同時在處理。

單一數據庫存儲難以滿足業務需求時, 採取集羣的方式, 將數據存儲在不同的服務器, 這可以是主主或者主從, 主從中主負責寫, 從負責讀, 將與數據庫有關的壓力進行分解到多臺機器上。

分佈式 ID

在複雜分佈式系統中，往往需要對大量的數據和消息進行唯一標識。很容易想到的是利用自增, 但是自增有很多問題，例如 ID 有太強的規律, 可能會被惡意查詢蒐集, 面對數據日漸增長，對數據分庫分表後需要有一個唯一 ID 來標識一條數據或消息，這樣數據庫的自增 ID 顯然不能滿足需求；特別一點的如商品、訂單、用戶也都需要有唯一 ID 做標識。此時一個能夠生成全局唯一 ID 的系統是非常必要的。概括下來，那業務系統對 ID 號的要求有哪些呢？

分佈式 ID 要求

面對分佈式 ID, 需要滿足下面的要求:

  1. 全局唯一性：不能出現重複的 ID 號，既然是唯一標識，這是最基本的要求。

  2. 趨勢遞增：在 MySQL InnoDB 引擎中使用的是聚集索引，由於多數 RDBMS 使用 B-tree 的數據結構來存儲索引數據，在主鍵的選擇上面我們應該儘量使用有序的主鍵保證寫入性能。

  3. 單調遞增：保證下一個 ID 一定大於上一個 ID，例如事務版本號、IM 增量消息、排序等特殊需求。

  4. 信息安全：如果 ID 是連續的，惡意用戶的扒取工作就非常容易做了，直接按照順序下載指定 URL 即可；如果是訂單號就更危險了，競對可以直接知道我們一天的單量。所以在一些應用場景下，會需要 ID 無規則、不規則。

上述 123 對應三類不同的場景，但是 3 和 4 的需求是互斥的，也就是無法使用同一個方案滿足。除了對 ID 號碼自身的要求，業務還對 ID 號生成系統的可用性要求極高，想象一下，如果 ID 生成系統癱瘓，整個與數據有關的動作都無法執行，會帶來一場災難。由此總結下一個 ID 生成系統最少應該做到如下幾點：

  1. 平均延遲和 TP999 延遲都要儘可能低；

  2. 可用性 5 個 9(這是美團的要求, 有些企業例如阿里要求 6 個 9)；

  3. 高 QPS。

分佈式 ID 生成策略

目前業界常用的 ID 生成策略有很多, 例如 UUID、雪花生成算法、Redis、Zookeeper 等, 這兒只簡單講講 UUID 以及 Snowflake，後面要開篇詳談。

UUID 生成算法

UUID(Universally Unique Identifier) 的標準型式包含 32 個 16 進制數字，以連字號分爲五段，形式爲 8-4-4-4-12 的 36 個字符，示例：550e8400-e29b-41d4-a716-446655440000，到目前爲止業界一共有 5 種方式生成 UUID，詳情見 IETF 發佈的 UUID 規範 A Universally Unique IDentifier (UUID) URN Namespace。

優點：

缺點：

② 對 MySQL 索引不利：如果作爲數據庫主鍵，在 InnoDB 引擎下，UUID 的無序性可能會引起數據位置頻繁變 動，嚴重影響性能。

雪花生成算法

這種方案大致來說是一種以劃分命名空間（UUID 也算，由於比較常見，所以單獨分析）來生成 ID 的一種算法，這種方案把 64-bit 分別劃分成多段，分開來標示機器、時間等，比如在 snowflake 中的 64-bit 分別表示如下圖（圖片來自網絡）所示：

41-bit 的時間可以表示（1L<<41）/(1000L_3600_24*365)=69 年的時間，10-bit 機器可以分別表示 1024 臺機器。如果我們對 IDC 劃分有需求，還可以將 10-bit 分 5-bit 給 IDC，分 5-bit 給工作機器。這樣就可以表示 32 個 IDC，每個 IDC 下可以有 32 臺機器，可以根據自身需求定義。12 個自增序列號可以表示 212212 個 ID，理論上 snowflake 方案的 QPS 約爲 409.6w/s，這種分配方式可以保證在任何一個 IDC 的任何一臺機器在任意毫秒內生成的 ID 都是不同的。

這種方式的優缺點是：

優點：

缺點：

彈性擴容

說人話, 就是讓集羣根據計劃在某一段時間自動對資源進行擴容，並在設置的計劃還原時間時釋放資源。這樣能解決規律性的資源峯谷需求，達到充分合理利用資源的目的。
但是彈性擴容有一些問題:

第一，虛擬機彈性能力較弱。使用虛擬機部署業務，在彈性擴容時，需要經過申請虛擬機、創建和部署虛擬機、配置業務環境、啓動業務實例這幾個步驟。前面的幾個步驟屬於私有云平臺，後面的步驟屬於業務工程師。一次擴容需要多部門配合完成，擴容時間以小時計，過程難以實現自動化。如果可以實現自動化 “一鍵快速擴容”，將極大地提高業務彈性效率，釋放更多的人力，同時也消除了人工操作導致事故的隱患。

第二，IT 成本高。由於虛擬機彈性能力較弱，業務部門爲了應對流量高峯和突發流量，普遍採用預留大量機器和服務實例的做法。即先部署好大量的虛擬機或物理機，按照業務高峯時所需資源做預留，一般是非高峯時段資源需求的兩倍。資源預留的辦法帶來非常高的 IT 成本，在非高峯時段，這些機器資源處於空閒狀態，也是巨大的浪費。

出處：https://www.cnblogs.com/Courage129/p/14425669.html

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/I0TeBsb6LeAnWhC81RqCHg

猜你喜歡