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

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

在 中使用 Amazon ECS任務VPC，您可以將單體應用程式分割為可在安全環境中獨立部署和擴展的個別部分。此架構稱為服務導向架構 (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 地址。大多數軟體只支援使用 DNSA記錄，這些記錄會直接解析為 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，並URL為您的 設定一致的一個API。不過，您可以將流量分割為後端上的各種微服務。