背景
理論上，客戶端可以直接向微服務(wù)發(fā)送請(qǐng)求，每個(gè)微服務(wù)都有一個(gè)公開的URL，該URL將映射到微服務(wù)的負(fù)載均衡器，由它負(fù)責(zé)在可用實(shí)例之間分發(fā)請(qǐng)求。但這種方式存在如下缺陷：
1. 客戶端需求和微服務(wù)暴露的細(xì)粒度 API 不匹配
經(jīng)常有一個(gè)業(yè)務(wù)調(diào)用很多個(gè)服務(wù)，假如客戶端發(fā)送許多請(qǐng)求，這在公網(wǎng)上可能會(huì)很低效，而且會(huì)使客戶端代碼變得更復(fù)雜。
2. 服務(wù)使用的協(xié)議不是 Web 友好的
有的服務(wù)可能使用二進(jìn)制 RPC（比如 thrift），有的服務(wù)可能使用 AMQP 消息傳遞協(xié)議。不管哪種協(xié)議都不是瀏覽器友好或防火墻友好的，最好是內(nèi)部使用。在防火墻之外，應(yīng)用程序應(yīng)該使用諸如 HTTP 和 WebSocket 之類的協(xié)議。
3. 難重構(gòu)
隨著時(shí)間推移可能想要更改系統(tǒng)劃分成服務(wù)的方式。例如，合并兩個(gè)服務(wù)或者將一個(gè)服務(wù)拆分成兩個(gè)或更多服務(wù)。如果客戶端與微服務(wù)直接通信，那么執(zhí)行這類重構(gòu)就很困難。
由于以上問題，客戶端與微服務(wù)直接通信很少是合理的，更好的方法是使用?API 網(wǎng)關(guān)，由 API 網(wǎng)關(guān)作為后端服務(wù)系統(tǒng)的唯一入口。它封裝了系統(tǒng)內(nèi)部架構(gòu)，為每個(gè)客戶端提供一個(gè)定制的 API 。由它負(fù)責(zé)服務(wù)請(qǐng)求路由、組合及協(xié)議轉(zhuǎn)換。有的 API 網(wǎng)關(guān)還有其它職責(zé)，如身份驗(yàn)證、監(jiān)控、負(fù)載均衡、緩存等。
整體架構(gòu)
完備的服務(wù)網(wǎng)關(guān)應(yīng)該包括三大部分：API 網(wǎng)關(guān)、網(wǎng)關(guān)控制臺(tái)、度量數(shù)據(jù)采集分析。實(shí)際形態(tài)各異，可以按需搭建，但肯定少不了 API 網(wǎng)關(guān)，網(wǎng)關(guān)控制臺(tái)的功能職責(zé)可能會(huì)放到服務(wù)注冊(cè)等地方而沒有單獨(dú)抽取出來，至于度量數(shù)據(jù)采集可能會(huì)在整個(gè)微服務(wù)架構(gòu)中存一個(gè)通用的度量數(shù)據(jù)采集應(yīng)用以監(jiān)控所有類型應(yīng)用。
API 網(wǎng)關(guān)的優(yōu)缺點(diǎn)
1. 優(yōu)點(diǎn)
封裝了應(yīng)用程序的內(nèi)部結(jié)構(gòu)。客戶端只需要同網(wǎng)關(guān)交互，而不必調(diào)用特定的服務(wù)。API 網(wǎng)關(guān)為每一類客戶端提供了特定的 API ，從而減少客戶端與應(yīng)用程序間的交互次數(shù)，簡化客戶端代碼的處理。
2. 缺點(diǎn)
增加了一個(gè)必須開發(fā)、部署和維護(hù)的高可用組件。還有一個(gè)風(fēng)險(xiǎn)是 API 網(wǎng)關(guān)變成了開發(fā)瓶頸。為了暴露每個(gè)微服務(wù)，開發(fā)人員必須更新 API 網(wǎng)關(guān)。API 網(wǎng)關(guān)的更新過程要盡可能地簡單，否則為了更新網(wǎng)關(guān)，開發(fā)人員將不得不排隊(duì)等待。不過，雖然有這些不足，但對(duì)于大多數(shù)現(xiàn)實(shí)世界的應(yīng)用程序而言使用 API 網(wǎng)關(guān)是合理的。
實(shí)現(xiàn)技術(shù)
1. 開發(fā)語言
對(duì)于大多數(shù)應(yīng)用程序而言，API 網(wǎng)關(guān)的性能和可擴(kuò)展性通常都非常重要。因此，API 網(wǎng)關(guān)將構(gòu)建在一個(gè)支持異步、I/O 非阻塞的平臺(tái)上。Java系可以使用一種基于 NIO 的框架，比如Netty、Vertx、Spring Reactor ，還可以使用 Node.js、NGINX Plus。
2. 響應(yīng)式編程
API 網(wǎng)關(guān)通過簡單地將請(qǐng)求路由給合適的后端服務(wù)來處理部分請(qǐng)求，而通過調(diào)用多個(gè)后端服務(wù)并合并結(jié)果來處理其它請(qǐng)求。對(duì)于沒有依賴關(guān)系的請(qǐng)求，API 網(wǎng)關(guān)應(yīng)該并發(fā)執(zhí)行以最小化響應(yīng)時(shí)間。使用傳統(tǒng)的異步回調(diào)方法編寫 API 組合代碼會(huì)陷入回調(diào)地獄。代碼會(huì)變得混亂、難以理解、容易出錯(cuò)。可以使用響應(yīng)式編程以一種聲明式樣式編寫代碼。比如 Scala 中的Future 、Java 8 中的 CompletableFuture 和 JavaScript 中的 Promise ，還有最初是微軟為 .NET 平臺(tái)開發(fā)的 Reactive Extensions（RX）。Netflix 創(chuàng)建了 RxJava for JVM ，專門用于他們的 API 網(wǎng)關(guān)。
3. 進(jìn)程通信模型
微服務(wù)的應(yīng)用程序必定是一個(gè)分布式系統(tǒng)，所以必須使用進(jìn)程間的通信機(jī)制。有兩種類型的進(jìn)程間通信機(jī)制可供選擇。一種是使用異步的、基于消息傳遞的機(jī)制。有些實(shí)現(xiàn)使用諸如JMS 或 AMQP 那樣的消息代理，而其它的實(shí)現(xiàn)（如 Zeromq ）則沒有代理，服務(wù)間直接通信。另一種是諸如 HTTP 或 Thrift 那樣的同步機(jī)制。通常，一個(gè)系統(tǒng)會(huì)同時(shí)使用異步和同步兩種類型。它甚至還可能使用同一類型的多種實(shí)現(xiàn)?？傊?，API 網(wǎng)關(guān)需要支持多種通信機(jī)制。
4. 服務(wù)發(fā)現(xiàn)
API 網(wǎng)關(guān)需要知道它與之通信的每個(gè)微服務(wù)的位置（IP 地址和端口）。應(yīng)用程序服務(wù)的位置是動(dòng)態(tài)分配的。而且，單個(gè)服務(wù)的一組實(shí)例也會(huì)隨著自動(dòng)擴(kuò)展或升級(jí)而動(dòng)態(tài)變化。API 網(wǎng)關(guān)需要使用系統(tǒng)的服務(wù)發(fā)現(xiàn)機(jī)制，可以是服務(wù)器端發(fā)現(xiàn)，也可以是客戶端發(fā)現(xiàn)。如果系統(tǒng)使用客戶端發(fā)現(xiàn)，那么 API 網(wǎng)關(guān)必須能夠查詢服務(wù)注冊(cè)中心，這是一個(gè)包含所有微服務(wù)實(shí)例及其位置的數(shù)據(jù)庫。
Spring cloud 提供了服務(wù)注冊(cè)和發(fā)現(xiàn)功能，如果需要自己實(shí)現(xiàn)，可以考慮用 Zookeeper 作為注冊(cè)表，客戶端用 Curator 。
5. 局部失敗
在實(shí)現(xiàn) API 網(wǎng)關(guān)時(shí)，還有一個(gè)問題需要處理，就是局部失敗的問題。該問題在所有的分布式系統(tǒng)中都會(huì)出現(xiàn)，無論什么時(shí)候，當(dāng)一個(gè)服務(wù)調(diào)用另一個(gè)響應(yīng)慢或不可用的服務(wù)，就會(huì)出現(xiàn)這個(gè)問題。API 網(wǎng)關(guān)永遠(yuǎn)不能因?yàn)闊o限期地等待下游服務(wù)而阻塞。不過，如何處理失敗取決于特定的場景以及哪個(gè)服務(wù)失敗。如果緩存數(shù)據(jù)可用，那么 API 網(wǎng)關(guān)還可以返回緩存數(shù)據(jù)。數(shù)據(jù)可以由API網(wǎng)關(guān)自己緩存，也可以存儲(chǔ)在像 Redis 或 Memcached 那樣的外部緩存中。通過返回默認(rèn)數(shù)據(jù)或者緩存數(shù)據(jù)，API 網(wǎng)關(guān)可以確保系統(tǒng)故障不影響用戶的體驗(yàn)。
在編寫代碼調(diào)用遠(yuǎn)程服務(wù)方面，Netflix Hystrix 是一個(gè)異常有用的庫。Hystrix 會(huì)將超出設(shè)定閥值的調(diào)用超時(shí)。它實(shí)現(xiàn)了一個(gè)“斷路器（circuit breaker）”模式，可以防止客戶端對(duì)無響應(yīng)的服務(wù)進(jìn)行不必要的等待。如果服務(wù)的錯(cuò)誤率超出了設(shè)定的閥值，那么 Hystrix 會(huì)切斷斷路器，在一個(gè)指定的時(shí)間范圍內(nèi)，所有請(qǐng)求都會(huì)立即失敗。Hystrix 允許用戶定義一個(gè)請(qǐng)求失敗后的后援操作，比如從緩存讀取數(shù)據(jù)，或者返回一個(gè)默認(rèn)值。如果你正在使用 JVM，那么你絕對(duì)應(yīng)該考慮使用 Hystrix 。而如果你正在使用一個(gè)非 JVM 環(huán)境，那么你應(yīng)該使用一個(gè)等效的庫。
6.參考實(shí)現(xiàn)方案
以上列出在 DIY 這個(gè) API 網(wǎng)關(guān)時(shí)需要考慮的點(diǎn)，以及參考的技術(shù)實(shí)現(xiàn)。下面是幾種目前比較流行的 API 網(wǎng)關(guān)搭建的技術(shù)方案供參考，后續(xù)文章將給出這些方案搭建的例子
1）Nginx + Lua實(shí)現(xiàn)負(fù)載均衡、限流、服務(wù)發(fā)現(xiàn)等功能
2）使用 spring cloud 技術(shù)棧，其中 zuul 就是用作 API 網(wǎng)關(guān)的
3）Mashape 的開源 API 網(wǎng)關(guān) Kong
7.網(wǎng)關(guān)控制臺(tái)
提供 domain 管理、應(yīng)用管理、服務(wù)授權(quán)、服務(wù)監(jiān)控、統(tǒng)計(jì)和度量數(shù)據(jù)展示、查看服務(wù)全局視圖等功能。服務(wù)消費(fèi)者和服務(wù)提供者都要在網(wǎng)關(guān)控制臺(tái)進(jìn)行應(yīng)用注冊(cè)，控制臺(tái)為每個(gè)應(yīng)用分配應(yīng)用id(appId唯一)和應(yīng)用密鑰(appSecret)。注冊(cè)時(shí)需要提供的信息：應(yīng)用名稱、應(yīng)用描述、應(yīng)用負(fù)責(zé)人相關(guān)信息。
