ECS+Route 53，解決雲中微服務系統的服務發現問題

為什麼微服務需要服務發現(Service Discovery)

我們可以想象一下，當我們需要遠端的訪問REST API或者Thrift API時，我們必須得知道服務的網路地址（IP Address和port）。傳統的應用程式都是執行在固定的物理機器上，IP Address和埠號都是相對固定的。可以透過配置檔案方式來實現不定期更新的IP Address和埠號。但是，在基於雲的微服務應用中，這是一個非常難以解決的問題。

在基於雲的微服務應用中，服務例項的網路地址（IP Address和Port）是動態分配的，並且由於系統的auto-scaling, failures 和 upgrades等因數，一些服務執行的例項數量也是動態變化的。因此，客戶端程式碼需要使用一個非常精細和準確的服務發現機制。

ECS 服務發現(Service Discovery)

Amazon ECS現在能支援與Route 53結合整合的服務發現功能。 這使得ECS服務可以在Amazon Route 53中自動註冊一個可預測且命名友好的DNS名稱。當您的服務負載或容器根據執行狀況而擴充套件或縮小時，透過Route 53託管的區域可以保持最新狀態， 並允許其他服務根據每個服務的狀態查詢他們需要建立連線的位置。 讓你透過ECS執行在VPC內部的Task，可以被更好的發現。

下面的拓撲圖很好的演示了ECS Service Discovery的架構和發現流程。大家可以在.這個網址找到基於本圖所做的演示。這個演示是在AWS全球部落格上發表的。https://amazonaws-china.com/blogs/aws/amazon-ecs-service-discovery/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+AmazonWebServicesBlog+(Amazon+Web+Services+Blog)

注意

服務發現目前僅在以下4個區域可使用：

ECS服務發現(Service Discovery) 概念和術語

服務發現由以下元件組成：

•  服務發現名稱空間(Service discovery namespace)：一組共享相同域名的邏輯服務組，如example.com。 每個Route 53託管區域和每個VPC都需要一個名稱空間。 如果您使用Amazon ECS控制檯來建立服務發現功能，則該工作流將為每個ECS群集建立一個私有名稱空間。

•  服務發現服務(Service discovery service)：存在於服務發現名稱空間中，並由名稱空間的服務名稱和DNS配置組成。 它提供了以下核心元件：

服務目錄(Service directory)：允許您透過DNS或Route 53自動命名API查詢服務獲取一個或多個可用於連線到該服務的可用連線埠(endpoint)。

•  健康檢查(Health checks)：執行定期的容器級健康檢查。 如果端點(endpoint)未透過執行狀況檢查，則將其從DNS路由中刪除並標記為不健康。 有關更多資訊，請參閱

ECS服務發現(Service Discovery) 設計和考慮

使用服務發現時應考慮以下內容：

•  服務發現支援公共名稱空間，但在建立服務發現服務之前，您必須擁有一個現有的公用託管區域，並使用Route 53進行註冊。

•  服務發現僅支援使用awsvpc網路模式的任務。

•  可以在您的VPC中查詢服務發現服務的DNS記錄。它們使用以下格式：“.”。有關示例，請參閱.

•  您可以為每個服務中的任務建立A或SRV記錄的任意組合。如果您使用SRV記錄，則需要一個埠。

•  在對服務名稱進行DNS查詢時，A記錄會返回一組與您的任務相對應的IP地址。 SRV記錄會為每個任務返回一組IP地址和埠。

•  如果為ECS服務配置了負載均衡器並啟用了服務發現，則會使用A記錄將流量路由到負載均衡器。負載均衡器也處理健康檢查。

•  為服務發現服務指定執行狀況檢查時，您必須使用由Amazon ECS管理的定製執行狀況檢查或Route 53執行狀況檢查。健康檢查的兩個選項不能合併。

HealthCheckCustomConfig —— Amazon ECS代表您管理健康檢查。 Amazon ECS使用來自容器和Elastic Load Balancing執行狀況檢查的資訊以及任務狀態來使用Route 53更新執行狀況。這是在建立服務發現服務時使用–health-check-custom-config引數指定的。有關更多資訊，請參閱Amazon Route 53 API參考中的。

HealthCheckConfig —— Route 53建立執行狀況檢查以監視任務。這要求任務公開可用。這是在建立服務發現服務時使用–health-check-config引數指定的。有關更多資訊，請參閱Amazon Route 53 API參考中的。

•  如果您使用的是Amazon ECS控制檯，則工作流會為每個ECS服務建立一個服務發現服務，並將所有任務IP地址對映為A記錄，或將任務IP地址和埠對映為SRV記錄。

•  配置了服務發現的現有ECS服務將無法更新其服務發現內容的相關配置。

注意

Fargate也支援任務支援服務發現，但必須使用平臺版本v1.1.0或更高版本。 有關更多資訊，請參閱 。

ECS服務發現(Service Discovery)定價

使用Amazon ECS服務發現的客戶需要使用Route 53自動命名API。 這涉及建立託管區域和查詢服務登錄檔的成本。 有關更多資訊，請參閱

