美团点评业务之技术解密，日均请求数十亿次的容器平台
http://www.infoq.com/cn/articles/technology-decryptionof-meitaun-services-review
本文介紹美團點評的 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 模式存在一些不足：
為了解決這些問題，我們基于 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 還有一些自研的特性。
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 有一下優勢：
松耦合架構設計：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 交換數據，組件之間不直接通信，這種設計使整個架構徹底松耦合，任何組件都很容易被替換、擴展的。
Pod 容器組支持：Pod 是一個容器組的抽象概念，將一組容器聚合成一個 Pod，作為調度和資源分配的接本單位。Pod 的設計更貼近生成場景對容器的需求，因為實際一個服務都是有多個業務進程組成的，這些進程在 VM 時代一般都放在同一個 VM 內，而在容器時代，最佳方案是一個容器只運行一個進程，而將這些強相關的進程放到不通的容器里，再將這些容器聚合成一個 Pod，是更理想的使用容器的方式。
Kubernetes 不僅是一個物理機 /VM 集群管理系統，或者說不僅是一個 IaaS，它自帶許多容器的編排控制功能，例如 RC，Service。容器時代業界更關心基于容器的編排管理，Kubernetes 考慮了大多數容器生成場景的需求，內置了許多容器編排功能，可以讓用戶開箱即用的方式使用容器自動化部署業務，高效運維。
kubernetes 已經成為業界容器標準之一，社區火熱，版本更新快，因此使用 k8s，在長期的技術支持上，是有比較長期的、穩定的報障。
Q3：容器能否在生產環境實際應用，并保持穩定的性能、不影響業務系統？
A3：
從技術上說，容器技術有 10 幾年的歷史，Docker 也有 5，6 年的歷史了，容器 /Docker 所依賴的 Linux 內核 Cgroup 和 Namespace 技術，歷史更悠久，因此容器的技術可靠性是完全可以信賴的。
Docker 版本更新較快，版本迭代頻繁，而且 docker 沒有長期穩定版 LTS 的支持，所以在生產場景中使用，難免會踩到 Docker 的 Bug，所以如果要在實際生產環境中大規模使用，需要有對 Docker 本身的維護能力。
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：美團云存儲后端有分布式對象存儲系統，也有分布式塊存儲系統。都是美團云自研的系統。
轉載于:https://www.cnblogs.com/davidwang456/articles/9251026.html
總結
以上是生活随笔為你收集整理的美团点评业务之技术解密，日均请求数十亿次的容器平台的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 谈服务发现的背景、架构以及落地方案
- 下一篇： 如何设计高可用的微服务架构