使用容器的正確方式，Docker在雪球的技術實踐

原創

作者：董明鑫 2018-09-17 08:31:08

開發架構

雪球目前擁有一千多個容器，項目數量大概有一百多個，規模并不是很大。但是得益于容器技術，雪球部署的效率非常高，雪球的開發人員只有幾十個，但是每個月的發布次數高達兩千多次。

【51CTO.com原創稿件】雪球目前擁有一千多個容器，項目數量大概有一百多個，規模并不是很大。但是得益于容器技術，雪球部署的效率非常高，雪球的開發人員只有幾十個，但是每個月的發布次數高達兩千多次。

[[243793]]

2018 年 5 月 18-19 日，由 51CTO 主辦的全球軟件與運維技術峰會在北京召開。在“開源與容器技術”分會場，雪球 SRE 工程師董明鑫帶來了《容器技術在雪球的實踐》的主題分享。

本文主要分為如下三個方面跟大家分享雪球在業務中引入和使用容器技術的心路歷程：

為什么要引入 Docker
Docker 在雪球的技術實踐
后續演進

雪球是一個投資者交流的社區，用戶可以在上面買賣股票，代銷基金等各種金融衍生業務，同時也可以通過雪盈證券來進行滬、深、港、美股的交易。

為什么要引入 Docker

隨著業務的發展，不同的社區業務之間所受到影響的概率正在逐漸升高，因此我們希望各個業務之間既能夠不被打擾，又能在資源上、機器間、甚至網絡上根據監管的要求予以不同層面的隔離。

早在 2014 年時，我們就發現容器技術具有本身鏡像小、靈活、啟動速度快等特點，而且在性能上比較適合于我們當時物理機不多的規模環境。

相比而言，傳統的虛擬化技術不但實現成本高，而且性能損耗也超過 10%。因此，基于對鏡像大小、啟動速度、性能損耗、和隔離需求的綜合考慮，我們選用了兩種容器引擎：LXC 和 Docker。

我們把 MySQL 之類有狀態的服務放在 LXC 里；而將線上業務之類無狀態的服務放在 Docker 中。

容器使用方法

眾所周知，Docker 是以類似于單機的軟件形態問世的，最初它的宣傳口號是：Build/Ship/Run。

因此它早期的 Workflow（流程）是：

在一臺 Host 主機上先運行 Docker Build。
然后運用 Docker Pull，從鏡像倉庫里把鏡像拉下來。
***使用 Docker Run，就有了一個運行的 Container。

需要解決的問題

上述的流程方案伴隨著如下有待解決的問題：

網絡連通性，由于是單機軟件，Docker 最初默認使用的是 Bridge 模式，不同宿主機之間的網絡并不相通。因此，早期大家交流最多的就是如何解決網絡連通性的問題。
多節點的服務部署與更新，在上馬該容器方案之后，我們發現由于本身性能損耗比較小，其節點的數量會出現爆炸式增長。

因此，往往會出現一臺物理機上能夠運行幾十個節點的狀況。容器節點的絕對數量會比物理節點的數量大一個數量級，甚至更多。那么這么多節點的服務部署與更新，直接導致了工作量的倍數增加。

監控，同時，我們需要為這么多節點的運行狀態采用合適的監控方案。

Docker 在雪球的技術實踐

網絡模式

首先給大家介紹一下我們早期的網絡解決方案：在上圖的左邊，我們默認采用的是 Docker 的 Bridge 模式。

大家知道，默認情況下 Docker 會在物理機上創建一個名為 docker0 的網橋。

每當一個新的 Container 被創建時，它就會相應地創建出一個 veth，然后將其連到容器的 eth0 上。

同時，每一個 veth 都會被分配到一個子網的 IP 地址，以保持與相同主機里各個容器的互通。

由于在生產環境中不只一張網卡，因此我們對它進行了改造。我們產生了一個“網卡綁定”，即生成了 bond0 網卡。我們通過創建一個 br0 網橋，來替換原來的 docker0 網橋。

在該 br0 網橋中，我們所配置的網段和物理機所處的網段是相同的。由于容器和物理機同處一個網段，因此核心上聯的交換機能夠看到該容器和不同宿主機的 MAC 地址。這就是一個網絡二層互通的解決方案。

該網絡模式具有優劣兩面性：

優點：由于在網絡二層上實現了連接互通，而且僅用到了內核轉發，因此整體性能非常好，與物理機真實網卡的效率差距不大。
缺點：管理較為復雜，需要我們自己手動的去管理容器的 IP 和 MAC 地址。

