Docker在螞蟻金融云平臺中的探索與實踐
螞蟻金融云是螞蟻金服推出的針對金融行業的云計算服務，旨在將螞蟻金服的大型分布式交易系統中間件技術以 PaaS 的方式提供給相應客戶。在整個的 PaaS 產品中，螞蟻金服通過基于 Docker 的 CaaS 層來為上層提供計算存儲網絡資源，以提高資源的利用率與交付速度，并用來隔離底層 IaaS 的不同，IaaS、CaaS 與 PaaS 三層相互借力，互相配合。為了進一步了解螞蟻金融云的整個體系架構，InfoQ 采訪了螞蟻金服基礎技術部系統組 leader 吳崢濤。
InfoQ：能否介紹下螞蟻金服的金融云 PaaS 平臺？
吳崢濤：金融云 PaaS 是從 2014 年中開始研發的，目前已經承載了網商銀行以及另外兩個核心業務，后續會以公有云和專有云兩種模式對外提供。之所以會有金融云 PaaS 這個項目，是因為螞蟻這些年來在大型分布式系統領域涉及的 SOA、消息通訊、水平擴展、分庫切片、數據一致、監控、安全等技術方向積累了大量的中間件以及與之完整配套的監控運維研發流程體系，這一切在性能和穩定 性以及擴展性上做的都不錯，能夠有效的支撐螞蟻的業務發展，并應對『雙 11』這樣的高負荷挑戰。很多金融客戶與伙伴都對此非常感興趣，所以我們希望能夠把這一整套的技術上云并產品化，以 PaaS 的方式整體對外輸出，幫助金融行業的客戶使用云計算技術去 IOE，幫助他們解決我們已經解決的技術問題，讓他們能專注于業務邏輯。上帝的歸上帝，凱撒的歸凱撒。
</blockquote>InfoQ：螞蟻金服想把自己的中間件技術以 PaaS 產品的形式對外輸出，這中間碰到了哪些問題？為什么會想到通過 Docker 這樣的技術來解決？
吳崢濤：遇到的問題有很多，最主要的問題包括：
金融云 PaaS 是承載在阿里云 IaaS 上的，最初的方案是，用戶部署應用的時候，根據所屬技術棧，由系統解析軟件包（例如 sofa4 依賴 CloudEngine、Tengine、cronolog、JDK 等等），下載安裝配置并啟動。這樣的資源交付、應用部署周期比較長，客戶體驗不太好。
</li>螞蟻的應用架構采用的是基于服務發現、消息總線的 SOA 方案，模塊間通過服務接口調用；服務可以是本地接口也可以是遠程接口，對于調用者是解耦合的。在實際部署的時候，我們會根據業務緯度切分大量的服務模塊出 來，以金融云 PaaS 中樞為例，目前已經有幾十種服務模塊。這樣的話，我們希望資源粒度越小越好，原有以 VM 為粒度的資源分配方式已經不能滿足我們的需求。同時資源交付速度慢導致擴容縮容慢，影響資源利用率。
</li>金融云 PaaS 如果對外輸出，可能使用非阿里云的 IaaS，所以需要一個中間層屏蔽多種 IAAS 的區別。
</li>鏡像管理比較麻煩，無法自動化，也不是白盒。
</li> </ol>而遇到的這些問題，都可以通過 Docker 來解決。
</blockquote>InfoQ：能否介紹下你們整個平臺的系統架構？Docker 在整個架構中扮演怎么樣的位置？
吳崢濤：我們在 PaaS 和 IaaS 之間插了一個 AntCaaS 層，這是一個基于 Docker 的管控平臺，他的職責是：
- 以微容器（Docker）為載體，為用戶（PaaS、SaaS）按需提供計算存儲網絡資源，提高資源的利用率與交付速度。
- 對 PaaS、SaaS 屏蔽 IaaS 實現細節。
- 實現容器、集群級別的標準化與可復制、可遷移。
</ol>
AntCaaS 提供 container、app、cluster 三層接口，可以把他當作一個輕量級的 IaaS，區別僅僅是提供 Container 而不是 VM，然后也提供 PaaS 層的接口。
一個比較有特色的功能是，通過『鏡像中心+集群 template+ 環境相關參數列表』，我們實現了集群的快速復制，目的是為了應付突發的負載高峰。
</blockquote>InfoQ：在 PaaS 層面，你們是如何屏蔽底層不同 IaaS 的區別的？
吳崢濤：目前 AntCaaS 可以直接運行在物理機上也可以運行在經典網絡的 ECS VM 集群中，VPC、ECS 支持還在開發過程中。在 AntCaaS 中，我們采用三層架構，通過創建不同 pool 來兼容不同的 IaaS。pool 包含了：
- 多個 node（container 的載體）。
- ZK 用以監控 node 和 container。
- scheduler 調度器，負載 container 的創建調度。
- manager，對 master 提供管控的 HTTP Rest 接口。
- registry-proxy 保證網絡聯通性以及 cache 鏡像數據，加速鏡像下載。
- 在 node 內起 cadvisor 監控 container。
</ol>
Docker 默認的 bridge/host 網絡模式不能滿足我們的需要，根據 IaaS 提供的網絡功能不同，我們擴展了 vlan/vxlan 兩種網絡 driver，第三者 vpc driver 還在開發中。
vlan 模式，事先為 container 分配一個與 node 不一樣的網段。
</li>
vxlan 模式，首先通過 ovs 實現跨 node 的私有網絡，然后通過 zk 緩存同步 vpcid、vpc ip、node ip 的映射關系，極端情況下，如果一個 vpc 有 1000 個 container 分布在 1000 個 node 上，那么新建一個 container 加入這個 vpc 時，需要通知所有的 node。
</li> </ol>
另外在 VPC 內，我們提供輕量級的 DNS，用于內部域名解析；輕量級的 LB，用于內部的負載均衡。
下圖是可擴展的容器創建流程。
</blockquote>
InfoQ：容器的安全問題是怎么解決的？
吳崢濤：基于 pool-node-container 的三層解決方案。用戶和 pool 是 1 對多的關系，所以 pool 的 node 必然都屬于同一個用戶，同一個 node 上的 container 屬于同一個用戶。pool 和 pool 之間根據 IaaS 不同采用不同的隔離方案，經典網絡的 ECS 使用安全組隔離，vpc ecs 使用 vpc 隔離。
</blockquote>InfoQ：社區中有反饋說 Docker 會經常無故掛掉，你們有遇到過嗎？有做過深入跟進嗎？
吳崢濤：碰到過，我們的架構設計允許 Docker Daemon 和 Container 掛掉。使用了集團的一個 Docker Patch，在 Docker Daemon 掛掉后，不影響 container 運行。出現比較多的場景是 docker pull 時候。
</blockquote>InfoQ：你們是如何將基于 Docker 的系統與原有系統對接的？
吳崢濤：為了與現有的運維流程管控 SCM 系統對接，幫助現有系統遷移，以及幫助開發同學轉換開發模式，我們做了不少妥協方案。作為 Docker fans，理想的開發模式是下面這樣。
但是實際上螞蟻目前已經有 1000 多個應用，幾千的開發人員，很難讓他們一下都切換到 Docker 這種以鏡像為中心的研發模式上；但是如果一個團隊一個團隊的推廣，那么耗時不可控。并且螞蟻原有的運維、監控、SCM 等系統都是以 VM 為緯度的，基于 Docker 的運維發布系統需要與原有系統對接集成難度比較大。
所以我們的第一個策略是，首先解決線上環境的 Docker 化部署問題，開發者的本地開發環境 Docker 化問題暫且不管，希望通過線上環境 Docker 化來吸引開發人員學習使用 Docker。
接下來的問題是，誰來寫 Dockerfile，首先各個研發團隊的人不關心是否使用 Docker 部署，所以不可能寫 Dockerfile，由 Docker 團隊或者運維同學負責，沒有應用代碼的編輯權限，同時工作量太大并且不了解應用容易出問題。所幸螞蟻的業務應用大多數都是基于 sofa3 或 sofa4 框架的 Java 應用，所以我們做了 sofa3/4 的基礎鏡像以及提供一個輔助工具，使用 sofa3/4 鏡像啟動一個 container，然后使用原有的發布工具將應用的 tgz 包（類似 war）發布到 container 中。這樣就不需要寫 Dockerfile，同時原有運維系統也能把 container 當作 VM，無縫對接。
</blockquote>InfoQ：聊聊你們異地多機房的統一鏡像中心解決方案？
吳崢濤：關于跨機房鏡像中心的解決方案要點：