在技術選型時，我們往往會仔細考量各項成本，尤其關注實現成本，這種“斤斤計較”其實能帶來直接的經濟效益。那么，你是否有系統地思考過如何計算這些成本呢？本節課將通過一個日志中心的例子，帶領你逐步進行成本計算。

之所以選擇日志中心，主要有兩點考慮：

1. 重要且通用：日志中心作為系統監控的核心組件，幾乎所有系統的監控和故障排查都依賴它。因此，大部分系統中都能用到日志中心。
2. 高成本、計算復雜：日志中心是一個成本較高的項目，計算方式相對復雜。如果你能掌握課程中的這個例子，日后就能運用類似的思路去計算其他組件的成本，變得更加得心應手。

根據流量推算存儲容量及投入成本

在互聯網服務中，最大的變量就是用戶流量。相比普通服務，高并發系統需要同時處理更多的在線用戶，因此在設計這類系統的容量時，需要根據用戶請求量和同時在線人數來推算系統硬件投入的成本。

很多系統在初期會采用云服務來構建日志中心。然而當核心接口流量超過10萬 QPS后，許多公司就會考慮自建機房，甚至后期會持續改進日志中心，開發一些個性化的服務。實際上，這些優化和實現的核心目的都與成本息息相關。為了讓這個概念更加直觀，我們來通過一個實際例子，計算一個高并發網站的日志中心所需的存儲容量和成本。

假設一個高并發網站在流量高峰期，其核心 API 的 QPS 約為 30 萬，我們按每天 8 小時計算，并假設每次核心接口請求會產生 1KB 的日志。由此可以計算出該網站每天的請求量和日志數據量：

• 每日請求量
  每天請求量 =3600 秒 X 8 小時 X 300000 QPS = 8 640 000 000 次請求 / 天 = 86 億次請求 / 天
• 每日日志數據量
  每天日志數據量：8 640 000 000 X 1KB => 8.6TB/ 天

你可能會疑惑，為什么這里按每天 8 小時計算？這是因為大多數網站的用戶訪問量都有一定規律性，有些網站流量集中在上下班時間和夜晚，有些則在工作時間。結合一般用戶的日常習慣和每天約8小時的專注時間，按8小時計算會相對合理。當然這個時間只是一個參考，不同業務的訪問高峰可能不同，實際情況可以根據網站用戶習慣進行調整。

回到剛才的計算，我們看到，如果每次請求產生 1KB 的日志，每天將會有約 8.6TB 的日志數據需要處理、傳輸、整理、計算和存儲。

為了方便問題追溯，我們還需設定日志的保存周期。假設日志保留30天，那么一個月的日志量將達到：

8.6TB X 30 天 = 258 TB /30 天

通過以上計算可以看出，一個高并發網站的日志存儲需求十分龐大。這種分析思路不僅適用于日志中心，還可以作為其他組件容量與成本計算的參考。

從容量算硬盤的投入

在計算出日志量后，我們就可以進一步估算購買硬件所需的成本。不過需要提前說明的是，硬件價格是動態變化的，且不同商家的定價會有所差異，因此具體成本可能會有差異。這次我們主要關注計算思路，學會后你可以根據實際情況來調整。

目前，常見的服務器硬盤規格為8TB、7200轉、3.5寸，單價約為2300元?？紤]到實際可用容量，8TB硬盤的實際可用存儲空間約為7.3TB。結合之前的每月日志量，可以計算出所需的硬盤數量，計算公式如下：

258 TB/7.3 TB = 35.34 塊

由于硬盤數量必須是整數，所以需要36塊硬盤。然后將數量與單價相乘，就得出硬件的總成本：

2300 元 X 36 = 82800 元

為了確保數據安全并增強查詢性能，我們通常會使用分布式存儲，將數據存儲三份。這樣一來，在分布式存儲方案下，至少需要108塊硬盤。此時的投入成本為：

82800 X 3 個數據副本 = 24.8W 元

