面對互聯(lián)網(wǎng)的快速發(fā)展，第三方支付平臺也在產(chǎn)品更新、客戶服務(wù)上不斷進(jìn)行完善。做為第三方支付領(lǐng)導(dǎo)者的易寶支付，在近幾年不斷推出易碼付、掌柜通、EPOS支付等產(chǎn)品。產(chǎn)品類型的增加、功能項的優(yōu)化等等技術(shù)問題，如何在原有系統(tǒng)基礎(chǔ)上進(jìn)行擴(kuò)展?如何在擴(kuò)展的同時不影響原有系統(tǒng)的正常運(yùn)營?這些問題與易寶支付相關(guān)人員進(jìn)行了交流。今天我們還將討論如何計算系統(tǒng)的可擴(kuò)展性，也就是如何進(jìn)行系統(tǒng)容量或者系統(tǒng)能力的規(guī)劃。系統(tǒng)穩(wěn)定性就像陽光、空氣、水一樣，只有失去了才知道珍貴。

網(wǎng)絡(luò)隨著企業(yè)業(yè)務(wù)的發(fā)展而發(fā)展。無論是計劃新局域網(wǎng)(LAN)還是維護(hù)現(xiàn)有LAN，都需要根據(jù)業(yè)務(wù)需求對數(shù)據(jù)容量要求進(jìn)行建模。因此，網(wǎng)絡(luò)容量規(guī)劃的起點(diǎn)是記錄你現(xiàn)有的資源，網(wǎng)絡(luò)當(dāng)前的性能，并評估潛在的需求變化。

事實(shí)上，如果做好網(wǎng)站的容量規(guī)劃，系統(tǒng)過載這類問題完全可以通過正確的管理流程和適當(dāng)?shù)馁Y源投入來避免。

對互聯(lián)網(wǎng)公司而言，清楚地掌握并合理地規(guī)劃平臺的容量是業(yè)務(wù)成敗的關(guān)鍵之一。首先產(chǎn)品部門需要根據(jù)業(yè)務(wù)的規(guī)劃來預(yù)測用戶的訪問量，以確定產(chǎn)品所需要的服務(wù)能力，據(jù)此進(jìn)一步確定系統(tǒng)所需要的容量。系統(tǒng)運(yùn)維部門的工程師根據(jù)產(chǎn)品需求預(yù)測出容量需求，以確定下一年度系統(tǒng)資源的預(yù)算，人力資源部門根據(jù)產(chǎn)品需求確定需要招聘多少不同技能的人員，比如軟件開發(fā)工程師、系統(tǒng)運(yùn)維工程師、數(shù)據(jù)庫管理員等。預(yù)算部門根據(jù)各部門的需求，準(zhǔn)備足夠的資金確保增加或者減少服務(wù)器和網(wǎng)絡(luò)設(shè)備，雇傭更多稱職的工程師來擴(kuò)展系統(tǒng)容量，以達(dá)到預(yù)期的產(chǎn)品需求。

基本步驟

了解了以上這些基本信息后，我們應(yīng)該如何計算并確定平臺的合理預(yù)留空間呢?以下是需要遵循的幾個基本步驟：

實(shí)例操作

下面我們通過一個典型的基于 SaaS 的 B2B 產(chǎn)品實(shí)例來解釋如何規(guī)劃系統(tǒng)的容量。這個產(chǎn)品非常受市場歡迎，而且客戶數(shù)量呈爆發(fā)式的增長。當(dāng)新客戶注冊該產(chǎn)品的服務(wù)時，平臺的負(fù)載會隨著每個客戶公司所帶來的用戶數(shù)量的變化而變化。到目前為止，該平臺共有 25 個客戶，約 1500 位用戶。

為確保平臺可以滿足業(yè)務(wù)發(fā)展的需要，該 SaaS 提供商的 CTO 正在做明年的預(yù)算，這需要我們準(zhǔn)確地預(yù)測成本，因此要求進(jìn)行一次系統(tǒng)容量的規(guī)劃。

第一步是理解平臺的技術(shù)架構(gòu)。該 SaaS 應(yīng)用的技術(shù)架構(gòu)非常簡單，包含網(wǎng)絡(luò)層、應(yīng)用層和數(shù)據(jù)層。在該容量規(guī)劃中，我們將聚焦網(wǎng)絡(luò)、應(yīng)用和數(shù)據(jù)庫服務(wù)器，暫時忽略路由器、交換機(jī)、防火墻和負(fù)載均衡等網(wǎng)絡(luò)設(shè)備，當(dāng)然，在實(shí)踐中我們必須定期對這些網(wǎng)絡(luò)設(shè)備進(jìn)行分析，以確保有足夠的預(yù)留空間。

