容器云中的应用模式（1）

本文来自 hyper.sh 上线四个月以来对用户的一些观察与访谈，作为一种新的服务，用户的创造力可能会超出设计者最初的构想，这里只是部分的归纳，希望能对读者有一定的启发。

背景： Hyper.sh 与容器云

今年8月，我们上线了 HYPER.sh 服务，我们打出的口号之一是——“用 Container 重新发明 IaaS (Re-Invent IaaS with Container)”，不同于之前各大小云服务商提供的容器服务，Hyper.sh 没有运行在一个 IaaS 系统上，容器就是云的一等公民。当然，Hyper.sh 使用了我们自己的开源项目 HyperContainer 替换掉了 Docker Runtime，所以可以无需底层 IaaS 就可以做到多租户的隔离。

在 Hyper.sh 上，用户无需拥有一个集群/资源池就可以直接创建容器，容器启动时间一般为 3-5 秒（加挂数据卷可能会让这一时间变长一些），在此基础上，计费也按照秒级进行。Hyper.sh 提供了 API 和客户端访问，除了公网 IP、安全组等 IaaS 传统项目之外，Hyper.sh 的客户端和 API 的体验和本地使用 Docker Daemon 别无二致，用户不需要察觉到支持这个 “云中的 Docker Daemon” 的是一个集群，他也看不到节点的概念，只需要 hyper pull 和 hyper run 就可以了。

所以，TNS 发表了一篇 Top Story — Hyper is Docker Done the Right Way 。这种超出以往的弹性与容器的轻量级属性一起，让一些以往没人做的事情变成了可能。

应用案例

持续集成 CD/CI

有 BuildBot 和 Jenkins 两大应用， Hyper.sh 没准是最被看好的 CD/CI 基础设施之一了吧。 《Buildbot集成Hyper_容器云，新型Serverless CI的诞生？》 里说了很多细节，在此感谢 CSDN 这篇极客头条的免费推广。简单地说，容器云因为资源粒度更细，避免了时间和资源的浪费，更提高了工作效率，节约了开支。

周期性批量处理

我们另外的一位用户会进行一些周期性的 ETL 工作，他会一次启动上百个 container，从 AWS S3 拉下原始数据，进行若干秒钟的处理后，把数据结果推送到他在自己数据中心中的服务器中。在之前使用 EC2 的时候，单台虚机的计费是小时起的，所以，算得快也不能省钱，而放在容器云上之后，直接可以用并发来交换时间，提高效率，却并不会显著增加成本。

在这个用户的启发下，我们还推出了新的 hyper cron 服务，如 cron 一般，为用户定时启动容器执行任务。

按需处理

我们还有一些用户，会进行一些高并发的按需处理，比如一个用户用容器云来承载一个视频处理应用，每当用户上传时，就运行新的容器进行处理，完成后就销毁容器；另外一位加州名校的老师，用 Hyper.sh 容器云来处理学生提交的作业，每个提交的作业会启动一个 container 进行结果验证，完成后销毁容器。这两个应用都和 CD/CI 非常类似，无需预先准备资源，随时按需扩展承载业务。

容器容灾

国外有很多用户已经开始使用容器提供服务了，这样的用户会发现，使用容器云同样是容灾的一个方便的手段，因为在 Hyper.sh 上启动容器的时间只有 3-5 秒，他们不需要在平时就有服务器跑着进行热备，只要在需要切换服务的时候，在 Hyper.sh 上启动容器就可以了。对大部分互联网服务来说，三到四个9的可用性就足够了，有了可以秒级启动的容器云，就完全没有必要维持热备的服务器了。

轻量网站

有很多低流量的网站，比如我的个人博客或一些稍大的个人项目，甚至完全没必要占据 512MB 内存，如果不启动一些不太重要的服务的话，甚至 64MB 内存都足够，在 Hyper.sh 上也有不少这样的用户，他们之前把网站放在VPS上或者根本没有自己的主机，现在放在 Hyper.sh 上的容器里，可以有自己的独立 IP，利用 letsencrypt 之类的服务提供 Https 服务更容易，成本也不高。

业务交付

我们的早期用户里，还有一些咨询公司或自由职业者，他们使用 docker 完成客户的外包任务，之前测试之后，还要帮助用户把产品跑到用户的平台上，或者帮用户搭建环境。现在他们可以直接把成品跑在 Hyper.sh 容器云上，测试完成之后，可以把整个容器直接交付给客户，不需要和他们的其他客户共享容器，所以测试、交付也更容易。

模式分析

以上只是一些比较常见的容器应用分析，有些比较微服务，而其他的却并不一定。但它们的共同特点是利用了 Hyper 这类容器云的高弹性和细粒度的资源调配，做到了之前依托 IaaS 无法达到的效率，节约了资源成本或时间成本，总的说有一下几点：

1. 不再需要资源池，或者说整个云就是资源池——不需要使用虚机池子进行任务调度了，每个任务跑一个容器，跑完销毁；
2. 并发换时间——秒级启动、秒级计费，没有很长启动和准备时间的开销，也没有1小时起价的约束，并行化提高效率也就没有了后顾之忧；
3. 按需启动，无需待机——只要在需要的时候启动容器就可以，不论是来任务启动、定时启动还是遇到事故紧急启动，都不需要预先预热系统；
4. 每个应用一个容器——容器间有良好隔离，不同应用按照各自生命周期管理，无需迁就。

这些容器云的简单模式，让应用变得比以往更加简单，也鼓励着各位用户，包括我们这些狗粮用户，在不断尝试新玩法。后面随着新业务的上线和更多用户的新玩法贡献，我也还会继续更新这个系列。