挑战
构建一个低延迟、高可靠性的基础设施，以服务数百万台连接的智能家居设备与公司消费者中心和移动应用程序之间的通信，重点关注水平可扩展性，快速加密一切的能力以及在出现故障时可以轻松恢复连接的能力。
解决方案
全面使用 Kubernetes-Docker-CoreOS 容器 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 与 GE 合作生产的少数消费者产品，如 PivotPower Strip。随着智能家居产品激增，Wink 于 2014 年在全国范围内在家得宝商店推出。它的第一个项目：一个能够与来自 Honeywell 和 Chamberlain 等十几个品牌的智能产品集成的中心。最大的挑战将是构建一个基础设施来服务所有这些中心和产品之间的通信，重点是最大限度地提高可靠性并最小化延迟。
"最初开始时，我们为了尽快将第一个产品推向市场，即最小可行产品，而行动非常快，”Klein 说。"很多时候你会走上一条路，最终不得不回溯并尝试不同的方法。但在这种特殊情况下，我们在前期做了很多工作，这导致我们做出了一个非常明智的决定，即在 CoreOS 容器 Linux 上部署它。这发生在它非常早期的阶段。”
第一个问题：Wink 的产品需要连接到人们家中防火墙后面的消费者设备。"你没有像 URL 这样的端点，你甚至不知道防火墙后面打开了哪些端口，”Klein 解释道。"因此，你实际上需要让它唤醒并与你的系统对话，然后在云和设备之间打开实时双向通信。而保持持久性非常非常重要，因为你想尽可能地减少发送消息的开销——你永远不知道什么时候有人会打开灯。”
使用 Wink Hub 的最早版本，当您决定打开或关闭灯光时，请求将被发送到云，然后执行。Wink 软件的后续更新启用了本地控制，将许多设备的延迟降低到大约 10 毫秒。但是，随着不断增长的智能家居产品生态系统对云启用的集成的需求，低延迟的互联网连接仍然是一个重要的考虑因素。
此外，Wink 还有一些其他要求：水平可扩展性，快速加密一切的能力，以及在出现故障时可以轻松恢复连接的连接。"从我们开始构建的整个结构来看，我们决定创建一个基于安全套接字的服务，”Klein 说。"我一直说，我们使用某种集群技术来部署我们的服务，因此我们做出的决定是，这将被容器化，在 Docker 上运行。”
2015 年，Docker 还没有被广泛使用，但正如 Klein 指出，“它当然被那些处于技术前沿的人所理解。我们开始寻找现有的潜在技术。其中一个限制因素是，我们需要部署多端口非 HTTP/HTTPS 服务。它并不真正适合一些早期的集群技术。我们非常喜欢这个项目，并且在一段时间内将其用于其他用途，但最初它过于针对 HTTP 工作负载。”
一旦 Wink 的后端工程团队决定了容器化工作负载，他们就必须对操作系统和容器编排平台做出决定。"显然，你不能仅仅启动容器并希望一切顺利，”Klein 笑着说。"你需要有一个有帮助的系统[以便]管理工作负载的分配位置。当容器不可避免地出现故障或出现类似情况时，需要重新启动它，你有一个负载均衡器。为了拥有一个健壮的基础设施，需要进行各种维护工作。”
Wink 考虑直接在通用 Linux 发行版（如 Ubuntu，这将需要安装工具来运行容器化工作负载）和集群管理系统（如 Mesos，它针对的是拥有更大团队/工作负载的企业）上进行构建，但最终将目光锁定在 CoreOS 容器 Linux 上。"一个容器优化 Linux 发行版系统正是我们所需要的，”他说。"我们不必为了尝试将像 Linux 发行版这样的东西拿来安装所有东西而大费周章。它有一个内置的容器编排系统，即 Fleet，以及一个易于使用的 API。它的功能并不像一些更重量级的解决方案那样丰富，但我们意识到，在那一刻，它正是我们所需要的。”
Wink 的中心（以及经过改进的应用程序）于 2014 年 7 月推出，并进行了短期部署，在第一个月内，他们就将服务迁移到了容器化的 CoreOS 部署中。从那以后，他们将几乎所有其他基础设施——从第三方云到云集成到他们的客户服务和支付门户——迁移到 CoreOS 容器 Linux 集群中。
使用这种设置确实需要一些定制。"Fleet 作为一个基本的容器编排系统非常不错，但它不会处理服务实例之间的路由、共享配置、秘密等，”Klein 说。"当然，所有这些功能层都可以实现，但如果你不想花太多时间手动编写单元文件——当然没有人会这样做——你需要创建一个工具来自动化其中的一些工作，我们就是这样做的。”
当 Kubernetes 容器集群管理器于 2015 年推出并与 CoreOS 核心技术集成时，Wink 迅速采纳了它，正如承诺的那样，它最终提供了 Wink 想要并且计划构建的功能。"如果没有 Kubernetes，我们可能会采用我们为自动化工具实现的逻辑和库，并在更高层的抽象和工具中使用它，以便非 DevOps 工程师可以通过命令行创建和管理集群，”Klein 说。"但 Kubernetes 使这完全没有必要——而且是由那些在集群管理方面比我们更有经验的人编写和维护的，所以越好不过。”现在，估计 Wink 80% 的工作负载运行在 CoreOS 容器 Linux 之上的 Kubernetes 上。
Wink 全力以赴的原因很明确：“它不是专有的，它是完全开放的，它非常便携，”Klein 说。“你可以在不同的云提供商上运行所有工作负载。你可以轻松运行混合 AWS 甚至引入自己的数据中心。这就是将所有东西统一在一个 Kubernetes-Docker-CoreOS 容器 Linux 堆栈上的好处。如果你只有一个 Linux 发行版需要验证，那么安全性将大幅提高。好处是巨大的，因为你可以节省资金，节省时间。”
Klein 承认，每个技术决策都有权衡。“对于某些人来说，尖端技术会让人害怕，”他说。“为了利用它，你必须不断跟上技术发展。你不能把它当作黑盒子。紧密关注开发。了解做出决策的原因。如果你了解项目的意图，从技术意图到某种哲学意图，那么它将帮助你理解如何在与这些系统保持和谐的状态下构建你的系统，而不是试图与它对抗。”
Wink 于 2015 年被 Flex 收购，现在控制着全美各地家庭中的 230 万台联网设备。该公司接下来会做什么？新版集线器 - Wink Hub 2 - 于去年 11 月上市，并且首次在沃尔玛商店以及家得宝商店出售。“美国两家最大的零售商都在推广该品牌和硬件，”Klein 自豪地说，但他补充说，“这确实带来了很大压力。这不是一个有很多科技爱好者的零售环境。这些都是想要能够正常工作的产品并且不能容忍技术借口的普通消费者。”这进一步证明了 Klein 对 Wink 团队构建的基础设施充满信心。
自 Wink 成立初期以来，其工程团队呈指数级增长，幕后，Klein 对 Wink 正在使用的机器学习最感兴趣。“我们构建了（一个）包含数据管道小部分的容器化系统，这些部分相互馈送并可以具有多个输出，”他说。“就像将数据管道作为微服务。” 再次，Klein 指出，在 CoreOS 容器 Linux 和 Kubernetes 上运行统一的堆栈是未来创新的主要驱动力。“你无需每次都重新发明轮子，”他说。“你可以直接投入工作。”