什么是API網(wǎng)關(guān)
API網(wǎng)關(guān)（API Gateway），從本質(zhì)上講是一個技術(shù)產(chǎn)品戴而，旨在提供API托管服務(wù)凑术，覆蓋設(shè)計(jì)、開發(fā)所意、測試淮逊、發(fā)布、運(yùn)營扁眯、運(yùn)維監(jiān)測、安全管控翅帜、下線等API各個生命周期階段姻檀，幫助開發(fā)人員快速建設(shè)以API為核心的系統(tǒng)架構(gòu)。常見的應(yīng)用場景有：（1）構(gòu)建集成中臺涝滴，即利用API網(wǎng)關(guān)豐富的適配組件和強(qiáng)大集成能力绣版，實(shí)現(xiàn)復(fù)雜業(yè)務(wù)系統(tǒng)的統(tǒng)一調(diào)用及管理胶台；（2）構(gòu)建多種類技術(shù)架構(gòu)，融合Serverless架構(gòu)杂抽、微服務(wù)架構(gòu)诈唬、前后臺分離架構(gòu)等；（3）構(gòu)建API生態(tài)缩麸，以企業(yè)核心業(yè)務(wù)打通上下游企業(yè)的數(shù)據(jù)流铸磅，幫助企業(yè)實(shí)現(xiàn)從傳統(tǒng)供應(yīng)鏈到價值鏈轉(zhuǎn)型。
應(yīng)運(yùn)而生的API網(wǎng)關(guān)
在從中國制造到中國智造的創(chuàng)新之路上杭朱，大量的傳統(tǒng)經(jīng)濟(jì)實(shí)體正在逐步逐步地?cái)?shù)字化轉(zhuǎn)型阅仔，撇開組織意識形態(tài)的數(shù)字化轉(zhuǎn)型不談，聚焦在傳統(tǒng)IT領(lǐng)域的數(shù)字化轉(zhuǎn)型弧械，基本的策略就是ABC戰(zhàn)略八酒，即AI、BigData和Cloud刃唐，而這三者又以Cloud作為基礎(chǔ)架構(gòu)必須為先行者羞迷，且最容易落地，加之企業(yè)的數(shù)據(jù)安全考慮等多種因素画饥，在Cloud戰(zhàn)略層面衔瓮，實(shí)體經(jīng)濟(jì)絕大部分都選擇混合云架構(gòu)，傳統(tǒng)制造型荒澡、IoT物聯(lián)網(wǎng)等應(yīng)用會選擇落地在企業(yè)專有云（Azure Stack/Ali Apsara等）或者私有云（Openstack/vmWare等）报辱。而面向C端用戶、營銷領(lǐng)域等應(yīng)用因?yàn)楸仨毭鎸ち业氖袌龈偁幁h(huán)境单山，所以往往會選擇能力成熟度更高的公有云落地碍现。在ABC戰(zhàn)略之下，企業(yè)的數(shù)字化轉(zhuǎn)型的一個重要舉措就是從服務(wù)2b到2c的延展米奸，其核心思想就是縮短供應(yīng)鏈的鏈路昼接，減少中間成本，因此傳統(tǒng)的monolithic應(yīng)用在2c應(yīng)用場景下悴晰，無論是并發(fā)慢睡、吞吐量還是可用性都在全面經(jīng)受挑戰(zhàn)，此時微服務(wù)應(yīng)運(yùn)而生铡溪。而2c轉(zhuǎn)型直白一點(diǎn)說就是直面消費(fèi)者漂辐，移動app就成為了2c服務(wù)的最重要的觸點(diǎn)。前后端的絕對分離棕硫，要求的就是后端服務(wù)的暴露的安全性管控的同時又能方便地進(jìn)行管理髓涯。此時API網(wǎng)關(guān)就在微服務(wù)和移動app之間構(gòu)建起來了一個最重要的分層，而對于一個實(shí)體經(jīng)濟(jì)而言API網(wǎng)關(guān)也必然面臨著混合云架構(gòu)的挑戰(zhàn)哈扮。
雙擎微服務(wù)的最佳搭檔
上一段落已經(jīng)簡述了微服務(wù)如何催生了API網(wǎng)關(guān)纬纪，關(guān)于這一點(diǎn)從兩大微服務(wù)體系的崛起過程也可以看出蚓再，Dubbo2012年開源的時候主要以阿里的大廠效應(yīng)，被眾多互聯(lián)網(wǎng)公司推崇包各，當(dāng)時也沒有明顯地提出微服務(wù)網(wǎng)關(guān)的概念摘仅，基本上都是自家開發(fā)open api。2014年微服務(wù)的概念被Martin Fowler提到以后问畅，Pivotal團(tuán)隊(duì)以Spring Boot為核心簡化開發(fā)之后對分布式組件進(jìn)行了整合（服務(wù)發(fā)現(xiàn)/注冊娃属，路由，負(fù)載均衡等）按声，并要求所有請求都統(tǒng)一通過API網(wǎng)關(guān)（Zuul）來訪問內(nèi)部服務(wù)膳犹，網(wǎng)關(guān)接收請求后，從Eureka獲取可用服務(wù)签则，由Ribbon進(jìn)行負(fù)載均衡后须床，分發(fā)到后端的具體實(shí)例，微服務(wù)之間通過Feign進(jìn)行通信處理業(yè)務(wù)渐裂，至此微服務(wù)體系的腳手架逐步被眾多Spring開發(fā)者所接受豺旬。而API網(wǎng)關(guān)之于Dubbo或者Spring Cloud而言都是一個毋庸置疑的必要組件，否則無法實(shí)現(xiàn)嚴(yán)格的前后端分離柒凉、無法滿足安全需求等族阅，當(dāng)然Dubbo的微服務(wù)網(wǎng)關(guān)時至今日始終沒有全家桶的套餐，在Dubbo官網(wǎng)的生態(tài)系統(tǒng)上可以看到API網(wǎng)關(guān)有三個：Kong/Dubbo Proxy/zuul膝捞。
Spring Cloud已經(jīng)放棄了Zuul坦刀，雖然Netflix升級為Zuul2，同時Spring Cloud也更推薦Spring Cloud Gateway蔬咬，同時支持整個Sping生態(tài)鲤遥，這個命名頗有些耍流氓的感覺，正如Zippo林艘。Dubbo Proxy對于開發(fā)而言需要大量的代碼盖奈，其純Code風(fēng)格正在變得越來越不親民，正其時Kong大行其道狐援。
目前由于Spring的生態(tài)較好钢坦，使用Kong直接作為微服務(wù)網(wǎng)關(guān)無法直接對接注冊中心（無論是zookeeper還是Nacos或者etcd都需要獨(dú)立開發(fā)Plugins），因此直接將Kong作為微服務(wù)網(wǎng)關(guān)的案例還較少啥酱，但是基于Nginx的Kong在性能上無論是理論還是實(shí)測其tps在同等硬件消耗的條件下爹凹，都好于zuul或者spring cloud gateway。通過插件開發(fā)統(tǒng)一對接了Dubbo的ZK注冊中心和Spring Cloud的Nacos注冊中心镶殷，將異構(gòu)的微服務(wù)統(tǒng)一注冊到Kong API網(wǎng)關(guān)禾酱，同時減少了Http請求鏈路長度。
Monolithic應(yīng)用的救贖
這邊2C應(yīng)用的微服務(wù)建設(shè)的如火如荼，好似傳統(tǒng)單體應(yīng)用可以偏安一隅宇植，然而實(shí)際上2C應(yīng)用的觸點(diǎn)的直接下一層是微服務(wù)不錯，也有效解決了并發(fā)埋心、高可用等問題指郁，但是不可避免地要將部分請求下探到傳統(tǒng)單體應(yīng)用，比如BOM拷呆、主數(shù)據(jù)等闲坎。而反應(yīng)遲鈍的傳統(tǒng)2B應(yīng)用此時才發(fā)覺大火已經(jīng)燒到了家門口，匆忙之間進(jìn)行微服務(wù)化顯然是不現(xiàn)實(shí)的茬斧，如何化解燃眉之急呢腰懂？
場景一：利用API網(wǎng)關(guān)的快速DB2API功能，實(shí)現(xiàn)數(shù)據(jù)庫到API的直接轉(zhuǎn)化项秉，同時注冊到Kong API網(wǎng)關(guān)绣溜，根據(jù)請求方分配不同的access id，對不同的access id進(jìn)行一定級別的限流娄蔼，可以快速滿足2C的快速應(yīng)用場景怖喻。
場景二：直接將原有單體應(yīng)用的接口（SOAP居多）注冊到Kong API網(wǎng)關(guān)，同樣根據(jù)請求方分配不同的access id岁诉，對不同的access id進(jìn)行一定級別的限流锚沸，可以防止單體應(yīng)用系統(tǒng)應(yīng)用負(fù)載過多而影響其正常業(yè)務(wù)操作。
上述兩個場景可以以最小的代價涕癣，最快的速度響應(yīng)2C應(yīng)用的急速擴(kuò)張哗蜈，從而留下喘息的時間進(jìn)行微服務(wù)改造、接口改造坠韩、資源擴(kuò)充等距潘。
混合多云下的多面手
作為一個API網(wǎng)關(guān)扳躬，既可以直接作為微服務(wù)網(wǎng)關(guān)用执赡，亦可以兼容異構(gòu)的微服務(wù)體系，同時將傳統(tǒng)數(shù)據(jù)庫變現(xiàn)API快速滿足業(yè)務(wù)需求派草，單體應(yīng)用接口上架API網(wǎng)關(guān)防止上游請求擊穿傳統(tǒng)應(yīng)用服務(wù)须蜗。下圖是一個混合云環(huán)境下分布式微服務(wù)API網(wǎng)關(guān)為中心的最佳實(shí)踐硅确。主要要素解釋如下：
1、各類中間件：緩存明肮、消息菱农、數(shù)據(jù)庫等
2、基于適配原則的中間適配代碼層
3柿估、微服務(wù)網(wǎng)關(guān)循未、注冊中心、配置中心等關(guān)鍵組件
4、統(tǒng)一的管理平臺：
4.1的妖、API內(nèi)管平臺：前后端開發(fā)和測試的協(xié)作平臺绣檬，面向全生命周期的API實(shí)踐
4.2、統(tǒng)一日志平臺：通過同構(gòu)的分布式網(wǎng)關(guān)將不同數(shù)據(jù)中心的日志回傳至統(tǒng)一的日志平臺
4.3嫂粟、統(tǒng)一鏈路追蹤平臺：提供從前后端分離的網(wǎng)關(guān)到鏈路底層的追蹤平臺
寫在最后
企業(yè)級的API網(wǎng)關(guān)解決方案往往不能像互聯(lián)網(wǎng)那樣干脆利索娇未，因?yàn)槠髽I(yè)有著悠久輝煌的歷史，自然包袱也是少不了的星虹，長久以來作為成本中心的企業(yè)IT零抬，在全面進(jìn)行數(shù)字化轉(zhuǎn)型的過程中，必然不能太過于激進(jìn)宽涌，兼容并蓄才能更有落地性平夜，因此API網(wǎng)關(guān)在企業(yè)的實(shí)踐需要考慮更復(fù)雜的應(yīng)用場景，既要面向未來的技術(shù)趨勢卸亮，也要兼顧到遺留系統(tǒng)的自然延續(xù)性忽妒。
