服務化應用對API Gateway的功能需求

2021-09-28 18:21:49 字數 372 閱讀 1684

api gateway需求中很大一部分需要根據不同的應用系統進行定製,目前看來暫時不大可能被納入k8s ingress或者istio gateway的規範之中。為了滿足這些需求,湧現出了各類不同的k8s ingress controller以及istio ingress gateway實現,包括ambassador ,kong, traefik,solo等。

這些閘道器產品在實現在提供基礎的k8s ingress能力的同時,提供了強大的api gateway功能,但由於缺少統一的標準,這些擴充套件實現之間相互之間並不相容。而且遺憾的是,目前這些ingress controller都還沒有正式提供和istio 控制面整合的能力。

備註:

caddy 作為微服務的 API gateway

大家都知道,docker這些年讓it界產生了深刻的變革,從開發到測試到運維,處處都有它的身影。它同時也和微服務架構相互促進,並肩前行。在最新版的 docker ce 17.03 裡,隨著swarm mode的成熟,在較簡單的場景裡已經可以不再需要專門的基礎設施管理,服務編排,服務發現,健康檢查,負載...

從單體應用走向服務化

之前講解了什麼是微服務 微服務的核心在於服務治理,微服務架構是將複雜臃腫的單體應用進行細粒度的服務化拆分,每個拆分出來的服務各自獨立打包部署,並交由小團隊進行開發和運維,從而極大地提高了應用交付的效率。什麼時候進行服務化拆分?拆分單體應用有哪些標準呢?這個時候就需要大規模地擴張開發人員,以支撐多個功...

池化服務與非池化服務

池化服務 選取池化服務時,伺服器物件在伺服器執行時 預先建立了指定數目的,並且只在使用者請求伺服器物件時,優先使用 已建立的伺服器物件,如果沒有空閒的伺服器物件才會建立新的伺服器物件返回給使用者程序進行相應的操作,並且當使用者操作結束後立即將伺服器物件 釋放回到伺服器物件池中等待下乙個使用者會話。h...