【51CTO.com快譯】隨著以API為核心的IT項(xiàng)目不斷增加，API網(wǎng)關(guān)與管理層亦愈發(fā)普遍。那么，我們是否應(yīng)當(dāng)為微服務(wù)搭配API網(wǎng)關(guān)？如果需要，其又能夠帶來哪些助益？

API網(wǎng)關(guān)是什么？

API網(wǎng)關(guān)負(fù)責(zé)提供一套單一且統(tǒng)一的API入口點(diǎn)，其跨越一個(gè)或者多個(gè)內(nèi)部API。其通常亦設(shè)定了層速率限制與安全性機(jī)制。Tyk.io等API管理層則能夠帶來更多其它功能，包括分析、貨幣化以及生命周期管理等等。

基于微服務(wù)的架構(gòu)當(dāng)中往往包含10到100項(xiàng)甚至更多服務(wù)。API網(wǎng)關(guān)能夠?yàn)橥獠肯M(fèi)方提供一套統(tǒng)一的入口點(diǎn)，且不會(huì)受到內(nèi)部微服務(wù)的具體數(shù)量與組成的影響。

API網(wǎng)關(guān)為微服務(wù)帶來的助益

避免將內(nèi)部信息泄露給外部客戶

API網(wǎng)關(guān)能夠?qū)⑼獠抗睞PI與內(nèi)部微服務(wù)API加以區(qū)分，使得各項(xiàng)微服務(wù)進(jìn)行添加與邊界變更。如此一來，微服務(wù)架構(gòu)就能隨時(shí)間推移而始終通過重組保護(hù)正確大小，且不會(huì)對(duì)外部綁定客戶造成影響。另外，其還能夠?yàn)槿课⒎?wù)提供單一入口點(diǎn)，從而避免外部客戶進(jìn)行服務(wù)發(fā)現(xiàn)及版本控制信息查看。

為微服務(wù)添加額外的安全層

API網(wǎng)關(guān)能夠提供一套額外的保護(hù)層，足以應(yīng)對(duì)SQL注入、XML解析攻擊以及拒絕服務(wù)（簡(jiǎn)稱DoS）攻擊等常見威脅因素，從而實(shí)現(xiàn)額外的保護(hù)層效果。

可支持混合通信協(xié)議

由于面向外部的API通常會(huì)提供一個(gè)基于HTTP或者REST的API，因此內(nèi)部微服務(wù)往往可借此使用多種不同通信協(xié)議。此類協(xié)議包括ProtoBuf、AMQP或者其它集成有SOAP、JSON-RPC或者XML-RPC的系統(tǒng)。API網(wǎng)關(guān)可跨越這些協(xié)議提供一個(gè)外部統(tǒng)一的基于REST API，允許各團(tuán)隊(duì)以此為基礎(chǔ)選擇最適合內(nèi)部架構(gòu)的協(xié)議方案。

降低微服務(wù)復(fù)雜性

微服務(wù)擁有多項(xiàng)常規(guī)重點(diǎn)，例如利用API令牌進(jìn)行驗(yàn)證、訪問控制以及速率限制等。每一項(xiàng)都會(huì)給相關(guān)實(shí)現(xiàn)服務(wù)帶來影響，進(jìn)而延長(zhǎng)微服務(wù)的開發(fā)時(shí)間。API網(wǎng)關(guān)能夠從代碼層面移除這些重點(diǎn)，使得大家的微服務(wù)能夠?qū)Ｗ⒂诟鼮閷?shí)際的核心任務(wù)。

微服務(wù)模擬與虛擬化

通過將微服務(wù)API與外部API加以區(qū)分，大家可以模擬或者虛擬化自己的服務(wù)，從而滿足設(shè)計(jì)要求或者配合集成測(cè)試。

微服務(wù)API網(wǎng)關(guān)的弊端

雖然使用API微服務(wù)網(wǎng)關(guān)好處多多，但其亦存在以下弊端：

• 整個(gè)開發(fā)架構(gòu)由于額外API網(wǎng)關(guān)的加入而需要更多編排與管理工作相配合。
• 必須在開發(fā)過程中對(duì)路由邏輯配置進(jìn)行管理，從而確保以合理的路由方式對(duì)接外部API與專用微服務(wù)。
• 除非架構(gòu)本身充分適合高可用性與規(guī)?；?，否則API網(wǎng)關(guān)往往會(huì)成為一項(xiàng)限制性因素，甚至引發(fā)單點(diǎn)故障。

原文標(biāo)題：Why Do Microservices Need an API Gateway?    原文作者： James Higginbotham

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】