美團點評業務之技術解密，日均請求數十億次的容器平臺

pennyz1s44 7年前發布 | 47K 次閱讀 Docker

本文介紹美團點評的 Docker 容器集群管理平臺（以下簡稱容器平臺）。該平臺始于 2015 年，基于美團云的基礎架構和組件而開發的 Docker 容器集群管理平臺。目前該平臺為美團點評的外賣、酒店、到店、貓眼等十幾個事業部提供容器計算服務，承載線上業務數百個，容器實例超過 3 萬個，日均線上請求超過 45 億次，業務類型涵蓋 Web、數據庫、緩存、消息隊列等等。

容器到來之前

在容器平臺實施之前，美團點評的所有業務都是運行在美團私有云提供的虛擬機之上。美團點評大部分的線上業務都是面向消費者和商家的，業務類型多樣，彈性的時間、頻度也不盡相同，這對彈性服務提出了很高的要求。

在這一點上，虛擬機已經難以滿足需求，主要體現以下兩點：

  • IT 成本高。由于虛擬機彈性能力較弱，業務部門為了應對流量高峰和突發流量，普遍采用預留大量機器和服務實例的做法。資源沒有得到充分使用產生浪費。

(點擊放大圖像)

容器時代

架構設計

美團點評將容器管理平臺視作一種云計算模式，因此云計算的架構同樣適用于容器。

如前所述，容器平臺的架構依托于美團私有云現有架構，其中私有云的大部分組件可以直接復用或者經過少量擴展開發，如圖所示。

(點擊放大圖像)

圖 1. 美團點評容器管理平臺架構

整體架構上與云計算架構是一致的，自上而下分為業務層、PaaS 層、IaaS 控制層及宿主機資源層。

  • 業務層 ：代表美團點評使用容器的業務線，他們是容器平臺的最終用戶。
  • PaaS 層 ：使用容器平臺的 HTTP API，完成容器的編排、部署、彈性伸縮，監控、服務治理等功能，對上面的業務層通過 HTTP API 或者 Web 的方式提供服務
  • IaaS 控制層 ：提供容器平臺的 API 處理、調度、網絡、用戶鑒權、鏡像倉庫等管理功能，對 PaaS 提供 HTTP API 接口
  • 宿主機資源層 ：Docker 宿主機集群，由多個機房，數百個節點組成。每個節點部署 HostServer，Docker、監控數據采集模塊，Volume 管理模塊，OVS 網絡管理模塊，Cgroup 管理模塊等。容器平臺中的絕大部分組件是基于美團私有云已有組件擴展開發的，例如鏡像倉庫、平臺控制器、HostServer、網絡管理模塊。容器平臺的技術棧，核心組件，包括平臺控制器，網絡服務，調度器等都是自研開發的。Docker 鏡像倉庫基于 Openstack 的 Glance 擴展開發，監控系統有使用 Falcon，CAT；服務治理、服務發現、服務負載均衡是使用的美團自研系統。開發語言主要是 Python 和 Golang。

容器網絡

高性能、高彈性的架構設計

容器平臺在網絡方面復用了美團云網絡基礎架構和組件，邏輯架構設計如圖所示。

(點擊放大圖像)

圖 2. 美團點評容器平臺網絡架構

在數據平面，我們采用萬兆網卡，結合 OVS-DPDK 方案，并進一步優化單流的轉發性能，將幾個 CPU 核綁定給 OVS-DPDK 轉發使用，需要少量的計算資源即可提供萬兆的數據轉發能力。OVS-DPDK 和容器所使用的 CPU 完全隔離，因此也不影響用戶的計算資源。控制平面我們使用 OVS 方案。所謂 OVS 方案是在每個宿主機上部署一個軟件的 Controller，動態接收網絡服務下發的網絡規則，并將規則進一步下發至 OVS 流表，決定是否對某網絡流放行。

自研配置模式 MosBridge

在 MosBridge 之前，我們配置容器網絡使用的是 None 模式。在實踐中，我們發現 None 模式存在一些不足：

  1. 容器剛啟動時是無網絡的，一些業務在啟動前會檢查網絡，導致業務啟動失敗；
  2. 網絡配置與 Docker 脫離，容器重啟后網絡配置丟失；
  3. 網絡配置由 Host-SRV 控制，對于以后網絡功能的升級和擴展帶來很多不便，例如對容器增加虛擬網卡，或者支持 VPC。

為了解決這些問題，我們基于 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 的負擔。

美團自研容器分支：MosDocker

基本介紹

