今天，我想談談如何在不同的促銷、高峰時間和突發的用戶流量期間處理數百萬個請求。我們談論的是整個平臺的延遲，您需要記住，系統只與最慢的組件一樣快。對于最終用戶，如果用戶需要等待幾秒鐘才能看到主頁上的內容，那么您的服務器有多強大并不重要。此外，請為一些意想不到的問題做好準備，例如如果您沒有足夠的帶寬來滿足需求。在這種情況下，無需尋找應用程序本身的問題。

讓我們從簡單的步驟開始。一般來說，關注系統性能總是有用的，但也要注意——過早的優化是萬惡之源。從了解當前應用程序中最慢的部分開始。

了解什么是慢的

如果您是第一次進行優化，您可能可以很快識別出問題組件。從在后端和前端拆分我們的應用程序開始。

默認前端優化

至于前端，請檢查前端（HTML/js/CSS）的標準緩存實踐：

• 在響應中使用緩存標頭（Etag、緩存等）
• 如果可以，將所有靜態數據存儲在 CDN 上
• 使用 tinypng 服務優化您的圖像
• 檢查您的 javascript 庫。確保您不使用具有相同功能的不同庫
• Gzip 所有 HTML/js/CSS 內容。所有現代瀏覽器都支持 gzipping
• 嘗試減少對 3rd 方服務的請求數量。包括不同的指標、分析和廣告工具

簡單的后端優化

至于后端，這里有一個簡單的列表，可以幫助您增加應用程序響應時間：

• 確保您使用的是數據庫連接池
• 檢查您的 SQL 查詢并為它們添加緩存
• 為整個響應添加緩存

您需要保持緩存更新，但在很多情況下，您可以顯著改善這種情況。

代碼和架構發生了變化

為了更深入，我建議從一些基準測試或加載測試開始。根據您的架構，您將需要使用不同的工具。使用無頭 chrome 應用程序（testcafe 和類似應用程序）進行端到端基準測試。

基本wrk用法：

wrk -t12 -c400 -d30s http://127.0.0.1:8080/

Running 30s test @ http://127.0.0.1:8080/

12 threads and 400 connections

Thread Stats Avg Stdev Max +/- Stdev

Latency 635.91us 0.89ms 12.92ms 93.69%

Req/Sec 56.20k 8.07k 62.00k 86.54%

22464657 requests in 30.00s, 17.76GB read

Requests/sec: 748868.53

Transfer/sec: 606.33MB

測試最流行的端點并查看總體情況并了解瓶頸所在。

探索細節

一旦我們獲得有關現有瓶頸的信息，我們就需要更深入地挖掘并了解如何解決。在大多數情況下，最慢的操作是網絡請求和讀/寫 I/O 操作。無論可能 - 嘗試使用非阻塞操作或輕線程進行網絡和 i/o 操作。您可以從使用不同的分析解決方案（如 New Relic 的線程分析器、Stackdriver Profiling 或簡單地將 pprof 用于 golang/c++ 應用程序）中獲得很多好處。

下一步是什么？

在解決了一般瓶頸之后，您可能會發現自己已經消除了所有主要問題，但仍然沒有您需要的響應時間。您可以采取的下一步是更新應用程序架構，設置具有自動縮放功能的 Kubernetes，并開始使用云提供商。

微服務

典型情況 - 當您有幾個組件在高峰時間消耗 80% 的資源時。這兩個組件核心功能的原因是運行速度不夠快并且項目失去了用戶。一個可靠且強大的解決方案是按部分拆分您的應用程序，這樣每個部分都可以獨立工作并僅在需要的地方添加資源。使用微服務，您可以歸檔：

• 通過模塊化更好地管理
• 大規模部署和更新軟件

使用 Kubernetes 和自動縮放

可能，如果您還沒有，您應該開始使用 Kubernetes。它確實使您能夠在需要時添加更多資源，并在選擇消失后將其關閉。K8s 提供了很好的、經過良好測試的容器編排解決方案，并添加了容錯更新，具有跨集群的內置通信等等。但缺點之一是維護起來既困難又費時。

使用云提供商

AWS、谷歌云、Azure——這些都是很棒的解決方案，它們將為您提供和管理先進的技術。雖然您將為所有這些花里胡哨的東西付出更多，但其中一些有助于輕松構建可擴展、可靠的解決方案。如果您預計每秒有數百萬個請求，那么您可能應該從一開始就考慮使用云提供商。