挑战
构建低延迟、高可靠的基础设施，用于服务数百万已连接智能家居设备与公司消费者集线器和移动应用之间的通信，重点在于横向扩展能力、快速加密所有内容的能力以及在出现问题时能够轻松恢复连接。
解决方案
全面使用 Kubernetes-Docker-CoreOS Container Linux 技术栈。
成效
“美国最大的两家零售商 [Home Depot 和 Walmart] 都在销售和推广这个品牌及硬件，” Wink 工程主管 Kit Klein 自豪地说——但他补充道，“这确实伴随着很大的压力。这不是一个有很多技术爱好者的零售场景。这些是希望东西能用起来并且对技术借口零容忍的普通人。”这进一步证明了 Klein 对 Wink 团队所构建基础设施的信心。凭借 Wink 80% 的工作负载运行在统一的 Kubernetes-Docker-CoreOS 技术栈上，该公司能够不断创新和改进其产品和服务。Klein 说，致力于这项技术，“使得在此基础设施之上进行构建相对容易”。
Kit Klein 拿出手机进行演示。Wink 工程主管 Kit Klein 轻轻滑动几下，打开了这家总部位于纽约市的公司创建的智能家居应用，然后点击了灯光按钮。他说：“说实话，当你拿着手机点亮灯时，当你感觉到手指触碰屏幕的压力时，灯就亮了。它只需要信号传到你大脑的时间。”
当然，打开灯——或者锁门、调节恒温器——只需要一根手指和不到 200 毫秒的时间。但是，Wink 能够以如此之快的速度和便利性帮助消费者管理他们的联网智能家居产品，得益于 Klein 及其团队使用统一的技术栈构建并不断发展的先进的云原生基础设施，该技术栈包括用于集群部署的开源操作系统 CoreOS，以及一个用于跨主机集群自动化应用容器的部署、扩展和运维的开源平台 Kubernetes，提供以容器为中心的基础设施。Klein 说：“当你有一个庞大、复杂的相互依赖的微服务网络，它们需要能够相互发现，并且需要具备横向扩展和容忍故障的能力时，这正是它真正优化的方向。很多人最终依赖一些大型云提供商提供的专有服务来做这些事情，但是通过采用 CoreOS/Kubernetes，你获得的是可移植性，不会被任何人锁定。你真的可以掌控自己的命运。”
事实上，Wink 做到了。该公司的使命宣言是让互联家庭易于使用——也就是说，对非技术用户友好、价格实惠，也许最重要的是可靠。Klein 说：“如果你点下开关却无法相信灯会亮，或者你远程查看房屋时信息不准确，那么系统的便利性就丧失了。”因此，基础设施就发挥作用了。
Wink 在 Quirky 内部孵化，Quirky 是一家开发众包发明的公司。Wink 应用于 2013 年首次推出，当时它只控制少量消费产品，例如 Quirky 与 GE 合作生产的 PivotPower Strip。随着智能家居产品的普及，Wink 于 2014 年在全美 Home Depot 门店推出。它的第一个项目是：一个可以与霍尼韦尔和 Chamberlain 等约十二个品牌的智能产品集成的集线器。最大的挑战将是构建基础设施，以服务于集线器和产品之间的所有这些通信，重点是最大化可靠性和最小化延迟。
“当我们刚开始的时候，我们进展非常快，试图尽快将第一个产品推向市场，即最小可行产品，” Klein 说，“很多时候你会走一条路，结果却不得不回头尝试不同的方法。但在这个特殊案例中，我们前期做了大量工作，这使得我们做出了一个非常明智的决定，将其部署在 CoreOS Container Linux 上。而这在它的生命周期中是非常早期的。”
首要关注点：Wink 的产品需要连接到人们家中的消费者设备，且设备位于防火墙后。Klein 解释说：“你没有像 URL 那样的终端，你甚至不知道那个防火墙后面哪些端口是开放的。因此，你基本上需要让这个设备唤醒并与你的系统通信，然后在云端和设备之间打开实时的双向通信。它持续在线真的非常非常重要，因为你想尽可能减少发送消息的开销——你永远不知道什么时候有人会打开灯。”
使用最早版本的 Wink Hub，当你决定打开或关闭灯光时，请求会发送到云端然后执行。随后的 Wink 软件更新实现了本地控制，将许多设备的延迟降低到约 10 毫秒。但是，随着越来越庞大的智能家居产品生态系统需要基于云的集成，低延迟互联网连接仍然是一个关键考虑因素。
此外，Wink 还有其他要求：横向扩展能力、快速加密所有内容的能力以及在出现问题时能够轻松恢复连接。Klein 说：“审视我们最初建立的整个结构，我们决定构建一个基于安全 socket 的服务。我想说，我们一直使用某种集群技术来部署我们的服务，所以我们得出的决定是，这将是容器化的，运行在 Docker 上。”
Klein 指出，在 2015 年，Docker 尚未被广泛使用，但“走在技术前沿的人们当然了解它。我们开始研究当时存在的潜在技术。其中一个限制因素是我们需要部署多端口非 HTTP/HTTPS 服务。这对于一些早期的集群技术来说并不是很适合。我们非常喜欢这个项目，并且最终在其他方面使用了一段时间，但最初它过于侧重于 HTTP 工作负载。”
Wink 的后端工程团队决定采用容器化工作负载后，他们必须决定使用哪种操作系统和容器编排平台。Klein 笑着说：“显然，你不能仅仅启动容器然后指望一切顺利。你需要有一个系统来帮助管理工作负载的分配位置。当容器不可避免地崩溃或出现其他问题时，为了重新启动它，你需要一个负载均衡器。要拥有一个强大的基础设施，需要各种各样的内务管理工作。”
Wink 考虑过直接在通用 Linux 发行版（如 Ubuntu）上构建（这将需要安装运行容器化工作负载的工具），也考虑过 Mesos 等集群管理系统（它针对拥有更大团队/工作负载的企业），但最终将目光投向了 CoreOS Container Linux。他说：“一个针对容器优化的 Linux 发行版系统正是我们需要的。我们不必费劲地尝试拿一个 Linux 发行版然后安装所有东西。它内置了容器编排系统 Fleet，还有一个易于使用的 API。它不像一些更重量级的解决方案那样功能丰富，但我们意识到，当时它正是我们所需要的。”
Wink 的集线器（以及经过改进的应用）于 2014 年 7 月推出，采用了短期部署方式，并在第一个月内将服务迁移到了容器化的 CoreOS 部署。从那时起，他们几乎将所有其他基础设施部分——从第三方云到云的集成到他们的客户服务和支付门户——都迁移到了 CoreOS Container Linux 集群上。
使用这种设置确实需要一些定制。Klein 说：“Fleet 作为基础容器编排系统非常不错，但它不负责服务实例之间的路由、配置共享、密钥等。当然，所有这些功能层都可以实现，但如果你不想花费大量时间手动编写单元文件——当然没人愿意——你就需要创建一个工具来自动化其中的一部分，我们也这样做了。”
Wink 在 Kubernetes 于 2015 年推出并与 CoreOS 核心技术集成后迅速接受了它，正如承诺的那样，它最终提供了 Wink 想要且计划构建的功能。Klein 说：“如果不是 Kubernetes，我们很可能会利用我们为创建的自动化工具实现的逻辑和库，将其用于一个更高级别的抽象和工具，以便非 DevOps 工程师可以从命令行创建和管理集群。但 Kubernetes 使这一切完全没有必要——而且它是由比我们更有丰富集群管理经验的人编写和维护的，所以一切都更好了。”现在，Wink 约 80% 的工作负载运行在 CoreOS Container Linux 之上的 Kubernetes 上。
Klein 说：“它不是专有的，它是完全开放的，并且具有很好的可移植性。你可以在不同的云提供商上运行所有工作负载。你可以轻松运行混合 AWS，甚至可以引入自己的数据中心。这就是将所有内容统一在一个 Kubernetes-Docker-CoreOS Container Linux 技术栈上的好处。如果你只需要验证一种 Linux 发行版，那么会带来巨大的安全优势。这些好处是巨大的，因为你省钱又省时。”
Klein 承认，在每一个技术决策中都存在权衡。他说：“尖端技术对某些人来说可能会令人望而生畏。为了利用这一点，你真的必须跟上技术发展。你不能把它当作一个黑匣子。紧跟开发进展。理解决策背后的原因。如果你理解项目背后的意图，从技术意图到某种哲学意图，那么这将有助于你理解如何与这些系统协调一致地构建你的系统，而不是试图与其对抗。”
Wink 于 2015 年被 Flex 收购，现在控制着全国各地家庭中的 230 万台联网设备。该公司的下一步是什么？新版集线器 Wink Hub 2 已于去年 11 月上架——除了 Home Depot 之外，首次在 Walmart 门店销售。Klein 自豪地说：“美国最大的两家零售商正在销售和推广该品牌和硬件。”——但他补充道：“这确实伴随着很大的压力。这不是一个有很多技术爱好者的零售场景。这些是希望东西能用起来并且对技术借口零容忍的普通人。”这进一步证明了 Klein 对 Wink 团队所构建基础设施的信心。
Wink 的工程团队自早期以来呈指数级增长，在幕后，Klein 对 Wink 正在使用的机器学习最感到兴奋。他说：“我们构建了一个由数据管道容器化的小部分组成的系统，它们相互馈送并可以有多种输出。这就像作为微服务的数据管道。”Klein 再次指出，运行在 CoreOS Container Linux 和 Kubernetes 上的统一技术栈是未来创新的主要驱动力。他说：“你不是每次都在重复造轮子。你只需要开始工作。”