由于整體處于網絡大二層，一旦系統達到了一定規模，網絡中的 ARP 包會產生網絡廣播風暴，甚至會偶發出現 PPS（Package Per Second）過高，網絡間歇性不通等奇怪的現象。

由于處于底層網絡連接，在實現網絡隔離時也較為復雜。

服務部署

對于服務的部署而言，我們最初沿用虛擬機的做法，將容器啟動起來后就不再停下了，因此：

如果節點需要新增，我們就通過 Salt 來管理機器的配置。
如果節點需要更新，我們就通過 Capistrano 進行服務的分發，和多個節點的部署操作，變更容器中的業務程序。

其中，優勢為：

與原來的基礎設施相比，遷移的成本非常低。由于我們通過復用原來的基礎設施，直接將各種服務部署在原先的物理機上進行，因此我們很容易地遷移到了容器之中。

而對于開發人員來說，他們看不到容器這一層，也就如同在使用原來的物理機一樣，毫無“違和感”。

與虛擬機相比，啟動比較快，運行時沒有虛擬化的損耗。
最重要的是一定程度上滿足了我們對于隔離的需求。

而劣勢則有：

遷移和擴容非常繁瑣。例如：當某個服務需要擴容時，我們就需要有人登錄到該物理機上，生成并啟動一個空的容器，再把服務部署進去。此舉較為低效。
缺乏統一的平臺進行各種歷史版本的管理與維護。我們需要通過文檔來記錄整個機房的容器數量，和各個容器的 IP/MAC 地址，因此出錯的可能性極高。
缺少流程和權限的控制。我們基本上采用的是原始的管控方式。

自研容器管理平臺

面對上述缺點，我們需要自行研發一個容器管理平臺，去管理各種物理機、容器、IP 與 MAC 地址、以及進行流程控制。

因此我們變更的整套發布流程為：

由開發人員將代碼提交到代碼倉庫（如 Github）之中。
觸發一個 Hook 去構建鏡像，在構建的同時做一些 CI（持續集成），包括靜態代碼掃描和單測等。
將報告附加到鏡像的信息里，并存入鏡像倉庫中。
部署測試環境。
小流量上線，上線之后，做一些自動化的 API Diff 測試，以判斷是否可用。
繼續全量上線。

鏡像構建

有了容器管理平臺，就會涉及到鏡像的自動構建。和業界其他公司的做法類似，我們也使用的是基于通用操作系統的鏡像。

然后向鏡像中添加那些我們公司內部會特別用到的包，得到一個通用的 base 鏡像，再通過分別加入不同語言的依賴，得到不同的鏡像。

每次業務版本發布，將代碼放入相應語言的鏡像即可得到一個業務的鏡像。構建鏡像的時候需要注意盡量避免無用的層級和內容，這有助于提升存儲和傳輸效率。

系統依賴

我們的這一整套解決方案涉及到了如下周邊的開源項目與技術：

負載均衡

由于會頻繁發生節點的增減，我們該如何通過流量的調度和服務的發現，來實現自動加入負載均衡呢？對于那些非 Http 協議的 RPC，又該如何自動安全地摘掉某個節點呢？

我們在此使用了 Nginx+Lua（即 OpenResty），去實現邏輯并動態更改 Upstream。

當有節點啟動時，我們就能夠將它自動注冊與加入；而當有節點被銷毀時，也能及時將其摘掉。

同時，我們在內部使用了 Finagle 作為 RPC 的框架，并通過 ZooKeeper 實現了服務的發現。

日志收集

由于節點眾多，我們需要進行各種日志的收集。在此，我們大致分為兩類收集方式：

一類是 Nginx 這種不易侵入代碼的，我們并沒有設法去改變日志的流向，而是讓它直接“打”到物理機的硬盤上，然后使用 Flume 進行收集，傳輸到 Kafka 中。
另一類是我們自己的業務。我們實現了一個 Log4 Appender，把日志直接寫到 Kafka，再從 Kafka 轉寫到 ElasticSearch 里面。

網絡模式

在該場景下，我們采用的是上述提到的改進后的 Bridge+Host 模式。

監控系統

監控系統由上圖所示的幾個組件所構成。它將收集（Collector）到的不同監控指標數據，傳輸到 Graphite 上，而 Grafana 可讀取 Graphite 的信息，并用圖形予以展示。

