一般來說，在一個集群中運行現代化分布式應用的兩個關鍵組件是：可靠的狀態管理和靈活的調度。Amazon ECS簡化了構建和運行容器化應用的流程，但是如何實現才是Amazon ECS真正有意思的地方。今天，我想要探討Amazon ECS架構并闡述這個架構能夠做些什么。如下是Amazon ECS的基本組件圖：
我們如何協調（Coordination）集群
讓我們來談談Amazon ECS到底做了什么。Amazon ECS的核心是集群管理器，它是一個后臺服務，能夠處理集群協調和狀態管理的任務。在集群管理器之上是不同的調度器。集群管理和容器調度是互相解耦的，所以Amazon支持客戶使用和創建他們自己的調度器。集群其實就是應用可以使用的計算資源池。而這里的資源池就是根據容器劃分的Amazon EC2實例的CPU、內存和網絡資源。Amazon ECS通過運行在集群中每個EC2實例上的容器代理來協調集群。代理允許Amazon ECS與集群中的EC2實例進行通信，并根據用戶或調度器的請求來啟動、終止和監控容器。代理使用Go語言編寫，資源占用少，目前在GitHub上基于Apache協議開源。歡迎大家貢獻和反饋。
我們如何管理狀態
為了協調集群，我們的集群上需要有一個SSOT[單一數據源]：集群中的EC2實例，運行在EC2實例上的任務，組成任務的容器，可用/占用資源(例如，網絡端口、內存、CPU等)。在獲得精確的集群狀態信息之前，我們是不可能成功開啟和終止容器的。為了解決這個問題，需要在某個地方存儲狀態，因此現代集群管理器的心臟是鍵值數據庫。
這個鍵值數據庫對任何集群輸入的和存儲于此的信息表現為SSOT。為了保證可靠性和可擴展性，這個鍵值數據庫需要采用分布式來確保持久性和可用性，并規避網絡劃分和硬件故障帶來的影響。也正因為鍵值數據庫是分布式的，確保數據一致性以及正確的進行并發修改會變得更加困難，這種情況在狀態持續變化的環境（比如，容器的停止和啟動）中尤甚。對此，為了保證多狀態修改不會出現沖突，某些形式的并發控制就需要落實到位了。打個比方，假設有2個開發者從某個EC2實例請求剩余的內存以供他們的容器使用，這個時候，只有其中一個容器能夠真正得到這些資源，而另一個則會被告知請求未完成。
為了實現并發控制，我們采用了Amazon分布式系統的核心原語之一來實現Amazon ECS，這是一個基于Paxos的事務日志的數據存儲系統，它保存了每一項數據變更的記錄。在日志中，任何數據的寫入均以事務的形式提交，并對應一個特定順序的ID。數據當前的值就是日志中記錄的那些事務的總和。對于任何數據的讀取，得到的都只是日志當前時間點的一個快照。如果寫操作是繼上次讀取操作完成以來最新提交的事務，則判定寫操作成功。這種原語允許Amazon ECS以樂觀鎖的形式存儲集群的狀態信息，對于共享數據經常變動的場景（比如當需要表達諸如ECS之類的計算資源共享池的狀態時）而言，這是一種理想的方式。這個架構使得Amazon ECS具有高可用性、低延遲和高吞吐量的特點，因為數據存儲并未使用悲觀鎖（譯者注：作者自己表述得很含糊，大家參見多版本并發控制MVCC）。
通過API訪問
既然我們有了一個鍵值數據庫，那么我們便能夠成功協調集群，并確保所需數量的容器正在運行，因為我們有一種可靠的方法來存取集群的狀態。之前提到過，我們解耦了集群管理和容器調度兩個模塊，因為我們希望客戶能夠充分利用Amazon ECS狀態管理的能力。我們已經通過一系列API開放了Amazon ECS集群管理器，它允許客戶以結構化的方式訪問存儲在鍵值數據庫中的集群狀態信息。
通過list命令，客戶可以讀取托管的集群，特定集群中運行的EC2實例，運行中的任務以及組成任務的容器配置（如任務定義）。通過describe命令，客戶可以獲取EC2實例的具體信息以及每個實例上的可用資源。最近，客戶亦可以啟動和停止任何集群中的任務了。近期，我們針對Amazon ECS進行了一系列的負載測試，我們希望分享一些性能要點，客戶在Amazon ECS上創建應用的時候應該會關注它們的。
上圖顯示了一個負載測試的結果，在這次測試中，我們在Amazon ECS集群中添加和刪除實例，并測量72小時的周期內，調用‘Describe Task’API時，百分比排列位于第50位和第99位的延遲。你可以看到，盡管集群數量有較大的波動，但是延遲相對而言并沒有什么抖動。Amazon ECS可以如你所需地進行擴展，不管你的集群規模有多大，且根本無需操作或擴展集群管理器。
這組API是客戶在Amazon ECS上搭建解決方案的基礎。調度器只是提供了關于何時、何地以及如何開啟和停止容器的邏輯。Amazon ECS的架構為分享集群狀態而設計，它允許客戶根據需要為應用運行各種調度器（如二進制打包、發布等）。這個架構允許調度器查詢集群的具體狀態，并從通用池中分配資源。樂觀并發控制允許調度器無沖突地獲取它們所請求的資源。一些客戶已經在Amazon ECS上創建了各種有趣的解決方案，下面我們來分享一些具體的示例。
Hailo——彈性資源池上的定制調度
Hailo是一個免費的移動APP，它允許人們招呼一輛認證的出租車到其所在地。Hailo擁有一個全球網絡，囊括了超過60000名司機以及一百萬以上的乘客。Hailo于2011年成立，從第一天開始就使用了AWS。在過去的幾年中，Hailo從AWS單一區域上運行的應用集合演化為貫穿多個區域的微服務架構。之前，每個微服務都跑在靜態劃分的實例集群上。Hailo遇到的問題是跨分區的資源使用率較低。這個架構并不具備很強的擴展性，并且Hailo也不希望它的工程師關心基礎設施的細節或者微服務的部署問題。
為此，Hailo決定基于服務優先級以及其它的運行時指標對容器進行調度。后來他們選擇了Amazon ECS來作為集群管理器，因為ECS可以輕松的管理任務狀態并訪問集群狀態的API。同樣，Hailo可以根據自己的需求來定制調度器。
Remind——平臺即服務
Remind是一個web端和移動端應用，使得老師能夠給學生發送信息并和家長取得聯系。Remind平臺上擁有24M用戶和超過1.5M的老師。它每月傳遞150M條信息。Remind起初使用Heroku來運行整個應用設施，從消息推送引擎、前后端API、Web客戶端到聊天后臺。這些設施中的大部分都以龐大的應用塊進行部署。
隨著用戶的增長，Remind希望擁有橫向擴展的能力。因此大約在2014年年底，它的工程師團隊開始摸索著向基于容器的微服務架構遷移。團隊希望基于AWS搭建一個PaaS，確保它能夠兼容Heroku的API。一開始，團隊期望能有一個開源的解決方案（比如，CoreOS和Kubernetes）來負責集群的管理以及容器的協作，但是由于團隊的規模較小，因此他們沒有時間來管理集群的基礎設施，同時保證高可用性。
在簡要評估了Amazon ECS之后，團隊決定在此服務的基礎上搭建PaaS。Amazon ECS是全托管式的，這使得工程資源能夠被集中于開發和部署應用；這里并沒有集群需要管理和擴展。在6月份，Remind開源了他們基于ECS的PaaS解決方案，名為“Empire”。憑借Empire，Remind得到了可觀的性能提升（例如，延遲和穩定性）以及安全優勢。他們接下來幾個月的計劃是將90%以上的核心設施遷移到Empire。
Amazon ECS——一個全托管的平臺
上述只是我們從客戶處看到的其中兩個用例。Amazon ECS架構允許我們提供一個具有高可擴展、高可用、低延遲的容器管理服務。通過API樂觀并發（譯者注：樂觀鎖）地訪問共享集群狀態的能力，使得用戶得以按需創建任何定制容器解決方案。我們一直致力于為客戶消除重復而繁重的任務。通過Amazone ECS，根本不需要安裝或操作集群管理程序，客戶理應僅僅專注于開發優秀的應用。
Amazon與Google間的容器競爭持續發酵
Google容器引擎（GKE）由pod、replication controller和節點組成。pod是一組特定的應用程序邏輯主機模型的容器邏輯分組；replication controller確保特定數量的pod副本任何時候都在運行；節點是加強了容器環境的Google計算引擎虛擬機。
GKE基于Google的Kubernetes容器編排平臺。Kubernetes 1.1版本在1.0版首次亮相之后4個月的11月24號發布，是市場中第一個能夠通過水平節點自動伸縮功能來實現自動伸縮節點的產品，這個功能受到用戶的高度追捧，從而為許多使用GKE的案例提供了有力的支持。
“我們為很多各種類型的項目使用自動伸縮”， Descartes Labs公司的聯合創始人和首席云架構師Tim Kelton如是說。這家公司位于新墨西哥洲，是機器學習方面的初創公司，能夠處理PB級別的衛星數據。
自動伸縮的pod在處理大型批處理作業時能夠派上大用場，Kelton解釋道。有時，他的公司處理PB級的數據，這就需要擴展到3000個內核。在Kubernetes的第一個版本（隨后很快被GKE合并）中，“這不是核心特性集的一部分”，他說。
雖然GKE不支持垂直容器擴展或者節點自動伸縮，但是，根據GKE高級產品經理，同時也主導Kubernetes產品管理的David Aronchick透露，這些功能很快就是實現。
Amazon EC2容器服務（ECS）由服務、任務和實例組成。服務是構成應用程序的任務組，而實例是支持容器的彈性計算云端虛擬機，與GKE中的節點很像。
Google的ECS的自動伸縮能力與GKE是相反的：使用亞馬遜CloudWatch和亞馬遜網絡服務Lamda可以實現服務自動伸縮，實例也可以基于CloudWatch metrics進行自動伸縮，但是任務——等同于pod，屬于粗糙邏輯，無法自動伸縮。
雖然所有類型的自動縮放都很重要，但是亞馬遜用戶希望將任務自動伸縮加入ECS中。
“運行一個新的實例意味著你要有額外的容量來運行額外的任務，但這并不意味著任何新的任務都將被啟動”，ACI信息科技集團副總裁Chris Moyer如是說。ACI，位于紐約，是一家基于Web的內容聚合技術的公司，也是TechTarget的貢獻者。“如果你只是自動伸縮實例，并不能真正幫助你解決額外的負載——你必須真正運行額外的任務來實現擴展。”
跨區域冗余
在ECS發展過程中，亞馬遜優先發展在同一個集群中，針對基于用戶需求的任務自動伸縮冗余性，本地跨越可用區域（AZs）的能力，當ECS服務調度啟動新的任務時，它也會嘗試通過集群中的AZs自動平衡這些任務。
“這很重要，因為單個AZ允許失敗，所以如果兩個任務都允許在同一個AZ中，很容易拖垮你的服務”，Moyer說。
據Aronchick介紹，Google可以在GKE中通過命令行接口（CLI）跨多個區域。
"實現跨區域非常容易，兩三條命令就能搞定"，Aronchick如是說。
然而，這就要談到GKE用戶最大的心愿：將跨區域功能改進到Web界面上，包括跨域集群擴展功能。
“實現用戶界面需要大量工作”，Vendasta科技首席架構師Dale Hopkins說，Vendasta為媒體公司設計銷售和營銷軟件。用戶界面目前支持集群創建以及其他少數功能。Hopkins說：“擴展集群是不直觀的。”
互操作性
ECS作為一個可擴展平臺，旨在融入客戶現有的工作流，主要處理代表用戶的集群狀態。將ECS集成到現有工作流中來兼容客戶在用的工具，比如用以高級調度的Apache Mesos。亞馬遜還自豪的聲稱擁有廣泛的容器伙伴網絡來為亞馬遜ECS貢獻新特性，比如監視、持續集成和安全。
同時，Google已經與一批云端容器合作伙伴合作，這些合作商允許Kubernetes可以通過多個云端供應商被部署——這也是CLI現在的一個功能，Aronchick如是說。去年夏天Kubernetes 1.0版本發布時， Google引導了Cloud Native 計算基金會的成立，基金會成員包括云服務公司，比如IBM和Red Hat，以及終端用戶如eBay和Twitter。
“[附] Kubernetes，其實我可以在亞馬遜部署，在Azure上部署，在IBM上部署，也可以部署在我自己的物理硬件上，”Descartes的Kelton 說。 “這是非常有吸引力的，因為我們有選擇。”
Google也有一個開源項目，擁有數百提交者和每月數以千計的代碼提交，使得 Kubernetes可以快速的添加新功能，比如水平pod自動擴展。
Google是Kubernetes的創始者，而且Google做了很多杰出的工作壯大了社區，451 Research的研究員Jay Lyman如是說。
富者愈富
盡管如此，使用老牌和熟悉的次級亞馬遜服務來實現集成使得亞馬遜ECS特別吸引新的客戶。
一家總部位于紐約的公司，與一些大的企業就IT項目上進行咨詢，計劃在兩個新項目上使用ECS， 據其創始人John D'Esposito介紹。驅使我們使用ECS的主要優點是使用現有的、成熟的基礎設施服務比如彈性負載平衡、虛擬私有云、身份和訪問管理，以及彈性塊存儲可以實現無縫集成。
GKE和Compute Engine的定價還是對客戶非常有吸引力的。除了在以10分鐘為單位收費的VM資源的底層，GKE包括免費的Kubernetes主節點——這是特別吸引Vendasta的Hopkins的地方。
“直到我可以獲得大量機器，我才會給 Kubernetes支付額外的費用。對于第一套機器，GKE為我免費提供Kubernetes節點”，Hopkins說。
在Kubernetes和容器引擎被引入之前，Hopkins和Kelton都已經在用Google云服務，包括Google App引擎。這樣，數據重力就會在他們所選擇部署的云端容器上起作用。
“我們的大多數數據集是PB級規模的，所以你不能只是移動或復制它們，你必須真正去計算數據”，Kelton說。大多數數據目前存放在Google云平臺，雖然Descartes不與AWS的合作伙伴合作。
微軟Azure Container服務整裝待發
雖然Google和亞馬遜在云端容器競爭中到目前為止仍處于前沿，但亞馬遜最大的競爭對手仍然是微軟的Azure，它在有限預覽階段擁有自己基于Linux的云端容器的服務，以及Windows Server的新版本，今年之后，將支持基于Windows的容器。
“我們的大多數客戶都是......無論是在Azure或亞馬遜，” 位于Rochester的HKM咨詢公司的合伙創始人Chris Riley如是說，“微軟已經拿到了一些他們正在開發的有趣工具。如果我們看到一個次要的，它很可能Google之前的Azure“。
簡單性和易用性是很多微軟的產品的設計重點，Lumagate的CTO Kristian Nese介紹，Lumagate是挪威的一家微軟Azure系統集成商。
“我們現在部署Azure的容器服務，僅僅需要100行代碼，”Nese說。 “一旦你部署了Azure的容器服務，你實際上部署了23個資源......如果你想手動做到這一點，可能需要數千行代碼。”
Azure容器服務在預覽階段也支持自動擴展，是一個獨立服務形式，被稱作VM量表集。
Azure還將提供成熟和熟悉的工具來管理容器，如Azure的資源管理器，Nese補充說。
