Apache Mesos两级调度与细粒度共享：把集群利用率从一半拉到80%

前阵子帮一个团队的调度体系做资源整合，发现一个特别典型的浪费场景：线上API服务白天的CPU和内存占用能到集群的八成，到了夜间常常跌到三成以下；离线批处理任务正好相反，夜幕降临才开始密集跑数。两边明明是一家人，却各自圈了半片机房，谁也不能碰谁的机器，平均算下来集群利用率连一半都不到。后来我们把这些资源收到同一个共享池里，用Apache Mesos做统一调度，才第一次直观感受到“细粒度的资源共享”这七个字到底值多少成本。

Mesos是一个开源的分布式系统内核，核心定位是“调度数据中心里的资源”，理解它的最佳角度是当成一台机房级的操作系统：传统操作系统把CPU、内存按进程切分，Mesos则把整个集群的CPU、内存、磁盘、端口按最小粒度切分，再分配给一个个彼此不相干的分布式框架——Hadoop跑批、Spark做分析、Web服务常驻、自定义调度器跑业务任务，全部共享同一批物理机。这篇文章想讲的，不光是Mesos怎么装起来，更是它两级调度如何运作、细粒度共享为什么能省出大量成本，以及我实际部署过程中踩过的那些坑。

1. 先从“资源利用率为什么上不去”说起

1.1 静态分区带来的双重浪费

很多团队最初的资源分配方式，就是“一亩三分地”：按部门或业务线把机器划开，你的是你的，我的是我的。这种模式管理起来简单，责任边界清晰，但代价是极大的资源冗余。

问题首先在时间维度。凡是真实的业务负载，都有明显的波峰波谷。在线服务的流量集中在白天，夜间则是离线计算的大好时机；报表任务往往在凌晨跑，而开发测试集群的利用率可能整个月都不到一成。静态分区锁死了这种借调的可能，甲集群的量，乙集群再闲也接不了。

问题也出在空间维度。A业务申请了10台机器，实际每台只用到2核；B业务在同一个机房抢不到机器，还要再买新服务器。我把这种模式戏称为“囤地思维”——大家都怕未来不够用，于是拼命把资源圈到自己名下，结果谁也没用满。按行业里常见的统计口径，这类静态分区的平均资源利用率通常在40%到60%之间，但机房电费和设备折旧却按100%在算。

1.2 粗粒度调度解决不了共享问题

如果说静态分区是“机器级别的隔离”，那粗粒度调度也只是往前挪了一小步。早期很多调度系统按“槽位”分配资源，一个任务拿到一个slot，这个slot往往等于一整台机器或固定大小的几个CPU核、一块固定内存。小任务也占一个大槽位的话，剩余资源在任务没结束前是没法再给别人用的，细化粒度仍然很粗。

细粒度共享的思路完全不同。它把资源拆成CPU核数、内存MB数、磁盘MB数这类最小可分配单位，一台物理机同一时间可以混跑多个框架的任务。Mesos里，这条规则贯穿始终：Agent节点上报自己的资源总量，Master把它切分成Offer，框架按需求领取其中的一部分，余量立刻回到池子里，给下一个框架继续分配。

我常用一个大楼来打比方：静态分区等于把楼层直接分给几个公司，谁家白天没人你也借不到；粗粒度调度呢，是允许公司在楼层里按会议室抢位置，但最小单位是一整层，一个人也要占一层；细粒度资源共享是会议室可以按桌子分，三家公司可以在同一层楼办公，桌子之间互不干扰。Mesos做的就是最后这件事。

这里还需要解释一个前提：共享归共享，隔离问题怎么解决？“共享”不代表任务可以互相捣乱，没有隔离机制，A框架的OOM可能拖垮B框架。Mesos本身内置了容器隔离机制，底层依赖cgroups和命名空间，任务跑在容器里，资源限制清晰，你占多少就给你多少，超额就被限制或杀掉。细化到这个程度，才有了“既混部又不互相踩脚”的现实基础。

2. Mesos核心架构拆解

2.1 四个角色各司其职

