大廠爲什麼都很重視 API 網關？聊聊 API 網關的作用

-     API 網關的用處     -

在這篇文章中將我們一起來探討當前的 API 網關的作用。

API 網關我的分析中會用到以下三種場景。

Open API

企業需要將自身數據、能力等作爲開發平臺向外開放，通常會以 rest 的方式向外提供，最好的例子就是淘寶開放平臺、騰訊公司的 QQ 開發平臺、微信開放平臺。

Open API 開放平臺必然涉及到客戶應用的接入、API 權限的管理、調用次數管理等，必然會有一個統一的入口進行管理，這正是 API 網關可以發揮作用的時候。

微服務網關

微服務的概念最早在 2012 年提出，在 Martin Fowler 的大力推廣下，微服務在 2014 年後得到了大力發展。在微服務架構中，有一個組件可以說是必不可少的，那就是微服務網關，微服務網關處理了負載均衡，緩存，路由，訪問控制，服務代理，監控，日誌等。API 網關在微服務架構中正是以微服務網關的身份存在。

API 服務管理平臺

上述的微服務架構對企業來說有可能實施上是困難的，企業有很多遺留系統，要全部抽取爲微服務器改動太大，對企業來說成本太高。但是由於不同系統間存在大量的 API 服務互相調用，因此需要對系統間服務調用進行管理，清晰地看到各系統調用關係，對系統間調用進行監控等。

API 網關可以解決這些問題，我們可以認爲如果沒有大規模的實施微服務架構，那麼對企業來說微服務網關就是企業的 API 服務管理平臺。

-     API 網關在企業整體架構中的地位     -

一個企業隨着信息系統複雜度的提高，必然出現外部合作伙伴應用、企業自身的公網應用、企業內網應用等，在架構上應該將這三種應用區別開，三種應用的安排級別、訪問方式也不一樣。

因此在我的設計中將這三種應用分別用不同的網關進行 API 管理，分別是：API 網關（OpenAPI 合夥夥伴應用）、API 網關（內部應用）、API 網關（內部公網應用）。

-     企業如何應用 API 網關     -

1、對於 OpenAPI 使用的 API 網關來說，一般合作伙伴要以應用的形式接入到 OpenAPI 平臺，合作伙伴需要到 OpenAPI 平臺申請應用。

因此在 OpenAPI 網關之外，需要有一個面向合作伙伴的使用的平臺用於合作伙伴，這就要求 OpenAPI 網關需要提供 API 給這個用戶平臺進行訪問。

如下架構：

當然如果是在簡單的場景下，可能並不需要提供一個面向合作伙伴的門戶，只需要由公司的運營人員直接添加合作伙伴應用 id / 密鑰等，這種情況下也就不需要合作伙伴門戶子系統。

2、對於內網的 API 網關，在起到的作用上來說可以認爲是微服務網關，也可以認爲是內網的 API 服務治理平臺。當企業將所有的應用使用微服務的架構管理起來，那麼 API 網關就起到了微服務網關的作用。

而當企業只是將系統與系統之間的調用使用 rest api 的方式進行訪問時使用 API 網關對調用進行管理，那麼 API 網關起到的就是 API 服務治理的作用。

架構參考如下：

3、對於公司內部公網應用（如 APP、公司的網站），如果管理上比較細緻，在架構上是可能由獨立的 API 網關來處理這部分內部公網應用，如果想比較簡單的處理，也可以是使用面向合作伙伴的 API 網關。

如果使用獨立的 API 網關，有以下的好處：

基於以上的分析，如果公司有能力，那麼還是建議分開使用合作伙伴 OPEN API 網關和內部公網應用網關。

-     API 網關有哪些競爭方案     -

1、對於 Open API 平臺的 API 網關，我分析只能選擇 API 網關作爲解決方案，業界沒有發現比較好的可以用來作爲 Open API 平臺的入口的其他方案。

2、對於作爲微服務網關的 API 網關，業界的選擇可以選擇的解決方案比較多，也取決於微服務器的實現方案，有一些微服務架構的實現方案是不需要微服務網關的。

