杏仁容器化平臺以杏仁為基礎Mesos和Marathon構建，使用Calico多主機網絡提供容器，并通過Consul注冊和發現服務。

考慮到成本和可控性，選擇這個方案的原因。由于使用的組件都是開源項目，幾乎不需要二次開發，每個功能都由不同的組件提供，可以控制非常細的粒度。

總體結構見下圖：

Docker它提供了資源使用的控制，可以在啟動容器時*CPU以及內存的限制，但在大機環境中，需要更高效、更集成的資源管理模式。分布式資源管理框架Mesos，經過了Facebook、Twitter的萬臺主機驗證無疑是一個不錯的選擇。

Mesos實現了兩級調度架構，可管理多種應用，支持Docker。第一級調度是Master保護過程，管理Mesos所有節點在集群中運行Slave保護過程。集群由物理服務器或虛擬服務器組成，用于運行應用程序，如Hadoop和MPI作業。二級調度稱為Framework組件組成。Framework包括調度器（Scheduler）和執行器（Executor）執行器將在每個節點上運行。Mesos可與不同類型的Framework通信，每種Framework由相應的應用集群管理。圖中僅顯示Hadoop和MPI其他類型的應用程序也有兩種類型Framework。

Mesos Master協調全部的Slave，確定每個節點的可用資源，然后注冊Master的Framework（作為Master發出的客戶端)resource offer。Framework 可根據應用程序的需要選擇接受或拒絕 ster的resource offer。一旦接受邀請，Master會協調Framework和Slave因此，Mesos可以將Hadoop、Cassandra同時在同一節點運行多個任務。

通過以下實例可以進一步理解Mesos資源分配：

我們選擇了容器調度Marathon。Marathon 可以和 Mesos 一起合作的 framework，用于運行持久性應用，如docker。用戶可以通過WEB UI和API發布應用程序mesos集群中。

Marathon主要有以下特點：

Mesos containers 和 Docker

例如，我們啟動三個服務，即一個節點、三個節點和五個節點。如果我們想擴展這些服務，我們可以調用它們Marathon的API擴展，而且是秒級的。如果主機停機，Marathon它將均勻地將服務轉移到其他機器上，并選擇有空閑資源的機器進行遷移。這可以確保服務是動態調度，確保服務的高可用性，這些都是自己處理的，不需要手動干預。

支持Http,Tcp自定義腳本測活

界面如下:

在環境中docker網絡功能通常通過映射主機端口提供，但考慮到生產環境中的性能和兼容性（有些應用程序需要獨家享受）IP），1容器1 IP方案至關重要。

目前Docker通過不同的實現方式，網絡方案主要分為隧道和路由兩類。

隧道通過隧道，或Overlay Networking的方式:

隧道方案在IaaS層網絡也有更多的應用共識是隨著節點規模的增長，復雜度會提高，跟蹤網絡問題也比較麻煩。這是大規模集群需要考慮的一點。

典型的路由代表有：

最后，考慮到性能和集成成本，我們選擇了Calico。

Marathon支持多種服務發現和負載方式：

在環境中，考慮到易用性，我們使用它Marathon-lb進行服務注冊和負載，前端的nginx二次轉發請求haproxy固定端口。在生產環境中，為了減少二次轉發的成本，并兼容服務使用consul我們使用注冊方法Registrator注冊應用程序Consul,再通過consul-template動態地將應用程序訪問地址寫入nginx，并由nginx提供負載功能。

Registrator的latest版本鏡像不能注冊(很久沒有更新)，需要使用 ster版本

Marathon和Consul都有自己的測活配置，如果Consul測量間隔大于Marathon測活間隔會導致服務不可用。Marathon整個過程的灰度將在發布過程中得到保證，但是Registrator只要檢測到容器啟動，就會注冊Consul,此時Consul可用和不可用的服務實例同時存在(不可用的實例不會添加)nginx負載)，但當Marathon完成應用測活后，老應用會立即被殺死，此時Consul不可用的服務器還沒有完成測，但可用的服務已被殺死，整個服務處于不可用狀態，reload nginx因為沒有可用的upstream server會報錯的。所以一定要保證。Consul測量間隔小于Marathon目前測活間隔為1:5。

Mesos slave配置變更后，需要清理mesos slave只有元數據才能啟動。具體命令可參考slave的log。