挑戰
Wink 正在構建一個低延遲、高可靠性的基礎設施，用於連線數百萬個智慧家居裝置與公司的消費者集線器和移動應用程式之間的通訊，重點關注水平可伸縮性、快速加密一切的能力，以及在出現問題時可以輕鬆恢復連線。
解決方案
全面使用 Kubernetes-Docker-CoreOS Container Linux 堆疊。
影響
“美國最大的兩家零售商 [家得寶和沃爾瑪] 都在銷售和推廣這個品牌和硬體，”Wink 工程主管 Kit Klein 自豪地說，“儘管他補充說，‘這確實帶來了很大的壓力。這不是一個有很多技術愛好者的零售場景。這些人是普通人，他們只想要一個能用的東西，對技術藉口零容忍。’ 這進一步證明了 Klein 對 Wink 團隊所構建的基礎設施的信心。Wink 80% 的工作負載執行在 Kubernetes-Docker-CoreOS 的統一堆疊上，公司已將自己置於不斷創新和改進產品和服務的位置。Klein 說，致力於這項技術“使得在基礎設施之上進行構建相對容易。”
Kit Klein 掏出手機進行演示。輕輕滑動幾下，Wink 的工程主管便調出這家紐約市公司建立的智慧家居應用程式，然後點選了燈泡按鈕。“老實說，當你拿著手機，點選燈泡時，”他說，“在你感覺到手指在螢幕上按壓的力道時，燈就已經亮了。這需要訊號傳輸到你大腦的時間。”
當然，開啟燈——或者鎖門或改變恆溫器——只需要一根手指和不到 200 毫秒的時間。但讓 Wink 能夠以如此速度和便捷性幫助消費者管理他們的聯網智慧家居產品的，是一個複雜而云原生的基礎設施。Klein 和他的團隊使用 CoreOS（一個為叢集部署設計的開源作業系統）和 Kubernetes（一個用於跨主機叢集自動化部署、擴充套件和操作應用程式容器的開源平臺，提供以容器為中心的基礎設施）的統一堆疊構建並持續開發了這個基礎設施。“當你有一個龐大而複雜的相互依賴的微服務網路，它們需要能夠相互發現，並且需要水平可伸縮且容忍故障，這就是這個系統真正最佳化的目標，”Klein 說。“很多人最終依賴於一些大型雲提供商提供的專有服務來完成這些事情，但透過採用 CoreOS/Kubernetes，你獲得的是可移植性，不會被任何一家鎖定。你真的可以掌控自己的命運。”
事實上，Wink 做到了。公司的使命宣言是讓聯網家居觸手可及——也就是說，對於非技術使用者來說易於使用、價格實惠，或許最重要的是可靠。“如果你不能相信當你按下開關時燈會亮，或者如果你遠端檢視你的房子而資訊不準確，那麼系統的便利性就喪失了，”Klein 說。“所以這就是基礎設施發揮作用的地方。”
Wink 孵化於一家開發眾包發明的公司 Quirky。Wink 應用程式於 2013 年首次推出，當時它只控制少數消費產品，例如 Quirky 與通用電氣合作生產的 PivotPower Strip。隨著智慧家居產品激增，Wink 於 2014 年在家得寶 (Home Depot) 全國門店推出。它的第一個專案是一個集線器，可以與 Honeywell 和 Chamberlain 等大約十幾個品牌的智慧產品整合。最大的挑戰將是構建基礎設施來服務集線器和產品之間的所有通訊，重點是最大限度地提高可靠性並最小化延遲。
“當我們最初開始時，我們快速行動，試圖將第一個產品推向市場，即最小可行產品，”Klein 說。“很多時候，你走了一條路，結果不得不回頭嘗試不同的事情。但在這種特殊情況下，我們做了大量的預先工作，這導致我們做出了一個非常明智的決定，將其部署在 CoreOS Container Linux 上。而且那是在其生命週期的非常早期。”
首要問題是：Wink 的產品需要連線到人們家中的消費裝置，這些裝置位於防火牆後面。“你沒有像 URL 這樣的端點，你甚至不知道防火牆後面哪些埠是開放的，”Klein 解釋道。“所以你本質上需要讓這個東西喚醒並與你的系統通訊，然後開啟雲和裝置之間的即時雙向通訊。而且它真的非常非常重要，因為你希望儘可能減少傳送訊息的開銷——你永遠不知道什麼時候有人會開燈。”
Wink Hub 的早期版本，當你決定開燈或關燈時，請求會發送到雲端然後執行。Wink 軟體的後續更新啟用了本地控制，將許多裝置的延遲降低到約 10 毫秒。但隨著對日益增長的智慧家居產品生態系統進行雲端整合的需求，低延遲網際網路連線仍然是一個關鍵考慮因素。
此外，Wink 還有其他要求：水平可伸縮性、快速加密一切的能力，以及在出現問題時可以輕鬆恢復連線。“縱觀我們開始的整個結構，我們決定構建一個基於安全套接字的服務，”Klein 說。“我敢說，我們一直使用某種叢集技術來部署我們的服務，所以我們做出的決定是，這個東西將採用容器化，在 Docker 上執行。”
2015 年，Docker 尚未被廣泛使用，但正如 Klein 指出的，“走在技術前沿的人當然瞭解它。我們開始研究可能存在的潛在技術。限制因素之一是我們需要部署多埠非 HTTP/HTTPS 服務。它不太適合一些早期的叢集技術。我們非常喜歡這個專案，並最終在其他方面使用了一段時間，但最初它過於專注於 HTTP 工作負載。”
一旦 Wink 的後端工程團隊決定採用容器化工作負載，他們就必須對作業系統和容器編排平臺做出決策。“顯然，你不能只是啟動容器，然後希望一切順利，”Klein 笑著說。“你需要一個系統來幫助管理工作負載的分配。當容器不可避免地崩潰或發生類似情況時，要重新啟動它，你需要一個負載均衡器。需要各種各樣的內務管理工作才能擁有一個健壯的基礎設施。”
Wink 考慮過直接基於 Ubuntu 等通用 Linux 發行版構建（這需要安裝工具來執行容器化工作負載）和 Mesos 等叢集管理系統（這針對擁有更大團隊/工作負載的企業），但最終將目光投向了 CoreOS Container Linux。“容器最佳化的 Linux 發行版系統正是我們所需要的，”他說。“我們不必費力地嘗試使用 Linux 發行版並安裝所有東西。它有一個內建的容器編排系統，即 Fleet，以及一個易於使用的 API。它的功能不如一些更強大的解決方案豐富，但我們意識到，在那時，它正是我們所需要的。”
Wink 的集線器（以及經過改造的應用程式）於 2014 年 7 月推出，並進行了短期部署。在第一個月內，他們就將服務遷移到容器化的 CoreOS 部署。自那時起，他們幾乎將所有其他基礎設施部分——從第三方雲到雲的整合到客戶服務和支付門戶——都遷移到了 CoreOS Container Linux 叢集上。
使用此設定確實需要一些自定義。“Fleet 作為基本的容器編排系統非常好，但它不負責路由、共享配置、秘密等，在服務例項之間，”Klein 說。“所有這些功能層當然都可以實現，但如果你不想花很多時間手動編寫單元檔案——當然沒人會這麼做——你需要建立一個工具來自動化其中一些工作，我們就是這樣做的。”
Wink 在 Kubernetes 容器叢集管理器於 2015 年釋出並與 CoreOS 核心技術整合後，迅速採用了它。正如所承諾的，它最終提供了 Wink 想要並計劃構建的功能。“如果不是 Kubernetes，我們很可能會採用我們為建立的自動化工具實現的邏輯和庫，並將其用於更高級別的抽象和工具，供非 DevOps 工程師從命令列建立和管理叢集，”Klein 說。“但 Kubernetes 完全消除了這種不必要性——並且由比我們更有叢集管理經驗的人編寫和維護，所以再好不過了。”現在，Wink 約 80% 的工作負載都執行在 CoreOS Container Linux 上的 Kubernetes 上。
Wink 全力以赴的原因很清楚：“它不是專有的，它完全開放，它非常便攜，”Klein 說。“你可以在不同的雲提供商之間執行所有工作負載。你可以輕鬆執行混合 AWS，甚至可以引入你自己的資料中心。這就是所有東西都統一在一個 Kubernetes-Docker-CoreOS Container Linux 堆疊上的好處。如果你只有一個 Linux 發行版需要驗證，那麼安全收益是巨大的。這些好處是巨大的，因為你節省了金錢和時間。”
Klein 承認，每項技術決策都有取捨。“尖端技術對某些人來說會令人恐懼，”他說。“為了利用這一點，你真的必須跟上技術。你不能把它當作一個黑盒子。緊跟開發。理解決策是如何做出的。如果你理解專案背後的意圖，從技術意圖到某種哲學意圖，那麼這有助於你理解如何與這些系統和諧地構建你的系統，而不是試圖對抗它。”
Wink 於 2015 年被 Flex 收購，現在控制著全國各地家庭中 230 萬個聯網裝置。該公司接下來會做什麼？新版集線器——Wink Hub 2——於去年 11 月上市，除了家得寶之外，還首次在沃爾瑪門店銷售。“美國最大的兩家零售商正在銷售和推廣該品牌和硬體，”Klein 自豪地說——儘管他補充說，“這確實帶來了很大的壓力。這不是一個有很多技術愛好者的零售場景。這些人是普通人，他們只想要一個能用的東西，對技術藉口零容忍。”這進一步證明了 Klein 對 Wink 團隊所構建的基礎設施的信心。
自早期以來，Wink 的工程團隊呈指數級增長，在幕後，Klein 對 Wink 正在使用的機器學習最感興趣。“我們構建了一個容器化的資料管道小節系統，它們相互饋送，並且可以有多個輸出，”他說。“這就像微服務資料管道。” Klein 再次指出，CoreOS Container Linux 和 Kubernetes 上執行的統一堆疊是未來創新的主要驅動力。“你每次都不需要重新發明輪子，”他說。“你可以直接投入工作。”