API網關通常位於流量的入口，負責對進出的流量進行加工處理。當然，大到整個公司的流量，小到一個服務的入口，都可以有網關，無非規模不同，功能多少不一，但本質上都是對流量就行控制。
網上關於API網關的文章有很多，但是大多內容比較空洞。我接下來准備分幾個主題，每個主題都旨在解決一類問題。大家不妨站在開發者的角度上想一想，如果是你，你會怎樣解決這些問題。
這次先說的是關於API網關“性能”的內容。
網關作為流量的入口，需要處理極大量的並發請求，對一個大型網關而言，峰值QPS往往會達到百萬級別，因此，對網關而言，性能是必須重點考慮的一個因素。
當前主流的服務架構，一般都是在配置比較高的硬件服務器上划分出很多容器，根據請求量的大小，進行橫向擴容/縮容。
一個粗略的網關系統的架構，大致是下面這個樣子的：
這一篇，只講API網關這一層的性能。
硬件本身的性能是一定的，因為硬件本身的資源是一定的，這里和資源相關的性能是指機器的性能，比如磁盤每秒能轉多少圈，CPU每秒能進行多少次運算，網卡每秒能傳輸多少數據，等等。
這一層的性能不是我們要討論的，我們服務端開發人員也無能為力，這一層的性能只能靠搞硬件的大神們了。不過，摩爾定律差不多已經失效的今天，除了量子計算之外，傳統的計算機硬件性能可提升的空間應該已經極其極其有限了。
我們回到軟件的性能上來，理論上，我們談到軟件性能時，基本上就是指在有限的硬件資源下，在保證服務的響應時間（后續用rt代替）在一定范圍內時，每秒可以處理的請求數（后續用qps代替）。請求數越大，性能就越好，或者對於API網關來說，用另一個詞更合適一些：吞吐量。
舉個例子，一個請求的rt是10ms，同樣配置的機器，網關A可以保證qps=100時，rt=10ms不變，另一個網關B，可以保證qps=1000時，rt=10ms不變，我們說網關B的性能更好，其實是網關B的吞吐量更高。
對於服務響應時間，補充一點，服務響應的rt = 網關層的耗時 + 下游服務的耗時。我們假設下游服務的耗時是一直穩定的，至於怎樣保證下游讀物耗時一直穩定，那是下游的事情，這里我們只考慮網關層的耗時。
所以，應該怎樣提升網關的性能（吞吐量）呢？
等等，在回答這個問題之前，還有一個更重要的問題，為啥要提高網關的性能？
因為要節約成本啊，10台機器可以搞定的事情，如果現在用1台就能搞定，那肯定能省很多錢。或者，更高尚一些，能為這個星球節省一些資源，畢竟，程序員們都是心懷宇宙的。
好，回到剛才的問題，怎樣提升網關的性能呢？
答：性能和耗時是成反比的，因此，提升性能=縮短耗時。
網關的耗時基本由3部分組成：
- 等待請求的數據傳過來
- 等下游服務響應
- 網關本身的數據處理
1和2，顯然沒辦法，這是網絡傳輸和下游服務的事。
至於第3點，數據就那么多，算法也擺在那，貌似也沒辦法縮短時間。並發很低的情況下，確實是這樣的，但是，並發很高的場景下，比如網關系統，情況就發生了變化。這個變化很重要，具體變化是：比如我們的機器時4核的，當並發是4的時候，每個核處理一個請求，剛剛好，耗時就是上面的1+2+3.但是當並發很大，比如4000的時候，就會冒出來第4個耗時：線程切換的耗時。
線程切換是怎么回事？不解釋，網上一搜一大把。
線程切換為什么會耗時？同上。
怎么縮短線程切換的耗時？切換的少了就耗時少了。
怎么降低線程切換頻率？少創建一些線程就行了。
可是並發那么多，線程少了怎么處理的過來？IO多路復用
IO多路復用是什么？不解釋，網上一搜一大把。
最后，我一直認為，但凡性能問題，說到底都是軟件（使用硬件的方式）問題和硬件問題（計算速度）。
硬件不多說，看自己電腦配置。
軟件這里推的是我正在使用的Eolinker，國產的開源API網關，團隊開發也有專門的客服，比其他個人開發的使用體驗更好，感興趣可以自己試試：www.eolinker.com
