一般來說，在一個集群中運行現(xiàn)代化分布式應用的兩個關(guān)鍵組件是：可靠的狀態(tài)管理和靈活的調(diào)度。Amazon ECS簡化了構(gòu)建和運行容器化應用的流程，但是如何實現(xiàn)才是Amazon ECS真正有意思的地方。今天，我想要探討Amazon ECS架構(gòu)并闡述這個架構(gòu)能夠做些什么。如下是Amazon ECS的基本組件圖：

我們?nèi)绾螀f(xié)調(diào)（Coordination）集群

讓我們來談談Amazon ECS到底做了什么。Amazon ECS的核心是集群管理器，它是一個后臺服務，能夠處理集群協(xié)調(diào)和狀態(tài)管理的任務。在集群管理器之上是不同的調(diào)度器。集群管理和容器調(diào)度是互相解耦的，所以Amazon支持客戶使用和創(chuàng)建他們自己的調(diào)度器。集群其實就是應用可以使用的計算資源池。而這里的資源池就是根據(jù)容器劃分的Amazon EC2實例的CPU、內(nèi)存和網(wǎng)絡資源。Amazon ECS通過運行在集群中每個EC2實例上的容器代理來協(xié)調(diào)集群。代理允許Amazon ECS與集群中的EC2實例進行通信，并根據(jù)用戶或調(diào)度器的請求來啟動、終止和監(jiān)控容器。代理使用Go語言編寫，資源占用少，目前在GitHub上基于Apache協(xié)議開源。歡迎大家貢獻和反饋。

我們?nèi)绾喂芾頎顟B(tài)

為了協(xié)調(diào)集群，我們的集群上需要有一個SSOT[單一數(shù)據(jù)源]：集群中的EC2實例，運行在EC2實例上的任務，組成任務的容器，可用/占用資源(例如，網(wǎng)絡端口、內(nèi)存、CPU等)。在獲得精確的集群狀態(tài)信息之前，我們是不可能成功開啟和終止容器的。為了解決這個問題，需要在某個地方存儲狀態(tài)，因此現(xiàn)代集群管理器的心臟是鍵值數(shù)據(jù)庫。

這個鍵值數(shù)據(jù)庫對任何集群輸入的和存儲于此的信息表現(xiàn)為SSOT。為了保證可靠性和可擴展性，這個鍵值數(shù)據(jù)庫需要采用分布式來確保持久性和可用性，并規(guī)避網(wǎng)絡劃分和硬件故障帶來的影響。也正因為鍵值數(shù)據(jù)庫是分布式的，確保數(shù)據(jù)一致性以及正確的進行并發(fā)修改會變得更加困難，這種情況在狀態(tài)持續(xù)變化的環(huán)境（比如，容器的停止和啟動）中尤甚。對此，為了保證多狀態(tài)修改不會出現(xiàn)沖突，某些形式的并發(fā)控制就需要落實到位了。打個比方，假設有2個開發(fā)者從某個EC2實例請求剩余的內(nèi)存以供他們的容器使用，這個時候，只有其中一個容器能夠真正得到這些資源，而另一個則會被告知請求未完成。

為了實現(xiàn)并發(fā)控制，我們采用了Amazon分布式系統(tǒng)的核心原語之一來實現(xiàn)Amazon ECS，這是一個基于Paxos的事務日志的數(shù)據(jù)存儲系統(tǒng)，它保存了每一項數(shù)據(jù)變更的記錄。在日志中，任何數(shù)據(jù)的寫入均以事務的形式提交，并對應一個特定順序的ID。數(shù)據(jù)當前的值就是日志中記錄的那些事務的總和。對于任何數(shù)據(jù)的讀取，得到的都只是日志當前時間點的一個快照。如果寫操作是繼上次讀取操作完成以來最新提交的事務，則判定寫操作成功。這種原語允許Amazon ECS以樂觀鎖的形式存儲集群的狀態(tài)信息，對于共享數(shù)據(jù)經(jīng)常變動的場景（比如當需要表達諸如ECS之類的計算資源共享池的狀態(tài)時）而言，這是一種理想的方式。這個架構(gòu)使得Amazon ECS具有高可用性、低延遲和高吞吐量的特點，因為數(shù)據(jù)存儲并未使用悲觀鎖（譯者注：作者自己表述得很含糊，大家參見多版本并發(fā)控制MVCC）。
通過API訪問

