兼职的 ScrumMaster 的确会出现很多问题。很难跳出自己的 “经验” 去思考问题。

是不是你的参数设置的不正确？

Mesos 实战总结 张包峰 http://blog.csdn.net/pelick/article/details/21236837

背景 我们使用 Mesos 也有一段时间了，目前有两个项目使用 Mesos 作为底层资源管理系统，各自部了一套集群。这中间对比 Mesos 的论文和源码实现，到底哪些功能实现了，哪些功能未实现，版本是否稳定，使用是否顺畅，有哪些坑会遇到等等这些问题，同组的同事们都遇到了不少。大致总结一下使用过程中的感受吧。

Mesos 使用方式 Mesos Master 在给 framework 分配资源的时候采用的是多资源下的最大最小公平算法，即 DRF 算法，对于 Mesos 的第一层调度来说，使用方实现的 Scheduler 应该实现自己的调度策略和资源分配策略，Mesos Master 对所有的 framework 一视同仁，尽量为各个 framework 的资源分配做到” 公平”。对于这一点，我们在使用 Mesos 实现 Scheduler 的时候，有两种使用方式。

第一种，项目 Q 会起一个 long-running 的 framework，作为 QMaster，负责接收业务系统发来的任务请求。这个情况下，QMaster 接收整个 Mesos 集群的机器的所有资源，任何一种请求任务都会被调度到某台 Mesos Slave 上的 Executor 执行，完了之后把资源返还给 Mesos 集群，从而在 QMaster 处再次 resourceOffer 的时候再接收到。这种场景下，QMaster 内部需要维护很多内容，比如不同用户请求来的任务需要队列管理，队列和队列之间的优先级、session 管理、调度策略等都需要 QMaster 内部维护。

第二种，项目 D 也会起一个 long-running 的 DMaster Framework，负责接收业务系统发来的任务请求。针对不同请求，DMaster 会起新的 DEngine 来管理这一次任务，而 DEngine 本身也是一个 Framework，实现了 Mesos Scheduler，DEngine 根据自己获得的资源，会选择 Slave 起 Executor 做任务的执行，并且这次任务的监控和执行情况由 DEngine 管理，所有的 DEngine 的生命周期、资源等是由 DMaster 掌控的。DMaster 也需要维护 DEngine 的管理。

其实两种使用方式本质上是一样的，我们在使用 Mesos 的时候，在 Mesos 的第二层也实现了双层调度。只是第一种使用方式中，把我们的第二层都维护在了同一个 Framework 下面，把一些元数据写到了 zk 上，帮助容错。而第二种使用方式会产生很多 Framework，但是从结构上来说比较清晰一些，比较适用于任务本身比较重的情况，相比较之下，第一种使用方式还是比较轻量级的。

Mesos 优点 使用下来，感觉 Mesos 的轻量级使用蛮好用的。Executor 和 Scheduler 之间的简单通信，通过 frameworkMessage 这样的接口传输一些消息还是比较方便的。如果 Executor Lost 了，Schedule 能够接收到事件并尝试重启；如果 Executor 出异常后上报给了 Scheduler，Scheduler 就可以 killTask 掉该 Executor；如果 Executor 正常结束，使用 driver.sendStatusUpdate() 更新状态，并最后显示 driver.stop() 关闭，可以看到 Executor 正常 Finish 完成任务。以上这些管理和调度可以依赖 Mesos 轻量级地实现，并且 Mesos 对机器资源的使用情况有监控作用，分配任务的时候增加一些自己的调度策略，负载均衡也是很好实现的。

Mesos 不足 Mesos 对每种 Framework 的分配策略限定在 DRF 算法，没有 YARN 丰富，这点其实倒也不算是不足。Mesos 目前比较大的问题是一套 Mesos 集群只适合一种计算框架，多套计算框架在一套 Mesos 集群上使用，无法做到框架之间的资源隔离。对于 Mesos 来说，为不同业务模块 Framework 分配资源这件事情是不区分的，Scheduler 在接收到 CPU 和 MEM 的时候，可以根据机器信息使用 Scheduler 的 offerRescinded 接口拒绝分配来的资源，理论上能做到一定的过滤，但是被拒绝掉的资源不会实时在这次资源分配中再次分配出去，而是会在下次资源分配触发的时候再分发出去，而且分配的资源的机器属性也是不能控制的。综上，Mesos 没有提供多框架之间的隔离、分组能力，我们使用的时候只能给多个应用部署多套 Mesos 集群。