我們從 Docker 1.11 版本開始，自研維護一個分支，我們稱之為 MosDocker。除了一些 Bugfix 之外，MosDocker 還有一些自研的特性。

  1. MosBridge：支持美團云網絡架構的網絡驅動。
  2. Cgroup 持久化：擴展 Docker Update 接口，可以使更多的 cgroup 配置持久化在容器中，保證容器重啟后 cgroup 配置不丟失。
  3. 支持子鏡像的 Docker Save，可以大幅度提高 Docker 鏡像的上傳、下載速度。

MosDocker 的大部分特性是解決美團點評業務場景的需求問題，不適合開源。對于社區的 bugfix，我們會定期 review 并 backport 到我們的 MosDocker 版本里。

原理探究：服務治理與容器編排

(點擊放大圖像)

圖 5：美團點評服務治理平臺

組件：

  • MNS：命名服務
  • SG_agent: 服務治理代理
  • HLB：彈性負載均衡器

功能：

  • 服務命名、注冊、發現
  • 負載均衡
  • 容錯
  • 灰度發布
  • 服務調用數據可視化

(點擊放大圖像)

圖 6：set 容器組設計

設計特性

  • 松耦合
  • 容器組作為一個整體調度、管理
  • 容器之間 CPU、IO 資源隔離
  • 網絡棧，Volume 共享

參考 Kubernetes 的 Pod 設計，針對我們的容器平臺設計實現了 set 容器組。容器組對外呈現一個 IP，內置一個 busybox 作為 infra-container，它不提供任何業務功能，set 的網絡、volume 都配置在 busybox 上，所有其他的容器都和 busybox 共享。

在實際業務中的推廣應用

通過引入 Docker 技術，為業務部門帶來諸多好處，典型的好處有幾點：

  • 快速部署，快速應對業務突發流量由于使用 Docker，業務的機器申請、部署、業務發布一步完成，業務擴容從原來的小時級縮減為秒級，極大地提高了業務的彈性能力。

  • 節省 IT 硬件和運維成本Docker 在計算上效率更高，加之高彈性使得業務部門不必預留大量的資源，節省大量的硬件投資。

    以某業務為例，之前為了應對流量波動和突發流量，預留了 32 臺 8 核 8G 的虛擬機。使用容器彈性方案，即 3 臺容器 + 彈性擴容的方案取代固定 32 臺虛擬機，平均單機 QPS 提升 85%， 平均資源占用率降低 44-56%。

    (點擊放大圖像)

    圖 7. 某業務虛擬機和容器平均單機 QPS

    (點擊放大圖像)

    圖 8 某業務虛擬機和容器資源使用量

  • Docker 在線擴容能力，保障服務不中斷

總結

在容器化過程中，我們發現 Docker 或者容器技術本身存在許多問題和不足，例如，Docker 存在 IO 隔離性不強的問題，無法對 Buffered IO 做限制；偶爾 Docker Daemon 會卡死，無反應的問題；容器內存 OOM 導致容器被刪除，開啟 OOM_kill_disabled 后可能導致宿主機內核崩潰等等問題。因此 Docker 或者容器技術，在我們看來應該和虛擬機是互補的關系，不能指望在所有場景中 Docker 都可以替代虛擬機，因此只有將 Docker 和虛擬機并重，才能滿足用戶的各種場景對云計算的需求。

QA 環節

Q1: 想問下，在美團點評內部的業務系統中，一般應用容器的規格大致是什么范圍，3C 4G 這些？因為有些容器規格分配太大，對于彈性擴縮容，有些影響。導致某些節點存在大量的資源碎片。謝謝

A1:4G 內存的容器還好，我們線上物理機標配是 128G 內存，而且容器的內存只是 cgroup 里的一個設置，實際分配內存還是以容器使用為準。對于一些內存 bound 型業務，內存需要 10G 甚至更多的，我們給這類業務單獨一個物理機集群使用，不和其他業務混部。

Q2：k8s 的優勢所在，Docker 在美團使用情況？

