架構修煉之道 | 一個傳統網關系統有幾種 “死” 法

本文節選自《架構修煉之道》，作者京東王新棟。

圖 | meghan-holmes-779221-unsplash

這里說的傳統，是按照網關技術演進的階段劃分的，從同步到半同步，再到全異步，我們將同步和半同步技術下的網關稱為“傳統”網關，同步網關的意思是從接收請求到調用API接口提供方的過程都是同步調用；半同步則是指將I/O請求線程和業務處理線程分開，但業務線程內部還是同步調用API接口；全異步的意思就比較清楚了，整個鏈路都是異步請求。接下來介紹“傳統”網關會在什么情況下“down掉”。

API網關系統有兩大特點，一個是訪問量大，另一個是依賴系統多。如下圖所示，“單純”的情況下（比如系統A提供的接口只供網關調用）網關系統要承受比被依賴的系統多數倍的流量，因為API網關是所有依賴API的集合。網關還會通過RPC調用很多底層系統，每個系統的穩定性水平參差不齊，接口的性能也會間接影響網關整體的運行穩定性。因此我們在做防范的時候就要從這兩個特點入手。

上面介紹了API網關的兩大特點，這兩個特點算外部因素，接著再來看一下內部因素。程序都是運行在計算機上面的，計算機的每個部件的利用率和負載水平直接影響程序的運行。比如CPU、內存、磁盤等。另外系統之間的交互還需要網絡，這些都需考慮。一段程序在計算機中的運行依賴部件如下圖所示。

關注CPU

用戶請求在進入網關的時候我們從技術上已經把I/O請求線程和業務處理線程隔離開了，這一點可以利用Servlet3異步特性實現（下面還會詳細介紹Servlet3的異步特性），如下圖所示。

業務線程池毫無疑問是在CPU里面運行的，線程是計算機CPU最寶貴的資源，我們一定要重點關注CPU利用率和CPU負載。

• CPU利用率：顯示的是程序在運行期間實時占用的CPU百分比。

• CPU負載：顯示的是一段時間內正在使用和等待使用CPU的平均任務數。在Linux系統中，我們可以使用uptime或top（使用top會看到更詳細的信息）命令來查看系統的負載情況。如果使用uptime命令則會得到如下一行:

11:36 up 23 days, 2:31, 2users, load averages: 1.74 1.58 1.60

最后的loadaverages的意思是系統平均負載，它包含三個數字，這三個數字分別表示1分鐘、5分鐘、15分鐘內系統的負載平均值。我們可以按照1分鐘的粒度取第一個數字，從而判定系統負載的大小。

上面的23days說明筆者有23天沒有重啟過計算機了。

注意，CPU利用率高，并不意味著負載就一定大，兩者沒有必然聯系。

關于這兩個概念的理解，我們還可以舉一個例子來說明。有8個人在排隊玩一個打地鼠的游戲機，要求1分鐘之內要打完100個地鼠，如果有人一分鐘之內沒有完成這個任務，那么就需要重新排隊，等待下一輪。游戲機在這里相當于CPU，正在或等待玩打地鼠游戲的人就相當于任務數量。

在玩游戲的過程中，肯定有的人在規定的1分鐘之內打完100個地鼠，完成任務之后就離開了，有人沒有完成任務而去重新排隊，還有可能有新增的人來玩這個游戲，人數的變化相當于任務的增減。有的人拿起打地鼠的錘子就開始玩，一直打完1分鐘，而有的人可能在前20秒看手機，后40秒才開始玩打地鼠。把游戲機看作CPU，排隊的人數看作任務數，我們說前一種人（任務）的CPU利用率高，后一種人（任務）的CPU利用率低。

當然CPU不會在前20秒休息、后40秒工作，只是說，有的程序可能涉及的計算量比較大，CPU利用率就高，而有的程序涉及的計算少，CPU的利用率就低。不管CPU利用率是高是低，跟后面有多少人（任務）在排隊沒有必然的聯系。