Mesos 和 YARN Mesos 和 YARN 是双层调度系统的代表。Mesos 早于 YARN 诞生，是 C 实现的。两者在底层 CPU 的隔离上都使用了 cgroup。但是对于内存资源，为了能够更灵活的控制内存使用量，YARN 采用了进程监控的方案控制内存。 在资源分配模型方面，在 YARN 中，用户以队列的形式组织，每个用户可属于一个或多个队列，且只能向这些队列中提交 application。每个队列被划分了一定比例的资源。而 Mesos 的资源分配模型应该是很简单的，对于 CPU 和内存也没有 YARN 那些的虚拟使用方式，往往资源也会白白浪费掉，而且不太好预估。 在资源保证机制方面，YARN 采用的是增量资源分配机制，优先为应用程序预留一个节点上的资源，优点是不会发生饿死现象，但有一定的浪费。Mesos 使用的是 All or nothing 的模式，可能会造成作业饿死（大资源的作业长时间无法得到满足）。

资源调度系统发展 Google 新的 Omega 应该是在开发中，论文参见。。。，Mesos 的作者 Andy 也在参与 Omega 的开发。从 Hadoop v1 的 JobTracker，到 Mesos 和 YARN，再到 Omega，资源管理系统经历了三代的演变。Omega 的简单介绍可以参考董的解析 Google 集群资源管理系统 Omega，以下我从他的文章里摘抄几点： 中央式调度器： 资源的调度和作业的管理功能全部放到一个进程中完成，典型的代表是 Hadoop JobTracker。这种设计方式的缺点是扩展性差：首先，集群规模受限，其次，新的调度策略难以融入现有代码中，比如之前仅支持 MapReduce 作业，现在要支持流式作业，而将流式作业的调度策略嵌入到中央式调度器中是一项很难的工作。

双层调度器： 各个框架调度器并不知道整个集群资源使用情况，只是被动的接收资源； Master 仅将可用的资源推送给各个框架，而框架自己选择使用还是拒绝这些资源；一旦框架（比如 Hadoop JobTracker）接收到新资源后，再进一步将资源分配给其内部的各个应用程序（各个 MapReduce 作业），进而实现双层调度。 双层调度器有两个缺点，其一，各个框架无法知道整个集群的实时资源使用情况；其二，采用悲观锁，并发粒度小。

共享状态调度器： 为了克服双层调度器的以上两个缺点，Google 开发了下一代资源管理系统 Omega，Omega 是一种基于共享状态的调度器，该调度器将双层调度器中的集中式资源调度模块简化成了一些持久化的共享数据（状态）和针对这些数据的验证代码，而这里的 “共享数据” 实际上就是整个集群的实时资源使用信息。一旦引入共享数据后，共享数据的并发访问方式就成为该系统设计的核心，而 Omega 则采用了传统数据库中基于多版本的并发访问控制方式（也称为 “乐观锁”, MVCC, Multi-Version Concurrency Control），这大大提升了 Omega 的并发性。

参考 DRF 算法 解析 Google 集群资源管理系统 Omega

2.2. Docker 镜像（image）

2.2.1. Docker 镜像

Docker 镜像是 Docker 系统中的构建模块（Build Component），是启动一个 Docker 容器的基础。

我们可以通过一个官方提供的示意图来帮助我们来理解一下镜像的概念。

[attach] 2435[/attach]

Docker 镜像位于 bootfs 之上，实际上 bootfs 在系统启动后会被卸载的。Docker 镜像（Images）是分层的，这得益于其采用的联合文件系统，前面我们已经介绍过了。镜像是有继承（父子）关系的，每一层镜像的下面一层称为父镜像，没有父镜像的称为基础镜像（Base Iamge，其实叫做 Root Image 可能更确切，不过这可能容易和 rootfs 混淆）。

