低調的牛肉

我們現在的系統，最開始只面向內網系統，這種情況下，訪問量都不是特別的大並且比較平穩，最近開始接了一些互聯網區的系統，訪問量一下子上來了，所以也不得不考慮這方面的問題。

首先要說明，我們公司雖然也號稱上了雲，但是基本上還是基礎的IasS這個級別，並沒有PasS，也沒有容器管理平臺什麼的，所以網上說的那些自動的流量監控、自動擴容縮容什麼的，我們並沒有使用過；所以針對這種情況，基本上還是一些土辦法。

流量估算

什麼系統會調用？這些系統的使用用戶是誰？每日調用量是多少？高峰期預計是多少？

每個公司的情況可能不太一樣，我們公司也成了好多年了，這些數據參考之前的產品/活動/需求基本上可以評估個大概範圍，比如一個業務場景下，每天大概會有10萬的調用量，在開發、壓力測試和生產資源申請的過程中，就按照（評估數量*N）的一個值進行估量。

如果是小公司的話，或者某個業務場景是第一次上，那麼這個數量是比較難估計的，這時候只能猜一個數量，不過就算是猜的，也比沒有強。

緩存

請求過來，基本的過程就是解析入參、查詢DB、加工處理、返回參數，需要使用的資源包括：網絡帶寬、CPU、內存、磁盤IO等；如果請求量增加，總會有一個資源會遇到瓶頸，通常來看，最容易產生瓶頸的是磁盤IO，基本上是數據庫的磁盤IO。

使用緩存，就是為了減少數據庫的壓力，避免在請求量突然增多的時候，數據庫崩掉從而導致整個項目的癱瘓。

緩存也可以分成多級，包括客戶端（瀏覽器）緩存、CDN、服務器級別的緩存（內存式緩存、分佈式緩存）；

限流

限制用戶的請求流量，例如使用計數器、頁面設置多次提交的間隔時間、滴漏、請求排隊等。

我們系統本身沒有做什麼限流措施，完全是依賴於API Gateway來做這些功能的；

有些項目甚至是這樣做的，一個接口ABC三個系統都要調用，AB系統比較關鍵並且調用量穩定，C系統要求沒那麼高但是調用量比較大，那麼接口被部署成兩套環境，一套給AB系統使用，一套給C系統使用（數據庫也使用備庫），前者保證其穩定性，後者嘛...也會保證其穩定性，但是如果萬一掛掉的話，至少不會影響到AB系統的使用。

服務降級

我認為這種方法在真實的業務場景中，是比較難實現的，不是說技術上不好做，而是業務上比較難操作。

通常服務降級不是IT說降就降的，這得業務（用戶）說了算才行；就算是降級，也只能降那些不太重要的功能（接口），降級後頁面顯示成什麼樣子，接口返回什麼內容，這些都是要提前設計好的；如果是關鍵性的功能（接口），是沒有降級可能的。

希望我的回答，能夠幫助到你！我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。

會點代碼的大叔

對於軟件系統而言，若特定時間段內流量暴增，那軟件系統及相關API的性能瓶頸立馬就會表現出來，服務器資源被佔滿，隨之導致服務及系統不可用。所以我們要在系統架構時充分考慮到洪峰帶來的性能壓力，以達到“三高架構”。

什麼是“三高架構”

架構領域所說的“三高”是指：

• 高併發：並行處理的請求越多則代表併發越高；
  

• 高性能：服務性能好，響應處理速度快；

• 高可用：服務不可用的時間短、或基本沒有。

API接口如何應對暴增的流量？

如何使我們的API達到“三高”呢？可以通過一些技術方案來實現，我這裡整理了一些以供大家參考：

1、合理的緩存設計

在API層提緩存，很多人就覺得API不應該加緩存，因為大多數接口數據對實時性都是有要求的，但這裡說的緩存主要是指藉助內存來緩解DB層的查詢（因為內存讀寫速度比硬盤讀寫速度快得多）。

要知道，API的數據來源主要是從數據庫中查詢出來的，所以在流量洪峰時，所有的流量都會打到DB層，這樣數據庫的查詢壓力很大。我們建議在用Redis等NoSQL產品來同步一份熱點數據，API直接從Redis中取數據，取不到數據再從DB層查詢。

2、數據庫主從同步、讀寫分離

單一的數據節點在高併發場景下是抗不住的，所以需要做主從同步+讀寫分離。讀從庫，寫主庫，能有效避免主服務器出現性能瓶頸、降低阻塞、併發能力提升。

3、服務限流

當系統資源無法應對大量請求時，為保證有限資源能正常使用，我們就需要就需要按照一定策略對服務做限流處理。

其實很好理解，舉例說明一下：每逢假期熱門景點就是人山人海，所以這些景區的門票都會做限制，防止人員過多導致隱患發生。

服務限流有很多種模式，在架構領域常見的有：

• 熔斷：當服務出現問題若短時間內無法修復，則開啟熔斷，拒絕訪問，避免大流量請求對後端造成的過載壓力；然後系統能實時監測服務的修復情況，一旦服務正常後，就自動關閉熔斷，恢復服務。

• 服務降級：一個大型系統會涉及很多服務，有些重要，有些不重要。當服務器負載嚴重時，可以對不重要的服務進行降級處理（即：停止服務），將資源回收提供給核心業務去使用。像電商平臺每次做活動時，一些非核心業務都會臨時關閉，這就是服務降級。

• 隊列處理：我們可以將所有的請求放置在一個“隊列池”裡，後端服務從這個“隊列池”中依次取出請求進行處理，這種排隊機制很大程度緩解了後端服務器的壓力，只不過它也帶來一些延遲。

4、動態擴容

以硬件的擴容來應對大流量衝擊，像現在的容器化部署都可以做到彈性擴容，當資源不夠時秒級擴容。

網絡圈

對於開發人員來說，在開發接口時是需要考慮高併發的情況的，在開發時要儘量優化代碼提升接口性能，採用緩存機制以降低對數據庫的操作；接口需要進行壓力測試，並且將測試結果作為接口指標，在實際業務場景中，可以通過日常檢測提前預估接口的訪問情況，及時對服務器作出調整和擴容，以應對高併發的情況。

對於突然性的併發訪問，可以採用流量限制的方式，通過對線程、數據庫連接數等進行限制從而降低服務器的壓力，如果是在分佈系統中，也可以採用消息隊列的模式，通過消息隊列作為緩衝削弱訪問壓力；或者採用頁面靜態化的方式，將一些信息動態生成html頁面，通過訪問html頁面降低對數據庫的訪問、提升效率；也可以搭建服務器集群，通過集群的圖片分離、負載均衡等方式來分散訪問壓力，提升訪問效率。

關鍵字: 系統 科技 接口