外部API的設(shè)計(jì)難題
讓客戶端直接調(diào)用服務(wù)，可行且實(shí)現(xiàn)簡(jiǎn)單。但存在弊端：
- 效率低，用戶體驗(yàn)差。服務(wù)API往往顆粒度比較細(xì)，客戶端需要調(diào)用多次API才能檢索到需要的數(shù)據(jù)
- 封裝不足，緊耦合?？蛻舳诵枰私饷總€(gè)服務(wù)，服務(wù)端API接口的改變，會(huì)要求客戶端一同修改。
- 客戶端使用不便?？赡艽嬖诜阑饓?/li>
API Gateway模式
API Gateway服務(wù)是外部API客戶端進(jìn)入基于微服務(wù)應(yīng)用程序的入口點(diǎn)，負(fù)責(zé)請(qǐng)求路由、API組合、協(xié)議轉(zhuǎn)換（隱藏微服務(wù)應(yīng)用程序內(nèi)部多種協(xié)議細(xì)節(jié)）和邊緣功能（身份驗(yàn)證、流量監(jiān)控、速率限制、緩存、指標(biāo)手機(jī)、請(qǐng)求日志等功能）。
邊緣功能的實(shí)現(xiàn)可以放在三個(gè)位置：
- 后端服務(wù)
- API Gateway
- API Gateway上游的邊緣服務(wù)。使用邊緣服務(wù)，也可以進(jìn)一步的分割問題。例如身份驗(yàn)證，可以建立Auth服務(wù)。
好處是，封裝了應(yīng)用程序的內(nèi)部結(jié)構(gòu)。
弊端是，1.可能成為開發(fā)的瓶頸，2.只有在更新API Gateway之后，才能提供服務(wù)的API。
API Gateway的設(shè)計(jì)難題
在設(shè)計(jì)API Gateway的時(shí)候，需要考慮以下幾個(gè)問題：
- 性能和可擴(kuò)展性。同步I/O可能會(huì)存在線程數(shù)量和并發(fā)連接數(shù)量的上限。異步I/O，更具擴(kuò)展性，但是更復(fù)雜，代碼更難編寫、理解和調(diào)試。
- 使用響應(yīng)式編程。在API組合的時(shí)候，需要考慮到調(diào)用服務(wù)的依賴性。
- 處理局部故障。一種方法是，負(fù)載均衡器后面運(yùn)行多個(gè)API Gateway服實(shí)例，另一種方式是，使用斷路器。
不同客戶端需要不同的數(shù)據(jù)
解決這個(gè)挑戰(zhàn)，可以
- 讓客戶端指定所需要的數(shù)據(jù)，如利用expand參數(shù)，或者基于圖形的API框架GraphQL
- 后端前置模式，為每個(gè)客戶端，實(shí)現(xiàn)單獨(dú)的接口。
基于圖形的API框架的關(guān)鍵思想是，服務(wù)器的API由基于圖形的模式組成，。該模式定義了一組節(jié)點(diǎn)（類型），他們具有屬性（字段）和其他節(jié)點(diǎn)的關(guān)系?？蛻舳送ㄟ^，查詢圖的節(jié)點(diǎn)和與其他節(jié)點(diǎn)的關(guān)系，檢索數(shù)據(jù)。
這種基于圖形的API框架的好處是：
- 是客戶端能夠控制返回的數(shù)據(jù)
- API更靈活，可以顯著減少開發(fā)的工作量。
兩種最流行的基于圖形的API技術(shù)是：GraphQL和Netflix Falcor