2.2.2. 镜像仓库

我们可以将 Docker 镜像仓库理解为 Git 仓库。Dcoker 镜像仓库分为远程和本地，本地的概念好理解，而一般来说远程仓库就是 Registry，包括官方的或者自建的私有 Registry；我们通过 docker pull 和 docker push 命令在本地和远程之间进行镜像传输。

Docker 镜像的命名规则和 GitHub 也很像。比如我们自己创建的仓库名称都是类似 liubin/redis 这样格式的，前面的 liubin 是用户名或 namespace，后面是仓库名。

不过我们前面已经看到运行的 ubuntu 镜像的时候是仓库名就是 ubuntu，而不带用户名前缀，这是表明它是由官方制作的，或者由官方认可的第三方制作的镜像。我们可以认为官方仓库提供的镜像都是安全的、最新的，所以也可以放心使用。

2.3. Docker 容器（Container）

容器是一个基于 Docker 镜像创建、包含为了运行某一特定程序的所有需要的 OS、软件、配置文件和数据，是一个可移植的运行单元。在宿主机来看，它只不过是一个简单的用户进程而已。

容器启动的时候，Docker 会在镜像最上层挂载一个 read-write 的文件系统，即上图中标记为 writable 的 Container 层，容器将跑在这个文件系统上。这层可写的文件系统是容器中才有的概念，如果我们对此容器进行 commit 操作，那么该层文件系统则会被提交为一个新的只读的镜像层，并位于镜像层的最上面的。

我们可以认为 Docker 镜像是 “静” 的".exe"文件，只在 “硬盘” 上；而容器是 “动” 的，是在 “内存中” 的，要想启动一个容器，需要先把".exe"装载到内存。

镜像和容器具有如下的转换关系：

镜像 -> docker run -> 容器 容器 -> docker commit -> 镜像 有时候我们经常会将两个名称混用，不过这并不会影响我们的理解。

2.4. Docker Registry

Docker Registry 是 Docker 架构中的分发模块，它用来存储 Docker 镜像，我们可以将它理解为 GitHub。

Docker Hub 是一个官方的 Docker Registry，也是 Docker 镜像的默认存储位置。

当然从安全管理的角度上来说，我们可能更愿意在自己公司内部托管一个私有的 Docker Registry，这可以通过使用 Docker 官方提供的 Registry 注 5 软件实现。

注 5 Docker Registry https://github.com/dotcloud/docker-registry

运行私有 Registry 非常简单，这也是一个典型的 Docker 风格的应用发布例子。

docker run –p 5000:5000 registry

1. Docker 架构解析 2.1. Docker 整体结构

Docker 是一个构建、发布、运行分布式应用的平台（见下图），Docker 平台由 Docker Engine（运行环境 + 打包工具）、Docker Hub（API + 生态系统）两部分组成。

[attach] 2434[/attach]

从图中我们可以看到，Docker 的底层是各种 Linux OS 以及云计算基础设施，而上层则是各种应用程序和管理工具，每层之间都是通过 API 来通信的。

Docker 引擎

Docker 引擎是一组开源软件，位于 Docker 平台的核心位置。它提供了容器运行时以及打包、管理等工具。

Docker 引擎可以直观理解为就是在某一台机器上运行的 Docker 程序，实际上它是一个 C/S 结构的软件，有一个后台守护进程在运行，每次我们运行 docker 命令的时候实际上都是通过 RESTful Remote API 来和守护进程进行交互的，即使是在同一台机器上也是如此。

Docker Hub

Docker Hub 是一个云端的分布式应用服务，它专注于内容、协作和工作流。Docker Hub 除了可以托管、下载、查找 Docker 镜像之外，还提供了包括更管理、团队协作、生命周期流程自动化等功能，以及对第三方工具和服务的集成。

[i=s] 本帖最后由 laofo 于 2014-8-22 15:30 编辑

1.3.5. 联合文件系统

联合文件系统是一个分层的轻量、高性能文件系统。Docker 之所以这么吸引人，很大程度上在于其在镜像管理上所做出的创新。而联合文件系统正是构建 Docker 镜像的基础。

