實戰應用：藉助Kubernetes不停機從Heroku遷移至AWS

作者｜Mike Sedzielewski

譯者｜大愚若智

本文介紹了 Voucherify 為了應對成本和資源利用率等方面的挑戰，將原本託管於 Heroku 的大部分平台組件不停機遷移至 AWS 的原因和遷移思路。

幾個月前，我們成功地將大部分基礎架構組件從 Heroku 遷移至 AWS。現在，當一切塵埃（還是應該說「雲」）落定後，我想簡要介紹一下做出這一決策的主要考慮因素，以及如何在確保我們的 Voucherify API 不停機（哪怕一分鐘都沒中斷）的情況下順利完成了遷移任務。

架構概況

為了更好地理解遷移工作的原因，先來簡單了解一下 Voucherify 是什麼，原本的架構是怎樣的。

Voucherify 提供了可編程的構建塊，可幫助用戶構建優惠券、推介、商戶會員制度等宣傳推廣活動。基本上，可將其理解為一種以 API 為先的平台，開發者可藉此構建複雜並且個性化的宣傳推廣活動，例如當客戶成為「高級」會員後，通過郵件向客戶發送優惠券代碼。企業還可以藉助這個平台追蹤代碼的兌換情況，藉此確定怎樣的推廣活動可以獲得最佳效果。最後，該平台還提供了儀錶盤，營銷人員可以藉此簡化與推廣有關的維護工作，開發者也可以藉此簡化整個活動的監控工作。

整個平台基本上可分為三個組件：

暴露相關 API 的核心應用程序

提供儀錶盤頁面的網站

對與 API 無關的其他作業提供支撐的微服務

在數據存儲方面，我們使用了 Postgres、Mongo 以及 Redis trio。

遷移後的架構是這樣的：

負載：我們有一百多位客戶，每月會產生數百萬的 API 調用，其中包括常規請求以及一些開銷巨大的請求，例如批量導入 / 導出，或與第三方集成系統同步等。

為何一開始使用 Heroku？

當我們在 2015 年上線 Voucherify 時，Heroku 曾是最完美的解決方案。它為我們提供了極具成本效益的託管方式以及完善的持續部署工作流程。任何曾經用過 Heroku 的人都會明白將其與 GitHub 集成的過程會有多簡單，以及部署速度能夠有多快。此外 Heroku 還提供了完善的文檔，並且社區也充滿了活力。

藉此我們可以更好地專註於自身產品的迭代，並且在很長一段時間（對我們來說，是大約 16 個月）里不需要為 DevOps 工作委派專職人員。託管在 Heroku 上最大的好處在於速度。我們只需要構建、發布、擴展，完全無需考慮基礎架構問題（部署腳本、縮放、安全性等）。此外速度方面的收益還體現在 Heroku 遍布全球的數據中心為我們提供的低延遲訪問體驗，對我們來說這一點非常重要，因為我們這個以 API 為先的平台最重要的事情是確保開發者獲得一流體驗，我覺得任何開發者面對卡頓的響應都不會感到開心。

轉折點

Heroku 本來挺好，但我們的平台開始逐漸變得更加動態化。新的企業客戶希望每天調用數萬次 API，原本我們採用了「游擊隊」式的方法縮放 Dyno，但這樣的做法開始變得越來越昂貴。我們已經明白，長遠來看，這種架構的縮放性已經無法滿足我們的要求。畢竟作為一家已經起步的企業，我們必須快速加以應對。

當時我們的成本是這樣的：

API 服務?—?750 美元（僅包括處理流量的 Dyno，不包括資料庫）

Web 儀錶盤?—$50 美元

處理更多 API 流量的另一個 Dyno，至少 50 美元

對於大批量操作（導入、導出），我們需要更大內存更大規模的容器，因此每個 Web Dyno 的成本將增長至 250 美元

但價格並非我們決定棄用 Heroku 的唯一原因。

首先，我們開始遇到一些很奇怪，並且難以調試的基礎架構問題。有好幾次我們注意到平台遇到了問題，無法獲得確定性的響應結果。調查問題的過程中，卻（在很久很久之後）發現問題源自 Heroku 本身。他們的服務狀態頁面不能及時更新。有時候他們的反應速度很快，但有時候我們只能自行嘗試解決，因為等他們來處理還要多等好幾個小時。

