微服務(wù)越來越火，越來越多的公司開始采用微服務(wù)架構(gòu)。今天還有人讓我?guī)屯扑]好的微服務(wù)實施廠商。但采用微服務(wù)并不容易，實施微服務(wù)可能不可或缺的一個很重要的組件就是API 網(wǎng)關(guān)。微服務(wù)若要部署于容器云平臺，API網(wǎng)關(guān)的實現(xiàn)能力、部署方式、產(chǎn)品選擇等就顯得至關(guān)重要。

網(wǎng)關(guān)，顧名思義，網(wǎng)絡(luò)關(guān)口，擔(dān)負(fù)著安全檢查、認(rèn)證授權(quán)、路由分發(fā)、流量控制、熔斷保護(hù)等重要的職責(zé)。API網(wǎng)關(guān)，那就是API的網(wǎng)絡(luò)關(guān)口、通道，是整個微服務(wù)平臺的咽喉，API請求應(yīng)答必經(jīng)之路。為了利用容器云彈性伸縮等特性，結(jié)合微服務(wù)的優(yōu)點，部署微服務(wù)于容器云平臺，則API網(wǎng)關(guān)的實施部署則會顯得更復(fù)雜些。

[[238635]]

一、API網(wǎng)關(guān)

API網(wǎng)關(guān)(API Gateway)是一個服務(wù)器，是調(diào)用服務(wù)的唯一節(jié)點和請求應(yīng)答出入口。API Gateway封裝內(nèi)部系統(tǒng)的架構(gòu)，并且提供API給各個客戶端。通常情況下它還需要實現(xiàn)其他功能，如認(rèn)證授權(quán)、訪問控制、路由、負(fù)載均衡、緩存、日志、限流限額、轉(zhuǎn)換、映射、過濾、熔斷、注冊、服務(wù)編排、API管理、監(jiān)控、統(tǒng)計分析等等。

從API網(wǎng)關(guān)的能力來看，我們可以理解其重要性。一夫當(dāng)關(guān)，萬夫莫開。API網(wǎng)關(guān)就承擔(dān)這么一個重要的職責(zé)。其不但是整個服務(wù)系統(tǒng)的安全屏障，也承擔(dān)著很多服務(wù)治理的能力。所以實現(xiàn)或者選擇一個好的API網(wǎng)關(guān)，是建設(shè)容器云和微服務(wù)體系中一個至關(guān)重要的事項。這也決定了API網(wǎng)關(guān)的部署，要盡可能的減少接觸面，確保安全。

二、API網(wǎng)關(guān)的作用和價值

現(xiàn)在有很多人也在鼓吹A(chǔ)PI經(jīng)濟(jì)，建立OpenAPI，為合作伙伴或客戶提供云端API服務(wù)，根據(jù)服務(wù)的次數(shù)來收取一定的費用。這個我們暫不討論，不過要采用微服務(wù)架構(gòu)，API網(wǎng)關(guān)組件是不可或缺的。

很多人對于微服務(wù)API網(wǎng)關(guān)也都有比較深入的介紹。一個重要的原因是客戶端和微服務(wù)通信、微服務(wù)重構(gòu)、協(xié)議轉(zhuǎn)換等的需要，所以我們需要一個API網(wǎng)關(guān)來承擔(dān)這樣的一個角色。

API網(wǎng)關(guān)提供集成能力，統(tǒng)一對外的接口，保護(hù)開放的應(yīng)用，加速應(yīng)用開發(fā)，也實現(xiàn)數(shù)據(jù)價值，監(jiān)控分析業(yè)務(wù)趨勢，協(xié)助構(gòu)建開放平臺等。

1. 集成以實現(xiàn)互連互通

API是系統(tǒng)間集成和企業(yè)間整個業(yè)務(wù)生態(tài)系統(tǒng)集成的接口，不管微服務(wù)架構(gòu)或者ESB架構(gòu)，一個很重要的價值就是實現(xiàn)系統(tǒng)或服務(wù)的集成，實現(xiàn)數(shù)據(jù)、服務(wù)共享，盤活整個公司的資源，同時減少重復(fù)的投資和建設(shè)。

