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

# 分散式系統元件
<a name="distributed-systems-components"></a>

 在微服務架構中，服務探索是指在分散式系統中動態定位和識別個別微服務的網路位置 (IP 地址和連接埠） 的程序。

 選擇 方法時 AWS，請考慮下列因素：
+  **程式碼修改：**您可以獲得優勢，而無需修改程式碼嗎？ 
+  **跨 VPC 或跨帳戶流量：**如果需要，您的系統是否需要跨不同 VPCs或 進行有效的通訊管理 AWS 帳戶？ 
+  **部署策略：**您的系統是否使用或計劃使用進階部署策略，例如藍綠或金絲雀部署？ 
+  **效能考量：**如果您的架構經常與外部服務通訊，對整體效能會有什麼影響？ 

 AWS 在微服務架構中提供數種實作服務探索的方法：
+  **Amazon ECS Service Discovery：**Amazon ECS 支援使用以 DNS 為基礎的方法或與 整合的服務探索 AWS Cloud Map （請參閱 [ECS Service Discovery](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html))。ECS Service Connect 進一步改善連線管理，這對於具有多個互動服務的大型應用程式特別有益。
+  **Amazon Route 53：**Route 53 與 ECS 和其他 AWS 服務整合，例如 EKS，以促進服務探索。在 ECS 內容中，Route 53 可以使用 ECS Service Discovery 功能，該功能利用 Auto Naming API 自動註冊和取消註冊服務。
+  **AWS Cloud Map：**此選項提供動態 API 型服務探索，可在您的服務間傳播變更。

 對於更進階的通訊需求，**Amazon VPC Lattice** 是一種應用程式聯網服務，可一致地連線、監控和保護服務之間的通訊，有助於提高生產力，讓您的開發人員可以專注於建置對業務重要的功能。您可以定義網路流量管理、存取和監控的政策，以簡化且一致的方式跨執行個體、容器和無伺服器應用程式連接運算服務。

 如果您已經使用第三方軟體，例如 [HashiCorp Consul](https://www.consul.io/) 或 [Netflix Eureka](https://github.com/Netflix/eureka) 進行服務探索，您可能偏好在遷移至 時繼續使用這些軟體 AWS，以便更順暢地進行轉換。

 這些選項之間的選擇應符合您的特定需求。對於更簡單的需求，如 Amazon ECS 或 等 DNS 型解決方案 AWS Cloud Map 可能就足夠了。對於更複雜或更大的系統，像 Amazon VPC Lattice 之類的服務網格可能更合適。

 總而言之，在 上設計微服務架構 AWS ，就是選擇適當的工具來滿足您的特定需求。請記住討論的考量事項，您可以確保做出明智的決策，以最佳化系統的服務探索和服務間通訊。