微服務(wù)實(shí)戰(zhàn)（二）：使用API Gateway

【編者的話】本系列的第一篇介紹了微服務(wù)架構(gòu)模式。它討論了采用微服務(wù)的優(yōu)點(diǎn)和缺點(diǎn)柿究，除了一些復(fù)雜的微服務(wù)，這種模式還是復(fù)雜應(yīng)用的理想選擇奔缠。

當(dāng)你決定將應(yīng)用作為一組微服務(wù)時(shí)蜻底，需要決定應(yīng)用客戶(hù)端如何與微服務(wù)交互。在單體式程序中拔稳，通常只有一組冗余的或者負(fù)載均衡的服務(wù)提供點(diǎn)葛峻。在微服務(wù)架構(gòu)中，每一個(gè)微服務(wù)暴露一組細(xì)粒度的服務(wù)提供點(diǎn)巴比。在本篇文章中术奖，我們來(lái)看它如何影響客戶(hù)端到服務(wù)端通信，同時(shí)提出一種API Gateway的方法轻绞。

介紹

假定你正在為在線購(gòu)物應(yīng)用開(kāi)發(fā)一個(gè)原生手機(jī)客戶(hù)端采记。你需要實(shí)現(xiàn)一個(gè)產(chǎn)品最終頁(yè)來(lái)展示商品信息。

例如政勃，下面的圖展示了你在亞馬遜Android客戶(hù)端上滑動(dòng)產(chǎn)品最終頁(yè)時(shí)看到的信息唧龄。

雖然這是一個(gè)智能手機(jī)應(yīng)用，這個(gè)產(chǎn)品最終頁(yè)展示了非常多的信息稼病。例如选侨，不僅這里有產(chǎn)品基本信息（名字、描述和價(jià)格）然走，還有以下內(nèi)容：

購(gòu)物車(chē)中的物品數(shù)

下單歷史

用戶(hù)評(píng)論

低庫(kù)存警告

快遞選項(xiàng)

各式各樣的推薦援制，包括經(jīng)常跟這個(gè)物品一起被購(gòu)買(mǎi)的產(chǎn)品、購(gòu)買(mǎi)該物品的其他顧客購(gòu)買(mǎi)的產(chǎn)品以及購(gòu)買(mǎi)該產(chǎn)品的顧客還瀏覽了哪些產(chǎn)品芍瑞。

可選的購(gòu)物選項(xiàng)

當(dāng)采用一個(gè)單體式應(yīng)用架構(gòu)晨仑，一個(gè)移動(dòng)客戶(hù)端將會(huì)通過(guò)一個(gè)REST請(qǐng)求（GET api.company.com/productdetails/productId）來(lái)獲取這些數(shù)據(jù)。一個(gè)負(fù)載均衡將請(qǐng)求分發(fā)到多個(gè)應(yīng)用實(shí)例之一。應(yīng)用將查詢(xún)各種數(shù)據(jù)庫(kù)并返回請(qǐng)求給客戶(hù)端洪己。

相對(duì)的妥凳，若是采用微服務(wù)架構(gòu)，最終頁(yè)上的數(shù)據(jù)會(huì)分布在不同的微服務(wù)上答捕。下面列舉了可能與產(chǎn)品最終頁(yè)數(shù)據(jù)有關(guān)的一些微服務(wù)：

購(gòu)物車(chē)服務(wù) -- 購(gòu)物車(chē)中的物品數(shù)

下單服務(wù) -- 下單歷史

分類(lèi)服務(wù) -- 基本產(chǎn)品信息逝钥，如名字、圖片和價(jià)格

評(píng)論服務(wù) -- 用戶(hù)評(píng)論

庫(kù)存服務(wù) -- 低庫(kù)存警告

快遞服務(wù) -- 快遞選項(xiàng)拱镐、截止時(shí)間艘款、來(lái)自不同快遞API的成本計(jì)算

推薦服務(wù) -- 推薦產(chǎn)品

我們需要決定移動(dòng)客戶(hù)端如何訪問(wèn)這些服務(wù)。請(qǐng)看下面這幾種方式

客戶(hù)端到微服務(wù)直接通信