A2：kubernetes 源于 Google 的 Borg 系統，Borg 是一個分布式容器集群管理平臺，在 Google 內部使用 10 多年，承載海量的 Google 線上業務，架構、性能都在業內有廣泛聲譽。Kubernetes 可以看作 Borg 用 Go 語言重寫，和 Borg 一脈相承，所以 Kubernetes 一經推出便廣受業界推崇，現在已經是容器集群管理系統的業界標桿。簡單來說 Kuberenetes 有一下優勢：

  1. 松耦合架構設計：etcd 是 k8s 的元數據存儲中心，使用 RAFT 算法保證數據強一致性，除了支持 POST/PUT/GET/DELETE 之外，還支持 WATCH，是 k8s 的真實之源。apiserver 是無狀態的 API 服務器，是唯一可以和 etcd 通信的組件，所有其他組件都是通過 apiserver 訪問 etcd 的，apiserver 可以水平擴展。Controller-mananger 集成 RC、Deployment 等控制器。Scheduler 是 Pod 的調度器。Kubelet 是 Node 上資源和容器 runtime 的管理器。除 etcd, apiserver 之外，所有組件之間的通信方式都是通過 Watch etcd 交換數據，組件之間不直接通信，這種設計使整個架構徹底松耦合，任何組件都很容易被替換、擴展的。

  2. Pod 容器組支持：Pod 是一個容器組的抽象概念，將一組容器聚合成一個 Pod，作為調度和資源分配的接本單位。Pod 的設計更貼近生成場景對容器的需求，因為實際一個服務都是有多個業務進程組成的，這些進程在 VM 時代一般都放在同一個 VM 內，而在容器時代，最佳方案是一個容器只運行一個進程，而將這些強相關的進程放到不通的容器里，再將這些容器聚合成一個 Pod，是更理想的使用容器的方式。

  3. Kubernetes 不僅是一個物理機 /VM 集群管理系統，或者說不僅是一個 IaaS，它自帶許多容器的編排控制功能，例如 RC，Service。容器時代業界更關心基于容器的編排管理，Kubernetes 考慮了大多數容器生成場景的需求，內置了許多容器編排功能，可以讓用戶開箱即用的方式使用容器自動化部署業務，高效運維。

  4. kubernetes 已經成為業界容器標準之一，社區火熱，版本更新快，因此使用 k8s，在長期的技術支持上，是有比較長期的、穩定的報障。

Q3：容器能否在生產環境實際應用，并保持穩定的性能、不影響業務系統？

A3：

  1. 從技術上說，容器技術有 10 幾年的歷史，Docker 也有 5，6 年的歷史了，容器 /Docker 所依賴的 Linux 內核 Cgroup 和 Namespace 技術，歷史更悠久，因此容器的技術可靠性是完全可以信賴的。

  2. Docker 版本更新較快，版本迭代頻繁，而且 docker 沒有長期穩定版 LTS 的支持，所以在生產場景中使用，難免會踩到 Docker 的 Bug，所以如果要在實際生產環境中大規模使用，需要有對 Docker 本身的維護能力。

  3. Docker 和 VM 相比，虛擬化層次不同，導致 Docker 的隔離性要比 VM 弱，在多租戶環境中有安全隔離的問題，另外在單宿主機上，容器之間的資源競爭也可能導致業務會受到影響，需要對容器的資源隔離，特別是 cgroup 的隔離有較為精細的運維。

Q4：volume 管理都做了哪些工作？特別想知道怎么管理數據的

A4：美團云 Docker 平臺的 Volume 管理經過 3 個階段：

階段 1：本地文件系統做 volume，優點是開發快，缺點是限容、隔離性差，數據可靠性差

階段 2：本地 lvm 磁盤，解決了 volume 隔離性問題，但可靠性仍然不足

階段 3：現階段，我們使用美團云自研的分布式彈性塊存儲服務，相當于 aws 的 EBS，用 ebs 做 volume 存儲后端，完全解決了容量限制，隔離性，可靠性的問題，在 volume 備份、遷移上也有優勢。

Q5：swarm 和 k8s、mesors 哪個更建議生產環境使用？

A5：據我所知，業界大規模使用容器的方案有 k8s 和 Mesos 的，Swarm 早期功能簡單，不能滿足生產所需，不過 Docker 公司對 Swarm 的更新很快，而且 Swarm 和 Docker 是一致的接口，相信以后會有較多的實踐。

Q6: 請問美團后端儲存用的是普通的磁盤，還是儲存陣列，如果是存儲陣列，是如何集成管理的呢？

A6：美團云存儲后端有分布式對象存儲系統，也有分布式塊存儲系統。都是美團云自研的系統。

作者介紹

鄭坤， 2011 年中科院計算所博士畢業，曾在華為從事內核研發工作。2015 年加入美團，負責美團云容器平臺的設計開發，以及在美團點評內部容器化推廣工作。很高興本次分享 Docker 技術在美團點評的實踐情況。

感謝木環對本文的審校。

給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ，@丁曉昀），微信（微信號： InfoQChina ）關注我們。

 

來自：http://www.infoq.com/cn/articles/technology-decryptionof-meitaun-services-review

 

 本文由用戶 pennyz1s44 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！