API 網關從入門到放棄

API 網關從入門到放棄**

假設你正在開發一個電商網站，那麼這裏會涉及到不少後端的微服務，好比會員、商品、推薦服務等等

網關因爲對接不少種不一樣的協議，所以可能須要實現不少種調用方式，好比HTTP、Dubbo等，基於性能緣由，最好都採用異步的方式，而Http、Dubbo都是支持異步的，好比apache就提供了基於NIO實現的異步HTTP客戶端。由於網關會涉及到不少異步調用，好比攔截器、HTTP客戶端、dubbo、redis等，所以須要考慮下異步調用的方式，若是基於回調或者future的話，代碼嵌套會很深，可讀性不好，能夠參考zuul和spring cloud gateway的方案，基於響應式進行改

而異步化的方式則徹底不一樣，一般狀況下一個CPU核啓動一個線程便可處理全部的請求、響應。一個請求的生命週期再也不固定於一個線程，而是會分紅不一樣的階段交由不一樣的線程池處理，系統的資源可以獲得更充分的利用。並且由於線程再也不被某一個鏈接獨佔，一個鏈接所佔用的系統資源也會低得多，只是一個文件描述符加上幾個監聽器等，而在阻塞模型中，每條鏈接都會獨佔一個線程，而線程是一個很是重的資源。對於上游服務的延遲狀況，也可以獲得很大的緩解，由於在阻塞模型中，慢請求會獨佔一個線程資源，而異步化以後，由於單條鏈接所佔用的資源變的很是低，系統能夠同時處理大量的請求。

**