2. 提供統(tǒng)一對外接口以實現(xiàn)標(biāo)準(zhǔn)化、規(guī)范化

當(dāng)實現(xiàn)新的業(yè)務(wù)應(yīng)用時或者需要集成不同系統(tǒng)或者服務(wù)之間的功能，調(diào)用不同服務(wù)提供的能力時，利用API網(wǎng)關(guān)可以讓用戶在不感知服務(wù)邊緣的情況下，利用統(tǒng)一的接口編排組裝服務(wù)。對于一個公司內(nèi)部不同的服務(wù)，由于歷史原因提供的接口可能有不小的差異，通過API網(wǎng)關(guān)可以消除這種差異，統(tǒng)一對外提供標(biāo)準(zhǔn)化的接口，比如Restful接口。 當(dāng)內(nèi)部服務(wù)更新時，也可以通過API網(wǎng)關(guān)進(jìn)行適配轉(zhuǎn)換，對客戶端透明，不需要調(diào)用方進(jìn)行調(diào)整。

3. 保護(hù)開放的應(yīng)用以實現(xiàn)安全

在我們看來，API網(wǎng)關(guān)最重要的能力是其安全能力。減少對外暴露的服務(wù)可以增加系統(tǒng)安全性。實現(xiàn)授權(quán)認(rèn)證、訪問控制、防范威脅和OWASP漏洞、通過SSO和統(tǒng)一身份管理來等提高安全性，為應(yīng)用程序、移動和IoT提供端到端的安全機制。也可能需要在API網(wǎng)關(guān)實現(xiàn)流量控制、限額、過濾、熔斷、服務(wù)優(yōu)先級控制、負(fù)載均衡等機制來保護(hù)應(yīng)用服務(wù)的安全。不管private API或者OpenAPI， 其安全性都是一個時刻都需要認(rèn)真面對的課題。

4. 簡化應(yīng)用和服務(wù)的開發(fā)以提升效率

在API網(wǎng)關(guān)層實現(xiàn)這些安全機制，不但提高安全性，也簡化了應(yīng)用服務(wù)的開發(fā)。使開發(fā)人員專注于業(yè)務(wù)應(yīng)用、業(yè)務(wù)服務(wù)的研發(fā)，不再考慮基礎(chǔ)能力基礎(chǔ)組件，提升開發(fā)部署的效率，從而提升收益率。通過對 API服務(wù)的分類分級，簡化和控制開發(fā)人員對數(shù)據(jù)和服務(wù)的訪問;服務(wù)的開放和共享，可以構(gòu)建更大范圍內(nèi)的協(xié)作和開發(fā)人員生態(tài)體系。加快業(yè)務(wù)服務(wù)業(yè)務(wù)應(yīng)用的交付。

5. 釋放數(shù)據(jù)價值，促進(jìn)行業(yè)發(fā)展

數(shù)據(jù)永遠(yuǎn)都是有價值的，其價值的大小在于怎么去使用它?；谖⒎?wù)的API服務(wù)提供了一種實現(xiàn)數(shù)據(jù)價值的方式，由API網(wǎng)關(guān)來管理這些API服務(wù)，是這些API服務(wù)不但可以自己用，也可以實現(xiàn)額外收益。同時又為其他企業(yè)提供了節(jié)省成本的方式，從而實現(xiàn)戰(zhàn)略雙贏。

6. 監(jiān)控分析業(yè)務(wù)趨勢，助力智能決策

API網(wǎng)關(guān)還要承擔(dān)API的監(jiān)控和管理職責(zé)。哪些API服務(wù)調(diào)用的多，哪些API服務(wù)調(diào)用的少，誰調(diào)用的多，以及高峰流量時刻、平均流量、響應(yīng)時間等等都是需要監(jiān)控和統(tǒng)計分析的。這些數(shù)據(jù)將有助于我們對API服務(wù)進(jìn)行運維或重構(gòu)，有助于我們做出合理決策。更為智能決策提供必須的數(shù)據(jù)支持。

7. 協(xié)助構(gòu)建開放平臺，建立生態(tài)系統(tǒng)