Service Mesh，這是新興的基於無 API 網關的架構，通過在客戶端上的代理完成屏蔽網絡層的訪問，這樣達到對應用層最小的改動，當前 Service Mesh 的產品還正在開發中，並沒有非常成熟可直接應用的產品。發展最迅速的產品是 Istio。建議大家密切關注相關產品的研發、業務使用進展。

基於 dubbo 架構，在這個架構中通常是不需要網關的，是由客戶端直接訪問服務提供方，由註冊中心向客戶端返回服務方的地址。

-     API 網關解決方案     -

私有云開源解決方案如下：

公有云解決方案：

自開發解決方案：

-     企業怎麼選擇 API 網關     -

如果是要選擇一款已有的 API 網關，那麼需要從以下幾個方面去考慮。

1、性能與可用性

如果一旦採用了 API 網關，那麼 API 網關就會作爲企業應用核心，因此性能和可用性是必須要求的。

從性能上來說，需要讓網關增加的時間消耗越短越好，個人覺得需要 10ms 以下。系統需要採用非阻塞的 IO，如 epoll，NIO 等。網關和各種依賴的交互也需要是非阻塞的，這樣才能保證整體系統的高可用性，如：Node.js 的響應式編程和基於 java 體現的 RxJava 和 Future。

網關必須支持集羣部署，任務一臺服務器的 crash 都應該不影響整體系統的可用性。

多套網關應該支持同一管理平臺和同一監控中心。如：一個企業的 OpenAPI 網關和內部應用的多個系統羣的不同的微服務網關可以在同一監控中心進行監控。

2、可擴展性、可維護性

一款產品總有不能滿足生產需求的地方，因此需求思考產品在如何進行二次開發和維護，是否方便公司團隊接手維護產品。

3、需求匹配度

需要評估各 API 網關在需求上是否能滿足，如：如果是 OpenAPI 平臺需要使用 API 網關，那麼需要看 API 網關在合作伙伴應用接入、合作伙伴門戶集成、訪問次數限額等 OpenAPI 核心需求上去思考產品是否能滿足要求。如果是微服務網關，那麼要從微服務的運維、監控、管理等方面去思考產品是否足夠強大。

4、是否開源？公司是否有自開發的能力？

現有的開源產品如 kong，zuul，orange 都有基礎的 API 網關的核心功能，這些開源產品大多離很好的使用有一定的距離，如：沒有提供管理功能的 UI 界面、監控功能弱小，不支持 OpenAPI 平臺，沒有公司運營與運維的功能等。

當然開源產品能獲取源代碼，如果公司有比較強的研發能力，能 hold 住這些開源產品，經過二次開發 kong、zuul 應該還是適應一些公司，不過需求注意以下一些點：

另外 kong 提供企業版本的 API 網關，當然也是基於 ngnix+lua 的，企業版本可以購買他們的技術支持、培訓等服務、以及擁有界面的管理、監控等功能。

5、公有云還是私有云

現在的亞馬遜、阿里、騰訊雲都在提供基礎公有云的 API 網關，當然這些網關的基礎功能肯定是沒有問題，但是二次開發，擴展功能、監控功能可能就不能滿足部分用戶的定製需求了。另外很多企業因爲自身信息安全的原因，不能使用外網公有網的 API 網關服務，這樣就只有選擇私有云的方案了。

在需求上如果基於公有云的 API 網關只能做到由內部人員爲外網人員申請應用，無法做到定製的合作伙伴門戶，這也不適合於部分企業的需求。

如果作爲微服務網關，大多數情況下是希望網關服務器和服務提供方服務器是要在內網的，在這裏情況下也只有私有云的 API 網關才能滿足需求。

綜合上面的分析，基礎公有云的 API 網關只有滿足一部分簡單客戶的需求，對於很多企業來說私有云的 API 網關纔是正確的選擇。

作者：coolfiry

cnblogs.com/coolfiry/p/8193768.html

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/bvJXZuxFE_QX6WzdKsylpA

猜你喜歡