AUFS（AnotherUnionFS）是一个分层的基于 Copy On Write 技术的文件系统，支持 Union Mount，就是将具有不同文件夹结构的镜像层进行叠加挂载，让它们看上去就像是一个文件系统那样。

1.4. 容器技术 VS 虚拟机技术

容器技术和 Hypervisor 技术虽然不属于同一层次的概念，但是作为具有计算能力的应用运行载体来说，它们还是有一定的共通性和竞争关系，这里作此对比完全是为了加深读者对容器技术的理解而已。

[attach] 2432[/attach]

比如开源 PaaS 实现软件 tsuru 最初使用的是基于虚拟机的技术，创建一个应用程序需要 5 分钟左右的时间，而在采用 Docker 之后，已经将这个时间缩短到了 10 秒钟了注 3。

注 3 tsuru and docker by Andrews Medina https://speakerdeck.com/andrewsmedina/tsuru-and-docker

1.5. 我们能用 Docker 干什么？

Docker 可以应用在各种场景下，比如公司内部开发测试使用，或者作为共有或者私有 PaaS 平台等。

现在 PaaS 平台的发展已经非常成熟了，这里我们只罗列一些在开发中使用 Docker 技术可能会给我们带来的益处。

1.5.1 在开发中

构建开发环境变得简单

简单包括几个方面的意思

[list=1] [] 快速：只需 docker run 即可 [] 共享：通过 Dockerfile 或者 Registry [] 自动化：一切代码化的东西都可以自动化 [] 统一：每个人的开发环境都是一模一样的 [/list] 设想我们要基于 Nginx/PHP、MySQL 和 Redis 开发，我们可以创建 3 个 Docker 镜像保存到公司私有的 Registry 中去，每个开发人员使用的时候是需要执行 docker run redis 即可以享用自己独有的 Redis 服务了，而且这 3 个容器不管从占用磁盘空间还是运行性能来说，都比虚拟机要好很多。

1.5.2. 在测试中

解决环境构建问题

有时候构建测试的环境是一项费时费力的工作，而 Docker 能让这变得轻松。如果你的测试比较简单的话，甚至直接拿开发构建的镜像就可以开始了。

消除环境不一致导致的问题

“在我的机器上运行的好好的，怎么到你那里就不行了？”，我想超过半数的程序员都曾经说过类似的话。如果对导致这一问题的原因进行统计的话，我想排在第一位的应该非 “环境不一致” 莫属了，这包括操作系统和软件的版本、环境变量、文件路径等。

使用 Docker 的话你再也不用为此烦恼了。因为你交付的东西不光是你的代码、配置文件、数据库定义，还包括你的应用程序运行的环境：OS 加上各种中间件、类库 + 你的应用程序。

1.5.3. 部署和运维

基于容器的部署和自动化

Docker 定义了重新打包程序的方法。

Docker 容器 + 用户应用 = 部署单位（构件）

Docker 可以看作是用代码编写出来的国际集装箱，它可以把任何应用及相关依赖项打包成一个轻量、可移植（Portable）、自包涵的容器。

以前部署代码都是代码级别的，有了 Docker，则可以进行容器级别的部署。这样带来的最大的好处就是开发者本地测试、CI 服务器测试、测试人员测试，以及生产环境运行的都可以是同一个 Docker 镜像。

快速进行横向扩展

Docker 容器的启动速度很快，可以瞬间启动大量容器，所以在非常适合在业务高峰期进行横向扩展。这比传统的启动 EC2 实例或者物理机可要快多了。

天生的和云计算技术相结合

当然，由于 Docker 具有很好的移植性，所以它更强大的地方还在于和云环境结合使用。

Docker 容器是可移植，或者说跨平台。将来的应用部署可能是在本地进行打包（成 Docker 镜像）然后传送到云端运行，至于是 AWS 还是 GCE 这不是问题，Docker 都能在其上运行。这样不仅能在一定程度上解决 vendor-lockin 的问题，同时也使得在不同的云服务提供商之间迁移也变得简单。尤其是未来在使用多云（multi-cloud）环境的时候，这将非常便利。