如果還要保證數據的可用性，我們可以選擇 RAID 5 陣列。RAID 5 會將多個硬盤組成一個陣列，其中部分硬盤提供完整存儲容量，另外一部分硬盤則用于校驗和冗余。雖然具體的 RAID 配比有多種方案，但為了簡化計算，我們選擇以下配置：每四塊硬盤組成一組，其中三塊提供完整容量，一塊用于校驗。

在 RAID 5 模式下，容量計算公式為：

單組 raid5 容量 =((n-1)/n) * 總磁盤容量，其中 n 為硬盤數

其中nn 為硬盤數量。將4塊硬盤代入公式：

108 / 3 = 36 塊校驗盤

這表明，一組RAID 5由四塊硬盤組成，其中三塊提供完整的存儲容量。由此可以計算出，為了滿足存儲需求，我們需要在108塊硬盤的基礎上增加四分之一的容量來存放校驗數據，即：

108 / 3 = 36 塊校驗盤

因此，最終需要的硬盤數量為：

最終需要的硬盤數量就是 108 塊 + 36 塊 Raid5 校驗硬盤 = 144 塊硬盤，每塊硬盤 2300 元，總成本是：

每塊硬盤的價格為2300元，因此總成本為：

144 X 2300 元 = 331200 元

為了方便計算，我們可以取整按33萬元來計算。

除了確?？捎眯酝?，還需考慮硬盤的壽命。由于硬盤是易損設備，一般在連續工作兩到三年后會陸續出現損壞情況。為應對硬盤損壞和補貨緩慢等問題，通常會預備大約總數三分之一的硬盤作為備件。也就是說，需常備40塊硬盤用于故障替換，維護成本約為：

2300 元 X 40 = 92000 元

綜上，至少需投入的硬件成本為一次性硬盤采購費用加上維護費用，即：

33+9.2=42 萬元

根據硬盤推算服務器投入

接下來，我們需要計算服務器的相關成本。服務器有多種規格，不同規格可以插入的硬盤數量也不同，具體如下：

• 普通 1U 服務器：可插 4 個 3.5 寸硬盤，或 2 個 SSD 硬盤
• 普通 2U 服務器：可插 12 個 3.5 寸硬盤，或 6 個 SSD 硬盤

在上一步中，我們已經計算出做 RAID 5 的情況下需要 144 塊硬盤。若采用 2U 服務器，則需要的服務器數量為：

144 塊硬盤12 塊/臺=12 臺服務器

假設每臺服務器的費用為 3 萬元，那么服務器的硬件成本為：

12 臺服務器 X 3W = 36W 元

補充說明：為了提高可用性，通常將相同數據的副本分散在不同的機柜和交換機上部署。這種方式可以在機柜或網絡設備出現故障時，依然保證數據的高可用性。

根據服務器托管推算維護費用

除了購買服務器，還需要考慮維護費用。將 2U 服務器托管在優質機房內，每臺服務器的年托管費用約為 1 萬元。前面計算得出，我們需要 12 臺服務器，那么一年的托管費用為：

12 臺×1 萬元=12 萬元

接著，我們來計算第一年的總投入，包括硬盤采購與維護、服務器硬件成本、托管費用，以及帶寬費用。具體計算如下：

第一年投入費用=42 萬（硬盤新購與備用）+36 萬（服務器一次性投入）+12 萬（服務器托管費）+10 萬（寬帶費用）=100 萬元

后續每年維護費用包括硬盤替換（假設備用盤用完）、服務器托管費以及帶寬費用，計算如下：

9.2 萬（備用硬盤）+12 萬（托管費）+10 萬（帶寬費）=31.2 萬元

基于第一年投入和后續維護費用，我們可以計算三年內運轉 30 萬 QPS 核心服務所需的成本，具體如下：

31.2 萬元×2 年=62.4 萬元+第一年投入 100 萬元=162.4 萬元

