產(chǎn)品的數(shù)據(jù)量一旦飛速的起來，宕機就變成了分分鐘的事情。作為一個成熟而優(yōu)秀的產(chǎn)品經(jīng)理，你要做的就是先理解后臺邏輯，在做產(chǎn)品規(guī)劃的時候就考慮到一切可能的風險。本文講述了后臺宕機的原因、機制和解決之法，希望加深產(chǎn)品經(jīng)理對后臺宕機的理解，從而控制風險。

世界上最痛苦的事情不是產(chǎn)品流量沒起來，而是流量上來了服務后臺卻掛了；世界上最痛苦的事情不是版本沒有如期上線，而是上線后程序員被祭了天。

但凡一款爆發(fā)式增長的產(chǎn)品，幾乎都在后臺服務上折過腰，一般公司的操作方法：殺一個CTO祭天。但是，祭天有用嗎？這事兒就真的和產(chǎn)品經(jīng)理一點關系都沒有嗎？

今天麗莎阿姨就和你一起來聊聊后臺服務的那些事兒。聽完后，希望你能理解程序員小哥，與他在同一認知維度上思考，更關鍵的是也許你的一個小小舉措就能拯救一條猿命啊。

俗話說得好，程序員有三難：

• 安卓：折疊、挖孔、齊劉海
• 蘋果：證書、上架、熱更新
• 前端開發(fā)：IE 六、七、八、九、十
• 后端開發(fā)：并發(fā)、寫庫、做運維

相比于其他，后端開發(fā)的最大難度就是需要在有限的資源上對海量的數(shù)據(jù)做高效地處理。

怎么理解這句話呢？

• 有限的資源：例如當前一個很厲害的 88 核/710GB 的后臺服務器，其實也就是宇宙第一強手機 HUAWEI P40Pro（8 核/8G）的十倍左右。
• 海量的數(shù)據(jù)：就我們產(chǎn)品而言，隨便挑一個數(shù)據(jù)庫都已經(jīng)有好幾 T 的大小。
• 高效地處理：后臺處理一慢，用戶體驗就變的很糟糕，絲毫不敢懈怠。

所以，產(chǎn)品的數(shù)據(jù)量一旦飛速的起來，宕機就變成了分分鐘的事情。

一個正常的猿外人，首先的思考就是：為啥不擴容？不就是錢能解決問題的嗎？

一、擴容能解決宕機的問題嗎？

1. 不是所有的資源都能簡單的擴容

12306 網(wǎng)站夠有錢吧，但是上線當初就是瘋狂的崩啊，所以花錢并不能直接解決問題。那么為啥不能簡單橫向擴容呢？

原因很簡單：如果系統(tǒng)用到了一些有單點限制的資源，那其他系統(tǒng)再怎么擴容也沒用。哪些是常見的單點資源呢？一般是數(shù)據(jù)庫、緩存、核心依賴的第三方服務等等。

2. 你永遠不知道宕機和出軌哪一個先來

如上圖所示，隨著用戶量的增長服務器的費用也會水漲船高，但是用戶量的增長很多時候要聽天命。就像微博的突發(fā)事件，事情來了用戶暴漲XXXX萬，事情過后一片唏噓。

不擴容不是人，擴完容人散了，你就是豬。所以，對于產(chǎn)品經(jīng)理們來說，能夠非常精準的預測到即將到來的流量就變的尤為重要。數(shù)據(jù)監(jiān)控，模型推演，歷史事件對比分析都是非常有效的方式。

這個時候，猿外人估計也會想到，為什么程序猿不進行動態(tài)的縮擴容呢？

麗莎阿姨舉一個非常形象的例子：把后臺服務當做一個奶茶店，假設一個營業(yè)員小哥正常 1 分鐘處理一個用戶，以下是可能會遇到的一些情況：

• 特殊工藝的奶茶：制作工藝非常復雜，做一杯要 5min，那這個營業(yè)員這 5 分鐘暫時不能接客；
• 水龍頭流的很慢：每次接杯水都要好久，處理一個用戶的時間自然要變得很長；
• 還有一批混混：不知道被誰雇傭過來的，過來排隊但又不買；

這些問題，都是后臺開發(fā)的過程中會遇到的實際問題，要處理起來每一個都非常棘手，并非雇傭和解雇幾個小哥就能解決的。

二、后臺服務為什么會掛？

常見的原因有兩個：

• 單點系統(tǒng)可能會掛或者處理能力有限，典型：數(shù)據(jù)庫、Redis 緩存(10W qps)
• 第三方依賴可能會故障，包括核心依賴、非核心依賴

