前言
在Hadoop YARN发展早期，社区曾经讨论过在YARN之上提供PaaS服务。当时业界已经有很多企业提供付费模式的PaaS服务，作为当时已经被大量使用在公司企业内部的Hadoop系统，自然我们可以提出这样一个大胆的想法；为什么不可以在YARN之上构建PaaS云服务呢？不过遗憾的是，这个建议最终没有被实现，停留在了当年的讨论中。但是这并不妨碍我们去了解它的一个设计思路，以及构想。
PaaS服务
PaaS概念
首先，我们还是得重新提一下PaaS这个概念，尽管说这个概念被提出在很多年以前了。PaaS的全称为Platform as a Service,平台即服务，即把平台服务器作为对外服务的一种商业模式。对于用户来说，使用PaaS服务可以免去用户对于服务器，硬件，网络这种底层服务结构的工作，使得用户将更多的重心放在其自身应用之上。
PaaS的基本架构
对于PaaS的架构模式，它的基本架构可以分为3层：
- 第一，客户端层，简单的可以理解为提供给客户端用户使用的应用相关命令。
- 第二，系统核心结构层。这层里面主要包括客户端应用请求转发处理，服务健康状况监控，主要服务的控制。
- 第三，应用服务层。这层包括，应用运行时环境，运行所在的容器，支持多租户的运行模式等等。
下面是PaaS的一个基本架构图，和上面提到的会有略微的差别：
这里要额外1个比较重要的角色：
Router：这是一个请求路由的角色，它主要做1个事情，将用户的应用请求转发到它对应的应用服务器里去。所以在其内部需要维护一份，应用对应用服务实例列表的映射关系。
如果将相关的周边服务全部包括进来，PaaS的基本架构可以用下图来表示：
标明一点，上图显示的数据关系存储以及块存储，并不是指对外开放的存储服务，而是为了保存应用配置信息，以及war包这种运行文件的。
OK，理解了这些基本概念后，我们再来谈谈基于Hadoop YARN之上的PaaS构想，就会好理解很多了。
YARN之上的PaaS构想
为什么这里我们会提出在YARN之上构建PaaS的设想呢？有下面几点原因：
- YARN对于底层硬件没有特别的要求，普通常规化的服务器通过集群的形式对外提供整体服务，这与PaaS的服务形式一致。
- 很多企业自身内部已经部署并在使用Hadoop集群。在上面直接做PaaS，迁移成本比较低，包括数据，应用等等。
- YARN的3层结构（YARN client，YARN Core，Application应用层）和PaaS的3层结构也能够对应上。
- Hadoop自身作为Java框架应用，对于目前大多数的Java开发者来说，无需过高学习成本。
下面我们来聊聊基于YARN之上的PaaS构想。思路构想的一个核心点就是把PaaS中的关键服务对等于YARN中的服务。
PaaS的容器====>YARN里的Container容器
PaaS里的主控制器====>YARN里的ResourceManager服务
PaaS涉及用户的应用执行包存储====>Hadoop HDFS提供的文件系统服务
有了上面3个角色外，其实还少了1个关键的角色：路由控制角色，这个确实需要我们额外去设计的，先给出YARN之上的PaaS架构图：
上图中有几层关联关系，需要我们去了解的：
1.用户用命令行启动application应用，向RM发送请求，RM启动AppMaster。
2.AppMaster再向RM申请多个Container。这里会做一个额外的步骤，新启动的Container会注册[Container, Application]这样的关系在Zookeeper里面。表明这些Container对应的是具体Application实例的。
3.Router Proxy代理会向Zookeeper中获取对应Container–>Application信息，将用户发来的应用请求转发到对应的Container执行容器中。
大体是这样一个过程。上面所有关于Container容器的健康管理工作还是依赖于RM内部本身的机制来做。
为什么这里要额外引进Zookeeper做状态存储呢而不是直接保存到RM中呢？
两点原因：
1.这层映射关系可能会非常多。
2.把这层关系独立出去，可以与原本RM的管理区分开来，后续的改进调整也会比较容易一些。
以上就是YARN之上的PaaS构想，期待这块后续的进展吧。
参考资料
[1].https://blog.csdn.net/everlasting_188/article/details/79661203
[2].https://issues.apache.org/jira/browse/YARN-153. PaaS on YARN: an YARN application to demonstrate that YARN can be used as a PaaS