挑战
构建一个低延迟、高可靠性的基础设施，用于服务数百万个连接的智能家居设备与公司消费者中心和移动应用程序之间的通信，重点是水平可扩展性、快速加密一切的能力，以及在发生任何问题时可以轻松恢复的连接。
解决方案
全面使用 Kubernetes-Docker-CoreOS Container Linux 堆栈。
影响
“两大美国零售商[家得宝和沃尔玛]正在销售和推广该品牌和硬件，”Wink 工程主管 Kit Klein 自豪地说——尽管他补充说“这真的带来了很大的压力。这不是一个有很多技术爱好者的零售环境。这些是想要一些能工作并且不能容忍技术借口的人。”这也进一步证明了 Klein 对 Wink 团队构建的基础设施的信任。Wink 80% 的工作负载在 Kubernetes-Docker-CoreOS 的统一堆栈上运行，这使公司能够不断创新并改进其产品和服务。Klein 说，致力于这项技术“使得在基础设施之上构建相对容易。”
Kit Klein 拿出他的手机来演示。在滑动几下后，这家位于纽约市的公司的工程主管 Wink 打开了智能家居应用程序，然后点击了灯光按钮。“老实说，当您拿着手机并点击灯光时，”他说，“当您感觉到手指在屏幕上的压力时，它就亮了。它需要的时间与信号传输到您大脑的时间一样长。”
当然，只需一根手指和不到 200 毫秒即可打开灯 - 或锁门或更改恒温器。但 Wink 能够如此快速和轻松地帮助消费者管理其连接的智能家居产品，这归功于 Klein 及其团队使用 CoreOS 的统一堆栈构建并继续开发的复杂的云原生基础设施。CoreOS 是为集群部署设计的开源操作系统，而 Kubernetes 是一个开源平台，用于自动化跨主机集群的应用程序容器的部署、扩展和操作，提供以容器为中心的基础设施。“当您拥有一个大型、复杂的相互依赖的微服务网络，这些微服务需要能够相互发现，并且需要水平可扩展且能容忍故障时，这正是为此优化的，”Klein 说。“很多人最终依赖[一些大型云提供商]提供的专有服务来完成其中的一些工作，但是采用 CoreOS/Kubernetes 所获得的是可移植性，不会被任何人锁定。您可以真正掌握自己的命运。”
的确，Wink 做到了。该公司的使命是使连接的家庭易于使用——即，对非技术所有者来说用户友好、价格实惠，也许最重要的是，可靠。“如果您不能相信当您按下开关时，您知道灯会亮起来，或者如果您是远程的，并且您正在检查您的房子，并且该信息不准确，那么系统的便利性就会丧失，”Klein 说。“这就是基础设施发挥作用的地方。”
Wink 在 Quirky 内孵化，Quirky 是一家开发众包发明的公司。Wink 应用程序于 2013 年首次推出，当时它仅控制少数消费产品，例如 Quirky 与 GE 合作生产的 PivotPower 插线板。随着智能家居产品的激增，Wink 于 2014 年在全国家得宝商店推出。其首个项目：一个可以与霍尼韦尔和 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 说。“当然，可以实现所有这些功能层，但是如果您不想花费大量时间手动编写单元文件——当然没有人这样做——您需要创建一个工具来自动化其中的一些操作，我们就是这样做的。”
当 Kubernetes 容器集群管理器在 2015 年推出并与 CoreOS 核心技术集成时，Wink 迅速接受了它，并且正如承诺的那样，它最终提供了 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 万个连接设备。该公司下一步的计划是什么？新版本的 Hub——Wink Hub 2——已于去年 11 月上架，并且首次在沃尔玛商店以及家得宝销售。“两家美国最大的零售商都在销售和推广该品牌和硬件，”Klein 自豪地说——尽管他补充说，“这确实带来了很大的压力。这不是一个有很多技术爱好者的零售环境。这些是希望产品能正常工作，并且对技术借口零容忍的普通人。” 这进一步证明了 Klein 对 Wink 团队构建的基础设施的信心有多大。
自早期以来，Wink 的工程团队呈指数级增长，在幕后，Klein 对 Wink 使用的机器学习最为兴奋。“我们构建了一个容器化的小型数据管道系统，它们相互馈送，并可以有多个输出，”他说。“这就像微服务式的数据管道。” 同样，Klein 指出，拥有在 CoreOS Container Linux 和 Kubernetes 上运行的统一堆栈是未来创新的主要驱动力。“你无需每次都重新发明轮子，”他说。“你可以直接开始工作。”