其次，Heroku（估計其他 PaaS 也是如此）的資源利用率很低。Heroku 只關心硬體的資源結構，但據我們所知，這樣的資源限制策略雖然很重要並且合理，但畢竟每個應用程序都有各自的特點，因此相關的 CPU/ 內存利用率配置文件也需要酌情調整。為了升級更大的內存，我們還得為額外的 CPU 資源付費，但這些 CPU 資源我們根本不需要。如果需要進一步縮放應用，情況還會更嚴峻，不必要的成本也會更高。就以我們的情況來說吧，我們的基礎架構工程師 Tom 曾經說過：

現在，每月支付相同費用（750 美元，僅服務，不包括資料庫）的情況下，我們再也不需要頭疼批量操作的問題，因為目前的資源利用率更合理。更重要的是，我們的流量翻了六倍。

第三，缺乏私有 IP 地址。我們曾經收到通知說自己的應用程序發送了大量垃圾信息，但實際並非如此。更重要的是，我們的一些企業客戶會通過安全策略控制出站通信，為了設置自己的防火牆，他們詢問我們的 IP 地址，而在使用 Heroku 的情況下甚至這樣的要求我們都無法滿足。

最後，載入項極為有限。Heroku 的一些載入項無法兼容 Voucherify 集成的最新版軟體。例如 Compose 載入項只能用於 2.6 版的軟體。

結合所有這些因素，繼續使用 Heroku 只能導致我們浪費更多資金和時間。

拯救者 AWS

為何選擇 AWS？我猜答案可能會讓一些人失望，但畢竟 AWS 是目前最流行的雲提供商，我們也從以往的項目中積累了豐富的經驗。事先我們並沒有進行調研，此外我們的資料庫實例原本就已經託管在 AWS 的同一個區域中。

遷移過程——如何確保所有系統不中斷運行

我們的 API 需要出處理全球成千上萬的優惠券兌換請求，如果 API 停機，全球會有大量用戶感到沮喪，並認為自己剛剛結賬換來的優惠券就已經失效了。或者可能會讓某些用戶無法使用生日禮券支付自己期待已久的無人機。這樣令人不悅的情況會很快引起我們企業客戶的關注，進而讓他們對我們的服務感到失望，這種局面是我們最不想看到的。

因此我們採取了一種循序漸進的，以可用性為最高要務的遷移策略。我們的做法如下：

首先通過 Bash 腳本遷移一個應用程序。在確定了所有細節（依賴項、安全補丁等）之後，腳本的運行就變成了常規的 IT 維護任務。為此我們選擇了容器技術，因為我們的 API 需要通過一組伺服器運行，並且需要具備負載均衡、自動縮放、故障轉移等能力（Heroku 自帶這些功能），相關的編排工作是通過 Kubernetes 實現的，相比 Mesos 和 Docker Swarm，Kubernetes 似乎有著最大規模的社區。

Kubernetes 內建了對 Google Cloud Platform 的支持，但並未直接支持 AWS，因此我們使用 StackPoint 簡化 k8s 的配置。通過這種方式，我們就不需要花費大量時間來配置 AWS 群集。StackPoint 最棒的地方在於，可以提供與節點數量無關的統一費率。使用 k8s 的其他好處在於，我們可以在需要時將群集遷移至其他雲平台，這讓我們喜出望外，因為最近就有客戶詢問是否能提供 AWS 之外的其他託管選項。通過這樣的方式，我們可以隨時在其他區域創建群集，而整個過程可以在 15 分鐘內順利完成。

引入了 k8s 監視平台：Prometheus + Grafana。我們計劃令行撰文介紹具體做法，如果你也關注這個問題，不妨訂閱我們的博客。

通過計算 Heroku 平台當前的資源使用率，為所需容器資源設置基準線，並作為選擇 EC2 節點規模的依據。

通過 Route53 對流量逐步進行重路由：

0% AWS?—?90% Heroku

25%?—?75%

50%?—?50%

100% AWS

結果

最終我們獲得了一個更可預測的平台，並且面對未來幾個月的流量增長也獲得了更穩妥的保障。我們的幾個服務依然會使用 Heroku，例如儀錶盤，因為這樣做更易於部署，並且這些服務實際上並不需要那麼多資源。

活動推薦

隨著 AI、Big Data、Cloud 的逐漸成熟，FAAS、CAAS 等技術的興起，以及被運維業務的多樣化和複雜化，很多傳統的運維技術和解決方案已經不能滿足當前運維所需，AIOps 智能運維、大數據運維、ChatOps、SRE、Chaos Engineering、微服務與容器運維等新技術和方嚮應運而生，它們一方面把最前沿的技術結合到運維中來，一方面在人員角色、領域範圍、文化等方面又有了很多擴展，讓傳統運維有了翻天覆地的變化。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！