笔者认为基于 IaaS + 容器技术的应用交付、部署方式将来一定会成为一种流行的方式。

进行 Blue-green 部署

「Blue-green deployment」这个词最初出现在《Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation 》一书，后经 ThoughtWorks 的 Martin Fowler 发扬光大注 4。

注 4 http://martinfowler.com/bliki/BlueGreenDeployment.html [attach] 2433[/attach] Blue-green deployment 方法其实很简单，就是保持两套一样的生产环境，而实际上只有一套环境真正的对外提供服务（图中绿色环境），而另一套环境则处于待机状态（图中蓝色）。部署的时候，我们会先上线到蓝色环境中，如果测试没有问题了，再将路由切换到新的服务上。

Blue-green 部署能带来如下好处。 [list=1] [] 最小化停机时间 [] 快速回滚 [*] hot standby [/list] 而未来的开发和部署和可能就会像下面这样进行了。

① 开发人员将代码 push 到 Git 仓库 ② CI 工具通过 webhook 得到最新代码，构建 Docker 镜像并启动容器进行测试。 ③ 测试通过后将镜像打标签后 push 到私有镜像 Registry ④ CI 工具通知 CD 工具 ⑤ CD 工具通过 Mesos/Marathon 等进行基于容器的部署 ⑥ 测试没有问题后进行容器的切换（即 Blue-green 切换）

说得我也想去杭州 NSN 了，呵呵

[i=s] 本帖最后由 laofo 于 2014-8-22 13:31 编辑

Mesos 渐入主流，Twitter 模式有望 “无限复制”

云计算到底是什么，有哪些功能？在经过多年的迷茫之后， Mesosphere 可能就是你要找的答案。该公司的愿景是让应用程序和服务易发布、易扩展，同时资源易获取。这是一种 Google 和 Facebook 数据中心的自动化服务器管理技术，或者更准确地说，在 Twitter 公司。 Mesosphere 在 Mesos 商业化的早期阶段，是由加州大学伯克利分校的 AMPLab 首先开发的一款开源资源管理系统，现在是一个 Apache 软件基金会的项目，[b][color=Red] 其最大用户有 Twitter 和 Airbnb [/b]，他们用它来实现和谷歌类似的数据中心自动化，谷歌是通过自己声名远扬的 Borg 系统建造的。这些公司可以随时推出新的应用程序而忽略崩溃的服务器。 这是因为在 Mesos，资源都是一个大共享池的一部分，系统被设计用来确保服务的可获取性。如果服务器崩溃了，系统管理员不需要在半夜醒来处理。开发人员也不必关心构建高可用性应用程序的复杂性。如果一台服务器发生故障，它的工作负载可以自动迁移到别的地方。

