---
title: Java 服务托管到 YARN
date: '2014-04-21 18:33:29'
draft: false
summary: 如果 Storm、Spark 和 HBase 都能跑在 YARN 上，那么把长期运行的 Java 服务纳入同一调度体系就是顺理成章的下一步。
slug: java-services-on-yarn-as-internal-paas
syndication:
- platform: Weibo
  url: https://weibo.com/1648815335/B0Mt2nk7Z
tags:
- yarn
- paas
- java
- distributed-systems
topics:
- software-engineering
type: post
---

当时在想一个问题：既然 `Storm`、`Spark`、`HBase` 这些系统都能跑在 `YARN` 上，为什么不能再往前走一步，做一个框架，把普通的 `Java` 服务也托管到 `YARN` 上，变成一种内部 `PaaS`？

这个想法背后的直觉其实很简单。`YARN` 已经提供了资源调度、容器分配、生命周期管理这些基础能力，而很多内部服务平台本质上也在解决类似的问题：

- 服务实例要部署到哪
- 资源怎么分配
- 失败之后如何拉起
- 如何在集群里统一管理运行状态

如果这些基础能力已经在 `YARN` 里存在，那继续在它上面托管长期运行的 `Java` 服务，按理说并不违和。

我后来也查到，早在 `2012` 年就有人提出过类似思路，比如 `paas-on-hadoop-yarn` 这类方案，甚至还有过 `prototype`。但问题是，社区后面并没有看到特别成型的真实落地案例，也没有形成持续演进的生态。

这件事本身挺有意思。它说明一个基础设施平台即便“理论上可以承载更多东西”，也不代表它就一定会自然演化成更通用的平台。中间还隔着开发体验、服务治理、网络模型、状态管理、调试方式这些更具体的问题。

所以这个问题后来对我更像一个观察点：一个系统能不能变成平台，不只取决于它能不能调度资源，还取决于它是否能把应用真正关心的那层抽象一起接住。