由ECS，Swarm，或者Kurbernetes所提供的容器編排這一層，在整個部署和運行基于容器的應用程序的整個藍圖中占有非常重要的位置。

首先，我們?yōu)榱丝蓴U展性需要容器組成集群。隨著我們負載的增長，我們需要增加更多的容器，橫向的擴展它們，跨服務器來并行的處理更高的負載。

第二，我們需要組建容器集群來保證健壯性和高可用性。當一臺主機或一個容器失效時，我們希望容器可以重新構建，或許是在另外一臺健康的主機上重新啟動，從而讓整個系統(tǒng)不會受到任何的影響。

最后，編排層的工具所提供的一個重要功能就是抽象，讓開發(fā)者遠離具體的底層實現(xiàn)細節(jié)。在容器化的世界中，我們毋需關心每個獨立的主機，只需要關注我們期望的容器有多少在運行，在‘適當?shù)牡胤?rsquo;運行。編排和集群工具為我們做這些，讓我們能夠輕松的將容器部署到集群中，而且還能夠計算出最佳的調(diào)度方式，從而決定容器應該運行在哪些主機上。

設計健壯性和高性能分布式集群系統(tǒng)的難度是非常大的。所以諸如Kubernetes和Swarm這樣的工具讓我們自己毋需去構建集群。ECS借此更進一步，通過簡化編排層的設置、運行和管理來實現(xiàn)毋需人工參與。基于此緣故，ECS無疑是哪些使用容器來運行應用的開發(fā)者們應該密切關注的項目。

ECS架構

ECS并非是一個黑匣子的服務，它運行在你的EC2服務實例中，你可以使用SSH登錄，像管理其它的EC2服務一樣進行管理。

在集群中的EC2服務均會運行著一個ECS代理，ECS代理是一個連接主機到中心的ECS服務的輕量級進程。ECS代理響應主機注冊到ECS服務，且掌控所有的請求，用于容器的部署或者是諸如啟動／停止容器之類的生命周期事件。順便說一下，使用go實現(xiàn)的ECS代理已經(jīng)開源。

當創(chuàng)建一個新的服務器時，我們既可以選擇手動的配置ECS代理，也可以選擇使用預構建的已經(jīng)配置完畢的AMI鏡像。

通過亞馬遜CTO Werner Vogels的博客,我們得知集中的服務已經(jīng)邏輯上分為集群管理和在主機上控制容器部署的調(diào)度。這背后的緣由就是讓容器的調(diào)度成為可插拔式的，所以我們甚至可以使用其它的調(diào)度器，例如Mesos或者是其它開發(fā)者自定義的調(diào)度器。自定義調(diào)度器的文檔在本文撰寫時還在開發(fā)當中，但是我們可以閱讀此博客以及參考其源代碼，這是目前為止最佳的參考實踐。

下面的示意圖很好的演示了ECS集群的邏輯層次：容器實例包含多個任務，任務包含多個容器，EC2容器實例集群可以分散到多個可用區(qū)域中，Elastic Load Balancers可以用于跨任務的動態(tài)分布負載。此圖可以幫助讀者在閱讀接下來的內(nèi)容整理思路。

服務和任務

在ECS中，Docker負載被描述為任務。

一個任務本質(zhì)上是定義了一個或多個容器，其中包括你打算運行的容器的名稱（和Docker Hub的名稱保持一致），以及在容器實例啟動時相應的端口和磁盤卷的映射信息。

當任務運行時，則啟動了底層的容器。當所有的容器進程完成使命時，任務也就結束了。任務既可以是很短的也可以是長時間運行的，舉例來說，提供一個數(shù)據(jù)處理任務的短的事件驅動，或者是一個web服務進程。

這里需要提醒一件事情，那就是架構上給定的一個任務，其所有的容器均運行在同一臺主機中。如果我們打算定位容器的話，那么就使用在同一個任務下來組織它們的方法來實現(xiàn)。如果我們打算將服務運行在不同的主機，我們則僅需定義多個任務來實現(xiàn)控制即可。初看這似乎是一種約束，但最終它給我們的和Kubernetes pods一樣的對容器定位在一定程度的控制能力。

為了說明上述問題，如下面截圖所示，我們可以看到定義了一個特定的任務，此任務擁有一個容器，容器托管nginx web服務。

除了任務之外，服務是ECS概念中排名第二重要的。一個服務是給定一個任務所請求運行的特定的實例數(shù)量。舉例來說，如果我們有一個如上述所定義的運行nginx web服務容器的任務的話，我們則要定義一個服務，來請求3個或更多的實例組成集群，從而完成web服務的任務。

服務是ECS如何提供彈性的保證。當一個服務啟動后，服務就會監(jiān)控其中的任務是否是活動的，實例的數(shù)量是否正確，以及其中容器的數(shù)量是否正常。如果任務停止運行了，或者是無響應了，又或者是出現(xiàn)問題了。服務就會請求啟動更多的任務，以及必要的話清理任務。

下面截圖所示，在集群中一個nginx服務被定義為3個運行的任務。這些任務個個都處于運行狀態(tài)。