VPC 中的 Amazon ECS 服務之間的聯網

在 VPC 中使用 Amazon ECS 任務，您可以將整合式應用程式分割為單獨的部分，這些部分可以在安全的環境中獨立部署和擴展。這種架構稱為面向服務的體系結構（SOA）或微服務。但是，要確保 VPC 內外的所有這些部分都可以相互通信可能很難。有幾種促進溝通的方法，所有方法都有不同的優點和缺點。

使用服務 Connect

我們建議使用 Amazon ECS 服務 Connect，它為服務探索、連線和流量監控提供 Amazon ECS 組態。透過 Service Connect，您的應用程式可以使用簡短名稱和標準連接埠來連線至相同叢集中的 ECS 服務、其他叢集，包括相同的 VPC。 AWS 區域如需詳細資訊，請參閱 Amazon 彈性容器服務開發人員指南中的 Amazon ECS 服務 Connect。

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

僅在部署期間發生變更

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

使用服務探索

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

在前面的圖中，有三個服務。 serviceA有一個容器和通信serviceB，其中有兩個容器。 serviceB還必須與通信serviceC，其中有一個容器。這三個服務中的每個容器都可以使用 AWS Cloud Map 來源的內部 DNS 名稱，從需要通訊的下游服務中尋找容器的內部 IP 位址。

這種 service-to-service 通信方法提供了低延遲。乍一看，這也很簡單，因為容器之間沒有額外的組件。流量直接從一個容器傳輸到另一個容器。

使用awsvpc網絡模式，其中每個任務都有自己唯一的 IP 地址時，這種方法是合適的。大多數軟件僅支持直接解析為 IP 地址的 DNS A 記錄的使用。使用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 位址，以及使用網路模式時更進階的 IP 位址和連接埠組合。bridge它會將流量平均分配到所有 IP 地址和連接埠組合，即使多個容器實際託管在同一個 Amazon EC2 執行個體上，也只是在不同的連接埠上。

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

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