我有分寸

容器云中的应用模式(1)

gnawux cloudcontainerpatternhyper

本文来自 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 pullhyper 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. 每个应用一个容器——容器间有良好隔离,不同应用按照各自生命周期管理,无需迁就。

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

gnawux
me!#$!@#$@#$wangxu!@#$%^&*()_me