挑战
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 上运行的统一堆栈是未来创新的主要驱动力。“你每次都不需要重新发明轮子，”他说。“你可以直接投入工作。”