理論上說(shuō)沃琅，一個(gè)客戶(hù)端可以直接給多個(gè)微服務(wù)中的任何一個(gè)發(fā)起請(qǐng)求哗咆。每一個(gè)微服務(wù)都會(huì)有一個(gè)對(duì)外服務(wù)端(https://serviceName.api.company.name)。這個(gè)URL可能會(huì)映射到微服務(wù)的負(fù)載均衡上益眉，它再轉(zhuǎn)發(fā)請(qǐng)求到具體節(jié)點(diǎn)上晌柬。為了搜索產(chǎn)品細(xì)節(jié)，移動(dòng)端需要向上述微服務(wù)逐個(gè)發(fā)請(qǐng)求郭脂。

不幸的是年碘，這個(gè)方案有很多困難和限制。其中一個(gè)問(wèn)題是客戶(hù)端的需求量與每個(gè)微服務(wù)暴露的細(xì)粒度API數(shù)量的不匹配朱庆。如圖中盛泡，客戶(hù)端需要7次單獨(dú)請(qǐng)求。在更復(fù)雜的場(chǎng)景中娱颊，可能會(huì)需要更多次請(qǐng)求。例如凯砍，亞馬遜的產(chǎn)品最終頁(yè)要請(qǐng)求數(shù)百個(gè)微服務(wù)箱硕。雖然一個(gè)客戶(hù)端可以通過(guò)LAN發(fā)起很多個(gè)請(qǐng)求，但是在公網(wǎng)上這樣會(huì)很沒(méi)有效率悟衩，這個(gè)問(wèn)題在移動(dòng)互聯(lián)網(wǎng)上尤為突出剧罩。這個(gè)方案同時(shí)會(huì)導(dǎo)致客戶(hù)端代碼非常復(fù)雜。

另一個(gè)存在的問(wèn)題是客戶(hù)端直接請(qǐng)求微服務(wù)的協(xié)議可能并不是web友好型座泳。一個(gè)服務(wù)可能是用Thrift的RPC協(xié)議惠昔，而另一個(gè)服務(wù)可能是用AMQP消息協(xié)議。它們都不是瀏覽或防火墻友好的挑势，并且最好是內(nèi)部使用镇防。應(yīng)用應(yīng)該在防火墻外采用類(lèi)似HTTP或者WEBSocket協(xié)議。

這個(gè)方案的另一個(gè)缺點(diǎn)是它很難重構(gòu)微服務(wù)潮饱。隨著時(shí)間的推移来氧，我們可能需要改變系統(tǒng)微服務(wù)目前的切分方案。例如，我們可能需要將兩個(gè)服務(wù)合并或者將一個(gè)服務(wù)拆分為多個(gè)啦扬。但是中狂，如果客戶(hù)端直接與微服務(wù)交互，那么這種重構(gòu)就很難實(shí)施扑毡。

由于上述三種問(wèn)題的原因胃榕，客戶(hù)端直接與服務(wù)器端通信的方式很少在實(shí)際中使用。

采用一個(gè)API Gateway

通常來(lái)說(shuō)瞄摊，一個(gè)更好的解決辦法是采用API Gateway的方式勤晚。API Gateway是一個(gè)服務(wù)器，也可以說(shuō)是進(jìn)入系統(tǒng)的唯一節(jié)點(diǎn)泉褐。這跟面向?qū)ο笤O(shè)計(jì)模式中的Facade模式很像赐写。API Gateway封裝內(nèi)部系統(tǒng)的架構(gòu)，并且提供API給各個(gè)客戶(hù)端膜赃。它還可能有其他功能挺邀，如授權(quán)、監(jiān)控跳座、負(fù)載均衡端铛、緩存、請(qǐng)求分片和管理疲眷、靜態(tài)響應(yīng)處理等禾蚕。下圖展示了一個(gè)適應(yīng)當(dāng)前架構(gòu)的API Gateway。

API Gateway負(fù)責(zé)請(qǐng)求轉(zhuǎn)發(fā)狂丝、合成和協(xié)議轉(zhuǎn)換换淆。所有來(lái)自客戶(hù)端的請(qǐng)求都要先經(jīng)過(guò)API Gateway，然后路由這些請(qǐng)求到對(duì)應(yīng)的微服務(wù)几颜。API Gateway將經(jīng)常通過(guò)調(diào)用多個(gè)微服務(wù)來(lái)處理一個(gè)請(qǐng)求以及聚合多個(gè)服務(wù)的結(jié)果倍试。它可以在web協(xié)議與內(nèi)部使用的非Web友好型協(xié)議間進(jìn)行轉(zhuǎn)換，如HTTP協(xié)議蛋哭、WebSocket協(xié)議县习。