同時，我們也根據內部業務的適配需要，對報警組件 Cabot 進行了改造和定制。

此時我們的平臺已經與虛擬機的用法有了較大的區別。如上圖所示，主要的不同之處體現在編譯、環境、分發、節點變更，流程控制、以及權限控制之上。我們的用法更具自動化。

由于是自行研發的容器管理平臺，這給我們帶來的直接好處包括：

流程與權限的控制。
代碼版本與環境的固化，多個版本的發布，鏡像的管理。
部署與擴容效率的大幅提升。

但是其自身也有著一定的缺點，包括：

在流程控制邏輯，機器與網絡管理，以及本身的耦合程度上都存在著缺陷。因此它并不算是一個非常好的架構，也沒能真正實現“高內聚低耦合”。
由于是自研的產品，其功能上并不完善，沒能實現自愈，無法根據新增節點去自動選擇物理機、并自動分配與管理 IP 地址。

引入 Swarm

2015 年，我們開始著手改造該容器管理平臺。由于該平臺之前都是基于 DockerAPI 構建的。

而 Swarm 恰好能對 Docker 的原生 API 提供非常好的支持，因此我們覺得如果引入 Swarm 的話，對于以前代碼的改造成本將會降到***。

那么我們該如何對原先的網絡二層方案進行改造呢？如前所述，我們一直實現的是讓容器的 IP 地址與物理機的 IP 地址相對等。

因此并不存在網絡不通的情況。同時，我們的 Redis 是直接部署在物理機上的。

所以依據上圖中各個列表的對比，我們覺得 Calico 方案更適合我們的業務場景。

因此，我們在上層使用 Rolling 來進行各種流程的操作，中下層則用 Swarm+Calico 來予以容器和網絡的管理。

Calico 使用的是 DownwardDefault 模式，該模式通過運用 BGP 協議，來實現對于不同機器之間路由信息的分發。

在默認情況下，Calico 是 Node 與 Node 之間的 Mesh 方式，即：任意兩個 Node 之間都有著 BGP 連接。

當我們在一臺物理機上啟動了某個容器之后，它就會添加一條包含著從容器 IP 地址到物理機的路由信息。

由于多臺物理機同處一個 Mesh，那么每一臺機器都會學習到該路由信息。而隨著我們系統規模的逐漸增大，每一臺物理機上的路由表也會相應地增多，這就會影響到網絡的整體性能。

因此我們需要采用這種 Downward Default 部署模式，使得不必讓每臺物理機都擁有全量的路由表，而僅讓交換機持有便可。

眾所周知，BGP 會給每一臺物理機分配一個 AS（自治域是 BGP 中的一個概念）號，那么我們就可以給各臺物理機都分配相同的 AS 號。

而給它們的上聯交換機分配另一個 AS 號，同時也給核心交換機再分配第三種 AS 號。

通過此法，每一臺物理機只會和自己上聯的交換機做路由分發，那么當有一個新的節點啟動之后，我們便可以將這條路由信息插入到該節點自己的路由表中，然后再告知與其相連的上聯交換機。

上聯交換機在學習到了這條路由之后，再進一步推給核心交換機。

總結起來，該模式的特點是：

單個節點不必知道其他物理機的相關信息，它只需將數據包發往網關便可。因此單臺物理機上的路由表也會大幅減少，其數量可保持在“單機上的容器數量 +一個常數（自行配置的路由）”的水平上。
每個上聯交換機只需掌握自己機架上所有物理機的路由表信息。
核心交換機則需要持有所有的路由表。而這恰是其自身性能與功能的體現。

當然，該模式也帶來了一些不便之處，即：對于每一個數據流量而言，即使目標 IP 在整個網絡中并不存在，它們也需要一步一步地向上查詢直到核心交換機處，***再判斷是否真的需要丟棄該數據包。

后續演進

在此之后，我們也將 DevOps 的思想和模式逐步引入了當前的平臺。具體包括如下三個方面：

通過更加自助化的流程，來解放運維。讓開發人員自助式地創建、添加、監控他們自己的項目，我們只需了解各個項目在平臺中所占用的資源情況便可，從而能夠使得自己的精力更加專注于平臺的開發與完善。
如今，由于 Kubernetes 基本上已成為了業界的標準，因此我們逐步替換了之前所用到的 Swarm，并通過 Kubernetes 來實現更好的調度方案。
支持多機房和多云環境，以達到更高的容災等級，滿足業務的發展需求，并完善集群的管理。