開放、合作越來越向各個層面擴展和延伸。大到全球化、地球村，小到團(tuán)隊協(xié)作，你已經(jīng)無法單打獨斗。封閉只會束縛自己。所以對企業(yè)來說，也是需要逐步構(gòu)建和合作伙伴的生態(tài)系統(tǒng)，構(gòu)建自己的開放平臺以融入這個生態(tài)。API 網(wǎng)關(guān)是其關(guān)鍵的一環(huán)。

三、API網(wǎng)關(guān)要實現(xiàn)的能力

那么API網(wǎng)關(guān)要實現(xiàn)哪些能力?通常情況下，需要考慮下面這些能力：

1. API安全

安全第一，就像我們的社會交通一樣，第一要保證安全，然后才是快速通過。這也是在實現(xiàn)或選擇API網(wǎng)關(guān)時首先要考慮的問題。

安全涉及的問題也比較多，API網(wǎng)關(guān)層通常要實現(xiàn)身份統(tǒng)一認(rèn)證，可對接統(tǒng)一認(rèn)證中心、權(quán)限中心，實現(xiàn)授權(quán)認(rèn)證、訪問控制等功能。

為了最小化延遲，API網(wǎng)關(guān)要盡可能的薄。安全的前提下實現(xiàn)快速通過。不能堵塞，所以需要盡可能的減少延遲。

另外考慮采用安全傳輸，防止數(shù)據(jù)包被其他人篡改、偽造，防止非公共數(shù)據(jù)被其他人竊聽?？赡苓€需要考慮服務(wù)基礎(chǔ)設(shè)施安全以及第三方應(yīng)用/內(nèi)容安全。

2. 服務(wù)預(yù)處理

路由、過濾、流控、限額、熔斷、轉(zhuǎn)換、優(yōu)先級、負(fù)載均衡……我們在《微服務(wù)之服務(wù)治理》一文中有過討論，這里就不再贅述。主要的服務(wù)治理策略，防止服務(wù)不可用。

3. 服務(wù)編排

使用API網(wǎng)關(guān)層構(gòu)建組合服務(wù)——業(yè)務(wù)服務(wù)，這涉及到API網(wǎng)關(guān)的開發(fā)能力，也就是服務(wù)編排能力，大部分開源的API網(wǎng)關(guān)是不支持的。我們在《容器云之服務(wù)編排設(shè)計》一文中也討論過。不過有個問題需要考慮，采用微服務(wù)架構(gòu)，服務(wù)部署時可能部署多個服務(wù)實例，是每個服務(wù)實例都在注冊中心注冊，還是所有的服務(wù)實例只注冊一個服務(wù)?這是我們曾經(jīng)遇到的問題。

如果采用商用的API網(wǎng)關(guān)產(chǎn)品，基本上都有服務(wù)編排和服務(wù)注冊能力，可以利用API網(wǎng)關(guān)的服務(wù)注冊能力，在API網(wǎng)關(guān)層實現(xiàn)服務(wù)注冊，而不用在每個微服務(wù)代碼里實現(xiàn)服務(wù)注冊。這樣既可以在API網(wǎng)關(guān)層實現(xiàn)服務(wù)的編排，也可以充分利用容器云的負(fù)載均衡和彈性伸縮等特性，微服務(wù)實例不需要注冊到注冊中心，每個微服務(wù)(一到多個微服務(wù)實例)僅在注冊中心注冊一次。

這樣，也簡化了微服務(wù)開發(fā)，更多的關(guān)注微服務(wù)業(yè)務(wù)實現(xiàn)，把服務(wù)的注冊、編排、流控等等都交給API網(wǎng)關(guān)層去實現(xiàn)。

4. 服務(wù)注冊

API網(wǎng)關(guān)層提供服務(wù)編排能力，編排的服務(wù)也需要注冊到注冊中心，成為一個新的服務(wù)。API網(wǎng)關(guān)需要提供服務(wù)注冊的能力。