API Gateway可以提供給客戶(hù)端一個(gè)定制化的API。它暴露一個(gè)粗粒度API給移動(dòng)客戶(hù)端谆趾。以產(chǎn)品最終頁(yè)這個(gè)使用場(chǎng)景為例躁愿。API Gateway提供一個(gè)服務(wù)提供點(diǎn)（/productdetails?productid=xxx）使得移動(dòng)客戶(hù)端可以在一個(gè)請(qǐng)求中檢索到產(chǎn)品最終頁(yè)的全部數(shù)據(jù)。API Gateway通過(guò)調(diào)用多個(gè)服務(wù)來(lái)處理這一個(gè)請(qǐng)求并返回結(jié)果沪蓬，涉及產(chǎn)品信息彤钟、推薦、評(píng)論等怜跑。

一個(gè)很好的API Gateway例子是Netfix API Gateway样勃。Netflix流服務(wù)提供數(shù)百個(gè)不同的微服務(wù)吠勘，包括電視、機(jī)頂盒峡眶、智能手機(jī)剧防、游戲系統(tǒng)、平板電腦等辫樱。起初峭拘，Netflix視圖提供一個(gè)適用全場(chǎng)景的API。但是狮暑，他們發(fā)現(xiàn)這種形式不好用鸡挠，因?yàn)樯婕暗礁魇礁鳂拥脑O(shè)備以及它們獨(dú)特的需求。現(xiàn)在搬男，他們采用一個(gè)API Gateway來(lái)提供容錯(cuò)性高的API拣展，針對(duì)不同類(lèi)型設(shè)備有相應(yīng)代碼。事實(shí)上缔逛，一個(gè)適配器處理一個(gè)請(qǐng)求平均要調(diào)用6到8個(gè)后端服務(wù)备埃。Netflix API Gateway每天處理數(shù)十億的請(qǐng)求。

API Gateway的優(yōu)點(diǎn)和缺點(diǎn)

如你所料褐奴，采用API Gateway也是優(yōu)缺點(diǎn)并存的按脚。API Gateway的一個(gè)最大好處是封裝應(yīng)用內(nèi)部結(jié)構(gòu)。相比起來(lái)調(diào)用指定的服務(wù)敦冬，客戶(hù)端直接跟gatway交互更簡(jiǎn)單點(diǎn)辅搬。API Gateway提供給每一個(gè)客戶(hù)端一個(gè)特定API，這樣減少了客戶(hù)端與服務(wù)器端的通信次數(shù)脖旱，也簡(jiǎn)化了客戶(hù)端代碼堪遂。

API Gateway也有一些缺點(diǎn)。它是一個(gè)高可用的組件夯缺，必須要開(kāi)發(fā)蚤氏、部署和管理。還有一個(gè)問(wèn)題踊兜，它可能成為開(kāi)發(fā)的一個(gè)瓶頸。開(kāi)發(fā)者必須更新API Gateway來(lái)提供新服務(wù)提供點(diǎn)來(lái)支持新暴露的微服務(wù)佳恬。更新API Gateway時(shí)必須越輕量級(jí)越好捏境。否則，開(kāi)發(fā)者將因?yàn)楦翯ateway而排隊(duì)列毁葱。但是垫言，除了這些缺點(diǎn)，對(duì)于大部分的應(yīng)用倾剿，采用API Gateway的方式都是有效的筷频。

實(shí)現(xiàn)一個(gè)API Gateway

既然我們已經(jīng)知道了采用API Gateway的動(dòng)機(jī)和優(yōu)缺點(diǎn)蚌成，下面來(lái)看在設(shè)計(jì)它時(shí)需要考慮哪些事情。

性能和可擴(kuò)展性

只有少數(shù)公司需要處理像Netflix那樣的規(guī)模凛捏，每天需要處理數(shù)十億的請(qǐng)求担忧。但是，對(duì)于大多數(shù)應(yīng)用坯癣，API Gateway的性能和可擴(kuò)展性也是非常重要的瓶盛。因此，創(chuàng)建一個(gè)支持同步示罗、非阻塞I/O的API Gateway是有意義的惩猫。已經(jīng)有不同的技術(shù)可以用來(lái)實(shí)現(xiàn)一個(gè)可擴(kuò)展的API Gateway。在JVM上蚜点，采用基于NIO技術(shù)的框架轧房，如Netty，Vertx绍绘，Spring Reactor或者JBoss Undertow奶镶。Node.js是一個(gè)非JVM的流行平臺(tái)，它是一個(gè)在Chrome的JavaScript引擎基礎(chǔ)上建立的平臺(tái)脯倒。一個(gè)可選的方案是NGINX Plus实辑。NGINX Plus提供一個(gè)成熟的、可擴(kuò)展的藻丢、高性能web服務(wù)器和反向代理剪撬，它們均容易部署、配置和二次開(kāi)發(fā)悠反。NGINX Plus可以管理授權(quán)残黑、權(quán)限控制、負(fù)載均衡斋否、緩存并提供應(yīng)用健康檢查和監(jiān)控梨水。

