雪球目前擁有一千多個容器，項目數量大概有一百多個，規模并不是很大。但是得益于容器技術，雪球部署的效率非常高，雪球的開發人員隻有幾十個，但是每個月的釋出次數高達兩千多次。
2018 年 5 月 18-19 日，由 51CTO 主辦的全球軟體與運維技術峰會在北京召開。在“開源與容器技術”分會場，雪球 SRE 工程師董明鑫帶來了《容器技術在雪球的實踐》的主題分享。
本文主要分為如下三個方面跟大家分享雪球在業務中引入和使用容器技術的心路曆程：
● 為什麼要引入 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 的 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 來實作更好的排程方案。
支援多機房和多雲環境，以達到更高的容災等級，滿足業務的發展需求，并完善叢集的管理。
上圖展示了一種嵌套式的關系：在我們的每一個 Project 中，都可以有多個 IDC。
而每個 IDC 裡又有着不同的 Kubernetes 叢集。同時在每一個叢集裡，我們為每一個項目都配置設定了一個 Namespace。
根據不同的環境，這些項目的 Namespace 會擁有不同的 Deployment。例如想要做到部署與釋出的分離，我們就相應地做了多個 Deployment，不同的 Deployment 标示不同的環境。
預設将流量引入第一個 Deployment，等到第二個 Deployment 被部署好以後，需要釋出的時候，我們再直接把流量“切”過去。
同時，鑒于我們的平台上原來就已經具有了諸如日志、負載均衡、監控之類的解決方案。
而 Kubernetes 本身又是一個較為全面的解決方案，是以我們以降低成本為原則，謹慎地向 Kubernetes 進行過渡，盡量保持平台的相容性，不至讓開發人員産生“違和感”。
如今，我們的容器隻有一千多個，項目數量大概有一百多個。但是我們在部署效率方面的提升還是非常顯著的，我們的幾十個開發人員每個月所釋出的次數就能達到兩千多次，每個交易日的日志量大概有 1.5T。
原文釋出時間為：2018-10-25
本文作者：董明鑫
本文來自雲栖社群合作夥伴“
資料和雲”，了解相關資訊可以關注“
”。