當然，這里未包含大客戶的硬件采購折扣、冗余容量、網絡設備、適配卡等費用以及人力成本。但即便忽略這些，當你看到這樣的成本支出，再想想某些場景中用 2000 臺服務器來運行 ELK，相信你會深刻體會到，多寫一行日志的成本究竟有多高。

服務器采購冗余

接下來，我們談談采購服務器時保留冗余的問題。如果沒有親身經歷過，可能會容易忽略這一點。

對于核心機房的托管，服務器的采購和安裝周期需要特別關注。很多核心機房往往缺乏空余的機柜位，因此，為了滿足未來幾年的業務增長需求，許多公司會提前多采購一些備用服務器。曾有公司按照評估結果的四倍來備貨，不過不同企業的業務增長速度不同，冗余比例并沒有統一標準。就我個人而言，習慣根據當前流量增長趨勢，預估未來三年的服務器需求量來進行采購。

因此，回頭看我們之前計算的服務器成本，實際上只是基于現有需求而已，只能算是“剛好夠用”。實際操作中，做成本估算時一定要將冗余考慮在內，以免因資源不足影響業務發展。

如何節省存儲成本？

一般來說，業務都有成長期，當我們業務處于飛速發展、快速迭代的階段，推薦前期多投入硬件來支撐業務。當我們的業務形態和市場穩定后，就要開始琢磨如何在保障服務的前提下降低成本的問題。

臨時應對流量方案

如果在服務器采購時沒有留出冗余，而服務流量增長了，我們可以采取一些臨時措施來緩解壓力。可以從節省服務器存儲空間和減少日志量這兩個方面著手，例如：

• 縮短日志保存周期：將日志保存周期從 30 天縮短為 7 天，這樣可以節省約四分之三的存儲空間。
• 區分核心和非核心業務日志：非核心業務日志可以只保存 7 天，而核心業務日志則繼續保存 30 天，以優先保障關鍵數據。
• 減少日志量：這可能需要分析并調整日志輸出，對穩定業務的排查日志適當縮減，減少不必要的記錄量。
• 進行數據壓縮：如果服務器數量充足或磁盤較少、CPU 負載不高，可以考慮對數據進行壓縮處理，這樣可節省一半的存儲空間。

以上這些措施能夠在短期內緩解存儲壓力，作為應急之策。但是在控制成本時，建議不要犧牲業務服務，尤其是核心業務的穩定性。接下來，我們可以探討一種特殊情況。

如果業務高峰期的流量激增，遠超過 30W QPS，就有更多流量瞬間請求尖峰，或者出現大量故障的情況。這時甚至沒有報錯服務的日志中心也會被影響，開始出現異常。高峰期日志會延遲半小時，甚至是一天，最終后果就是系統報警不及時，即便排查問題，也查不到實時故障情況，這會嚴重影響日志中心的運轉。出現上述情況，是因為日志中心普遍采用共享的多租戶方式，隔離性很差。這時候個別系統的日志會瘋狂報錯，占用所有日志中心的資源。為了規避這種風險，一些核心服務通常會獨立使用一套日志服務，和周邊業務分離開，保證對核心服務的及時監控。

高并發寫的存儲冷熱分離

為了節省成本，還可以從硬件方面入手。如果我們的服務有明顯的高峰期，但平時流量并不大，采購過多服務器可能會造成資源浪費。這時可以通過采購高性能硬件來支撐高峰期流量，達到更節約的效果。

例如，單個磁盤的寫性能約為 200MB/s，在 RAID 5 環境下，單盤性能減半，約為 100MB/s。假設一臺服務器能裝 9 塊硬盤，則總寫性能為：

100MB/s×9 塊硬盤=900MB/s

這樣的磁盤吞吐量可以滿足實時寫入、少量讀取的日志中心需求，但應對極端高峰時可能還需額外優化。為此，我們可以考慮冷熱分離策略：在寫入需求激增時，用 SSD 來處理高并發寫入，而將冷數據存儲在普通硬盤上。

