一靖榕、什么是API網(wǎng)關(guān)
API網(wǎng)關(guān)是一個(gè)進(jìn)入系統(tǒng)的單一入口點(diǎn)的服務(wù)器欧聘。它類似于面向?qū)ο笤O(shè)計(jì)的門面模式。API網(wǎng)關(guān)封裝了內(nèi)部系統(tǒng)架構(gòu)员淫，并提供了針對每個(gè)客戶端定制的API合蔽。它可能具有其他職責(zé)，例如認(rèn)證介返，監(jiān)視拴事，負(fù)載平衡沃斤，緩存，請求整形和管理以及靜態(tài)響應(yīng)處理刃宵。
微服務(wù)場景下衡瓶，每一個(gè)微服務(wù)對外暴露了一組細(xì)粒度的服務(wù)∩ぃ客戶端的請求可能會(huì)涉及到一串的服務(wù)調(diào)用哮针，如果將這些微服務(wù)都暴露給客戶端，那么會(huì)增加客戶端代碼的復(fù)雜度坦袍。
參考GOF設(shè)計(jì)模式中的Facade模式十厢，將細(xì)粒度的服務(wù)組合起來提供一個(gè)粗粒度的服務(wù)，所有請求都導(dǎo)入一個(gè)統(tǒng)一的入口捂齐，那么整個(gè)服務(wù)只需要暴露一個(gè)api蛮放，對外屏蔽了服務(wù)端的實(shí)現(xiàn)細(xì)節(jié)，也減少了客戶端與服務(wù)器的網(wǎng)絡(luò)調(diào)用次數(shù)辛燥。這就是api gateway筛武。
有了api gateway之后，一些與業(yè)務(wù)關(guān)系并不大的通用處理邏輯可以從api gateway中剝離出來挎塌，api gateway僅僅負(fù)責(zé)服務(wù)的編排與結(jié)果的組裝徘六。
二、API網(wǎng)關(guān)優(yōu)缺點(diǎn)
網(wǎng)關(guān)的作用
1榴都、確贝猓客戶端無法察覺應(yīng)用程序是如何被拆分為多項(xiàng)微服務(wù)的。
2嘴高、確备鸵簦客戶端不受服務(wù)實(shí)例的位置的影響。
3拴驮、為每套客戶端提供最優(yōu)API春瞬。
4、降低請求/往返次數(shù)套啤。舉例來說宽气，API網(wǎng)關(guān)能夠確保客戶端在單次往返中就從多項(xiàng)服務(wù)中檢索出數(shù)據(jù)潜沦。請求數(shù)量更少意味著運(yùn)行負(fù)擔(dān)更低且用戶體驗(yàn)更好萄涯。API網(wǎng)關(guān)對于移動(dòng)應(yīng)用而言是必不可少的。
5唆鸡、將從客戶端調(diào)用多項(xiàng)服務(wù)的邏輯轉(zhuǎn)換為從API網(wǎng)關(guān)處調(diào)用涝影，從而簡化整個(gè)客戶端
API 網(wǎng)關(guān)出現(xiàn)的原因是微服務(wù)架構(gòu)的出現(xiàn)，不同的微服務(wù)一般會(huì)有不同的網(wǎng)絡(luò)地址争占，而外部客戶端可能需要調(diào)用多個(gè)服務(wù)的接口才能完成一個(gè)業(yè)務(wù)需求燃逻，如果讓客戶端直接與各個(gè)微服務(wù)通信序目，會(huì)有以下的問題：
1. 客戶端會(huì)多次請求不同的微服務(wù)，增加了客戶端的復(fù)雜性唆樊。
2. 存在跨域請求宛琅，在一定場景下處理相對復(fù)雜。
3. 認(rèn)證復(fù)雜逗旁，每個(gè)服務(wù)都需要獨(dú)立認(rèn)證嘿辟。
4. 難以重構(gòu)，隨著項(xiàng)目的迭代片效，可能需要重新劃分微服務(wù)红伦。例如，可能將多個(gè)服務(wù)合并成一個(gè)或者將一個(gè)服務(wù)拆分成多個(gè)淀衣。如果客戶端直接與微服務(wù)通信昙读，那么重構(gòu)將會(huì)很難實(shí)施。
5. 某些微服務(wù)可能使用了防火墻 / 瀏覽器不友好的協(xié)議膨桥，直接訪問會(huì)有一定的困難蛮浑。
使用API??網(wǎng)關(guān)的一個(gè)主要好處是它封裝了應(yīng)用程序的內(nèi)部結(jié)構(gòu)≈幌客戶端只需要與網(wǎng)關(guān)通話沮稚，而不必調(diào)用特定的服務(wù)。API網(wǎng)關(guān)為每種類型的客戶端提供特定的API册舞。這減少了客戶端和應(yīng)用程序之間的往返次數(shù)蕴掏。它還簡化了客戶端代碼。
API網(wǎng)關(guān)也有一些缺點(diǎn)调鲸。它是另一個(gè)高度可用的組件盛杰，必須開發(fā)，部署和管理藐石。還有一個(gè)風(fēng)險(xiǎn)是API網(wǎng)關(guān)成為開發(fā)瓶頸即供。開發(fā)人員必須更新API網(wǎng)關(guān)才能公開每個(gè)微服務(wù)的端點(diǎn)。重要的是于微，更新API網(wǎng)關(guān)的過程盡可能輕量級募狂。否則，開發(fā)人員將被迫排隊(duì)等待以更新網(wǎng)關(guān)角雷。盡管有這些缺點(diǎn)，然而性穿，對于大多數(shù)現(xiàn)實(shí)世界的應(yīng)用程序勺三，使用API??網(wǎng)關(guān)是有意義的。
三需曾、應(yīng)用的無狀態(tài)化以及微服務(wù)邊界問題
很多網(wǎng)站一開始可能不是微服務(wù)化的吗坚，在早期的一些項(xiàng)目里祈远，我們?yōu)榱丝焖偕暇€交付，會(huì)做一些單體的應(yīng)用商源。隨著訂單量的發(fā)展车份，我們就開始做所謂的“微服務(wù)化”，第一步是把所謂的單體應(yīng)用牡彻，變成應(yīng)用的無狀態(tài)化扫沼，以登錄SSO來看，就是一種解決去狀態(tài)化的方法庄吼。我們會(huì)拿到一個(gè)token缎除，每次訪問都會(huì)帶著token，這就是所謂的去狀態(tài)化总寻。之后每一個(gè)應(yīng)用都有橫向可擴(kuò)的能力器罐。當(dāng)訪問量大的時(shí)候，就可以通過加服務(wù)器來增強(qiáng)水平擴(kuò)展的能力渐行。
部署單片應(yīng)用程序意味著運(yùn)行單個(gè)通常是大型應(yīng)用程序的多個(gè)相同副本轰坊。您通常配置N個(gè)服務(wù)器（物理或虛擬），并在每個(gè)服務(wù)器上運(yùn)行應(yīng)用程序的M個(gè)實(shí)例祟印。單片應(yīng)用程序的部署并不總是完全直接的肴沫，但它比部署微服務(wù)應(yīng)用程序簡單得多。
邊界問題應(yīng)該是微服務(wù)難點(diǎn)之一旁理，因?yàn)檫吔鐔栴}直接影響模塊劃分顆粒度的劃分樊零，定義不同域模型，最終會(huì)影響到整個(gè)項(xiàng)目的水平孽文、甚至垂直擴(kuò)展性問題驻襟，如果不合理服務(wù)重構(gòu)的可能性會(huì)大幅增加。結(jié)合業(yè)務(wù)特性芋哭，項(xiàng)目主要?jiǎng)澐纸邮掌鞣?wù)沉衣，派發(fā)服務(wù)，處理器服務(wù)减牺，API服務(wù)豌习，客戶端服務(wù)以及最終展示頁面服務(wù)。
四拔疚、API網(wǎng)關(guān)的相關(guān)技術(shù)
在支持異步肥隆，非阻塞I / O的平臺上構(gòu)建API網(wǎng)關(guān)是有意義的。有多種不同的技術(shù)可以用于實(shí)現(xiàn)可擴(kuò)展的API網(wǎng)關(guān)稚失。
1栋艳、在JVM上，您可以使用基于NIO的框架之一句各，如Netty吸占、Vertx晴叨、Spring Reactor或JBoss Undertow。
2矾屯、一個(gè)流行的非JVM選項(xiàng)是Node.js兼蕊，它是一個(gè)基于Chrome的JavaScript引擎的平臺。
3件蚕、另一個(gè)選擇是使用NGINX Plus孙技。NGINX Plus提供了一個(gè)成熟的，可擴(kuò)展的高性能Web服務(wù)器和反向代理骤坐，易于部署绪杏，配置和編程。
4纽绍、Openresty作為api gateway
參考
1蕾久、服務(wù)網(wǎng)關(guān)-Zuul
2、微服務(wù)四大網(wǎng)關(guān)性能對比
3拌夏、千萬級調(diào)用量微服務(wù)架構(gòu)實(shí)踐
4僧著、構(gòu)建微服務(wù)：使用API??網(wǎng)關(guān)
5、從分布式一致性談到CAP理論障簿、BASE理論
6盹愚、API 網(wǎng)關(guān)設(shè)計(jì) （Rest 風(fēng)格）
7、微服務(wù)中網(wǎng)關(guān)（API Gateway）的技術(shù)選型
8站故、架構(gòu)師進(jìn)階之九Consul+Openresty作為api gateway