采用反應(yīng)性編程模型

對(duì)于有些請(qǐng)求，API Gateway可以通過(guò)直接路由請(qǐng)求到對(duì)應(yīng)的后端服務(wù)上的方式來(lái)處理茵臭。對(duì)于另外一些請(qǐng)求疫诽，它需要調(diào)用多個(gè)后端服務(wù)并合并結(jié)果來(lái)處理。對(duì)于一些請(qǐng)求旦委，例如產(chǎn)品最終頁(yè)面請(qǐng)求奇徒，發(fā)給后端服務(wù)的請(qǐng)求是相互獨(dú)立的。為了最小化響應(yīng)時(shí)間缨硝，API Gateway應(yīng)該并發(fā)的處理相互獨(dú)立的請(qǐng)求摩钙。但是，有時(shí)候請(qǐng)求之間是有依賴(lài)的查辩。API Gateway可能需要先通過(guò)授權(quán)服務(wù)來(lái)驗(yàn)證請(qǐng)求胖笛，然后在路由到后端服務(wù)网持。類(lèi)似的，為了獲得客戶(hù)的產(chǎn)品愿望清單长踊，需要先獲取該用戶(hù)的資料功舀，然后返回清單上產(chǎn)品的信息。這樣的一個(gè)API 組件是Netflix Video Grid之斯。

利用傳統(tǒng)的同步回調(diào)方法來(lái)實(shí)現(xiàn)API合并的代碼會(huì)使得你進(jìn)入回調(diào)函數(shù)的噩夢(mèng)中日杈。這種代碼將非常難度且難以維護(hù)。一個(gè)優(yōu)雅的解決方案是采用反應(yīng)性編程模式來(lái)實(shí)現(xiàn)佑刷。類(lèi)似的反應(yīng)抽象實(shí)現(xiàn)有Scala的Future莉擒，Java8的CompletableFuture和JavaScript的Promise√毙酰基于微軟.Net平臺(tái)的有Reactive Extensions(Rx)涨冀。Netflix為JVM環(huán)境創(chuàng)建了RxJava來(lái)使用他們的API Gateway。同樣地麦萤，JavaScript平臺(tái)有RxJS鹿鳖，可以在瀏覽器和Node.js平臺(tái)上運(yùn)行。采用反應(yīng)編程方法可以幫助快速實(shí)現(xiàn)一個(gè)高效的API Gateway代碼壮莹。

服務(wù)調(diào)用

一個(gè)基于微服務(wù)的應(yīng)用是一個(gè)分布式系統(tǒng)翅帜，并且必須采用線程間通信的機(jī)制。有兩種線程間通信的方法命满。一種是采用異步機(jī)制涝滴，基于消息的方法。這類(lèi)的實(shí)現(xiàn)方法有JMS和AMQP胶台。另外的歼疮，例如Zeromq屬于服務(wù)間直接通信。還有一種線程間通信采用同步機(jī)制诈唬，例如Thrift和HTTP韩脏。事實(shí)上一個(gè)系統(tǒng)會(huì)同時(shí)采用同步和異步兩種機(jī)制。由于它的實(shí)現(xiàn)方式有很多種铸磅，因此API Gateway就需要支持多種通信方式赡矢。

服務(wù)發(fā)現(xiàn)

API Gateway需要知道每一個(gè)微服務(wù)的IP和端口。在傳統(tǒng)應(yīng)用中阅仔，你可能會(huì)硬編碼這些地址济竹，但是在現(xiàn)在云基礎(chǔ)的微服務(wù)應(yīng)用中，這將是個(gè)簡(jiǎn)單的問(wèn)題霎槐。基礎(chǔ)服務(wù)通常會(huì)采用靜態(tài)地址梦谜，可以采用操作系統(tǒng)環(huán)境變量來(lái)指定丘跌。但是袭景，探測(cè)應(yīng)用服務(wù)的地址就沒(méi)那么容易了。應(yīng)用服務(wù)通常動(dòng)態(tài)分配地址和端口闭树。同樣的耸棒，由于擴(kuò)展或者升級(jí)，服務(wù)的實(shí)例也會(huì)動(dòng)態(tài)的改變报辱。因此与殃，API Gateway需要采用系統(tǒng)的服務(wù)發(fā)現(xiàn)機(jī)制，要么采用服務(wù)端發(fā)現(xiàn)碍现，要么是客戶(hù)端發(fā)現(xiàn)幅疼。后續(xù)的一篇文章將會(huì)更詳細(xì)的介紹這部分。如果采用客戶(hù)端發(fā)現(xiàn)服務(wù)昼接，API Gateway必須要去查詢(xún)服務(wù)注冊(cè)處爽篷，也就是微服務(wù)實(shí)例地址的數(shù)據(jù)庫(kù)。