假設每天產生 8TB 新日志，每個副本分布在 4 臺服務器上，則每臺服務器需承擔 2TB 的每日存儲需求。按 1TB SSD 的實際容量為 960GB，M.2 接口 SSD 單價約 1800 元、順序寫入性能在 3-5GB/s，則每臺服務器需配備兩塊 SSD，總計 24 塊 1TB SSD，計算如下：

1800 元×12 臺服務器×2 塊 SSD=43200 元

此外，SSD 需要定期更換，其壽命約為三年，年維護費用為：

1800 元×8 塊=14400 元

補充知識：SSD 不僅能提升寫入性能，還能提升讀取性能，并且一些分布式檢索系統支持自動冷熱遷移功能，使高頻數據更快速響應，而冷數據則存儲在更節省成本的硬盤中。

需要多少網卡更合算

通過增加 SSD 和冷熱數據分離，確實可以有效緩解業務高峰時日志寫入的壓力。然而，即便服務器磁盤能夠承受住流量壓力，網絡瓶頸也會隨之顯現。

通常情況下，內網速度不會太低，但一些小型自建機房可能配備萬兆交換機而服務器僅支持千兆網卡。理論上，千兆網卡的傳輸速度為：

1000 Mbps/8=125 MB/s

實際傳輸速度卻往往達不到這個理論值，大致在 100 MB/s 左右。當我們在內網中進行大數據文件的傳輸時，千兆網卡的帶寬會很容易被占滿。

過去，為了提高網絡吞吐量，常用的方法是多網卡接入交換機并在服務器上進行 Bond 處理。隨著光纖網卡的普及，萬兆光口網卡成為主流，其理論傳輸速度為：

10000 Mbps/8=1250 MB/s

而實際速度大概能達到 900 MB/s（即 7200 Mbps）左右。

再回到我們之前計算的日志高峰數據吞吐量：

300,000 QPS×1 KB=292.96 MB/s

對于千兆網卡來說，100 MB/s 的帶寬速度在四臺服務器分攤下勉強夠用。但在更高流量的高峰期，這一帶寬仍顯不足，因此需要升級為萬兆網卡。值得注意的是，萬兆網卡還需配合性能更高的三層交換機才能完全發揮作用。近年來，萬兆交換機已普及，通常包含在基礎設施成本中，這里不再單獨計算交換機的投入成本。

在之前的硬件成本計算中，我們提到每組服務器需要存儲三個副本，因此配置三塊萬兆光口網卡是足夠的。然而，為了確保系統的穩定性，我們不會將網卡的帶寬使用率保持在滿負荷狀態，最佳的傳輸速度應保持在 300 到 500 MB/s 之間，以便預留出額外的帶寬供其他服務使用或應對突發情況。

對于 12 臺服務器來說，它們分為 3 組副本（每組 4 臺服務器，每個副本存儲一份完整數據）。在這種配置下，每臺服務器的日常網絡吞吐量可以計算為：

292.96 MB/s?(高峰期日志數據吞吐量)/4 臺服務器=73 MB/s

在使用萬兆網卡的情況下，這樣的吞吐量僅占總帶寬的十分之一，完全能滿足日常的日志傳輸需求。如果使用千兆網卡，情況就不一樣了。

盡管千兆網卡的理論速度為 100 MB/s，計算得出的 73 MB/s 吞吐流量似乎可以在其容量范圍內，但這樣做是不夠的。這是因為我們在估算容量時必須留有彈性。使用千兆網卡時，實際負載接近滿載，一旦出現流量波動，就可能導致網絡擁堵，從而嚴重影響系統的穩定性。

此外，日志中心的功能不僅僅是滿足基礎的業務需求，它還需要承擔問題排查和數據挖掘分析的任務。如果僅僅為了基礎服務而建設一個如此昂貴的日志中心，確實是得不償失的。因此，在選擇網絡硬件時，確保充足的帶寬和冗余設計是至關重要的。

圖片