我們遇到過這樣一個問題：一個服務(wù)分別部署于容器云平臺和虛擬機，分別注冊于容器云平臺內(nèi)部注冊中心和容器云平臺外部注冊中心，如何實現(xiàn)這個服務(wù)的調(diào)用?這是我們一個開發(fā)團(tuán)隊面臨的問題。一方面希望利用容器云平臺的便捷的持續(xù)集成持續(xù)部署特性，另一方面也不太相信容器云平臺的可靠性和穩(wěn)定性，所以希望在虛擬機環(huán)境同時備份。同樣面臨著多服務(wù)實例的問題，彈性伸縮的問題。如果在服務(wù)Client端實現(xiàn)負(fù)載均衡，明顯要復(fù)雜很多。虛擬機和容器云平臺如果都部署網(wǎng)關(guān)服務(wù)，也比較麻煩。最好的方式就是通過統(tǒng)一的API網(wǎng)關(guān)，實現(xiàn)路由配置，也可實現(xiàn)流量分配，這樣一個API入口可以路由到不同的服務(wù)或服務(wù)實例(虛擬機或容器云平臺上)。在API網(wǎng)關(guān)層通過配置來實現(xiàn)，API網(wǎng)關(guān)作為一個獨立的組件來部署。比如Nginx plus其支持eureka、consul、etcd、等服務(wù)注冊機制，作為整個平臺獨立的一個API網(wǎng)關(guān)獨立部署。

5. API管理

通常情況下， API網(wǎng)關(guān)層需要考慮實現(xiàn)對API生命周期的管理、配置、監(jiān)控等能力，也就是API管理的能力。API也可分為private API和 Open API。我們在討論微服務(wù)階段模型中提到生態(tài)級，就是提供OpenAPI與合作伙伴等共同構(gòu)建服務(wù)生態(tài)系統(tǒng)。

商用API的管理產(chǎn)品通常包括API網(wǎng)關(guān)、API開發(fā)工具、管理控制臺等組件，提供API開發(fā)、配置、部署、監(jiān)控、更新等整個API生命周期管理。開源的API網(wǎng)關(guān)通常比較簡單。提供API網(wǎng)關(guān)的基礎(chǔ)能力或者僅API網(wǎng)關(guān)實施框架。

6. API網(wǎng)關(guān)部署

采用微服務(wù)部署于容器云平臺，API網(wǎng)關(guān)作為重要的基礎(chǔ)組件，其部署也需要認(rèn)真考慮。前期的文章中我們也討論過，就目前階段而言，采用容器云也不是所有組件都容器化部署，在都熱衷于討論去中心化的今天也不是沒有中心，所以我們建議采用中心化非容器化部署，采用雙機集群多活高可用模式部署，不要采用主備模式，也不要單機部署，雖然商用的產(chǎn)品處理能力足夠強，也要避免可能單點故障，單點瓶頸問題，難以擴展的問題。

在負(fù)載壓力大的需求下，可以考慮分渠道部署方式，比如Web、手機App、PC App等分別部署API網(wǎng)關(guān)。

四、API 網(wǎng)關(guān)選擇

1. 開源

越來越多的企業(yè)采用微服務(wù)，越來越多的人認(rèn)識到微服務(wù)API網(wǎng)關(guān)的重要性，API網(wǎng)關(guān)的發(fā)展和完善也越來越好。很多開源的產(chǎn)品功能也很強大，足以滿足大部分企業(yè)的部署需求?；谶@些開源產(chǎn)品，可以定制擴展一些功能，更好的滿足業(yè)務(wù)需求。

• Tyk是一個開放源碼的API網(wǎng)關(guān)、面板和API管理平臺，由Tyk公司開發(fā)和支持。Try 是一個基于Go實現(xiàn)的網(wǎng)關(guān)服務(wù)。包括Tyk API Gateway,Tyk Dashboard, Tyk Developer Portal, Tyk Pump, Tyk Identity Broker等組件。Tyk開源API Gateway對實際上的請求管理做了重大的提升：路由、訪問控制、數(shù)據(jù)轉(zhuǎn)換、日志等等。Tyk可以完全獨立運行，只需要有效的Redis數(shù)據(jù)庫，可以橫向擴展(如下圖)：

