根據各系統不同使用情境，會遇到各式各樣的瓶頸，因此需要分析系統主要問題，再針對此決定處理方案，對症下藥。
以下會先介紹之前工作中使用過的各式對策，會寫這篇文章，是因為這次遇到了與先前完全不相同的狀況...
資料庫瓶頸解決方案
1. Redis：利用 cache 機制，將常使用的資料放到 Cache 中，降低資料庫讀取次數，減輕資料庫服務負擔。
2. 讀寫分離：建立資料庫資料映像，讀取的需求導向映像資料庫，分散單一資料庫讀、寫使用需求。
站台瓶頸解決方案
- CDN：將靜態資料放置到 CDN，根據終端所在位置取得近端資源，減輕站台服務需求數量。
2. 微服務架構：將邏輯元件分散至多部主機上，避免單一請求處理耗時，提升需求處理速率(翻桌率)。
3. 負載平衡器(Load Balancer)：當一台主機無法負荷呼叫需求，由中控單位指定將後續需求指派給第二台、第三台...等其他尚有能力的主機處理。
切身瓶頸
這次遇到的狀況，特性為：
1. 突發非常態性，最高每分鐘有將近 2 萬次服務請求
2. 單純 I/O處理(上傳檔案)，除認證過程外，不涉及資料庫存取
斟酌前述解決方案後，雖可使用負載平衡器，但平時使用量啟用一台伺服器已綽綽有餘，要多開兩個伺服器(負載平衡器、API 伺服器)感覺有點大材小用，此時發現另一個解決方案 - 限流(throttling)。
API 伺服器限流
限流的概念是：規定在一定時間內 API 呼叫次數，超過限制量回傳 429 Too Many Requests 狀態碼。規則根據寫法與使用套件不同，可以限制來源 IP、使用者、目的地路由…等。
使用 ASP.Net Core 站台可參考以下相關套件介紹：https://nugetmusthaves.com/Tag/throttling
限流後，讓伺服器在可承受範圍內，服務最多數請求，避免系統資源被特定來源、特定路由用盡。
根據後續分析，當發現某些路由有異於其他者的高使用量需求，可以搭配微服務架構，將其工作獨立為另一站台。
當然，同時要分析此使用量是否正常，或是存在被攻擊弱點而引發攻擊，這就是另一個議題了....