之所以花了一些篇幅來介紹CPU的這兩個概念，因為這兩個指標實在是太重要了，在線上生產環境中是需要重點監控的。鑒于API網關的訪問量大和依賴系統多的特點，如果調用的API性能突然變差，在大訪問量的情況下，線程數會逐漸升高，直至將CPU資源耗盡。蔓延到整個網關集群，這就是雪崩的效應。

關注磁盤

磁盤有兩個比較重要的指標分別是磁盤使用率和磁盤負載百分比。磁盤使用率比較容易理解，我們重點說一下磁盤負載百分比這個指標。在Linux系統下查看該指標的命令為 iostat -x 1 10 （如果沒有iostat ，則需要使用yum install sysstat進行安裝），筆者下面的圖中示例值還構不成威脅，但如果 %util 接近 100%，則說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤可能存在瓶頸，如下圖所示。

程序運行的過程中我們可能都不會關注磁盤的使用，如果處理不當，這有可能是一個“定時炸彈”。網關的特性訪問量大，再加上有的程序里面的日志打印不規范，比如日志的級別設置得不合理，把info日志打印出來。即使在日志級別合理的情況下，比如error日志，這時又涉及網關的第二個特性，依賴系統多。當有API返回失敗錯誤的時候，就會有大量的error日志寫入磁盤，很容易把磁盤打滿，尤其在容器時代，每臺服務器分配的磁盤容量相對物理機來說都比較小，如果集群的所有機器磁盤被打滿，對網關系統來說無疑是一場災難。

關注網絡

在微服務系統架構下，應用離不開網絡，尤其是網關系統，它的特點之一就是依賴系統多。依賴就是RPC調用和網絡。在一個RPC環境下，網絡占據了一次RPC調用所耗時間的很大比重。網絡質量的好壞直接影響了一次請求從進入API網關到返回給用戶響應的時間長短。如下圖所示，網關到依賴系統B之間的網絡突然變差，調用時長增加，在請求訪問量多的時候，一請求一線程的模式下，會直接導致API 網關系統的任務線程數增多，如果短時間內不能恢復，則整個API網關的集群所有機器的CPU資源都會被線程耗盡。

同時現有的線上生產環境部署并不能完全保證同機房調用，甚至還有跨地區調用，因此網絡是我們要考慮的一個重要因素，同時網絡的因素需要和上面講到的CPU的線程資源相關聯去考慮。

現在可以總結一個傳統API網關系統會有幾種“死”法了，因為依賴的某個系統的API性能突然變差導致請求線程數量逐漸升高直至線程占滿了CPU，也就是API網關依賴系統多的特點因素，可以認為是被其他系統“拖死”的。線上生產環境下日志輸出不規范，過度打印日志，再加上請求量突然變大，導致清理工具來不及清理日志，最后磁盤滿了，可以認為是被日志“打死”的。網絡一直是一個除系統本身外最不穩定的因素，在系統之間調用的時候，網絡發生故障導致請求變慢，這一點和第一條被其他系統“拖死”類似，只是這次是網絡。

查理.芒格有一句名言：“如果我知道我會死在哪里，我將永遠不去那個地方”。同樣對于一個API網關系統，如果我們知道哪些因素會導致一個網關“掛掉”，那么我們就會提前防范，以避免這種“災難”的發生。當然并不是宣揚傳統網關不好，它也有自己的優勢，比如編程模型簡單、開發調試運維方便等。如果業務規模較小，比如每天調用量不足千萬，或者不到億級，那么可以繼續使用這種類型的網關，甚至達到億級規模之后再配合有效的容錯機制（比如Netflix的zuul1+Hystrix）也可以支撐上億規模的訪問量。不過我們有更好的異步網關解決方案，接下來介紹異步網關技術實現。

本文作者：王新棟

現就職于京東，“程序架道”公眾號作者。平時熱愛總結與分享，對高性能API網關、線程調優、NIO、微服務架構、容錯等技術有較深的研究和實戰經驗。目前致力于帶領團隊在平臺開放技術領域實現突破。