• Kong是一個可擴展的開源微服務(wù)API網(wǎng)關(guān)，Kong 在任何RESTful API的前面運行，通過插件擴展，它提供了超越核心平臺的額外功能和服務(wù)。它基于nginx 上進(jìn)行的開發(fā)。Kong部署于可靠的技術(shù)之上，比如NGINX和Apache Cassandra或者PostgreSQL，提供易用的RESTful API來操作和配置應(yīng)用服務(wù)。



• Zuul是Netflix出品的一個基于JVM路由和服務(wù)端的負(fù)載均衡器。它的主要功能有：認(rèn)證、動態(tài)路由、監(jiān)視、彈性、壓力測試、金絲雀測試、負(fù)載削減、安全、靜態(tài)響應(yīng)處理和主動/主動交換管理。被用來作為上Spring Cloud的API網(wǎng)關(guān)組件，可以和spring cloud的各個組件結(jié)合使用。
• Spring Cloud Gateway是構(gòu)建于Spring Frameworks 5, Factor項目和Spring Boot 2.0之上的可編程路由器。能夠匹配任何請求屬性的路由，熔斷、過濾、服務(wù)發(fā)現(xiàn)集成、限流、轉(zhuǎn)換等能力。它采用反應(yīng)式編程，比較新，我們嘗試用但由于時間緊，難以學(xué)習(xí)這么多新的技術(shù)，最后不得不依舊采用zuul暫時方案。
• NGINX或NGINX Plus提供一個成熟的、可擴展的、高性能web服務(wù)器和反向代理，它們均容易部署、配置和二次開發(fā)。Nginx可以結(jié)合Lua腳本實現(xiàn)一個API網(wǎng)關(guān)能力，NGINX Plus可以管理授權(quán)、權(quán)限控制、負(fù)載均衡、緩存并提供應(yīng)用健康檢查和監(jiān)控等。

還有很多其他的一些開源API網(wǎng)關(guān)，有興趣可以搜索查閱相關(guān)資料。

2. 自研

也有不少公司基于開源自研API網(wǎng)關(guān)，或者在實現(xiàn)微服務(wù)時使用類似SpringCloud Netflix Zuul等來實現(xiàn)微服務(wù)網(wǎng)關(guān)。這里涉及到微服務(wù)網(wǎng)關(guān)或者API網(wǎng)關(guān)的部署問題、以及服務(wù)間交互問題、網(wǎng)關(guān)要實現(xiàn)的能力問題等等。比如是集中式部署或是sidecar方式部署?不同的公司可能采用不同的方案。從我們視角來看，集中式部署應(yīng)該會更合適些，特別是如果想基于容器云平臺構(gòu)建服務(wù)中臺，更好的支撐業(yè)務(wù)應(yīng)用，集中式非容器化部署更好。

API gateway 的實現(xiàn)方式有很多種，對于大多數(shù)應(yīng)用，API Gateway的性能和可擴展性也是非常重要的。因此，創(chuàng)建一個支持同步、非阻塞I/O的API Gateway是有意義的。已經(jīng)有不同的技術(shù)可以用來實現(xiàn)一個可擴展的API Gateway。在JVM上，采用基于NIO技術(shù)的框架，如Netty，Vertx，Spring Reactor或者JBoss Undertow。Node.js是一個非JVM的流行平臺，它是一個在Chrome的JavaScript引擎基礎(chǔ)上建立的平臺。Spring Cloud Gateway就是基于Spring Ractor的實現(xiàn)。

API網(wǎng)關(guān)自研難度還是有的，要實現(xiàn)生產(chǎn)可用的微服務(wù)網(wǎng)關(guān)，需要考慮實現(xiàn)眾多的功能。比如SpringCloud的相關(guān)組件包括：Zuul、Ribbon、EureKa、Fein、Hystrix等。其中Zuul就是一個類似APIGateway的組件，但僅有zuul遠(yuǎn)遠(yuǎn)不夠。Ribbon是客戶端負(fù)載均衡工具，Eureka用于注冊和發(fā)現(xiàn)服務(wù)，Hystrix可以實現(xiàn)微服務(wù)的斷路服務(wù)，用于服務(wù)降級。Fein可以作為一個Rest服務(wù)的提供者，可以供內(nèi)部服務(wù)之間相互調(diào)用。包括但不限于所有這些能力都需要在API網(wǎng)關(guān)層實現(xiàn)。