Mesos的架构在分布式调度领域可以算是教科书级别的简洁，核心角色只有四个：Master、Agent、Framework和ZooKeeper。

Master是整个集群的“资源大脑”，负责掌握所有Agent的资源快照，执行资源分配策略，并且把可用资源主动推送给各个Framework。Agent是部署在每台物理机上的节点代理，定期向Master汇报剩余资源，负责接收任务请求、启动Executor、监督任务运行状态。Framework是使用资源的“客户”，它由两部分组成：Scheduler（调度器）负责跟Master打交道，申请资源、下发任务；Executor（执行器）跑在Agent上，具体执行任务进程。

ZooKeeper的作用是给Master提供高可用能力。一个集群里通常会部署多个Master实例，同一时间只有一个活着，其他处于“待命”状态。一旦活跃Master故障，ZooKeeper负责触发选举，新Master接管集群。Agent和Framework只认ZooKeeper里的那个Master地址，所以切换过程对它们基本透明。

用表格把这个关系收拢一下：

2.2 两级调度：为什么Master不累

Mesos最核心的设计是两级调度。我见过不少刚接触的人，第一反应就是“这不就是单调度器加代理吗”，其实和传统Monolithic Scheduler有本质区别。

传统调度器，经典代表是早期的集中式Hadoop调度器，它自己维护每个任务的状态、排队、资源匹配、失败重试，集群规模一大，调度器本身就成了瓶颈，任何细节故障都可能让整个集群卡住。Mesos把这条链路劈成了两半。

第一级调度发生在Master与Framework之间。Agent上报来的资源，由Master按分配策略打包成Offer，发送给各Framework。这一级只回答一个问题：这块资源给谁。第二级调度发生在Framework内部。Scheduler拿到Offer后，自行决定要不要接受、接受后跑什么任务、任务怎么编排，然后通过自己的Executor在Agent上启动实际进程。这一级完全由Framework自己掌控，Master不参与任务状态的追踪。

这种设计的直接回报是Master的负载很低。它不需要理解“任务”的语义，不需要区分MapReduce和Web服务，只需要维护“资源属于谁、还剩多少”这份账单。也因此，Mesos可以做到毫秒级调度，支撑数百个Framework和数千台Agent的规模。我搭建的测试环境里，从Offer发放到任务启动，体验上是“唰”一下就完成了。

顺着这个思路也能理解，为什么Mesos经常被叫做“分布式系统的内核”。它对框架形态几乎没有限制——你可以给它接入一个批处理框架，也可以接入常驻服务框架，只要实现Scheduler接口，再自带一个Executor，就能成为整个资源池的租户。

3. 细粒度共享的三个关键机制

3.1 Offer机制：资源是怎么“送货上门”的

细粒度共享的落地靠的是Offer机制。Offer的含义可以理解成Master向Framework递过来的一篮子“可领用资源”，里面写着Agent ID、资源数量、资源类型。Master每隔一定周期，把所有Agent的资源汇总起来，按分配策略打包成Offer，依次发给各个Framework。Framework有两条路可走：接受Offer并启动任务；或者拒绝Offer，把资源放回池子里再分给别人。

一个Offer的JSON形态大致长这样：

{ "id": "offer-id-001", "agent_id": "agent-001", "hostname": "node1", "resources": [ { "name": "cpus", "type": "SCALAR", "scalar": { "value": 4.0 } }, { "name": "mem", "type": "SCALAR", "scalar": { "value": 8192 } }, { "name": "ports", "type": "RANGES", "ranges": [ { "begin": 31000, "end": 32000 } ] } ] }

注意，这个机制的关键点在于“按需领取，余量回收”。一个框架只取它需要的2核4G，剩下的资源会继续被Master封装成新的Offer发给别的框架，Agent上同一时刻就会有多个框架的任务并存。我见过很多资源调度器在“抢占式回收”上做得非常暴烈，而Mesos这种“一次只授权一部分”的方式，可以称得上温和且精确。