Amazon ECS執行容器級別的執行狀況檢查，並將其結果釋出到Route 53自定義執行狀況檢查的API。目前這個功能對客戶是免費使用的。 如果您為公開的任務配置其他網路健康檢查，則需要為這些健康檢查付費。

動手搭建ECS服務發現(Service Discovery)

一、自建ECS Service Discovery Private Hosted Zone

1. 建立ECS Service

我這裡使用的region是us-east-1，並且是使用Fargate作為基礎架構。

1.1 配置服務

1.2 配置網路

在這裡配置Service Discovery的相關資訊。在配置之前，你需要提前建立好一個用於該Service的Load Balancer和對應的Target Group。

提前建立好Load Balancer和Target Group

在Load Balancing部分新增你剛才加入的ALB

下面是重頭部分，配置Service Discovery

1.3 配置自動擴充套件Auto-Scaling

可以根據自己的需要選擇是否要task級別的自動擴充套件

1.4 整體回顧

在ECS建立時最後的review可以看見，ECS的auto scaling在Route 53建立了新的Hosted Zone

Route 53的介面可以看見新加的Hosted Zone

2. 驗證建立好的服務發現是否能正常執行

在建立好帶ECS Service Discovery的Cluster之後，已經可以在Route 53的Private Zone上發現有關Service的A記錄了。注意這個A記錄的格式。service discovery service name.service discovery namespace.

注意Route 53上條目的名稱和ECS的Service名稱的關係

因為是Private Hosted Zone的測試，所以需要在同一個VPC下面的EC2透過dig命令檢視該服務的域名資訊。由下圖看以發現是可以正常查到的。

現在在該Service下新增一個新的Task，觀察Route 53上面是否會同樣生成一個新的條目：

等到Task的狀態是RUNNING之後，再回去看Route 53的記錄，發現又新添了一條

主機上也馬上能查到。

至此，我們可以看見透過ECS的服務發現來建立對應的任務(Task)並且自動的透過DNS來獲取IP地址是非常方便的。它很好的解決了開篇提出的在雲環境下發現服務變化困難的問題。

二、自建ECS Service Discovery Public Hosted Zone

注意：在AWS Console中只能建立Private namespace，如果希望建立Public namespace，即給公網使用的Service Discovery，只能透過CLI。建立的過程注意參考官網文件(雖然官網是Private Zone的，但是參考還是可以的)

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html#service-discovery-query

注意：你要把AWS CLI升級到最新的版本

1. 透過以下命令在已有的VPC中建立public namespace

aws servicediscovery create-public-dns-namespace –name Phoenix-Test-Public-Service-Discovery.com

輸出：

{
    "OperationId": "kf2rfgf777u4uzjlxloc5d2y7hh4th6t-jfghkvqu"
}

1.1 檢視建立public namespace的操作是否完成，如果完成，那麼會顯示成功，並且在Route 53上會生成一個public的域名

aws servicediscovery get-operation –operation-id kf2rfgf777u4uzjlxloc5d2y7hh4th6t-jfghkvqu

輸出：

Json

{
    "Operation": {
        "Id": "kf2rfgf777u4uzjlxloc5d2y7hh4th6t-jfghkvqu",
        "Type": "CREATE_NAMESPACE",
        "Status": "SUCCESS",
        "CreateDate": 1522567839.414,
        "UpdateDate": 1522567840.175,
        "Targets": {
            "NAMESPACE": "ns-t7e7zfqbjoubhvaz"
        }
    }}

在Route 53的Hosted Zone下面能看見相同的Pulbic Zone出現，注意這個Zone只能由系統的Service Discovery進行修改，無法自己在這個Hosted Zone裡面建立任何Record Set(會報沒有許可權的錯誤)

2. 建立完畢之後，後面的步驟和建立並使用Private Namespace是一樣的。這裡就不贅述了。僅把不一樣的地方展現出來。一樣也要注意要建立Target Group和ALB/NLB。在Private Hosted Zone裡面，Enable public DNS health check是不能用的。而在Public Hosted Zone中則可以

3. 測試Public Namespace的工作情況。可以看見在Public Hosted Zone中出現了對應的DNS條目。但是注意，返回的是Task的Private IP的A記錄。而非Public IP。

在自己能連上公網的PC機上去dig這個域名，是可以返回任務的私網IP地址的。即其能成功的在公網上釋出。

Amazon Web Services ( AWS )技術峰會 2018 中國站（上海）已經於 6 月 29 日圓滿落幕，感謝您對 AWS 的關注和支援。精彩仍在繼續，所建皆為不凡，AWS 技術峰會 2018 中國的第二站即將啟航。AWS 技術峰會 2018 北京站，將在2018 年 8 月 9 日登陸北京國家會議中心！

想和我們一起#所建不凡#？快來註冊#AWS技術峰會2018，前20名註冊的小夥伴將可獲得 $50亞馬遜優惠券，抓住機會，趕快註冊吧！