微服務越來越火，越來越多的公司開始采用微服務架構。今天還有人讓我幫推薦好的微服務實施廠商。但采用微服務并不容易，實施微服務可能不可或缺的一個很重要的組件就是API 網關。微服務若要部署于容器云平臺，API網關的實現能力、部署方式、產品選擇等就顯得至關重要。

網關，顧名思義，網絡關口，擔負著安全檢查、認證授權、路由分發、流量控制、熔斷保護等重要的職責。API網關，那就是API的網絡關口、通道，是整個微服務平臺的咽喉，API請求應答必經之路。為了利用容器云彈性伸縮等特性，結合微服務的優點，部署微服務于容器云平臺，則API網關的實施部署則會顯得更復雜些。

[[238635]]

一、API網關

API網關(API Gateway)是一個服務器，是調用服務的唯一節點和請求應答出入口。API Gateway封裝內部系統的架構，并且提供API給各個客戶端。通常情況下它還需要實現其他功能，如認證授權、訪問控制、路由、負載均衡、緩存、日志、限流限額、轉換、映射、過濾、熔斷、注冊、服務編排、API管理、監控、統計分析等等。

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

二、API網關的作用和價值

現在有很多人也在鼓吹API經濟，建立OpenAPI，為合作伙伴或客戶提供云端API服務，根據服務的次數來收取一定的費用。這個我們暫不討論，不過要采用微服務架構，API網關組件是不可或缺的。

很多人對于微服務API網關也都有比較深入的介紹。一個重要的原因是客戶端和微服務通信、微服務重構、協議轉換等的需要，所以我們需要一個API網關來承擔這樣的一個角色。

API網關提供集成能力，統一對外的接口，保護開放的應用，加速應用開發，也實現數據價值，監控分析業務趨勢，協助構建開放平臺等。

1. 集成以實現互連互通

API是系統間集成和企業間整個業務生態系統集成的接口，不管微服務架構或者ESB架構，一個很重要的價值就是實現系統或服務的集成，實現數據、服務共享，盤活整個公司的資源，同時減少重復的投資和建設。

2. 提供統一對外接口以實現標準化、規范化

當實現新的業務應用時或者需要集成不同系統或者服務之間的功能，調用不同服務提供的能力時，利用API網關可以讓用戶在不感知服務邊緣的情況下，利用統一的接口編排組裝服務。對于一個公司內部不同的服務，由于歷史原因提供的接口可能有不小的差異，通過API網關可以消除這種差異，統一對外提供標準化的接口，比如Restful接口。 當內部服務更新時，也可以通過API網關進行適配轉換，對客戶端透明，不需要調用方進行調整。

3. 保護開放的應用以實現安全

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

4. 簡化應用和服務的開發以提升效率

在API網關層實現這些安全機制，不但提高安全性，也簡化了應用服務的開發。使開發人員專注于業務應用、業務服務的研發，不再考慮基礎能力基礎組件，提升開發部署的效率，從而提升收益率。通過對 API服務的分類分級，簡化和控制開發人員對數據和服務的訪問;服務的開放和共享，可以構建更大范圍內的協作和開發人員生態體系。加快業務服務業務應用的交付。

5. 釋放數據價值，促進行業發展

數據永遠都是有價值的，其價值的大小在于怎么去使用它。基于微服務的API服務提供了一種實現數據價值的方式，由API網關來管理這些API服務，是這些API服務不但可以自己用，也可以實現額外收益。同時又為其他企業提供了節省成本的方式，從而實現戰略雙贏。

6. 監控分析業務趨勢，助力智能決策

API網關還要承擔API的監控和管理職責。哪些API服務調用的多，哪些API服務調用的少，誰調用的多，以及高峰流量時刻、平均流量、響應時間等等都是需要監控和統計分析的。這些數據將有助于我們對API服務進行運維或重構，有助于我們做出合理決策。更為智能決策提供必須的數據支持。

7. 協助構建開放平臺，建立生態系統

開放、合作越來越向各個層面擴展和延伸。大到全球化、地球村，小到團隊協作，你已經無法單打獨斗。封閉只會束縛自己。所以對企業來說，也是需要逐步構建和合作伙伴的生態系統，構建自己的開放平臺以融入這個生態。API 網關是其關鍵的一環。

三、API網關要實現的能力

那么API網關要實現哪些能力?通常情況下，需要考慮下面這些能力：

1. API安全

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

安全涉及的問題也比較多，API網關層通常要實現身份統一認證，可對接統一認證中心、權限中心，實現授權認證、訪問控制等功能。

為了最小化延遲，API網關要盡可能的薄。安全的前提下實現快速通過。不能堵塞，所以需要盡可能的減少延遲。

另外考慮采用安全傳輸，防止數據包被其他人篡改、偽造，防止非公共數據被其他人竊聽。可能還需要考慮服務基礎設施安全以及第三方應用/內容安全。

2. 服務預處理

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

3. 服務編排

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

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

這樣，也簡化了微服務開發，更多的關注微服務業務實現，把服務的注冊、編排、流控等等都交給API網關層去實現。

4. 服務注冊

API網關層提供服務編排能力，編排的服務也需要注冊到注冊中心，成為一個新的服務。API網關需要提供服務注冊的能力。

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

5. API管理

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

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

6. API網關部署

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

在負載壓力大的需求下，可以考慮分渠道部署方式，比如Web、手機App、PC App等分別部署API網關。

四、API 網關選擇

1. 開源

越來越多的企業采用微服務，越來越多的人認識到微服務API網關的重要性，API網關的發展和完善也越來越好。很多開源的產品功能也很強大，足以滿足大部分企業的部署需求。基于這些開源產品，可以定制擴展一些功能，更好的滿足業務需求。

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

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



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

還有很多其他的一些開源API網關，有興趣可以搜索查閱相關資料。

2. 自研

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

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

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

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

3. 商用

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

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

產品的詳細信息可以查閱網站相關資料深入了解。另外也可以考慮開源產品的企業版，比如Nginx Plus，Tyk專業版，Kong企業版等。

五、結論

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