还有几个容易被忽略的行为细节。第一，Framework如果连续多次拒绝Offer，Master会调整给它的分配权重，避免它被反复供给不需要的资源而“堵死”其他框架；第二，Offer是有时效的，约定期限内没有被接受，Master会撤销并重新分配。生产中经常碰到一个问题，某个框架的Scheduler进程卡住，Offer在它手里积压，其他框架等不到资源，这在第6章会提到排查思路。

3.2 DRF算法：多框架公平的尺子

细粒度共享有一个绕不开的问题：多个框架挤在同一个池子里，怎么定义“公平”？如果按平均分资源，计算密集型的框架会觉得委屈，因为内存它根本用不上；如果按CPU为主分配，内存密集型的框架就吃大亏。Mesos默认采用的主导资源公平算法DRF解决了这个争议。

DRF的核心思想不复杂：一个框架刚获得了集群总量中一定比例的CPU、一定比例的内存、一定比例的磁盘，取其中占比最高的资源，叫作“主导资源”。调度时优先满足主导资源占比较低的框架，让各个框架的主导资源占用率逐渐拉平。

举个直观的例子。假设集群总资源是16核CPU、64GB内存。框架A跑的活偏计算，一个任务要2核、1GB内存；框架B偏内存，一个任务要0.5核、4GB内存。如果只按CPU平均，框架B每个任务拿到的CPU比例是3.1%，但它每个任务占掉的内存高达6.25%，显然对内存池不友好。DRF的做法是，起点相等时先给分工明确的框架逐步让位，直到两边的主导资源占比对齐，再继续按比例增长。这种算法对异构框架混部特别友好，你吃CPU我吃内存，天然不容易打架。

DRF之下还有配额和权重可调。如果某个框架长期饥饿，管理员可以给它设置资源配额或调高资源权重，让它在竞争中得到更大比例。生产环境里，我通常会把“生产在线服务”这类必须优先保障的角色配上配额，把开发测试类框架置于无配额、随缘竞争的状态。

3.3 细粒度共享的收益边界

细粒度共享不是银弹，它的收益有一个明确的边界。物理机资源是碎片化的，资源切得越细，理论上利用率越高，但调度算法的计算量也在上升；框架越多，Master要提供的Offer越多，网络和内存开销都随之增加。另外，如果任务之间对磁盘、端口等资源有强依赖，并不意味着“细一点就能共享”。

所以，真正做混部的时候要控制两个变量：一是单机上同时跑的框架数量不宜过多，我自己的经验是同一个Agent上三到五个框架以内，调度行为还比较容易掌控；二是要预设配额和抢占规则，防止个别业务把整池资源吃干榨净。很多团队把Mesos用过一阵子后又退回到静态分区，往往不是因为Mesos不行，而是没有提前定义好公平策略，混部反而带来了服务质量的剧烈波动。

4. 从零部署一套可用的Mesos集群

4.1 环境规划与版本选型

开始动手之前，先说说环境规划。Mesos对机器本身的要求并不高，比较标准的入门配置是三台节点：一台Master加两台Agent。Master节点建议至少2核4GB内存，Agent节点根据实际负载配4核8GB或以上。生产环境里Master一般要跑奇数个节点配合ZooKeeper选举，比如3个Master，测试环境单Master也能起步。

版本方面，我用的是Mesos 1.11系列，搭配ZooKeeper 3.4/3.5都可以。操作系统我习惯用Ubuntu 20.04，官方提供的二进制包安装路径比较省心；CentOS 7也能装，但版本老、依赖多，踩坑的概率大一些。如果你是第一次摸Mesos，不推荐直接源码编译，全套编译一等就是半小时起步，而且中间缺这个依赖缺那个头文件，实在劝退。

4.2 安装与启动Master和Agent

二进制包安装的过程很简单，把官方仓库的地址配到系统源里，然后拉包、装依赖。以下是我常用的安装流程示意，仓库地址要根据你选的发行版替换成对应官方源：

# Ubuntu / Debian apt-get update apt-get install -y mesos # CentOS / RHEL yum install -y mesos

