微服務(wù)架構(gòu)開(kāi)發(fā)實(shí)戰(zhàn)：API網(wǎng)關(guān)意義和常見(jiàn)API網(wǎng)關(guān)的實(shí)現(xiàn)方式
API網(wǎng)關(guān)意義
API網(wǎng)關(guān)旨在用一套單一且統(tǒng)一的API入口點(diǎn)，來(lái)組合一個(gè)或多個(gè)內(nèi)部API。
API網(wǎng)關(guān)定位為應(yīng)用系統(tǒng)服務(wù)接口的網(wǎng)關(guān)，區(qū)別于網(wǎng)絡(luò)技術(shù)的網(wǎng)關(guān)，但是原理是一樣的。API網(wǎng)關(guān)統(tǒng)一服務(wù)入口，可方便實(shí)現(xiàn)對(duì)平臺(tái)眾多服務(wù)接口進(jìn)行管控，如對(duì)訪問(wèn)服務(wù)的身份認(rèn)證、防報(bào)文重放與防數(shù)據(jù)篡改、功能調(diào)用的業(yè)務(wù)鑒權(quán)，以及響應(yīng)數(shù)據(jù)的脫敏、流量與并發(fā)控制，甚至基于API調(diào)用的計(jì)量或計(jì)費(fèi)等。
API并不能適用于所有場(chǎng)景
在基于微服務(wù)的架構(gòu)設(shè)計(jì)中，往往包含多個(gè)服務(wù)，這些服務(wù)并不能適用于所有場(chǎng)景。例如，在一個(gè)面向PC的Web應(yīng)用中，服務(wù)所要提供的API是要返回一個(gè)頁(yè)面，而非單純的數(shù)據(jù)，那么這樣的API只能適用于Web應(yīng)用，而不能適用于移動(dòng)APP。
又如，在移動(dòng)APP的架構(gòu)設(shè)計(jì)中，由于網(wǎng)絡(luò)帶寬的限制，在設(shè)計(jì)API時(shí)，往往會(huì)考慮較少的網(wǎng)絡(luò)傳輸次數(shù)及更少的傳輸數(shù)據(jù)。而面向PC的Web應(yīng)用卻無(wú)須考慮這些限制。
圖10-1展示了不同場(chǎng)景下的API網(wǎng)關(guān)使用情況。
API網(wǎng)關(guān)常用于以下場(chǎng)景。
黑白名單:實(shí)現(xiàn)通過(guò)IP地址控制禁止訪問(wèn)網(wǎng)關(guān)功能。
日志:實(shí)現(xiàn)訪問(wèn)日志的記錄，可用于分析訪問(wèn)、處理性能指標(biāo)，同時(shí)將分析結(jié)果支持其他模塊功能應(yīng)用。
協(xié)議適配:實(shí)現(xiàn)通信協(xié)議校驗(yàn)、適配轉(zhuǎn)換的功能。
身份認(rèn)證:負(fù)責(zé)網(wǎng)關(guān)訪問(wèn)身份認(rèn)證驗(yàn)證。
計(jì)流限流:實(shí)現(xiàn)微服務(wù)訪問(wèn)流量計(jì)算，基于流量計(jì)算分析進(jìn)行限流，可以定義多種限流規(guī)則。
路由:是API網(wǎng)關(guān)很核心的模塊功能，此模塊實(shí)現(xiàn)根據(jù)請(qǐng)求鎖定目標(biāo)微服務(wù)，并將請(qǐng)求進(jìn)行轉(zhuǎn)發(fā)。
API網(wǎng)關(guān)所帶來(lái)的好處
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ù)架構(gòu)系統(tǒng)帶來(lái)了如下好處。
1.避免將內(nèi)部信息泄露給外部
在數(shù)據(jù)安全方面，API網(wǎng)關(guān)能夠?qū)⑼獠抗睞PI與內(nèi)部微服務(wù)API區(qū)分開(kāi)來(lái)，使各項(xiàng)微服務(wù)在添加或變更時(shí)，能有明確的安全邊界。這樣，微服務(wù)架構(gòu)就能隨時(shí)間推移而始終通過(guò)重組來(lái)保證系統(tǒng)安全，且不會(huì)對(duì)外部綁定客戶造成影響。另外，其還能夠?yàn)槿课⒎?wù)提供單一入口點(diǎn)，從而避免外部客戶進(jìn)行服務(wù)發(fā)現(xiàn)及版本控制信息查看。
2.為微服務(wù)添加額外的安全層
API網(wǎng)關(guān)能夠提供─套額外的保護(hù)層，足以應(yīng)對(duì)SQL注入、XML解析攻擊及拒絕服務(wù)(DoS)攻擊等常見(jiàn)威脅因素，從而實(shí)現(xiàn)額外的保護(hù)層效果。系統(tǒng)的權(quán)限控制也可以在這一層來(lái)實(shí)施。
3.支持混合通信協(xié)議
面向外部的API，由于考慮到平臺(tái)和語(yǔ)言的無(wú)關(guān)性，往往向外提供基于HTTP或REST的API。但內(nèi)部微服務(wù)往往會(huì)采用不同的通信協(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é)議方案。
4.降低構(gòu)建微服務(wù)的復(fù)雜性
微服務(wù)架構(gòu)系統(tǒng)往往擁有比單個(gè)架構(gòu)更多的管理復(fù)雜度，如API令牌驗(yàn)證、訪問(wèn)控制及速率限制等。每一項(xiàng)功能的實(shí)施，都會(huì)給相關(guān)實(shí)現(xiàn)服務(wù)帶來(lái)影響，進(jìn)而會(huì)延長(zhǎng)微服務(wù)的開(kāi)發(fā)時(shí)間。API網(wǎng)關(guān)能夠從代碼層面隔離這些功能項(xiàng)，使開(kāi)發(fā)人員在構(gòu)建單個(gè)微服務(wù)時(shí)，能夠?qū)Ｗ⒂趯?shí)際的核心業(yè)務(wù)。
5.微服務(wù)模擬與虛擬化
通過(guò)將微服務(wù)內(nèi)部API與外部API加以區(qū)分，大家可以模擬或虛擬化自己的服務(wù)，從而滿足設(shè)
計(jì)要求或配合集成測(cè)試。
API網(wǎng)關(guān)的弊端
雖然使用API網(wǎng)關(guān)會(huì)給微服務(wù)架構(gòu)帶來(lái)一定的好處，但同時(shí)仍然要考慮如下的弊端。
由于額外API網(wǎng)關(guān)的加入，會(huì)使整個(gè)開(kāi)發(fā)在架構(gòu)上考慮更多的編排與管理工作。
在開(kāi)發(fā)過(guò)程中，對(duì)路由邏輯配置要進(jìn)行統(tǒng)一的管理，從而能夠確保以合理的路由方式對(duì)接外部API與專用微服務(wù)。
除非架構(gòu)本身充分適應(yīng)高可用性與規(guī)模化要求，否則API網(wǎng)關(guān)往往會(huì)成為一項(xiàng)限制性因素，甚至引發(fā)單點(diǎn)故障。
常見(jiàn)API網(wǎng)關(guān)的實(shí)現(xiàn)方式
業(yè)界常用的API網(wǎng)關(guān)方式有很多，技術(shù)方案也很成熟，其中也不乏很多開(kāi)源的產(chǎn)品，如NG-INX、Tyk、Kong、API Umbrella、ApiAxle、Zuul、WSO2 API Manager等。下面介紹三種常見(jiàn)的API網(wǎng)關(guān)方案。
NGINX
NGINX是一個(gè)免費(fèi)的、開(kāi)源的、高性能的HTTP服務(wù)器和反向代理，以及一個(gè)IMAP/POP3代理服務(wù)器。NGINX以其高性能、穩(wěn)定性、豐富的功能集、簡(jiǎn)單的配置和低資源消耗而聞名。
NGINX是為解決C10K問(wèn)題而編寫(xiě)的少數(shù)服務(wù)器之一。與傳統(tǒng)服務(wù)器不同，NGINX不依賴于線程來(lái)處理請(qǐng)求。相反，它使用可擴(kuò)展的事件驅(qū)動(dòng)(異步）架構(gòu)。這種架構(gòu)在負(fù)載下使用小的但更重要的可預(yù)測(cè)的內(nèi)存量。即使用戶不希望處理數(shù)千個(gè)并發(fā)請(qǐng)求，仍然可以從NGINX的高性能和小內(nèi)存中獲益。NGINX在各個(gè)方向擴(kuò)展:從最小的VPS一直到大型服務(wù)器集群。
NGINX擁有諸如Netflix、Hulu、Pinterest、CloudFlare、Airbnb、WordPress.com、GitHub、SoundCloud、Zynga、Eventbrite、Zappos、Media Temple、Heroku、RightScale、Engine、Yard,MaxCDN等眾多高知名度網(wǎng)站。
NGINX具有很多非常優(yōu)越的特性。
作為Web服務(wù)器;相比Apache，NGINX使用更少的資源，支持更多的并發(fā)連接，體現(xiàn)更高的效率，這點(diǎn)使NGINX尤其受到虛擬主機(jī)提供商的歡迎。
作為負(fù)載均衡服務(wù)器:NGINX既可以在內(nèi)部直接支持Rails和PHP，也可以支持作為HTTP代理服務(wù)器對(duì)外進(jìn)行服務(wù)。NGINX用C語(yǔ)言編寫(xiě)，系統(tǒng)資源開(kāi)銷小，CPU使用效率高。
作為郵件代理服務(wù)器:NGINX同時(shí)也是一個(gè)非常優(yōu)秀的郵件代理服務(wù)器（最早開(kāi)發(fā)這個(gè)產(chǎn)品的目的之一也是作為郵件代理服務(wù)器）。
將NGINX作為API網(wǎng)關(guān)
NGINX用server_name來(lái)定義服務(wù)器名稱，所以它可以決定哪一個(gè)server塊將用來(lái)處理給定的請(qǐng)求，也就是實(shí)現(xiàn)了API網(wǎng)關(guān)的功能。
NGINX可以使用精確名稱、通配符、正則表達(dá)式來(lái)定義服務(wù)器名稱。下面是一個(gè)例子。
server{
listen
80;
server name example.org www.example.org;
server {
listen 80;
server name .example.org;
..
server{
listen
80;
server namemail.*;
server {
listen
80;
server name~^(?.+).examplel.net$;
。。。
}當(dāng)尋找一個(gè)虛擬服務(wù)器的名稱時(shí)，如果指定的名稱匹配多個(gè)變量，如通配符和正則表達(dá)式都匹配，將會(huì)按照以下的順序選擇第一個(gè)匹配的變量。
精確名稱。
以星號(hào)“*”開(kāi)頭的最長(zhǎng)的通配符，如“*.example.org”。
以星號(hào)“*”結(jié)尾的最長(zhǎng)的通配符，如“mail.*”。
第一個(gè)匹配的正則表達(dá)式（根據(jù)在配置文件中出現(xiàn)的順序）。
Spring Cloud Zuul
Zuul是Netflix公司開(kāi)源的一個(gè)API網(wǎng)關(guān)組件，提供了認(rèn)證、鑒權(quán)、限流、動(dòng)態(tài)路由、監(jiān)控、彈性、安全、負(fù)載均衡、協(xié)助單點(diǎn)壓測(cè)、靜態(tài)響應(yīng)等邊緣服務(wù)的框架。
Zuul的基本功能如下。
驗(yàn)證與安全保障:識(shí)別面向各類資源的驗(yàn)證要求并拒絕那些與要求不符的請(qǐng)求。
審查與監(jiān)控:在邊緣位置追蹤有意義的數(shù)據(jù)及統(tǒng)計(jì)結(jié)果，從而為用戶帶來(lái)準(zhǔn)確的生產(chǎn)狀態(tài)結(jié)論。
動(dòng)態(tài)路由:以動(dòng)態(tài)方式根據(jù)需要將請(qǐng)求路由至不同后端集群處。
壓力測(cè)試:逐漸增加指向集群的負(fù)載流量，從而計(jì)算性能水平。
負(fù)載分配:為每一種負(fù)載類型分配對(duì)應(yīng)容量，并棄用超出限定值的請(qǐng)求。
靜態(tài)響應(yīng)處理:在邊緣位置直接建立部分響應(yīng)，從而避免其流入內(nèi)部集群。
Zuul處理每個(gè)請(qǐng)求的方式是針對(duì)每個(gè)請(qǐng)求使用一個(gè)線程來(lái)處理。通常情況下，為了提高性能，所有請(qǐng)求會(huì)被放到處理隊(duì)列中，從線程池中選取空閑線程來(lái)處理該請(qǐng)求。2016年年底，Netlix將它們的網(wǎng)關(guān)服務(wù)Zuul進(jìn)行了升級(jí)，全新的Zuul 2將HTTP請(qǐng)求的處理方式從同步變成了異步，以提升其處理性能。
Spring Cloud Zuul是基于Netflix Zuul的微服務(wù)路由和過(guò)濾器的解決方案，也用于實(shí)現(xiàn)API網(wǎng)關(guān)。
有關(guān)Zuul的內(nèi)容，將會(huì)在本文后續(xù)章節(jié)中詳細(xì)介紹。
Kong
Kong 是專注于提供微服務(wù)API網(wǎng)關(guān)的管理平臺(tái)，它本身是基于NGINX的，但比NGINX提供了更為簡(jiǎn)單的配置方式，并且提供了一些優(yōu)秀的插件，如驗(yàn)證、日志、調(diào)用頻次限制等。
Kong 另外一個(gè)強(qiáng)大之處在于提供了大量的插件來(lái)擴(kuò)展應(yīng)用，通過(guò)設(shè)置不同的插件，可以為服務(wù)提供各種增強(qiáng)的功能。Kong 的插件平臺(tái)可以訪問(wèn)
https://konghq.com/pluginsl。
Kong具有以下特性。
支持云部署:可以運(yùn)行在Kubernetes管理的平臺(tái)上。
動(dòng)態(tài)負(fù)載均衡。
服務(wù)器發(fā)現(xiàn)
webSocket。
OAuth2.0。
日志。
安全:ACL(訪問(wèn)控制）、CORS（跨域資源共享）、動(dòng)態(tài)SSL、IP限制、爬蟲(chóng)檢測(cè)實(shí)現(xiàn)。
系統(tǒng)日志。
SSL。
監(jiān)控。
認(rèn)證:HMAC、JWT、Basic等。
速率限制。
緩存。
RESTAPI。
集群。
可擴(kuò)展。
圖10-2展示了Kong 的架構(gòu)示意圖，該圖來(lái)自Kong官網(wǎng)。
本篇文章內(nèi)容給大家講解的是API網(wǎng)關(guān)的意義和常見(jiàn)API網(wǎng)關(guān)的實(shí)現(xiàn)方式
下篇文章給大家講解如何集成 Zuul和實(shí)現(xiàn)API網(wǎng)關(guān)；
覺(jué)得文章不錯(cuò)的朋友可以轉(zhuǎn)發(fā)此文關(guān)注小編；
感謝大家的支持
本文就是愿天堂沒(méi)有BUG給大家分享的內(nèi)容，大家有收獲的話可以分享下，想學(xué)習(xí)更多的話可以到微信公眾號(hào)里找我，我等你哦。