Florian Leibert 走进 Mesosphere 现在，Mesosphere 正试图将 Mesos 打造成主流的群集管理软件。它提高了从风险投资公司 Andreessen Horowitz， Kleiner Perkins， Foundation Capital， Data Collective 以及 Fuel Capital 的种子资金。公司的创始人兼首席执行官、前 Twitter 和 Airbnb 工程师 Florian Leibert 形容 Mesosphere 的技术为 “通向未来分布式应用程序的路。” 除了 Mesos，Mesosphere 堆栈的另外两个关键组件是 Chronos 和 Marathon。我们之前讨论了（2013 年 9 月 Mesosphere 开源 Marathonin），可简单解释为：Chronos 是一个在 Mesos 上运行和管理计划任务的框架，比如 Hadoop 任务。Marathon 是一个用于启动长时间运行应用程序和服务（包括 Chronos 或者 Mesos 实例）的框架。 Leibert 在最近在旧金山的公司总部的一次采访中解释道： Marathon 就像 PaaS……在 Mesos 上，作为一个整体——Mesos API，Chronos 和 Marathon——Mesosphere 将允许企业建立自己的 Heroku。 [attach] 2429[/attach] Mesosphere 堆栈 Leibert 说，营销软件初创公司 HubSpot 在去年夏末开始使用 Mesos，而且已经在上面运行约 200 个不同的服务，许多用户可使用它运行流行的大数据框架和服务，比如 Hadoop、ElasticSearch、Spark、Storm 和 Kafka。Airbnb 在 Mesos 上运行 Facebook 建立的 SQL-on-Hadoop 查询引擎 Presto。在 2 月中旬，Mesosphere 发布 Mesos 上 Cassandra 数据库集群教程。 一个全新的云？ 但直到公司发布商业版软件，Leibert 说 Mesosphere 的目标是发展 Mesos 社区（偶尔对大用户提供商业支持）。如果有足够多的公司开始使用 Mesos 管理自己的服务器池或集群，这将在 IT 领域产生重大的影响，包括帮助企业重新考虑云计算是如何实现的。 在这个从服务到客户都是分布式的时代，传统的应用程序架构越来越不合时宜。例如，像 VMware 这样的公司的服务器虚拟化被证明是一个非常成功的技术，但不是一个变革。你可以把更多的应用程序填满到单一服务器，但是像 Google 数据中心虚拟化管理工具并不容易使用，通常也不便宜，当然设计时没有考虑到下一代的软件。 在公有云，用户和分析师一直在呼吁提高可移植性，因为 Mesos 用户针对 Mesos API 编程，他们可以跨任何 Linux 节点池运行——物理服务器、虚拟机或云实例。以 Airbnb 公司为例，其业务运行在 AWS 上，但是无论是更换云供应商还是迁移业务到内部，它们的体验是一样的，因为 Mesos 和 Marathon 可以在它运行的任何地方启动服务和管理。 [attach] 2430[/attach] Rails 在 Marathon 运行的截图 Mesosphere 已经创建了一个免费的工具 Elastic Mesos ，人们可以在亚马逊云上使用它。Leibert 说，因为切换到 Mesos 以及提高资源利用率，HubSpot 已经削减高达 50%（不超过 50%）的月度 AWS 费用。 当人们谈论像谷歌或 Facebook 一样运行，他们主要谈论这样的自动化和效率。Mesos 采用 Google、Facebook 等大型网络公司更喜欢的开源硬件设计看起来能更好地帮助企业。 挑战 虽然 Mesos 的势头迅猛，但 Mesopshere 面临更艰巨的任务，可能最终不得不说服一些公司为商业软件和支持支付费用，更令人担忧的是能否让主流企业确信他们真的和谷歌一样有效运行。 其他公司过去十年也曾做过类似的尝试，但 Mesosphere 有开源的支持。NoSQL、Hadoop、Linux、Xen 和 KVM 的成功之后，在其他项目中，开源软件现在如日中天，也许这足以实现自动化的梦想。 原文链接： Mesosphere thinks everyone’s servers should run like Twitter’s do, an it’s here to help

重新认识 Mesos 的设计架构

自董的博客 本文链接地址: http://dongxicheng.org/apache-mesos/study-mesos-architecture-in-deep/

