前一段时间自己开发了一套基于Yarn的容器调度系统，这篇文章就是分享其中的一些经验。
前言
这篇文章不会具体教你如何使用Yarn的API,但是会教你我实践过后的一些经验。接下来的内容会探讨以下两个主题：
- 基于Yarn开发分布式程序需要做的一些准备工作
- 基于Yarn开发容器调度系统的一些基本思路
基于Yarn开发分布式程序需要做的一些准备工作
肯定不能撸起袖子就开始干。你思考代码组织，那么你会是一个好的工程师。如果你开始思考系统分层结构，你会是一个好的架构师。当然，最好是都要思考一下啦。
*** Yarn 原生的API太底层，太复杂了 ***
如果你想愉快的开发Yarn的应用，那么对Yarn的API进行一次封装，是很有必要的。 Yarn为了灵活，或者为了能够满足开发者大部分的需求，底层交互的API就显得比较原始了。自然造成开发难度很大。这个也不是我一个人觉得，现在Apache的twill,以及Hulu他们开发的时候Adaptor那一层，其实都是为了解决这个问题。那为什么我没有用Twill呢，第一是文档实在太少，第二是有点复杂，我不需要这么复杂的东西。我觉得，Twill与其开发这么多功能，真的不如好好写写文档。
*** 最好是能开发一个解决一类问题的Framework ***
Yarn只是一个底层的资源管理和调度引擎。一般你需要基于之上开发一套解决特定问题的Framework。以Spark为例，他是解决分布式计算相关的一些问题。而以我开发的容器调度程序，其实是为了解决动态部署Web应用的。在他们之上，才是你的应用。比如你要统计日志，你只要在Spark上开发一个Application 。 比如你想要提供一个推荐系统，那么你只要用容器包装下，就能被容器调度程序调度部署。
所以通常而言，基于Yarn的分布式应用应该符合这么一个层次
Yarn -> Adapter -> Framework -> Application
Adapter 就是我第一条说的，你自个封装了Yarn的API。 Framework就是解决一类问题的编程框架，Application才是你真正要解决业务的系统。通过这种解耦，各个层次只要关注自己的核心功能点即可。
*** 保证你上层的Framework/Application可以移植 ***
Spark是个典型,他可以跑在Mesos上，也可以跑在Yarn上 ,还可以跑在自己上面(standalone)，就是因为Spark的Framework不依赖于底层的Core,这个Core其实就是各个资源调度服务的适配层。我封装了Yarn后，上层的Framework是看不到的Yarn的API的,直接依赖YarnAdaptor，如果需要，我可以再开发一套Mesos Adaptor。
这其实是上面两条带来的好处，因为有了Adaptor,上层的Framework可以不用绑死在某个资源调度引擎上。而Framework则可以让Applicaiton 无需关注底层调度的事情，只要关注业务即可。
另外，你费尽心机开发的Framework上，你自然是希望它能跑在更多的平台上，已满足更多的人的需求，对吧。
基于Yarn开发容器调度系统的一些基本思路
首先我们需要了解两个概念：
哑应用，所谓哑应用指的是无法和分布式系统直接进行交互，分布式系统也仅仅透过容器能进行生命周期的控制，比如关闭或者开启的应用。典型的比如MySQL,Nginx等这些基础应用。他们一般有自己特有的交互方式，譬如命令行或者socket协议或者HTTP协议。
伴生组件，因为有了哑应用的存在，分布式系统为了能够和这些应用交互，需要有一个代理。而这个代理和被代理的哑应用，具有相同的生命周期。典型的比如，某个服务被关停后，该事件会被分布式系统获知，分布式系统会将该事件发送给Nginx的伴生组件，伴生组件转化为Nginx能够识别的指令，将停止的服务从Nginx的ProxyBackend列表中剔除。
在容器调度系统中，如果Yarn的NodeManager 直接去管理Docker则需要Yarn本身去做支持，我觉得这是不妥的。Yarn的职责就是做好资源管理，分配，调度即可，并不需要和特定的某个技术耦合，毕竟Yarn是一个通用型的资源调度管理框架。我们只要开发一套Framework,这个framework的slave节点其实是对应容器的一个伴生对象，这样我们就能透过这个framework对容器进行管理，并且该framework还衔接了容器和Yarn。 我们简单描述下他们的流程
- 用户提交Application,申请资源
- Yarn 启动Framework 的master
- Yarn启动Framework 的 slave
- slave 连接上master,并且发送心跳，从而master知道slave的状况
- slave 启动 docker，slave 与被启动的这个docker container 一一对应
- slave 定时监控container
- slave发现container crash,slave 自动退出，yarn获得通知，收回资源
- master 发现有节点失败，发出新的节点要求，重新在另外一台服务器上启动slave,重复从2开始的步骤
这里还有一个问题，如果slave 被正常杀掉，可以通过JVM ShudownHook 顺带把container也关掉。 但是如果slave被kill -9 或者异常crash掉了，那么就可能导致资源泄露了。目前是这个信息是由master上报给集群管理平台，该平台会定时清理。你也可以存储该信息，譬如放到Redis或者MySQL中，然后启动后台清理任务即可。
了解了这个思路后，具体实施就变得简单了,就是开发一个基于Yarn的master-slave 程序即可，然后slave去管理对应的docker容器，包括接受新的指令。master提供管理界面展示容器信息，运行状态即可。
当然，你还可以再开发一套Framework B 专门和Nginx交互，这样比如上面的系统做了节点变更，通知B的master，然后B的master 通过自己的伴生组件Slave 完成Nginx的更新，从而实现后端服务的自动变更和通知。
现在看来，是不是这种概念完美的覆盖了应用之间的交互呢？