微服務應用程序架構
我不確定這是否是就基礎架構架構提出問題的正確論壇。但是希望如此發布問題：
我的一位客戶有一個使用最新微服務技術開發的 Web 應用程序。Kubernetes 是底層。最重要的是，他們正在使用 CDN、API 託管等。現在，從公共雲（azure 或 AWS）的角度來看，我如何在這裡建構基礎設施？關於他們使用的服務，我有幾個問題。為簡單起見，我將從 Azure POV 開始討論。決定使用 Azure 中的以下組件：
Azure CDN、Azure 應用程序網關、Azure FrontDoor。
我對這些服務的呼叫流程感到困惑。從客戶端（如 Web 瀏覽器），當有對應用程序的請求時，理想情況下，靜態內容需要由 Azure CDN 響應，而其他動態內容需要通過檢查容器或伺服器來響應。所以，這就是我對呼叫流程的假設：
瀏覽器 -> Azure 前門 -> 應用程序網關 -> API 管理微服務 -> 其他微服務 -> Azure CDN -> 瀏覽器
它是否正確？如果沒有，您能否指導我了解更好的架構。任何幫助將不勝感激。
好的，首先你有幾個不同的服務在那裡做同樣的事情，所以你想評估你是否需要它們。
- Azure CDN 和 Front Door 都提供相同的本地存在點和記憶體，因此您真的只需要一個或另一個
- Azure Front Door 和 App Gateway 都提供第 7 層負載平衡和 Web 應用程序防火牆，因此您可能不需要兩者。App GW 確實具有一些額外的功能，例如 vNet 附件和 K8s Ingress，因此兩者可能存在爭議
無論您選擇 Front Door 還是 CDN，他們都希望在您的堆棧中處於領先地位。理想情況下，您希望流量到達 FD/CDN，獲得記憶體響應，然後請求結束。
如果您不能從記憶體中提供服務，那麼現在您需要將您的流量導入 Kubernetes，因此您的前端資源（CDN 或 Front Door）現在將轉發到您將 Kubernetes 集群暴露給外部世界的情況。如果您決定需要它，這可能是應用程序網關、外部負載均衡器或 Azure API 管理器（如果您使用它來公開 API）。
Front Door 是一項未附加 vNet 的全域服務。您的 Kubernetes 集群是附加的 vNet，因此您需要一種將 Kubernetes 資源公開給 Front Door 的方法。這可以通過 App GW 完成，但會增加額外費用，您也可以使用具有公共 IP 的 Azure 負載均衡器設置 Kubernetes 入口，然後與前門對話。
如果您擺脫 App GW，那麼您將需要在集群中執行另一個入口控制器，例如 NGinx、Traefik 等。或者您可以保留 App GW，但我會使用 CDN 而不是 Front Door。
Front Door 和 CDN 使用相同的端點，因此提供相同的記憶體。