Mesos 中包含四类主要的服务（实际上是一个 socket server），它们分别是 Mesos Master，Mesos Slave，SchedulerProcess 和 ExecutorProcess，它们之间通过 Protocal Buffer 消息进行通信，每种服务内部注册了若干种 Protocal Buffer 消息处理器，一旦收到某种消息，则会调用相应的消息处理器进行处理。除了以上四种服务之外，Mesos 还对外提供了三种可编程组件，分别是 Alloctor、Framework Scheduler 和 Framework Executor，编写这几个组件必须按照要求实现了几个接口，而这些接口将分别被下图中相邻的服务调用。 [attach] 2427[/attach] 大部分人看到以上 Mesos 架构后，均会认为 Framework 必须是一个通用的框架，比如 MapReduce、Storm、Spark 等，而 Mesos Master 负责将资源分配给各个框架，而各个框架的 Scheduler 进一步将资源分配给其内部的各个应用程序。这种观念是错误的，是对 Mesos 架构的一种错误解读。 事实上，Framework 不仅可以是通用的框架，也可以是像 Hadoop 的 Job 或者 YARN 的 Application 那样的简单计算任务，也就是说，Framework 并需要一定是一个 “Framework”，或者一个长时间运行的服务（比如 JobTracker 等），也可以是一个短生命周期的 Job 或者 Application。如果让 Framework 对应一个 Hadoop Job，则可以这样设计 Framework Scheduler 和 Framework Executor： （1）Framework Scheduler 功能 Framework Scheduler 负责按照作业的输入数据量，将之分解成若干任务，并为这些任务申请资源、监控这些任务的运行状态，一旦发现某个任务运行失败则重新为之申请资源。 （2）Framework Executor 功能 为一个节点上的 Map Task 或者 Reduce Task 准备运行环境，包括准备各种 jar 包、二进制文件，设置必要的环境变量，进行必要的资源隔离，启动 Jetty Shuffle 以为 Reduce Task 提供远程数据拷贝服务等，接收来自 Framework Scheduler 的命令（启动任务、杀死任务等），并执行。 通过上面的介绍可以知道，Framework Scheduler 只负责运行一个 Hadoop Job，而如果你对 YARN 比较熟悉，便会发现者正是 YARN 中的 MapReduce ApplicationMaster 做的事情，没错，Mesos 与 YARN 的设计架构如此的相近，以至于我们很容易通过修改 YARN 的任何一个 ApplicationMaster，让它作为一个 Framework Scheduler 运行在 Mesos 中。 最近 Mesos 提供了一个 mesos-submit 工具（https://github.com/apache/mesos/blob/trunk/docs/Using-the-mesos-submit-tool.mdFramework，注意，该工具尚不完善），该工具可以让用户的 Scheduler 运行在任何一个 Mesos Slave 上，以防止客户端运行过多的 Framework Scheduler，这样，Mesos 的整个架构和工作流程已经变得与 YARN 相差无几了。 为了让大家更容易理解 Mesos 和 YARN 在架构上的相似性，下面给出了 Mesos 和 YARN 的组件对应表： [attach] 2428[/attach] 既然 Mesos 和 YARN 如此的相近，那么我们到底应该使用哪一个呢？或者说，哪一个系统更有前景？ 就目前看来，YARN 在以下几个方面存在明显优势：（1）人力投入大。目前 YARN 有专门的公司（hortonwork）维护和开发（2）知名度高。YARN 之前从 Hadoop 1.0 中演化而来，继承了 Hadoop 的知名度，且有大量公司和开发人员共享 patch。然而，Mesos 最大优点的设计简单、容易上手使用，它不像 YARN 那样，一个资源的分配过程要涉及到若干个状态机，且每种状态机十几种状态，十几种事件。但稳定性看，两个系统都处于研发和测试阶段，离稳定可用还有一段距离。

Good

有霸气，有胆识，有气魄

不是有个配置管理架构师准备到杭州履职了么？ :shutup:

我是去打酱油的啊。江浙自古出才子，我是去跟才子们学习的。

你这。。。。。。。。。。。。

好大个的一个坑啊，腿都摔瘸了

可惜被 IBM 收购了就逐渐的失势了。现在国内市场还大么？

无法解压。我到你博客里去下载了一个也无法成功解压。

一定一定。

支持原创，必须散分。

工作地址上海，上海的朋友最近看机会的可以去试试。

赞美

谢谢你为大家提供了这么好的一个工具和方案啊

Good, 期待文章。

目前国内 Subversion 的用户是最多的。bugzilla 用户也很广泛。你的总结可以让大家更好的使用这两个工具。

大赞技术贴，欢迎原创。

解决没有？ 有没有更多的信息更新？或者对诊断问有帮助？

把所有的命令写到一个 .bat 文件中，然后让 Jenkins 来调用这个 .bat 文件。

在一个 .bat 文件中共享变量则要容易的多。比如文件 proj.bat

set SOURCE=%1 set BUILDNO=%2

echo source build location is : %SOURCE% echo project build number is : %BUILDNO%

1%,%2 传进来的两个参数。使用格式是 proj.bat c:\builds 1.1.1 输出： C:\builds 1.1.1

:)

多谢提供面试总结。希望对后续的人有帮助

每个公司都有不尽如人意的地方，找工作的时候，想清楚自己想要什么就可以了。没必要鄙视。

找工作本来就是个你情我愿的事。

你是想请客么？ 如果这样可能过去面试的人会多些。