2021-02-01 分類: 網(wǎng)站建設
前言
假設你正在開發(fā)一個電商網(wǎng)站,那么這里會涉及到很多后端的微服務,比如會員、商品、推薦服務等等。
域名(
http://service.api.company.com),但這種方式會有幾個問題:
API Gateway
更好的方式是采用API網(wǎng)關,實現(xiàn)一個API網(wǎng)關接管所有的入口流量,類似Nginx的作用,將所有用戶的請求轉(zhuǎn)發(fā)給后端的服務器,但網(wǎng)關做的不僅僅只是簡單的轉(zhuǎn)發(fā),也會針對流量做一些擴展,比如鑒權(quán)、限流、權(quán)限、熔斷、協(xié)議轉(zhuǎn)換、錯誤碼統(tǒng)一、緩存、日志、監(jiān)控、告警等,這樣將通用的邏輯抽出來,由網(wǎng)關統(tǒng)一去做,業(yè)務方也能夠更專注于業(yè)務邏輯,提升迭代的效率。
通過引入API網(wǎng)關,客戶端只需要與API網(wǎng)關交互,而不用與各個業(yè)務方的接口分別通訊,但多引入一個組件就多引入了一個潛在的故障點,因此要實現(xiàn)一個高性能、穩(wěn)定的網(wǎng)關,也會涉及到很多點。
API注冊
業(yè)務方如何接入網(wǎng)關?一般來說有幾種方式。
協(xié)議轉(zhuǎn)換
內(nèi)部的API可能是由很多種不同的協(xié)議實現(xiàn)的,比如HTTP、Dubbo、GRPC等,但對于用戶來說其中很多都不是很友好,或者根本沒法對外暴露,比如Dubbo服務,因此需要在網(wǎng)關層做一次協(xié)議轉(zhuǎn)換,將用戶的HTTP協(xié)議請求,在網(wǎng)關層轉(zhuǎn)換成底層對應的協(xié)議,比如HTTP -> Dubbo, 但這里需要注意很多問題,比如參數(shù)類型,如果類型搞錯了,導致轉(zhuǎn)換出問題,而日志又不夠詳細的話,問題會很難定位。
服務發(fā)現(xiàn)
網(wǎng)關作為流量的入口,負責請求的轉(zhuǎn)發(fā),但首先需要知道轉(zhuǎn)發(fā)給誰,如何尋址,這里有幾種方式:
服務調(diào)用
網(wǎng)關由于對接很多種不同的協(xié)議,因此可能需要實現(xiàn)很多種調(diào)用方式,比如HTTP、Dubbo等,基于性能原因,最好都采用異步的方式,而Http、Dubbo都是支持異步的,比如apache就提供了基于NIO實現(xiàn)的異步HTTP客戶端。
因為網(wǎng)關會涉及到很多異步調(diào)用,比如攔截器、HTTP客戶端、dubbo、redis等,因此需要考慮下異步調(diào)用的方式,如果基于回調(diào)或者future的話,代碼嵌套會很深,可讀性很差,可以參考zuul和spring cloud gateway的方案,基于響應式進行改造。
優(yōu)雅下線
優(yōu)雅下線也是網(wǎng)關需要關注的一個問題,網(wǎng)關底層會涉及到很多種協(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)關作為所有流量的入口,性能是重中之重,早期大部分網(wǎng)關都是基于同步阻塞模型構(gòu)建的,比如Zuul 1.x。但這種同步的模型我們都知道,每個請求/連接都會占用一個線程,而線程在JVM中是一個很重的資源,比如Tomcat默認就是200個線程,如果網(wǎng)關隔離沒有做好的話,當發(fā)生網(wǎng)絡延遲、FullGC、第三方服務慢等情況造成上游服務延遲時,線程池很容易會被打滿,造成新的請求被拒絕,但這個時候其實線程都阻塞在IO上,系統(tǒng)的資源被沒有得到充分的利用。另外一點,容易受網(wǎng)絡、磁盤IO等延遲影響。需要謹慎設置超時時間,如果設置不當,且服務隔離做的不是很完善的話,網(wǎng)關很容易被一個慢接口拖垮。
而異步化的方式則完全不同,通常情況下一個CPU核啟動一個線程即可處理所有的請求、響應。一個請求的生命周期不再固定于一個線程,而是會分成不同的階段交由不同的線程池處理,系統(tǒng)的資源能夠得到更充分的利用。而且因為線程不再被某一個連接獨占,一個連接所占用的系統(tǒng)資源也會低得多,只是一個文件描述符加上幾個監(jiān)聽器等,而在阻塞模型中,每條連接都會獨占一個線程,而線程是一個非常重的資源。對于上游服務的延遲情況,也能夠得到很大的緩解,因為在阻塞模型中,慢請求會獨占一個線程資源,而異步化之后,因為單條連接所占用的資源變的非常低,系統(tǒng)可以同時處理大量的請求。
如果是JVM平臺,Zuul 2、Spring Cloud gateway等都是不錯的異步網(wǎng)關選型,另外也可以基于Netty、Spring Boot2.x的webflux、vert.x或者servlet3.1的異步支持進行自研。
緩存
對于一些冪等的get請求,可以在網(wǎng)關層面根據(jù)業(yè)務方指定的緩存頭做一層緩存,存儲到Redis等二級緩存中,這樣一些重復的請求,可以在網(wǎng)關層直接處理,而不用打到業(yè)務線,降低業(yè)務方的壓力,另外如果業(yè)務方節(jié)點掛掉,網(wǎng)關也能夠返回自身的緩存。
限流
限流對于每個業(yè)務組件來說,可以說都是一個必須的組件,如果限流做不好的話,當請求量突增時,很容易導致業(yè)務方的服務掛掉,比如雙11、雙12等大促時,接口的請求量是平時的數(shù)倍,如果沒有評估好容量,又沒有做限流的話,很容易服務整個不可用,因此需要根據(jù)業(yè)務方接口的處理能力,做好限流策略,相信大家都見過淘寶、百度搶紅包時的降級頁面。
因此一定要在接入層做好限流策略,對于非核心接口可以直接將降級掉,保障核心服務的可用性,對于核心接口,需要根據(jù)壓測時得到的接口容量,制定對應的限流策略。限流又分為幾種:
另外還有不同的策略:簡單計數(shù)、令牌桶等,大部分場景下其實簡單計數(shù)已經(jīng)夠用了,但如果需要支持突發(fā)流量等場景時,可以采用令牌桶等方案。還需要考慮根據(jù)什么限流,比如是IP、接口、用戶維度、還是請求參數(shù)中的某些值,這里可以采用表達式,相對比較靈活。
穩(wěn)定性
穩(wěn)定性是網(wǎng)關非常重要的一環(huán),監(jiān)控、告警需要做的很完善才可以,比如接口調(diào)用量、響應時間、異常、錯誤碼、成功率等相關的監(jiān)控告警,還有線程池相關的一些,比如活躍線程數(shù)、隊列積壓等,還有些系統(tǒng)層面的,比如CPU、內(nèi)存、FullGC這些基本的。
網(wǎng)關是所有服務的入口,對于網(wǎng)關的穩(wěn)定性的要求相對于其他服務會更高,最好能夠一直穩(wěn)定的運行,盡量少重啟,但當新增功能、或者加日志排查問題時,不可避免的需要重新發(fā)布,因此可以參考zuul的方式,將所有的核心功能都基于不同的攔截器實現(xiàn),攔截器的代碼采用Groovy編寫,存儲到數(shù)據(jù)庫中,支持動態(tài)加載、編譯、運行,這樣在出了問題的時候能夠第一時間定位并解決,并且如果網(wǎng)關需要開發(fā)新功能,只需要增加新的攔截器,并動態(tài)添加到網(wǎng)關即可,不需要重新發(fā)布。
熔斷降級
熔斷機制也是非常重要的一項。若某一個服務掛掉、接口響應嚴重超時等發(fā)生,則可能整個網(wǎng)關都被一個接口拖垮,因此需要增加熔斷降級,當發(fā)生特定異常的時候,對接口降級由網(wǎng)關直接返回,可以基于Hystrix或者Resilience4j實現(xiàn)。
日志
由于所有的請求都是由網(wǎng)關處理的,因此日志也需要相對比較完善,比如接口的耗時、請求方式、請求IP、請求參數(shù)、響應參數(shù)(注意脫敏)等,另外由于可能涉及到很多微服務,因此需要提供一個統(tǒng)一的traceId方便關聯(lián)所有的日志,可以將這個traceId置于響應頭中,方便排查問題。
隔離
比如線程池、http連接池、redis等應用層面的隔離,另外也可以根據(jù)業(yè)務場景,將核心業(yè)務部署帶單獨的網(wǎng)關集群,與其他非核心業(yè)務隔離開。
網(wǎng)關管控平臺
這塊也是非常重要的一環(huán),需要考慮好整個流程的用戶體驗,比如接入到網(wǎng)關的這個流程,能不能盡量簡化、智能,比如如果是dubbo接口,我們可以通過到git倉庫中獲取源碼、解析對應的類、方法,從而實現(xiàn)自動填充,盡量幫用戶減少操作;另外接口一般是從測試->預發(fā)->線上,如果每次都要填寫一遍表單會非常麻煩,我們能不能自動把這個事情做掉,另外如果網(wǎng)關部署到了多個可用區(qū)、甚至不同的國家,那這個時候,我們還需要接口數(shù)據(jù)同步功能,不然用戶需要到每個后臺都操作一遍,非常麻煩。
這塊個人的建議是直接參考阿里云、aws等提供的網(wǎng)關服務即可,功能非常全面。
其他
其他還有些需要考慮到的點,比如接口mock,文檔生成、sdk代碼生成、錯誤碼統(tǒng)一、服務治理相關的等,這里就不累述了。
總結(jié)
目前的網(wǎng)關還是中心化的架構(gòu),所有的請求都需要走一次網(wǎng)關,因此當大促或者流量突增時,網(wǎng)關可能會成為性能的瓶頸,而且當網(wǎng)關接入的大量接口的時候,做好流量評估也不是一項容易的工作,每次大促前都需要跟業(yè)務方一起針對接口做壓測,評估出大致的容量,并對網(wǎng)關進行擴容,而且網(wǎng)關是所有流量的入口,所有的請求都是由網(wǎng)關處理,要想準確的評估出容量很復雜??梢詤⒖寄壳氨容^流行的ServiceMesh,采用去中心化的方案,將網(wǎng)關的邏輯下沉到sidecar中,sidecar和應用部署到同一個節(jié)點,并接管應用流入、流出的流量,這樣大促時,只需要對相關的業(yè)務壓測,并針對性擴容即可,另外升級也會更平滑,中心化的網(wǎng)關,即使灰度發(fā)布,但是理論上所有業(yè)務方的流量都會流入到新版本的網(wǎng)關,如果出了問題,會影響到所有的業(yè)務,但這種去中心化的方式,可以先針對非核心業(yè)務升級,觀察一段時間沒問題后,再全量推上線。另外ServiceMesh的方案,對于多語言支持也更友好。
標題名稱:API網(wǎng)關:API 網(wǎng)關從入門到放棄
當前鏈接:http://m.rwnh.cn/news12/98562.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站導航、微信小程序、定制開發(fā)、App開發(fā)、外貿(mào)網(wǎng)站建設、品牌網(wǎng)站設計
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容