要實現(xiàn)這些能力，技術(shù)力量要求就比較高，投入也不小，后期更新和運維都是需要考慮的，所以不太適合傳統(tǒng)企業(yè)。傳統(tǒng)企業(yè)更適合商用的方案。

3. 商用

商用的API網(wǎng)關(guān)產(chǎn)品也非常多，根據(jù)Partner 全生命周期API管理魔力象限，處于領(lǐng)導(dǎo)地位的產(chǎn)品有Google Apigee，CA API Management，IBM API Management，Axway， Mulesoft，TIBCO Mashary， Redhat 3Scale等。大部分都是美國的公司，國內(nèi)這塊需求似乎不明確，或者沒有認(rèn)識到其重要性，所以相關(guān)人員也很少，很難聯(lián)系到。商用產(chǎn)品成本還是比較高，適合大的傳統(tǒng)企業(yè)。Axway API Management等產(chǎn)品功能很強很完整，超出大部分公司的需求，所以這些商用的產(chǎn)品適合大的跨國公司或有眾多分支機構(gòu)的企業(yè)。小公司用起來有些浪費。

• Axway專業(yè)做API網(wǎng)關(guān)產(chǎn)品，中國團(tuán)隊響應(yīng)非常敏捷，而且很nice，很熱心。這個要給贊，五星好評!
• Apigee目前算是最流行的一款A(yù)PI管理產(chǎn)品，國內(nèi)似乎沒有，在和Pivatal交流時他們提到pivotal的容器云產(chǎn)品內(nèi)置支持Apigee。
• CA API Management也是一款功能特別強大的產(chǎn)品，和Apigee不相上下，不過我多次聯(lián)系過CA 全球，CA API Management中國團(tuán)隊，網(wǎng)站留言等，得到過一次回復(fù)后就沒有進(jìn)一步的響應(yīng)，產(chǎn)品很好，服務(wù)卻很差，不得不給差評。
• 原來TIBCO有款A(yù)PI Exchange Gateway產(chǎn)品，是基于SOA服務(wù)的服務(wù)網(wǎng)關(guān)產(chǎn)品，不過產(chǎn)品相對功能簡單，有很大局限性，目前TIBCO重點在推TIBCO Mashary，這是TIBCO收購的產(chǎn)品，目前似乎還不支持on premises部署，這點有局限性，不過據(jù)說很快就可以支持。希望TIBCO能推出更好更適合不同需求更人性化的產(chǎn)品。也希望TIBCO中國團(tuán)隊好好努力。
• 3Scale API management也是Redhat 收購的產(chǎn)品，我也是聯(lián)系多次沒有進(jìn)一步響應(yīng)。非常遺憾，至少服務(wù)不得不給差評。

產(chǎn)品的詳細(xì)信息可以查閱網(wǎng)站相關(guān)資料深入了解。另外也可以考慮開源產(chǎn)品的企業(yè)版，比如Nginx Plus，Tyk專業(yè)版，Kong企業(yè)版等。

五、結(jié)論

對于傳統(tǒng)企業(yè)，在采用API網(wǎng)關(guān)時，可以遵循基礎(chǔ)設(shè)施平臺外購、業(yè)務(wù)應(yīng)用自研的原則。不必要花費大量的人力和財力來自研基礎(chǔ)設(shè)施平臺，外購成熟的產(chǎn)品是比較合適的方式。然后集中技術(shù)力量研發(fā)新業(yè)務(wù)應(yīng)用和支持新業(yè)務(wù)。除非有足夠的人力財力，并且想做行業(yè)內(nèi)推廣，以此來獲取收益，可以考慮自研基礎(chǔ)設(shè)施平臺，不過這樣和一家軟件公司也沒太大區(qū)別，成本投入也將非常大。如果基于開源做一些封裝修改也是可以，但不會有眾多的客戶的實際環(huán)境驗證，不會有商用產(chǎn)品的安全和穩(wěn)定。如果沒有足夠強的技術(shù)實力，一旦遇到復(fù)雜的技術(shù)問題，就可能影響到實際業(yè)務(wù)。所以不同的公司不同的實際情況，可以選擇合適的方式。