既然我們有了一個鍵值數(shù)據(jù)庫，那么我們便能夠成功協(xié)調(diào)集群，并確保所需數(shù)量的容器正在運行，因為我們有一種可靠的方法來存取集群的狀態(tài)。之前提到過，我們解耦了集群管理和容器調(diào)度兩個模塊，因為我們希望客戶能夠充分利用Amazon ECS狀態(tài)管理的能力。我們已經(jīng)通過一系列API開放了Amazon ECS集群管理器，它允許客戶以結(jié)構(gòu)化的方式訪問存儲在鍵值數(shù)據(jù)庫中的集群狀態(tài)信息。

通過list命令，客戶可以讀取托管的集群，特定集群中運行的EC2實例，運行中的任務以及組成任務的容器配置（如任務定義）。通過describe命令，客戶可以獲取EC2實例的具體信息以及每個實例上的可用資源。最近，客戶亦可以啟動和停止任何集群中的任務了。近期，我們針對Amazon ECS進行了一系列的負載測試，我們希望分享一些性能要點，客戶在Amazon ECS上創(chuàng)建應用的時候應該會關(guān)注它們的。

上圖顯示了一個負載測試的結(jié)果，在這次測試中，我們在Amazon ECS集群中添加和刪除實例，并測量72小時的周期內(nèi)，調(diào)用‘Describe Task’API時，百分比排列位于第50位和第99位的延遲。你可以看到，盡管集群數(shù)量有較大的波動，但是延遲相對而言并沒有什么抖動。Amazon ECS可以如你所需地進行擴展，不管你的集群規(guī)模有多大，且根本無需操作或擴展集群管理器。

這組API是客戶在Amazon ECS上搭建解決方案的基礎。調(diào)度器只是提供了關(guān)于何時、何地以及如何開啟和停止容器的邏輯。Amazon ECS的架構(gòu)為分享集群狀態(tài)而設計，它允許客戶根據(jù)需要為應用運行各種調(diào)度器（如二進制打包、發(fā)布等）。這個架構(gòu)允許調(diào)度器查詢集群的具體狀態(tài)，并從通用池中分配資源。樂觀并發(fā)控制允許調(diào)度器無沖突地獲取它們所請求的資源。一些客戶已經(jīng)在Amazon ECS上創(chuàng)建了各種有趣的解決方案，下面我們來分享一些具體的示例。
Hailo——彈性資源池上的定制調(diào)度

Hailo是一個免費的移動APP，它允許人們招呼一輛認證的出租車到其所在地。Hailo擁有一個全球網(wǎng)絡，囊括了超過60000名司機以及一百萬以上的乘客。Hailo于2011年成立，從第一天開始就使用了AWS。在過去的幾年中，Hailo從AWS單一區(qū)域上運行的應用集合演化為貫穿多個區(qū)域的微服務架構(gòu)。之前，每個微服務都跑在靜態(tài)劃分的實例集群上。Hailo遇到的問題是跨分區(qū)的資源使用率較低。這個架構(gòu)并不具備很強的擴展性，并且Hailo也不希望它的工程師關(guān)心基礎設施的細節(jié)或者微服務的部署問題。

為此，Hailo決定基于服務優(yōu)先級以及其它的運行時指標對容器進行調(diào)度。后來他們選擇了Amazon ECS來作為集群管理器，因為ECS可以輕松的管理任務狀態(tài)并訪問集群狀態(tài)的API。同樣，Hailo可以根據(jù)自己的需求來定制調(diào)度器。

Remind——平臺即服務

Remind是一個web端和移動端應用，使得老師能夠給學生發(fā)送信息并和家長取得聯(lián)系。Remind平臺上擁有24M用戶和超過1.5M的老師。它每月傳遞150M條信息。Remind起初使用Heroku來運行整個應用設施，從消息推送引擎、前后端API、Web客戶端到聊天后臺。這些設施中的大部分都以龐大的應用塊進行部署。

隨著用戶的增長，Remind希望擁有橫向擴展的能力。因此大約在2014年年底，它的工程師團隊開始摸索著向基于容器的微服務架構(gòu)遷移。團隊希望基于AWS搭建一個PaaS，確保它能夠兼容Heroku的API。一開始，團隊期望能有一個開源的解決方案（比如，CoreOS和Kubernetes）來負責集群的管理以及容器的協(xié)作，但是由于團隊的規(guī)模較小，因此他們沒有時間來管理集群的基礎設施，同時保證高可用性。

在簡要評估了Amazon ECS之后，團隊決定在此服務的基礎上搭建PaaS。Amazon ECS是全托管式的，這使得工程資源能夠被集中于開發(fā)和部署應用；這里并沒有集群需要管理和擴展。在6月份，Remind開源了他們基于ECS的PaaS解決方案，名為“Empire”。憑借Empire，Remind得到了可觀的性能提升（例如，延遲和穩(wěn)定性）以及安全優(yōu)勢。他們接下來幾個月的計劃是將90%以上的核心設施遷移到Empire。