處理部分失敗

在實(shí)現(xiàn)API Gateway過(guò)程中慢睡，另外一個(gè)需要考慮的問(wèn)題就是部分失敗逐工。這個(gè)問(wèn)題發(fā)生在分布式系統(tǒng)中當(dāng)一個(gè)服務(wù)調(diào)用另外一個(gè)服務(wù)超時(shí)或者不可用的情況。API Gateway不應(yīng)該被阻斷并處于無(wú)限期等待下游服務(wù)的狀態(tài)漂辐。但是泪喊，如何處理這種失敗依賴(lài)于特定的場(chǎng)景和具體服務(wù)。例如髓涯，如果是在產(chǎn)品詳情頁(yè)的推薦服務(wù)模塊無(wú)響應(yīng)袒啼，那么API Gateway應(yīng)該返回剩下的其他信息給用戶(hù)，因?yàn)檫@些信息也是有用的复凳。推薦部分可以返回空瘤泪，也可以返回固定的頂部10個(gè)給用戶(hù)。但是育八，如果是產(chǎn)品信息服務(wù)無(wú)響應(yīng)对途，那么API Gateway就應(yīng)該給客戶(hù)端返回一個(gè)錯(cuò)誤。

在緩存有效的時(shí)候髓棋，API Gateway應(yīng)該能夠返回緩存实檀。例如，由于產(chǎn)品價(jià)格變化并不頻繁按声，API Gateway在價(jià)格服務(wù)不可用時(shí)應(yīng)該返回緩存中的數(shù)值膳犹。這類(lèi)數(shù)據(jù)可以由API Gateway自身來(lái)緩存，也可以由Redis或Memcached這類(lèi)外部緩存實(shí)現(xiàn)签则。通過(guò)返回緩存數(shù)據(jù)或者默認(rèn)數(shù)據(jù)须床，API Gateway來(lái)確保系統(tǒng)錯(cuò)誤不影響到用戶(hù)體驗(yàn)。

Netflix Hystrix對(duì)于實(shí)現(xiàn)遠(yuǎn)程服務(wù)調(diào)用代碼來(lái)說(shuō)是一個(gè)非常好用的庫(kù)渐裂。Hystrix記錄那些超過(guò)預(yù)設(shè)定的極限值的調(diào)用豺旬。它實(shí)現(xiàn)了circuit break模式钠惩，使得可以將客戶(hù)端從無(wú)響應(yīng)服務(wù)的無(wú)盡等待中停止。如果一個(gè)服務(wù)的錯(cuò)誤率超過(guò)預(yù)設(shè)值族阅，Hystrix將中斷服務(wù)篓跛，并且在一段時(shí)間內(nèi)所有請(qǐng)求立刻失效。Hystrix可以為請(qǐng)求失敗定義一個(gè)fallback操作坦刀，例如讀取緩存或者返回默認(rèn)值愧沟。如果你在用JVM，就應(yīng)該考慮使用Hystrix鲤遥。如果你采用的非JVM環(huán)境沐寺，那么應(yīng)該考慮采用類(lèi)似功能的庫(kù)。

總結(jié)

對(duì)于大多數(shù)微服務(wù)基礎(chǔ)的應(yīng)用渴频，實(shí)現(xiàn)一個(gè)API Gateway都是有意義的芽丹，它就像是進(jìn)入系統(tǒng)的一個(gè)服務(wù)提供點(diǎn)。API Gateway負(fù)責(zé)請(qǐng)求轉(zhuǎn)發(fā)卜朗、請(qǐng)求合成和協(xié)議轉(zhuǎn)換拔第。它提供給應(yīng)用客戶(hù)端一個(gè)自定義的API。API Gateway可以通過(guò)返回緩存或者默認(rèn)值的方式來(lái)掩蓋后端服務(wù)的錯(cuò)誤场钉。在本系列的下一篇文章中蚊俺，我們將討論服務(wù)間的通信問(wèn)題。