第二步是確定需要關(guān)注的組件。在本案例中，這些要關(guān)注的組件就是網(wǎng)絡(luò)服務(wù)器、應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器。

第三步是確定每個組件的實(shí)際和最大的使用率。假設(shè)這些組件都有良好的運(yùn)維記錄，我們了解所有這些組件的實(shí)際峰值和平均使用率，在每次代碼發(fā)布前都進(jìn)行壓力測試，并且掌握每個組件的 TPS(每秒處理的用戶請求數(shù)或者每秒處理的交易數(shù))。

系統(tǒng)可以監(jiān)控每個發(fā)送到網(wǎng)絡(luò)服務(wù)器和應(yīng)用服務(wù)器的請求。從上表中可以看到，網(wǎng)絡(luò)服務(wù)器在高峰期每秒接受 125 個請求(TPS)，應(yīng)用服務(wù)器在高峰期每秒接受 80 個請求(TPS)。出現(xiàn)這種差別的原因是在網(wǎng)絡(luò)服務(wù)器上有大量不需要任何業(yè)務(wù)邏輯計算的靜態(tài)頁面，這些頁面包括企業(yè)官網(wǎng)、引導(dǎo)頁、圖片等。上表給出了每個組件高峰期請求的總數(shù)、服務(wù)器群組的節(jié)點(diǎn)數(shù)、單節(jié)點(diǎn)請求的峰值和單節(jié)點(diǎn)所允許的最大請求數(shù)。在壓力測試中，當(dāng)服務(wù)器對用戶需求的響應(yīng)時間高于內(nèi)部服務(wù)水平協(xié)議(SLA)標(biāo)準(zhǔn)時，所觀察到的請求數(shù)量就是每個節(jié)點(diǎn)所允許的最大請求數(shù)。

第四步是確定該業(yè)務(wù)流量的增長率。下圖顯示了該 SaaS 產(chǎn)品最近兩周每天的流量監(jiān)控數(shù)據(jù)，據(jù)此可以看出每周的流量增長情況。通過計算，我們得出每周的流量增長率為2%，年化相當(dāng)于280%的增長率，或者每年3倍的增長率。這種快速的增長既來自于現(xiàn)有的客戶使用越來越多的服務(wù)，也得益于銷售團(tuán)隊簽約新的客戶。

第五步是確定該 SaaS 產(chǎn)品受季節(jié)性影響的程度。由于該產(chǎn)品是為企業(yè)服務(wù)的，而企業(yè)的項目往往是在年初做預(yù)算，所以會有一定的周期性。下圖顯示了該 SaaS 案例中存量客戶的季節(jié)性變化趨勢。根據(jù)這個趨勢，我們可以觀察到存量客戶會受到影響的季節(jié)。由于這個容量規(guī)劃是在八月份進(jìn)行的，而八月通常是該產(chǎn)品使用率較低的月份;因此我們預(yù)計在明年的一月底前受季節(jié)效應(yīng)影響，流量會增加 50% 。

第六步是計算實(shí)施既定的系統(tǒng)擴(kuò)容項目后可以獲得的新容量。假如這個項目計劃在今年秋季實(shí)施，創(chuàng)建一個寫數(shù)據(jù)庫和兩個讀數(shù)據(jù)庫，把數(shù)據(jù)庫節(jié)點(diǎn)增加到三個，從而把現(xiàn)有請求分散到三個節(jié)點(diǎn)之間。

第七步是估計服務(wù)器的理想使用率。理想使用率是指一個特定組件可以安全地使用多大百分比的容量。有兩個理由使我們無法 100% 地使用組件。首先，盡管我們盡力收集數(shù)據(jù)，但在容量規(guī)劃中，必定會包含一定程度的誤差。為此，我們需要一個緩沖空間以容納這些不確切性。

從這個案例可以看到，對每個迭代進(jìn)行例行的壓力測試對掌握單個節(jié)點(diǎn)的處理能力變化非常重要;另外持續(xù)不斷地對用戶請求和系統(tǒng)資源的使用情況進(jìn)行監(jiān)測也是進(jìn)行系統(tǒng)容量規(guī)劃的基礎(chǔ)。

從這個案例可以看到，對每個迭代進(jìn)行例行的壓力測試以掌握單個節(jié)點(diǎn)的處理能力變化非常重要;另外持續(xù)不斷地對用戶請求和系統(tǒng)資源的使用情況進(jìn)行監(jiān)測也是進(jìn)行系統(tǒng)容量規(guī)劃的基礎(chǔ)。理解起來容易做起來難，一切盡在細(xì)節(jié)中，在于嚴(yán)瑾和堅持，在于事故中磨練出來的團(tuán)隊。

(新媒體責(zé)編：shang080503)