装完之后，先别急着启动，把路径和参数理顺。Master启动需要指定工作目录、ZooKeeper地址、法定数Quorum；Agent启动需要指定Master地址、工作目录、容器类型、资源参数。这两条命令是关键，直接决定集群能不能正常join：

# 在Master节点执行 mesos-master \ --work_dir=/var/lib/mesos \ --quorum=1 \ --zk=zk://node1:2181/mesos \ --port=5050 # 在Agent节点执行 mesos-agent \ --master=zk://node1:2181/mesos \ --work_dir=/var/lib/mesos \ --containerizers=mesos,docker \ --resources='cpus:8;mem:16384;disk:40960'

启动完成后，访问Master节点的5050端口，就能看到Web UI。正常状态下，左侧面板会显示当前有多少Agent已注册、每个Agent上报的资源总量和已分配量。看到“Agent已连接”这个状态，说明集群基本活了。如果Agent一直显示DISCONNECTED，优先检查ZooKeeper路径是否一致、防火墙是否放行5051端号。

4.3 用两个框架验证细粒度共享

集群只是空转没有意义，我用两个框架做了一次共享验证。第一步，先启动一个最简单的常驻服务框架，这个框架申请1核、512MB内存跑一个sleep任务；第二步，再启动一个批处理任务模拟框架，让它申请3核、4GB内存跑一段模拟计算。两个框架注册到同一个Master之后，我在Web UI上看到的现象是：第二台Agent上同时出现了两个框架的任务，各自占用自己的份额，谁也没有独占。

这个看上去平平无奇的画面，正是Mesos的核心价值所在：一台8核16GB的机器，可以同时跑线上服务、跑批处理、跑测试任务。对第一次体验Mesos的人来说，亲眼看到两个不同框架的任务在同一台机器上和平共处，比读十篇架构分析都更有体会。

5. 自定义框架接入与核心流程

5.1 写一个最简单的Scheduler

部署好集群之后，多数人都想跑自己的任务，这就得写一个Framework。写Framework的门槛其实不高，核心工作是实现Scheduler的回调函数。为了把逻辑讲清楚，我用一段伪代码风格示例展示最核心的流程：

class SimpleScheduler: def registered(self, driver, framework_id, master_info): print("framework registered:", framework_id) def resourceOffers(self, driver, offers): # 每个offer代表Master推荐的一份可领用资源 for offer in offers: if enough(offer, cpus=1, mem=1024): task = build_task( offer, cpus=1, mem=1024, command="sleep 300" ) # 接受offer并执行任务 driver.launchTasks(offer.id, [task]) else: # 不合适就拒绝，资源会被Master重新分配 driver.declineOffer(offer.id) def statusUpdate(self, driver, status): print("task status:", status.state)

流程拆开来就是四步：框架启动时向Master注册，Master回调registered；随后Master不断推送resourceOffers，框架在回调里决定接受还是拒绝；启动任务时用launchTasks下发TaskInfo，把任务描述、所需资源、执行命令全部打包进去；最后Agent上的Executor执行任务，并通过statusUpdate回调把状态实时回报给Scheduler。

这里需要特别提醒：Offer是“一次性消费”，一个Offer里描述的资源只能用于本次launchTasks调用。你必须在一个Offer内完成资源匹配，而不能指望把两个Offer拼在一起凑出足够内存——这是新手最容易踩的认知误区。

5.2 Executor是怎么把任务拉起来的

Framework的另一半是Executor。理解Executor，可以把它想成“任务的搬运工和监护人”。Scheduler在Master那头做决策，Executor在Agent这边干实事：接收TaskInfo、启动进程、监控状态、上报结果。

Mesos提供了一个默认的纯命令执行器：你给它一条shell命令，它就把命令跑起来。做实验、跑离线任务时用默认的就行，简单直接。但如果你的任务需要长时间常驻、需要管理多个子进程、需要动态调整资源，那就需要自定义Executor。自定义Executor的本质是你自己实现一个常驻进程，Mesos把任务信息交到它手里，由它来创建和管控实际业务进程。

