本篇內容介紹了“如何選擇適合自己的微服務API網(wǎng)關”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

在淶水等地區(qū)，都構建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產品創(chuàng)新能力，以專注、極致的服務理念，為客戶提供做網(wǎng)站、網(wǎng)站建設 網(wǎng)站設計制作按需定制,公司網(wǎng)站建設,企業(yè)網(wǎng)站建設,成都品牌網(wǎng)站建設,營銷型網(wǎng)站建設,成都外貿網(wǎng)站建設,淶水網(wǎng)站建設費用合理。

微服務 API 網(wǎng)關有什么作用？

讓我們先來看下微服務 API 網(wǎng)關的作用，下圖是一個簡要的說明：

API 網(wǎng)關并非一個新興的概念，在十幾年前就已經存在了，它的作用主要是作為流量的入口，統(tǒng)一的處理和業(yè)務相關的請求，讓請求更加安全、快速和準確的得到處理。它有以下傳統(tǒng)的功能：

1. 反向代理和負載均衡，這和 Nginx 的定位和功能是一致的；

2. 動態(tài)上游、動態(tài) SSL 證書和動態(tài)限流限速等運行時的動態(tài)功能，這是開源版本 Nginx 并不具備的功能；

3. 上游的主動和被動健康檢查，以及服務熔斷；

4. 在 API 網(wǎng)關的基礎之上進行擴展，成為全生命周期的 API 管理平臺。

在最近幾年，業(yè)務相關的流量，不再僅僅是由 PC 客戶端和瀏覽器發(fā)起，更多的來自手機、IoT 設備等，未來隨著 5G 的普及，這些流量會越來越多，同時，隨著微服務架構的結構變遷，服務之間的流量也開始爆發(fā)性的增長。在這種新的業(yè)務場景下，催生了API 網(wǎng)關更多、更高級的功能：

1. 云原生友好，架構要變得輕巧，便于容器化；

2. 對接 Prometheus、Zipkin、Skywalking 等統(tǒng)計、監(jiān)控組件；

3. 支持 gRPC 代理，以及 http 到 gRPC 之間的協(xié)議轉換，把用戶的 http 請求轉為內部服務的 gPRC 請求；

4. 承擔 OpenID Relying Party 的角色，對接 Auth0、okta 等身份認證提供商的服務，把流量的安全作為頭等大事來對待；

5. 通過運行時動態(tài)執(zhí)行用戶函數(shù)的方式來實現(xiàn) serverless，讓網(wǎng)關的邊緣節(jié)點更加靈活；

6. 不鎖定用戶，支持混合云的部署架構；

7. 最后就是網(wǎng)關節(jié)點要狀態(tài)無關，可以隨意的擴容和縮容。

一個微服務 API 網(wǎng)關具備了上述十幾項功能，就可以讓用戶的服務只關心業(yè)務本身，而和業(yè)務實現(xiàn)無關的功能，比如服務發(fā)現(xiàn)、服務熔斷、身份認證、限流限速、統(tǒng)計、性能分析等，就可以在獨立的網(wǎng)關層面來解決。從這個角度來看，API 網(wǎng)關既可以替代 Nginx 的所有功能，來處理南北向的流量，也可以完成 Istio 控制面和 Envoy 數(shù)據(jù)面的角色，來處理東西向的流量。

備選的 API 網(wǎng)關有哪些？

正因為微服務 API 網(wǎng)關的地位如此重要，所以它一直處于兵家必爭之地，傳統(tǒng)的 IT 巨頭在這個領域很早就都有布局，比如谷歌、CA、IBM、紅帽、salesforce、以及 AWS、阿里云等公有云廠商。

這些閉源的商業(yè)產品，它們的功能都很完善，覆蓋了 API 的設計、多語言 SDK、文檔、測試和發(fā)布等全生命周期管理，并且提供 SaaS 服務，有些還與公有云做了集成，使用起來非常方便，但同時也帶來兩個痛點：

1. 平臺鎖定。API 網(wǎng)關是業(yè)務流量的入口，它不像圖片、視頻等 cdn 加速的這種非業(yè)務流量可以隨意遷移，API 網(wǎng)關上會綁定不少業(yè)務相關的邏輯，一旦使用了閉源的方案，就很難平滑和低成本的遷移到其他平臺。

2. 無法二次開發(fā)。一般的大中型企業(yè)都會有自己獨特的需求，需要定制開發(fā)，這時候你就只能依靠廠商，而不能自己動手去做二次開發(fā)。

所以我們更偏重于開源的 API 網(wǎng)關方案，比如 Kong、APISIX 和 Trk 等。這些 API 網(wǎng)關是從云原生軟件基金會（CNCF）的全景圖中摘選的：

對比選型的依據(jù)

部署和維護成本

• 是可以在單機就能完整部署，還是需要多個節(jié)點配合才能使用？

• 是否有外部的數(shù)據(jù)庫依賴？比如 MySQL、Postgres？

• 是否有 web 控制臺可以操作整個集群？

開源還是閉源

• 你是否可以編寫自己的插件來擴展 API 網(wǎng)關的功能？

• 當你使用了某個 API 網(wǎng)關后，是否可以平滑而且低成本的遷移到其他 API 網(wǎng)關？

• 是否會被鎖定在特定的平臺上？

能否私有化部署

• 是否支持部署在用戶自己的內部服務器中？

• 是否支持多云、混合云的部署模式？

功能

• 是否支持動態(tài)上游、動態(tài) SSL 證書、主動/被動健康檢查這些基本的功能

• 能否對接 Prometheus、Zipkin、Skywalking 等統(tǒng)計、監(jiān)控組件

• 是否可以通過 HTTP REST API 和 yaml 配置文件這兩種方式，來控制網(wǎng)關配置

社區(qū)

• 使用者能否通過 Github、QQ 群、Stack Overflow 等方式聯(lián)系到社區(qū)的開發(fā)者？

• 開源許可證是否友好？

• 是否可以方便的提交自己的修改到主線版本？

• 背后是否有商業(yè)公司支持？

商業(yè)支持和價格

• 開源版本和商業(yè)版本差異是否很大？

• 商業(yè)版本是按照 API 調用次數(shù)還是訂閱方式收費？

API 網(wǎng)關對比

下面是各個 API 網(wǎng)關多個角度的對比結果：

從中我們可以看出，Kong 和 APISIX 都是非常好的選擇。

“如何選擇適合自己的微服務API網(wǎng)關”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質量的實用文章！