Effective Container Cloud (1)

本文來自 hyper.sh 上線四個月以來對用戶的一些觀察與訪談，作為一種新的服務，用戶的創造力可能會超出設計者最初的構想，這裡只是部分的歸納，希望能對讀者有一定的啟發。本人是 hyper.sh 的 cofounder，本文內容毫無疑問地有利益相關，請酌情參考。

原文位於本人 Blog: wangxu.me，原標題是「容器雲應用模式」，剛才忽然感覺，用 Effective XXX 這個 pattern 對應最後的模式解析部分挺有感覺的，就臨時改了一下名。

背景： Hyper.sh 與容器雲

今年8月，我們上線了 [HYPER.sh](Hyper.sh - Effortless Docker Hosting) 服務，我們打出的口號之一是——「用 Container 重新發明 IaaS (Re-Invent IaaS with Container)」，不同於之前各大小雲服務商提供的容器服務，Hyper.sh 沒有運行在一個 IaaS 系統上，容器就是雲的一等公民。當然，Hyper.sh 使用了我們自己的開源項目 [HyperContainer](hyperhq/hyperd) 替換掉了 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 - The New Stack 。這種超出以往的彈性與容器的輕量級屬性一起，讓一些以往沒人做的事情變成了可能。

應用案例

持續集成 CD/CI

有 BuildBot 和 Jenkins 兩大應用， Hyper.sh 沒準是最被看好的 CD/CI 基礎設施之一了吧。 [《Buildbot集成Hyper_容器雲，新型Serverless 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. 每個應用一個容器——容器間有良好隔離，不同應用按照各自生命周期管理，無需遷就。

這些容器雲的簡單模式，讓應用變得比以往更加簡單，也鼓勵著各位用戶，包括我們這些狗糧用戶，在不斷嘗試新玩法。後面隨著新業務的上線和更多用戶的新玩法貢獻，我也還會繼續更新這個系列。