Amazon ECS——一個全托管的平臺

上述只是我們從客戶處看到的其中兩個用例。Amazon ECS架構(gòu)允許我們提供一個具有高可擴展、高可用、低延遲的容器管理服務。通過API樂觀并發(fā)（譯者注：樂觀鎖）地訪問共享集群狀態(tài)的能力，使得用戶得以按需創(chuàng)建任何定制容器解決方案。我們一直致力于為客戶消除重復而繁重的任務。通過Amazone ECS，根本不需要安裝或操作集群管理程序，客戶理應僅僅專注于開發(fā)優(yōu)秀的應用。

Amazon與Google間的容器競爭持續(xù)發(fā)酵

Google容器引擎（GKE）由pod、replication controller和節(jié)點組成。pod是一組特定的應用程序邏輯主機模型的容器邏輯分組；replication controller確保特定數(shù)量的pod副本任何時候都在運行；節(jié)點是加強了容器環(huán)境的Google計算引擎虛擬機。

GKE基于Google的Kubernetes容器編排平臺。Kubernetes 1.1版本在1.0版首次亮相之后4個月的11月24號發(fā)布，是市場中第一個能夠通過水平節(jié)點自動伸縮功能來實現(xiàn)自動伸縮節(jié)點的產(chǎn)品，這個功能受到用戶的高度追捧，從而為許多使用GKE的案例提供了有力的支持。

“我們?yōu)楹芏喔鞣N類型的項目使用自動伸縮”， Descartes Labs公司的聯(lián)合創(chuàng)始人和首席云架構(gòu)師Tim Kelton如是說。這家公司位于新墨西哥洲，是機器學習方面的初創(chuàng)公司，能夠處理PB級別的衛(wèi)星數(shù)據(jù)。

自動伸縮的pod在處理大型批處理作業(yè)時能夠派上大用場，Kelton解釋道。有時，他的公司處理PB級的數(shù)據(jù)，這就需要擴展到3000個內(nèi)核。在Kubernetes的第一個版本（隨后很快被GKE合并）中，“這不是核心特性集的一部分”，他說。

雖然GKE不支持垂直容器擴展或者節(jié)點自動伸縮，但是，根據(jù)GKE高級產(chǎn)品經(jīng)理，同時也主導Kubernetes產(chǎn)品管理的David Aronchick透露，這些功能很快就是實現(xiàn)。

Amazon EC2容器服務（ECS）由服務、任務和實例組成。服務是構(gòu)成應用程序的任務組，而實例是支持容器的彈性計算云端虛擬機，與GKE中的節(jié)點很像。

Google的ECS的自動伸縮能力與GKE是相反的：使用亞馬遜CloudWatch和亞馬遜網(wǎng)絡服務Lamda可以實現(xiàn)服務自動伸縮，實例也可以基于CloudWatch metrics進行自動伸縮，但是任務——等同于pod，屬于粗糙邏輯，無法自動伸縮。

雖然所有類型的自動縮放都很重要，但是亞馬遜用戶希望將任務自動伸縮加入ECS中。

“運行一個新的實例意味著你要有額外的容量來運行額外的任務，但這并不意味著任何新的任務都將被啟動”，ACI信息科技集團副總裁Chris Moyer如是說。ACI，位于紐約，是一家基于Web的內(nèi)容聚合技術(shù)的公司，也是TechTarget的貢獻者。“如果你只是自動伸縮實例，并不能真正幫助你解決額外的負載——你必須真正運行額外的任務來實現(xiàn)擴展。”

跨區(qū)域冗余

在ECS發(fā)展過程中，亞馬遜優(yōu)先發(fā)展在同一個集群中，針對基于用戶需求的任務自動伸縮冗余性，本地跨越可用區(qū)域（AZs）的能力，當ECS服務調(diào)度啟動新的任務時，它也會嘗試通過集群中的AZs自動平衡這些任務。

“這很重要，因為單個AZ允許失敗，所以如果兩個任務都允許在同一個AZ中，很容易拖垮你的服務”，Moyer說。

據(jù)Aronchick介紹，Google可以在GKE中通過命令行接口（CLI）跨多個區(qū)域。

"實現(xiàn)跨區(qū)域非常容易，兩三條命令就能搞定"，Aronchick如是說。

然而，這就要談到GKE用戶最大的心愿：將跨區(qū)域功能改進到Web界面上，包括跨域集群擴展功能。

