《美團點評業務之技術解密,日均請求數十億次的容器平臺》要點:
本文介紹了美團點評業務之技術解密,日均請求數十億次的容器平臺,希望對您有用。如果有疑問,可以聯系我們。
本文介紹美團點評的 Docker 容器集群管理平臺(以下簡稱容器平臺).該平臺始于 2015 年,基于美團云的基礎架構和組件而開發的 Docker 容器集群管理平臺.目前該平臺為美團點評的外賣、酒店、到店、貓眼等十幾個事業部提供容器計算服務,承載線上業務數百個,容器實例超過 3 萬個,日均線上請求超過 45 億次,業務類型涵蓋 Web、數據庫、緩存、消息隊列等等.
在容器平臺實施之前,美團點評的所有業務都是運行在美團私有云提供的虛擬機之上.美團點評大部分的線上業務都是面向消費者和商家的,業務類型多樣,彈性的時間、頻度也不盡相同,這對彈性服務提出了很高的要求.
在這一點上,虛擬機已經難以滿足需求,主要體現以下兩點:
美團點評將容器管理平臺視作一種云計算模式,因此云計算的架構同樣適用于容器.
如前所述,容器平臺的架構依托于美團私有云現有架構,其中私有云的大部分組件可以直接復用或者經過少量擴展開發,如圖所示.
圖 1. 美團點評容器管理平臺架構
整體架構上與云計算架構是一致的,自上而下分為業務層、PaaS 層、IaaS 控制層及宿主機資源層.
容器平臺在網絡方面復用了美團云網絡基礎架構和組件,邏輯架構設計如圖所示.
圖 2. 美團點評容器平臺網絡架構
在數據平面,我們采用萬兆網卡,結合 OVS-DPDK 方案,并進一步優化單流的轉發性能,將幾個 CPU 核綁定給 OVS-DPDK 轉發使用,需要少量的計算資源即可提供萬兆的數據轉發能力.OVS-DPDK 和容器所使用的 CPU 完全隔離,因此也不影響用戶的計算資源.控制平面我們使用 OVS 方案.所謂 OVS 方案是在每個宿主機上部署一個軟件的 Controller,動態接收網絡服務下發的網絡規則,并將規則進一步下發至 OVS 流表,決定是否對某網絡流放行.
自研配置模式 MosBridge
在 MosBridge 之前,我們配置容器網絡使用的是 None 模式.在實踐中,我們發現 None 模式存在一些不足:
為了解決這些問題,我們基于 Libnetwork,開發了 MosBridge – 適配美團云網絡架構的 Docker 網絡驅動.在創建容器時,需要指定容器創建參數—net=mosbridge,并將 ip 地址,網關,OVS Bridge 等參數傳給 Docker,由 MosBridge 完成網絡的配置過程.有了 MosBridge,容器創建啟動后便有了網絡可以使用.容器的網絡配置也持久化在 MosBridge 中,容器重啟后網絡配置也不會丟失.
為了解決本地磁盤數據卷限容能力弱的問題,我們開發了 LVM Volume 方案.該方案在宿主機上創建一個 LVM VG 作為 Volume 的存儲后端.創建容器時,從 VG 中創建一個 LV 當作一塊磁盤,掛載到容器里.這樣 Volume 的容量便由 LVM 的 LV 加以強限制,得益于 LVM 機強大的管理能力,我們可以做到對 Volume 更精細、更高效的管理.例如,我們可以很方便地調用 LVM 命令查看 Volume 使用量,通過打標簽的方式實現 Volume 偽刪除和回收站功能,還可以使用 LVM 命令對 Volume 做在線擴容.
圖 3. LVM-Volume 方案
在設計實現容器監控之前,美團點評內部已經有了許多監控服務,例如 zabbix,falcon 和 CAT.我們不需要設計實現一套完整的監控服務,而更多地是如何高效地采集容器運行信息,根據運行環境的配置上報到相應的監控服務上.
圖 4:監控數據采集方案
針對業務和運維的監控需求,我們基于 libcontainer 開發了 mos-docker-agent 監控模塊.該模塊從宿主機 proc、cgroup 等接口采集容器數據,經過加工換算,再通過不同的監控系統 driver 上報數據.該模塊使用 go 語言編寫,既可以高效率,又可以直接使用 libcontainer.而且監控不經過 Docker Daemon,不加重 Daemon 的負擔.
我們從 Docker 1.11 版本開始,自研維護一個分支,我們稱之為 MosDocker.除了一些 Bugfix 之外,MosDocker 還有一些自研的特性.
MosDocker 的大部分特性是解決美團點評業務場景的需求問題,不適合開源.對于社區的 bugfix,我們會定期 review 并 backport 到我們的 MosDocker 版本里.
圖 5:美團點評服務治理平臺
組件:
功能:
圖 6:set 容器組設計
設計特性
參考 Kubernetes 的 Pod 設計,針對我們的容器平臺設計實現了 set 容器組.容器組對外呈現一個 IP,內置一個 busybox 作為 infra-container,它不提供任何業務功能,set 的網絡、volume 都配置在 busybox 上,所有其他的容器都和 busybox 共享.
?在實際業務中的推廣應用
通過引入 Docker 技術,為業務部門帶來諸多好處,典型的好處有幾點:
圖 7. 某業務虛擬機和容器平均單機 QPS
圖 8 某業務虛擬機和容器資源使用量
在容器化過程中,我們發現 Docker 或者容器技術本身存在許多問題和不足,例如,Docker 存在 IO 隔離性不強的問題,無法對 Buffered IO 做限制;偶爾 Docker Daemon 會卡死,無反應的問題;容器內存 OOM 導致容器被刪除,開啟 OOM_kill_disabled 后可能導致宿主機內核崩潰等等問題.因此 Docker 或者容器技術,在我們看來應該和虛擬機是互補的關系,不能指望在所有場景中 Docker 都可以替代虛擬機,因此只有將 Docker 和虛擬機并重,才能滿足用戶的各種場景對云計算的需求.
QA 環節
A1:4G 內存的容器還好,我們線上物理機標配是 128G 內存,而且容器的內存只是 cgroup 里的一個設置,實際分配內存還是以容器使用為準.對于一些內存 bound 型業務,內存需要 10G 甚至更多的,我們給這類業務單獨一個物理機集群使用,不和其他業務混部.
A2:kubernetes 源于 Google 的 Borg 系統,Borg 是一個分布式容器集群管理平臺,在 Google 內部使用 10 多年,承載海量的 Google 線上業務,架構、性能都在業內有廣泛聲譽.Kubernetes 可以看作 Borg 用 Go 語言重寫,和 Borg 一脈相承,所以 Kubernetes 一經推出便廣受業界推崇,現在已經是容器集群管理系統的業界標桿.簡單來說 Kuberenetes 有一下優勢:
A3:
A4:美團云 Docker 平臺的 Volume 管理經過 3 個階段:
階段 1:本地文件系統做 volume,優點是開發快,缺點是限容、隔離性差,數據可靠性差
階段 2:本地 lvm 磁盤,解決了 volume 隔離性問題,但可靠性仍然不足
階段 3:現階段,我們使用美團云自研的分布式彈性塊存儲服務,相當于 aws 的 EBS,用 ebs 做 volume 存儲后端,完全解決了容量限制,隔離性,可靠性的問題,在 volume 備份、遷移上也有優勢.
A5:據我所知,業界大規模使用容器的方案有 k8s 和 Mesos 的,Swarm 早期功能簡單,不能滿足生產所需,不過 Docker 公司對 Swarm 的更新很快,而且 Swarm 和 Docker 是一致的接口,相信以后會有較多的實踐.
A6:美團云存儲后端有分布式對象存儲系統,也有分布式塊存儲系統.都是美團云自研的系統.
鄭坤, 2011 年中科院計算所博士畢業,曾在華為從事內核研發工作.2015 年加入美團,負責美團云容器平臺的設計開發,以及在美團點評內部容器化推廣工作.很高興本次分享 Docker 技術在美團點評的實踐情況.
文章來自微信公眾號:高效開發運維
轉載請注明本頁網址:
http://www.snjht.com/jiaocheng/4077.html