理解这条链路，才知道两级调度的“第二级”藏在哪：Master把资源授权出去就不再干预，真正把任务跑成什么样子，是Framework自己负责的。这意味着Mesos的灵活度极高，但责任也全部转移给Framework的Scheduler和Executor了。

6. 运营半年后，我踩过的那些坑

6.1 进程卡死与Offer堆积

第一个坑，是某个数据处理的Scheduler在接收大量Offer后发生了内存泄漏，导致进程僵死。Master仍然按周期给它推送Offer，它却既不接受也不拒绝，资源在它那边形成“僵尸囤积”，其他框架越等越饿。查了很久才在Master日志里发现，分配模块发给它的Offer数量异常偏高。

这个问题的表面诱因是框架的Bug，根因是Mesos没有自动“踢掉”僵死框架的机制。解决方式有两层：第一，给Scheduler进程加内存监控和自动重启；第二，调小Master的--offer_timeout和--allocation_interval参数，让未及时处理的Offer更快被系统回收，减小僵尸攒积的时间窗口。

6.2 资源字符串与计量单位错配

第二个坑非常低级但极其常见：Agent的--resources参数里，CPU、内存、磁盘的单位和格式必须严格匹配Mesos的SCALAR类型解析器。我一开始直接写了mem:8GB，结果Agent启动时报资源解析错误，集群根本看不到这台机器。Mesos只认浮点数，单位要用MB或者换算后的数值，正确写法是mem:8192。

后来我在团队内部定了一条规矩：所有Agent节点的--resources参数都由统一的配置管理工具生成，不允许手写。人一旦手写，早晚会写出2Core、16G这种不合法写法，排查起来非常费劲。

6.3 内存限制导致的神秘OOM

第三个坑，和容器隔离相关。我给一个任务分配了2GB内存，设置容器限制为2GB，结果任务在高峰期频繁被“杀”。看日志找不到业务异常，看Agent日志才发现是cgroup OOM Kill。问题在于，任务的实际峰值内存是2.6GB，我按业务代码的估算值申请了2GB，容器果断把它杀掉。

这类问题的排查口诀是：容器OOM不一定代表业务代码有问题，先查申请值和实际峰值的差值。生产环境我一般会给任务申请值加20%到30%的余量，而不是卡着资源下限去定。

6.4 常见问题速查表

6.5 混部上线的一条稳妥路径

最后分享一个上线路径的建议。很多团队一上来就追求“大而全”，想把所有框架一次性接入Mesos，结果调度逻辑、配额策略、故障恢复全部没验证过，线上直接翻车。我的经验是分三步走。

第一步，只接入一个非核心的批处理框架，跑通Offer、任务状态、失败重试的完整链路。第二步，再把一个常驻服务框架接进去，确认两种不同形态的任务能共享同一批Agent，观察资源利用率的真实提升。第三步，确认稳定后，再逐步把其他业务迁入，并为每个框架按业务重要性设置配额。

调度系统最怕的不是资源不够，而是框架之间互相干扰且没人看到。如果你在控制面板上发现某个框架的任务状态批量异常，先不要急着改调度参数，优先排查它自己的Scheduler和Executor，绝大多数问题都出在框架侧。

最后说几句心里话

Mesos在今天已经不是热度最高的技术名词了，但它对“资源调度”这件事的思考方式，我仍然觉得非常值得借鉴。两级调度把Master做得极其轻巧，Offer机制让资源共享变得像领取购物车一样自然，DRF给异构框架提供了公平竞争的规则——这些都是跨时代的设计。如果你们团队有混部需求，或者你想理解Kubernetes之外的调度思路，亲手搭一套Mesos集群、接入一两个框架，观察资源利用率的变化，收获会比读任何文档都大。我个人在实际操作里最深的体会是：调度器的价值不在于它分配得有多精确，而在于它让“共享”这件事在技术和管理上都变得不再令人恐惧。从一台机器一个任务，到一台机器混跑多个任务，背后不只是一行配置的改动，而是一整套资源观的重构。