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
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/285790.html
標籤：其他