“實現(xiàn)用戶界面需要大量工作”，Vendasta科技首席架構(gòu)師Dale Hopkins說，Vendasta為媒體公司設計銷售和營銷軟件。用戶界面目前支持集群創(chuàng)建以及其他少數(shù)功能。Hopkins說：“擴展集群是不直觀的。”
互操作性

ECS作為一個可擴展平臺，旨在融入客戶現(xiàn)有的工作流，主要處理代表用戶的集群狀態(tài)。將ECS集成到現(xiàn)有工作流中來兼容客戶在用的工具，比如用以高級調(diào)度的Apache Mesos。亞馬遜還自豪的聲稱擁有廣泛的容器伙伴網(wǎng)絡來為亞馬遜ECS貢獻新特性，比如監(jiān)視、持續(xù)集成和安全。

同時，Google已經(jīng)與一批云端容器合作伙伴合作，這些合作商允許Kubernetes可以通過多個云端供應商被部署——這也是CLI現(xiàn)在的一個功能，Aronchick如是說。去年夏天Kubernetes 1.0版本發(fā)布時， Google引導了Cloud Native 計算基金會的成立，基金會成員包括云服務公司，比如IBM和Red Hat，以及終端用戶如eBay和Twitter。

“[附] Kubernetes，其實我可以在亞馬遜部署，在Azure上部署，在IBM上部署，也可以部署在我自己的物理硬件上，”Descartes的Kelton 說。 “這是非常有吸引力的，因為我們有選擇。”

Google也有一個開源項目，擁有數(shù)百提交者和每月數(shù)以千計的代碼提交，使得 Kubernetes可以快速的添加新功能，比如水平pod自動擴展。

Google是Kubernetes的創(chuàng)始者，而且Google做了很多杰出的工作壯大了社區(qū)，451 Research的研究員Jay Lyman如是說。

富者愈富

盡管如此，使用老牌和熟悉的次級亞馬遜服務來實現(xiàn)集成使得亞馬遜ECS特別吸引新的客戶。

一家總部位于紐約的公司，與一些大的企業(yè)就IT項目上進行咨詢，計劃在兩個新項目上使用ECS， 據(jù)其創(chuàng)始人John D'Esposito介紹。驅(qū)使我們使用ECS的主要優(yōu)點是使用現(xiàn)有的、成熟的基礎設施服務比如彈性負載平衡、虛擬私有云、身份和訪問管理，以及彈性塊存儲可以實現(xiàn)無縫集成。

GKE和Compute Engine的定價還是對客戶非常有吸引力的。除了在以10分鐘為單位收費的VM資源的底層，GKE包括免費的Kubernetes主節(jié)點——這是特別吸引Vendasta的Hopkins的地方。

“直到我可以獲得大量機器，我才會給 Kubernetes支付額外的費用。對于第一套機器，GKE為我免費提供Kubernetes節(jié)點”，Hopkins說。

在Kubernetes和容器引擎被引入之前，Hopkins和Kelton都已經(jīng)在用Google云服務，包括Google App引擎。這樣，數(shù)據(jù)重力就會在他們所選擇部署的云端容器上起作用。

“我們的大多數(shù)數(shù)據(jù)集是PB級規(guī)模的，所以你不能只是移動或復制它們，你必須真正去計算數(shù)據(jù)”，Kelton說。大多數(shù)數(shù)據(jù)目前存放在Google云平臺，雖然Descartes不與AWS的合作伙伴合作。
微軟Azure Container服務整裝待發(fā)

雖然Google和亞馬遜在云端容器競爭中到目前為止仍處于前沿，但亞馬遜最大的競爭對手仍然是微軟的Azure，它在有限預覽階段擁有自己基于Linux的云端容器的服務，以及Windows Server的新版本，今年之后，將支持基于Windows的容器。

“我們的大多數(shù)客戶都是......無論是在Azure或亞馬遜，” 位于Rochester的HKM咨詢公司的合伙創(chuàng)始人Chris Riley如是說，“微軟已經(jīng)拿到了一些他們正在開發(fā)的有趣工具。如果我們看到一個次要的，它很可能Google之前的Azure“。

簡單性和易用性是很多微軟的產(chǎn)品的設計重點，Lumagate的CTO Kristian Nese介紹，Lumagate是挪威的一家微軟Azure系統(tǒng)集成商。

“我們現(xiàn)在部署Azure的容器服務，僅僅需要100行代碼，”Nese說。 “一旦你部署了Azure的容器服務，你實際上部署了23個資源......如果你想手動做到這一點，可能需要數(shù)千行代碼。”

Azure容器服務在預覽階段也支持自動擴展，是一個獨立服務形式，被稱作VM量表集。

Azure還將提供成熟和熟悉的工具來管理容器，如Azure的資源管理器，Nese補充說。