后臺程序員怎么做能讓服務能更穩(wěn)一點？

1. 拆

拆是一個種常見的方法，常見的會根據(jù)伸縮立方和微服務做下面這些拆分。

水平拆分

這種方式比較常見，可以認為是簡單的水平擴容，簡單來說就是一臺不行，多跑一臺扛著。

功能性拆分

這種方案是根據(jù)功能模塊的不同，進行拆分后臺服務，不把雞蛋放在一個籃子里。如果有一個服務故障，不影響其它服務的運行。

數(shù)據(jù)拆分

前面有提到，數(shù)據(jù)庫經(jīng)常會成為單點的瓶頸。一般在功能性拆分的同時，我們也會做數(shù)據(jù)的拆分，不讓一份數(shù)據(jù)變得超級大。

2. 尋找更強的單點

如果單點暫時有瓶頸，那可以考慮：是不是有功能一樣，但是性能更強的單點可以替代呢？

常見的方式是換組件，自己的不行換云服務的，單機版不行換集群版本。

比如對于數(shù)據(jù)庫，阿里云上的 PolarDb 號稱比傳統(tǒng) MySQL 性能提升 6 倍左右。

3. 犧牲時效性

既然數(shù)據(jù)庫寫的單點很難解決，就從讀取上想辦法。這就像，老板太忙，就請一個秘書，雖然消息傳遞有一些時延差，但是可以分擔老板的精力，一個秘書忙不過來還可以再多請幾個。

如下圖，一個家校溝通的產(chǎn)品，老師發(fā)布作業(yè)這個場景就可以犧牲掉一部分的時效性。

4. 讓單個請求處理更快

慢請求是后臺永遠的噩夢，一旦有大量請求處理很慢，就非常危險了，所以要程序員小哥在開發(fā)的過程中，經(jīng)常做重構、優(yōu)化、做架構演進，目的就是讓請求處理得更快。

5. 提前計算好，不要等用戶來的時候再計算

對于一個業(yè)務來說，會存在一些數(shù)據(jù)統(tǒng)計相關的服務，如果按照來一個用戶計算一次的方式，服務的質量和數(shù)據(jù)庫的壓力都會非常大。

最好的方式就是在凌晨時把能計算的數(shù)據(jù)都計算好，等用戶來的時候，數(shù)據(jù)已經(jīng) ready，一個簡單的讀取就可以拿到他要的結果。

但是，如果這些都做了，服務還是要崩，我們能怎么辦？

三、終極大招：有損服務與降級

我們在產(chǎn)品設計和后臺開發(fā)的時候，需要清楚你的系統(tǒng)「強依賴」和「弱依賴」是什么。

• 用戶沒感覺是弱依賴
• 用戶有感覺是強依賴

有了上面這些概念以后，就可以來做一些對應的設計：

• 犧牲用戶體驗：用靜態(tài)化數(shù)據(jù)代替「千人千面」的動態(tài)數(shù)據(jù)；放緩流量進入的速率，增加驗證碼機制；簡單粗暴的，直接掛一個頁面顯示「XX 功能在 XX 時間內暫時關閉」
• 犧牲功能完整性：有一些功能是「防御性」的，如果愿意冒險“裸奔”一段時間也會帶來可觀的資源節(jié)約；臨時關閉「風控」；取消部分「條件是否滿足」的判斷
• 犧牲時效性：將一些原本就是異步進行的操作，處理效率放緩，甚至暫緩一段時間。如，送積分、送券等等

每個產(chǎn)品的后臺開發(fā)都是一個非常復雜的系統(tǒng)工程。服務器掛了，拿程序員祭天是一點作用都沒有的。

作為一個成熟而優(yōu)秀的產(chǎn)品經(jīng)理，你要做的就是先理解后臺邏輯，在做產(chǎn)品規(guī)劃的時候就考慮到一切可能的風險。然后，就算是后臺掛了，也能從上文中提到的思路與后臺小哥一起來思考解決問題。

做后臺很苦，請善待搬磚民工。文中的后臺相關技術術語如果有描述錯誤的之處，還請各位在評論區(qū)指出斧正，感謝。

#專欄作家#

Lisa Deng，微信公眾號：麗莎D的產(chǎn)品手記，人人都是產(chǎn)品經(jīng)理專欄作家。12年資深產(chǎn)品人，某教育公司產(chǎn)品總監(jiān)，關注在線教育、工具產(chǎn)品、AI應用等領域，擅長總結產(chǎn)品的基礎方法論。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協(xié)議