Azure Container Apps 提供內建的服務發現與路由功能，讓你的容器應用程式能彼此溝通，無需管理基礎設施。 當你在同一 環境中部署多個容器應用程式時，平台會自動處理 DNS 解析、負載平衡及流量路由安全。
如果啟用 了 Ingress ，每個容器應用程式都會獲得一個網域名稱。 你可以將該端點公開提供，或限制為只供相同環境中的其他容器應用程式使用。
容器應用程式可以透過以下任一方式互相聯繫：
- 完全限定域名（FQDN）： 預設產生的網域
-
應用程式名稱：內部通話的簡短網址
http://<APP_NAME> - Dapr 服務叫用：一種具有內建的重試與可檢視性的 sidecar 型方法，
- 自訂網域：你自己的網域名稱搭配管理憑證
注意
當你用 FQDN 或應用程式名稱呼叫同一環境中的其他容器應用程式時，網路流量不會離開該環境。
為何如此重要
在微服務架構中，服務之間需要可靠地呼叫彼此。 Azure Container Apps 免除了設定服務發現、管理 DNS 紀錄及設定反向代理的操作負擔。
以下是該平台為您處理的事項：
- 自動 DNS 註冊：每個容器應用程式一部署就會有一個可解析的主機名稱。
- 代理管理路由：所有應用程式間流量都經過內建的 Envoy 代理層，負責 TLS 終止、流量分割及負載平衡。
- 環境範圍隔離：內部端點只能從同一環境中存取，形成自然的安全邊界。
- 協定彈性：根據你的工作負載需求，可透過 HTTP/1.1、HTTP/2（針對 gRPC）或原始 TCP 通訊。
這些功能讓你能專注於應用程式邏輯，而非網路管道。
容器應用程式位置（FQDN）
每個容器應用程式的完整限定網域名稱由應用程式名稱、唯一環境識別碼及區域組成。 這些領域片段都屬於 azurecontainerapps.io 頂層領域。
外部與內部 FQDN
入口可見性設定控制你的應用程式是否能從外部環境存取：
| 可視性 | FQDN 格式 | 可從 |
|---|---|---|
| External | <APP_NAME>.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io |
任何地方（公共網際網路） |
| 內部 | <APP_NAME>.internal.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io |
僅環境相同 |
當你將 ingress 設為 內部時，FQDN 會包含一個 .internal. 區段。 同一環境中的其他容器應用程式仍可透過此位址存取該應用程式，但來自外部的請求會收到 404 該環境代理的回應。 DNS 名稱解析為環境的共享 IP，但代理會拒絕請求，因為該應用程式僅內部運作。
取得完全限定網域名稱
此命令 az containerapp show 會傳回容器應用程式的完整網域名稱。
az containerapp show \
--resource-group <RESOURCE_GROUP_NAME> \
--name <CONTAINER_APP_NAME> \
--query properties.configuration.ingress.fqdn
在此範例中，請以您的值取代 <> 括住的預留位置。
此命令會傳回類似網域名稱的值，如下列範例所示：
myapp.happyhill-70162bb9.canadacentral.azurecontainerapps.io
修訂標籤 FQDN
當您為特定版本指派標籤時，每個標籤都會使用三個連字號分隔符來取得其獨特的 FQDN：
<APP_NAME>---<LABEL>.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io
對於內部應用程式，該模式包含以下 .internal. 區段：
<APP_NAME>---<LABEL>.internal.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io
標籤 FQDN 可以讓你直接將流量傳送到特定版本。 此做法對於測試新版本、執行 A/B 實驗，或提供特定版本部署的穩定端點非常有用。
依名稱呼叫容器應用程式
在同一環境中呼叫另一個容器應用程式最直接的方式就是用它的名字來呼叫。 發送請求到 http://<CONTAINER_APP_NAME>，環境內建的 DNS 會自動解析該名稱。
http://my-backend-api
DNS 解析的運作原理
在幕後，Azure Container Apps 使用自訂的 DNS 設定，將容器應用程式名稱轉換成可路由的位址。 當你的應用程式向另一個應用程式的名稱或 FQDN 提出請求時：
- 環境的 DNS 伺服器會將主機名稱解析為 Envoy 代理服務位址。
- Envoy 代理從原始主機名稱識別目標應用程式。
- 代理會根據你的流量設定，將請求導向正確的版本。
這種架構意味著容器應用程式之間永遠不會直接與彼此的 pod 通訊。 所有流量都經過代理層，該層提供 TLS 終止、負載平衡及流量分割。
小提示
在同一環境中容器應用程式間呼叫時，請使用簡短的應用程式名稱（http://<APP_NAME>）。 它比完整的 FQDN 簡單，且運作方式相同，因為 DNS 透過同一個代理解決兩種模式。
傳輸通訊協定
容器應用程式支援三種進入點的傳輸模式，透過以下transport屬性設定：
| Transport | 應用案例 | 詳細資料 |
|---|---|---|
| 自動 （預設） | 標準網頁 API 與服務 | 自動協商 HTTP/1.1 和 HTTP/2 |
| HTTP/2 | gRPC 服務 | 啟用 HTTP/2 端對端，為 gRPC 所必需 |
| TCP | 非 HTTP 協定（資料庫、自訂協定） | 帶有埠映射的原始 TCP 連線 |
注意
外部 TCP 入口需要 自訂的 VNet。 如果你嘗試建立一個沒有自訂 VNet 的外部 TCP 應用程式，會收到 ContainerAppTcpRequiresVnet 錯誤訊息。 內部 TCP 入口不需要自訂 VNet。
使用 TCP 傳輸時，你也可以在主入口埠之外暴露額外的埠口。 每多出一個埠口就會建立一個獨立的 TCP 端點，讓環境中其他應用程式都能連接。
流量分割與修訂路由
Azure Container Apps 支援三種版本模式，影響容器應用程式間流量的分配方式：
| 模式 | 行為 |
|---|---|
| Single | 所有流量都傳送到最新的使用中版本。 |
| 多重 | 流量會依照您的流量規則，按百分比拆分到各個修訂版本。 |
| 標籤 | 每個有標籤的版本都會有一個獨特的 FQDN 以供直接存取。 |
在 多重 模式下，當其他容器應用程式呼叫你應用程式的 FQDN 時，代理伺服器會根據你設定的權重自動將請求分配到不同版本。 在 標籤 模式下，呼叫者可利用標籤 FQDN 鎖定特定版本。
如需詳細資訊，請參閱 Azure 容器應用程式中的修訂。
Dapr 服務叫用
Dapr (分散式應用程式執行階段) 提供應用程式間通訊的 sidecar 型方法。 啟用 Dapr 後，您的容器應用程式可透過 Azure Application Insights 取得具備雙向 TLS、自動重試及分散式追蹤功能的內建服務叫用。
Dapr 呼叫的運作方式
每個支援 Dapr 的容器應用程式都會在你的應用程式旁邊執行一個副車程序。 若要呼叫另一個支援 Dapr 的應用程式，請向負責服務發現與路由的 Dapr 側車發送本地 HTTP 請求：
http://localhost:3500/v1.0/invoke/<DAPR_APP_ID>/method/<METHOD_NAME>
例如，在一個 DAPR 應用程式 ID 為 catalog的應用程式中呼叫該order-processor方法：
http://localhost:3500/v1.0/invoke/order-processor/method/catalog
側車透過專用的 DNS 網域解析目標應用程式，並將請求路由至 Envoy 代理層。 這也是處理基於 FQDN 路由的基礎設施。
注意
Dapr 使用自己的 DNS 解析路徑（網域 .dapr ），與標準 FQDN 解析分開。 這兩條路徑都經過系統環境的代理基礎架構。
Dapr 應用程式 ID
Dapr 應用程式 ID 是其他應用程式用來呼叫你的服務的身份。 如果你沒有設定明確的應用程式 ID，Dapr 執行時會預設為你的容器應用程式名稱。 ARM API 會顯示為 appId: null 如果你沒有設定自訂 ID，而在執行階段將自動套用應用程式名稱。 如果你需要不同的識別碼，可以在 DAPR 設定中設定自訂的 App ID。
Dapr 應用程式 ID 必須在環境中是唯一的。 若您嘗試部署一個 Dapr 應用程式識別碼已遭到其他應用程式使用的容器應用程式，則容器應用程式資源會建立，但其修訂會無法佈建 (provisioningState: Failed)。 錯誤訊息會指出衝突的應用程式 ID 以及擁有該應用程式的應用程式。
僅支援 DAPR 的應用程式（無 HTTP 入口）
你可以在容器應用程式上啟用 DAPR，而不必設定 HTTP 入口。 在這種情況下，該應用程式無法透過 FQDN 或應用程式名稱存取，但其他啟用 Dapr 的應用程式仍可透過 Dapr 服務呼叫它。 此模式對於背景工作者或事件處理器非常有用，因為他們只需要接收網狀中其他服務的呼叫。
小提示
當你用 Azure CLI 建立 no-entry（無入口）應用程式時，請省略 --ingress 和 --target-port 標誌。 不使用--target-port來包括--ingress會傳回使用錯誤。
Dapr sidecar 組態
透過容器應用程式的屬性來設定 Dapr sidecar。 主要設定包括：
| Setting | 說明 |
|---|---|
appId |
Dapr 應用程式 ID（預設為容器應用程式名稱） |
appPort |
您的應用程式監聽的連接埠 (回退到進入點目標連接埠) |
appProtocol |
DAPR 與應用程式通訊的協定（例如 http， ） grpc |
logLevel |
Dapr sidecar 記錄詳細程度 |
enableApiLogging |
是否要記錄 Dapr API 呼叫 |
httpMaxRequestSize |
Dapr HTTP 伺服器的最大請求主體大小（MB） |
httpReadBufferSize |
HTTP 讀取緩衝區的最大大小（KB） |
欲了解更多關於如何與 Azure Container Apps 設定 Dapr 的資訊，請參閱 Dapr 與 Azure Container Apps 的整合。
應用程式間通訊的安全
Azure Container Apps 包含多項影響容器應用通訊的安全功能：
-
預設的 TLS：所有容器應用程式間的流量都經過 Envoy 代理，該代理負責 TLS 終止。 設定
allowInsecure為false（預設值）以強制執行 HTTPS 重定向。 -
用戶端憑證模式（mTLS）：透過將用戶端憑證模式
require設定為 、accept、 或ignore來配置互助 TLS。 - IP 限制：定義允許或拒絕規則，限制哪些 IP 位址能連到你的應用程式。
- CORS 政策：為呼叫你的容器應用程式的瀏覽器用戶端設定跨來源資源共享規則。
注意
當您使用 Dapr 服務叫用時，Dapr sidecar 會自動確保服務間與雙向 TLS 通訊的安全。 你不需要為 Dapr 之間的互相通訊單獨設定 mTLS。
如需詳細資訊，請參見 Azure Container Apps 中的 Ingress。
自訂網域
你可以在入口設定中設定自訂網域，將自己的網域名稱映射到容器應用程式。 每個自訂網域都可以參考受管理或上傳的 TLS 憑證。
自訂網域會與預設的 FQDN 一起註冊，所以你的應用程式會同時回應兩個地址。 當環境中其他容器應用程式需要存取你的應用程式時，它們可以使用預設的 FQDN、應用程式名稱或你的自訂網域。
欲了解更多資訊，請參閱Azure Container Apps中的
範例解決方案
示範如何利用 FQDN 與 DAPR 在容器間呼叫的範例可參考 Azure Samples。
相關概念
理解 Azure Container Apps 中的應用程式間通訊與多個相關主題相連結：
- Azure Container Apps 中的環境：是容器應用程式彼此發現並進行通訊的共享邊界
- Ingress in Azure Container Apps：如何設定外部與內部端點、TLS 及路由規則
- Dapr 與 Azure 容器應用程式整合：更深入涵蓋 Dapr 元件、發佈/訂閱及狀態管理，以及服務叫用
- Azure Container Apps 中的網路配置：VNet 整合、私有端點與環境中的網路安全
- 修訂Azure Container Apps：修訂模式與流量分割如何影響應用程式間路由