網(wǎng)關(guān)入門到放棄
點擊上方“程序員大白”，選擇“星標”公眾號
重磅干貨，第一時間送達
用途
鑒權(quán)
負載均衡
限流
權(quán)限
熔斷
協(xié)議轉(zhuǎn)換
內(nèi)部的API可能是由很多種不同的協(xié)議實現(xiàn)的，比如HTTP、Dubbo、GRPC等，但對于用戶來說其中很多都不是很友好，或者根本沒法對外暴露，比如Dubbo服務，因此需要在網(wǎng)關(guān)層做一次協(xié)議轉(zhuǎn)換，將用戶的HTTP協(xié)議請求，在網(wǎng)關(guān)層轉(zhuǎn)換成底層對應的協(xié)議，比如HTTP -> Dubbo, 但這里需要注意很多問題，比如參數(shù)類型，如果類型搞錯了，導致轉(zhuǎn)換出問題，而日志又不夠詳細的話，問題會很難定位
錯誤碼統(tǒng)一
緩存
日志
監(jiān)控
告警
接入
第一種采用插件掃描業(yè)務方的API,比如spring mvc的注解, 并結(jié)合swagger的注解, 從而實現(xiàn)參數(shù)校驗, 文檔&&SDK生成等功能, 掃描完成之后,需要上報到網(wǎng)管的存儲服務
手動錄入, .......
配置文件導入, 比如通過swagger\openAPI等, 比如阿里云的網(wǎng)關(guān)
服務發(fā)現(xiàn)
網(wǎng)關(guān)作為流量的入口, 負責請求的轉(zhuǎn)發(fā), 但首先需要知道轉(zhuǎn)發(fā)給誰, 如何尋址
寫死在代碼或配置文件中
域名
注冊中心
服務調(diào)用
網(wǎng)關(guān)由于對接很多種不同的協(xié)議，因此可能需要實現(xiàn)很多種調(diào)用方式，比如HTTP、Dubbo等，基于性能原因，最好都采用異步的方式，而Http、Dubbo都是支持異步的，比如apache就提供了基于NIO實現(xiàn)的異步HTTP客戶端。
因為網(wǎng)關(guān)會涉及到很多異步調(diào)用，比如攔截器、HTTP客戶端、dubbo、redis等，因此需要考慮下異步調(diào)用的方式，如果基于回調(diào)或者future的話，代碼嵌套會很深，可讀性很差，可以參考zuul和spring cloud gateway的方案，基于響應式進行改造。
優(yōu)雅下線
優(yōu)雅下線也是網(wǎng)關(guān)需要關(guān)注的一個問題，網(wǎng)關(guān)底層會涉及到很多種協(xié)議，比如HTTP、Dubbo，而HTTP又可以繼續(xù)細分，比如域名、注冊中心等，有些自身就支持優(yōu)雅下線，比如Nginx自身是支持健康監(jiān)測機制的，如果檢測到某一個節(jié)點已經(jīng)掛掉了，就會把這個節(jié)點摘掉，對于應用正常下線，需要結(jié)合發(fā)布系統(tǒng)，首先進行邏輯下線，然后對后續(xù)Nginx的健康監(jiān)測請求直接返回失敗(比如直接返回500),然后等待一段時間(根據(jù)Nginx配置決定)，然后再將應用實際下線掉。另外對于注冊中心的其實也類似，一般注冊中心是只支持手動下線的，可以在邏輯下線階段調(diào)用注冊中心的接口將節(jié)點下線掉，而有些不支持主動下線的，需要結(jié)合緩存的配置，讓應用延遲下線。另外對于其他比如Dubbo等原理也是類似。
性能
網(wǎng)關(guān)作為所有流量的入口，性能是重中之重，早期大部分網(wǎng)關(guān)都是基于同步阻塞模型構(gòu)建的，比如Zuul 1.x。但這種同步的模型我們都知道，每個請求/連接都會占用一個線程，而線程在JVM中是一個很重的資源，比如Tomcat默認就是200個線程，如果網(wǎng)關(guān)隔離沒有做好的話，當發(fā)生網(wǎng)絡(luò)延遲、FullGC、第三方服務慢等情況造成上游服務延遲時，線程池很容易會被打滿，造成新的請求被拒絕，但這個時候其實線程都阻塞在IO上，系統(tǒng)的資源被沒有得到充分的利用。另外一點，容易受網(wǎng)絡(luò)、磁盤IO等延遲影響。需要謹慎設(shè)置超時時間，如果設(shè)置不當，且服務隔離做的不是很完善的話，網(wǎng)關(guān)很容易被一個慢接口拖垮。
而異步化的方式則完全不同，通常情況下一個CPU核啟動一個線程即可處理所有的請求、響應。一個請求的生命周期不再固定于一個線程，而是會分成不同的階段交由不同的線程池處理，系統(tǒng)的資源能夠得到更充分的利用。而且因為線程不再被某一個連接獨占，一個連接所占用的系統(tǒng)資源也會低得多，只是一個文件描述符加上幾個監(jiān)聽器等，而在阻塞模型中，每條連接都會獨占一個線程，而線程是一個非常重的資源。對于上游服務的延遲情況，也能夠得到很大的緩解，因為在阻塞模型中，慢請求會獨占一個線程資源，而異步化之后，因為單條連接所占用的資源變的非常低，系統(tǒng)可以同時處理大量的請求。
如果是JVM平臺，Zuul 2、Spring Cloud gateway等都是不錯的異步網(wǎng)關(guān)選型，另外也可以基于Netty、Spring Boot2.x的webflux、vert.x或者servlet3.1的異步支持進行自研。
緩存
對于一些冪等的get請求，可以在網(wǎng)關(guān)層面根據(jù)業(yè)務方指定的緩存頭做一層緩存，存儲到Redis等二級緩存中，這樣一些重復的請求，可以在網(wǎng)關(guān)層直接處理，而不用打到業(yè)務線，降低業(yè)務方的壓力，另外如果業(yè)務方節(jié)點掛掉，網(wǎng)關(guān)也能夠返回自身的緩存。
限流
限流對于每個業(yè)務組件來說，可以說都是一個必須的組件，如果限流做不好的話，當請求量突增時，很容易導致業(yè)務方的服務掛掉，比如雙11、雙12等大促時，接口的請求量是平時的數(shù)倍，如果沒有評估好容量，又沒有做限流的話，很容易服務整個不可用，因此需要根據(jù)業(yè)務方接口的處理能力，做好限流策略，相信大家都見過淘寶、百度搶紅包時的降級頁面。
因此一定要在接入層做好限流策略，對于非核心接口可以直接將降級掉，保障核心服務的可用性，對于核心接口，需要根據(jù)壓測時得到的接口容量，制定對應的限流策略。限流又分為幾種:
單機。單機性能比較高，不涉及遠程調(diào)用，只是本地計數(shù)，對接口RT影響最小。但需要考慮下限流數(shù)的設(shè)置，比如是針對單臺網(wǎng)關(guān)、還是整個網(wǎng)關(guān)集群，如果是整個集群的話，需要考慮到網(wǎng)關(guān)縮容、擴容時修改對應的限流數(shù)。
分布式。分布式的就需要一個存儲節(jié)點維護當前接口的調(diào)用數(shù)，比如redis、sentinel等，這種方式由于涉及到遠程調(diào)用，會有些性能損耗，另外也需要考慮到存儲掛掉的問題，比如redis如果掛掉，網(wǎng)關(guān)需要考慮降級方案，是降級到本地限流，還是直接將限流功能本身降級掉。
另外還有不同的策略:簡單計數(shù)、令牌桶等，大部分場景下其實簡單計數(shù)已經(jīng)夠用了，但如果需要支持突發(fā)流量等場景時，可以采用令牌桶等方案。還需要考慮根據(jù)什么限流，比如是IP、接口、用戶維度、還是請求參數(shù)中的某些值，這里可以采用表達式，相對比較靈活。
穩(wěn)定性
穩(wěn)定性是網(wǎng)關(guān)非常重要的一環(huán)，監(jiān)控、告警需要做的很完善才可以，比如接口調(diào)用量、響應時間、異常、錯誤碼、成功率等相關(guān)的監(jiān)控告警，還有線程池相關(guān)的一些，比如活躍線程數(shù)、隊列積壓等，還有些系統(tǒng)層面的，比如CPU、內(nèi)存、FullGC這些基本的。
網(wǎng)關(guān)是所有服務的入口，對于網(wǎng)關(guān)的穩(wěn)定性的要求相對于其他服務會更高，最好能夠一直穩(wěn)定的運行，盡量少重啟，但當新增功能、或者加日志排查問題時，不可避免的需要重新發(fā)布，因此可以參考zuul的方式，將所有的核心功能都基于不同的攔截器實現(xiàn)，攔截器的代碼采用Groovy編寫，存儲到數(shù)據(jù)庫中，支持動態(tài)加載、編譯、運行，這樣在出了問題的時候能夠第一時間定位并解決，并且如果網(wǎng)關(guān)需要開發(fā)新功能，只需要增加新的攔截器，并動態(tài)添加到網(wǎng)關(guān)即可，不需要重新發(fā)布。
熔斷降級
熔斷機制也是非常重要的一項。若某一個服務掛掉、接口響應嚴重超時等發(fā)生，則可能整個網(wǎng)關(guān)都被一個接口拖垮，因此需要增加熔斷降級，當發(fā)生特定異常的時候，對接口降級由網(wǎng)關(guān)直接返回，可以基于Hystrix或者Resilience4j實現(xiàn)。
日志
由于所有的請求都是由網(wǎng)關(guān)處理的，因此日志也需要相對比較完善，比如接口的耗時、請求方式、請求IP、請求參數(shù)、響應參數(shù)(注意脫敏)等，另外由于可能涉及到很多微服務，因此需要提供一個統(tǒng)一的traceId方便關(guān)聯(lián)所有的日志，可以將這個traceId置于響應頭中，方便排查問題。
隔離
比如線程池、http連接池、redis等應用層面的隔離，另外也可以根據(jù)業(yè)務場景，將核心業(yè)務部署帶單獨的網(wǎng)關(guān)集群，與其他非核心業(yè)務隔離開。
網(wǎng)關(guān)管控平臺
這塊也是非常重要的一環(huán)，需要考慮好整個流程的用戶體驗，比如接入到網(wǎng)關(guān)的這個流程，能不能盡量簡化、智能，比如如果是dubbo接口，我們可以通過到git倉庫中獲取源碼、解析對應的類、方法，從而實現(xiàn)自動填充，盡量幫用戶減少操作；另外接口一般是從測試->預發(fā)->線上，如果每次都要填寫一遍表單會非常麻煩，我們能不能自動把這個事情做掉，另外如果網(wǎng)關(guān)部署到了多個可用區(qū)、甚至不同的國家，那這個時候，我們還需要接口數(shù)據(jù)同步功能，不然用戶需要到每個后臺都操作一遍，非常麻煩。
這塊個人的建議是直接參考阿里云、aws等提供的網(wǎng)關(guān)服務即可，功能非常全面。
其他
其他還有些需要考慮到的點，比如接口mock，文檔生成、sdk代碼生成、錯誤碼統(tǒng)一、服務治理相關(guān)的等，這里就不累述了。
總結(jié)
目前的網(wǎng)關(guān)還是中心化的架構(gòu)，所有的請求都需要走一次網(wǎng)關(guān)，因此當大促或者流量突增時，網(wǎng)關(guān)可能會成為性能的瓶頸，而且當網(wǎng)關(guān)接入的大量接口的時候，做好流量評估也不是一項容易的工作，每次大促前都需要跟業(yè)務方一起針對接口做壓測，評估出大致的容量，并對網(wǎng)關(guān)進行擴容，而且網(wǎng)關(guān)是所有流量的入口，所有的請求都是由網(wǎng)關(guān)處理，要想準確的評估出容量很復雜。可以參考目前比較流行的ServiceMesh，采用去中心化的方案，將網(wǎng)關(guān)的邏輯下沉到sidecar中，
sidecar和應用部署到同一個節(jié)點，并接管應用流入、流出的流量，這樣大促時，只需要對相關(guān)的業(yè)務壓測，并針對性擴容即可，另外升級也會更平滑，中心化的網(wǎng)關(guān)，即使灰度發(fā)布，但是理論上所有業(yè)務方的流量都會流入到新版本的網(wǎng)關(guān)，如果出了問題，會影響到所有的業(yè)務，但這種去中心化的方式，可以先針對非核心業(yè)務升級，觀察一段時間沒問題后，再全量推上線。另外ServiceMesh的方案，對于多語言支持也更友好
source:https://www.yuque.com/huanmeng-ftsgv/shang/lpfdlr#WP8MM
推薦閱讀
關(guān)于程序員大白
程序員大白是一群哈工大，東北大學，西湖大學和上海交通大學的碩士博士運營維護的號，大家樂于分享高質(zhì)量文章，喜歡總結(jié)知識，歡迎關(guān)注[程序員大白]，大家一起學習進步！