在 VPC 中連接 Amazon ECS 服務的最佳實務 - Amazon Elastic Container Service
使用 Service Connect使用服務探索使用內部負載平衡器

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

在 VPC 中連接 Amazon ECS 服務的最佳實務

在 VPC 中使用 Amazon ECS 任務，您可以將單體應用程式分割成可在安全環境中獨立部署和擴展的個別部分。此架構稱為服務導向架構 (SOA) 或微服務。不過，要確保 VPC 內外的所有這些部分可以互相通訊，可能具有挑戰性。促進溝通有幾種方法，所有方法都有不同的優點和缺點。

使用 Service Connect

我們建議 Service Connect，其提供 Amazon ECS 組態，用於服務探索、連線能力和流量監控。使用 Service Connect，您的應用程式可以使用短名稱和標準連接埠來連線至相同叢集、其他叢集中的服務，包括相同區域中跨 VPCs的服務。如需詳細資訊，請參閱 Amazon ECS Service Connect。

當您使用 Service Connect 時，Amazon ECS 會管理服務探索的所有部分：建立可探索的名稱、在任務開始和停止時動態管理每個任務的項目、在設定為探索名稱的每個任務中執行代理程式。您的應用程式可以使用 DNS 名稱的標準功能並進行連線來查詢名稱。如果您的應用程式已經這樣做，則不需要修改應用程式即可使用 Service Connect。

顯示使用服務連線之網路架構的圖表。
變更只會在部署期間發生

您可以在每個服務和任務定義內提供完整的組態。Amazon ECS 會管理每個服務部署中此組態的變更，以確保部署中的所有任務都以相同的方式運作。例如，DNS 做為服務探索的常見問題是控制遷移。如果您變更 DNS 名稱以指向新的替換 IP 地址，則可能需要最長的 TTL 時間，所有用戶端才會開始使用新的服務。透過 Service Connect，用戶端部署會透過取代用戶端任務來更新組態。您可以設定部署斷路器和其他部署組態，以與任何其他部署相同的方式影響 Service Connect 變更。

使用服務探索

service-to-service通訊的另一種方法是使用服務探索進行直接通訊。在此方法中，您可以使用 AWS Cloud Map 服務探索與 Amazon ECS 的整合。使用服務探索，Amazon ECS 會將啟動任務的清單同步至 AWS Cloud Map，這會維護 DNS 主機名稱，以解析該特定服務中一或多個任務的內部 IP 地址。Amazon VPC 中的其他服務可以使用此 DNS 主機名稱，使用其內部 IP 地址將流量直接傳送到另一個容器。如需詳細資訊，請參閱服務探索。

顯示使用服務探索之網路架構的圖表。

在上圖中，有三種 服務。 service-a-local 有一個容器，並與 通訊service-b-local，其中有兩個容器。 還service-b-local必須與 通訊service-c-local，其中有一個容器。所有三個服務中的每個容器都可以使用來自 的內部 DNS 名稱 AWS Cloud Map ，從其需要通訊的下游服務尋找容器的內部 IP 地址。

這種service-to-service通訊的方法提供低延遲。乍看之下，這也很簡單，因為容器之間沒有額外的元件。流量會直接從一個容器流向另一個容器。

此方法適合使用awsvpc網路模式，其中每個任務都有自己的唯一 IP 地址。大多數軟體僅支援使用 DNS A記錄，這些記錄會直接解析為 IP 地址。使用 awsvpc 網路模式時，每個任務的 IP 地址都是A記錄。不過，如果您使用bridge網路模式，多個容器可能會共用相同的 IP 地址。此外，動態連接埠映射會導致容器在該單一 IP 地址上隨機指派連接埠號碼。此時，A記錄已不足以進行服務探索。您還必須使用 SRV記錄。這種類型的記錄可以追蹤 IP 地址和連接埠號碼，但要求您適當地設定應用程式。您使用的某些預先建置應用程式可能不支援SRV記錄。

awsvpc 網路模式的另一個優點是每個服務都有唯一的安全群組。您可以設定此安全群組，僅允許來自需要與該服務通訊之特定上游服務的傳入連線。

使用服務探索進行直接service-to-service服務通訊的主要缺點是，您必須實作額外的邏輯，才能重試並處理連線失敗。DNS 記錄具有time-to-live(TTL) 期間，可控制它們的快取時間。更新 DNS 記錄和快取過期需要一些時間，以便您的應用程式可以挑選 DNS 記錄的最新版本。因此，您的應用程式最終可能會解析 DNS 記錄，以指向不存在的另一個容器。您的應用程式需要處理重試，並具有忽略不良後端的邏輯。

使用內部負載平衡器

service-to-service通訊的另一種方法是使用內部負載平衡器。內部負載平衡器完全存在於 VPC 內，只有 VPC 內的服務才能存取。

圖表顯示使用內部負載平衡器的網路架構。

負載平衡器透過將備援資源部署到每個子網路來維持高可用性。當來自 的容器serviceA需要與來自 的容器通訊時serviceB，它會開啟與負載平衡器的連線。然後，負載平衡器會從 開啟與容器的連線service B。負載平衡器可做為管理每個服務之間所有連線的集中位置。

如果來自 的容器serviceB停止，則負載平衡器可以從集區中移除該容器。負載平衡器也會針對其集區中的每個下游目標執行運作狀態檢查，並自動從集區移除不良的目標，直到它們再次正常運作為止。應用程式不再需要知道有多少下游容器。他們只要開啟與負載平衡器的連線。

此方法適用於所有網路模式。負載平衡器可以在使用 awsvpc 網路模式時追蹤任務 IP 地址，以及在使用 bridge 網路模式時更進階的 IP 地址和連接埠組合。它將流量平均分配到所有 IP 地址和連接埠組合，即使多個容器實際上託管在相同的 Amazon EC2 執行個體上，只是在不同連接埠上。

這種方法的一個缺點是成本。若要高度可用，負載平衡器需要在每個可用區域中擁有資源。這會增加額外的成本，因為支付負載平衡器的費用以及通過負載平衡器的流量。

不過，您可以透過讓多個服務共用負載平衡器來降低額外負荷成本。這特別適合使用 Application Load Balancer 的 REST 服務。您可以建立以路徑為基礎的路由規則，將流量路由到不同的 服務。例如， /api/user/*可能會路由到user屬於服務的容器，而 /api/order/*可能會路由到相關聯的order服務。使用此方法，您只需支付一個 Application Load Balancer 的費用，並為您的 API 有一個一致的 URL。不過，您可以將流量分割為後端上的各種微服務。