你以为只是“吃鸡”餐厅，别人却有物联网和云平台

对于餐馆运营者来讲门庭若市是好事，但客流量太大对于餐厅日常运营来讲是不小的压力，毕竟人越多，等待时间越长，客户的满意度就会直线下降，这对快餐厅来讲是致命的。

这家美国连锁“吃鸡”餐厅想出了用物联网的方式在所有餐厅收集大量数据后上传到公司内部云端，然后运用算法在云端做流程自动优化来提高运营效率。这年头开餐馆的都有云平台，厉不厉害。

我们如何为餐厅做运行中Kubernetes边缘算法的裸机聚类. 我们收到最常见的（也是最棒的）问题就是“但为什么呢？”，接下来，我们在本文中会对此作出回答。

为什么在餐厅中运用K8s？

为什么像Chick-fil-A这样的餐厅想要运用Kubernetes边缘算法？目标是什么？我们的结论是：

• 低延迟、基于网络的可靠应用

• 这些应用的可用性极高

• 为快速创新、和快速实现功能落地提供了平台

• 横向对比——基础设施和应用开发团队

容量压力

Chick-fil-A很大程度是因其诱人的食品和完美的客户服务而成功，而这些都是得益于在我们餐厅中辛勤工作和运营的优秀员工，他们在业内无人能及。所以结果就是餐厅非常繁忙。如果你去过Chick-fil-A，你会懂的。

在曼哈顿人潮拥挤的Chick-fil-A，图为正在餐厅门口排队等待的食客。该图来自华尔街日报

我们非常感恩能取得这样的成功，但这个成功给我们的业务运营带来了很大压力。整体来看，我们周日休息，但一周六天的营业额比竞争对手一周七天的还要高。我们有些店面的人流量比最初设计考虑最大人流量限制的三倍还要多。这些都是需要去解决的问题，首当其冲的就是规模引起的容纳能力的问题。

我们认为Chick-fil-A大部分容纳问题都可以由科技来解决。

“新一代”工作体量

我们的解决方法之一就是投资让餐厅更智能化。

我们的目标是：为餐厅加盟商/运营者、以及他们的员工简化餐厅工作流程，保证食物优质美味以及提升美食的供给速度，同时，加强当前客流量的容纳能力。

我们所有的努力都是基于这个假设：智能化厨卫设施能够收集更多数据，将这些数据运用在餐厅上，我们可以建立起更加智能化的系统，从而更好扩展业务版图。

举个简单的例子，想象一个能够预测每分钟应当烤制多少个华夫饼（或是其它食物）的预测模型。使用餐厅里的各种业务层面数据，模型经过云端的分析计算过程，推导出最后的预测结果。

虽然这个预测结果并不需要花费大量的精力，但它并不完全准确，也不能提高食物生产量。Chick-fil-A的营业额还会受到多方面因素影响，包括上下班高峰期、当地具体情况（交通、体育活动、天气等）。

但如果我们从销售点系统中的实际交易里收集数据来获得当下需求情况，并加入炸锅里正在制作食物情况的数据，再对之前提到的预测模型的结果进行微调，我们能够得到一个对于当下应该做什么种类、做多少份食品的更为准确预测结果。

这些数据也能给例如大厨或其他餐厅工作人员一个更智能的展示，也许未来能够促进厨房无人化的发展。

这样的目标带领着我们为我们的餐厅建立了一个物联网（IOT）平台。为了更好地扩张业务，我们还要掌握以下能力：1. 收集数据；2. 将这些数据应用于餐厅自动化的发展。

相对于选择那些生硬、独立，难以整合的供应商服务，我们想要拥有一套完全属于我们自己具有开放性的产业生态链。这个方法使我们的内部开发者和外部合作商能够开发互通的“平台”（或者说是Edge的应用），并且能够促进我们平台支持类似于安全性、独特性和互通性的普遍需求。

换言之，IOT/Edge团队是我们部署在Edge上整个应用程序基础里的一小部分，也是我们餐厅中运营部门平台中有效的运营助手。

构架概览

这是一个我们为达到目标而开发，也是目前正在使用的平台构架。

我们目前构架的简单简单示意图

云控制面

目前，我们在云端运行高阶控制面板和核心“物联网”服务，其中包含以下服务：

• 授权服务器——设备识别码管理

• 数据摄取/渠道——收集数据，并将其传输至需要的地方

• 运行中的时间序列数据——记录、监控、预警、追踪

• 配置管理——为我们使用GitOps（给Weaveworks上给我们提供这个名称的朋友们点赞）的应用团队提供自选服务配置。我们计划尽快分享出成果和源码。

这些服务的运行是基于Kubernetes，因此为我们团队的部署中提供了共同的范式。

边缘

边缘算法也即：部署运算资源，使之尽可能地达到更高的可用性和/或更低的延迟时间。

我们将我们的边缘算法环境视为“微型私有云”，也就是说，我们为开发者提供了一系列好用的服务，也可以在我们基础构架上部署他们的应用程序。

这是否意味着我们成为世界上最大的“云服务提供商”呢？你说了算。

回归正题，这个方法给了我们一种独特的规模。相比带有数十万 工具 集的几个大型K8s集群，我们可以全面地使用超过两千个集群，每个带有十来个工具集。这个数字还能随着我们每年新开店面而显著增长。

我们的边缘工作量包括：

• 提供类似于身份令牌服务、播送接收传讯(MQTT)、日志收集/导出(FluentBit)、监控（Prometheus）等服务

• 餐厅中与“物联网”产生交互的应用

• 一些响应HTTP请求的简单微型服务

提供一些机器学习模型：利用实时事件（MQTT）与合成云端开发预测，从而帮助在边缘做出决策和促进自动化。

我们的边缘计算物理环境从多个餐厅内交换机（和两个路由器）获得连接，因此系统可以在高性能局域网内运行。

现在，几乎所有在系统中收集的数据只会在本地保存极短的时间，之后会被上传到云端。 数据保存的流程可能会在未来改变，但目前的策略使我们早期的系统部署非常简单，并使数据更易于管理。

由于我们拥有一个高度可用的Kubernetes集群，并且在所有节点上都复制了数据，我们可以保留所有收集的数据，直到互联网再次可用于数据传输为止。 我们还可以根据业务需求在Edge上动态聚合，压缩或删除数据。

考虑到以上特性，我们仍然首先使用云来提供我们的服务。 Edge可以当做一个高可用，低延迟，供餐厅内使用的必不可少的后备部署系统。

跟随巨人的脚步

我们在消费级硬件上运行我们的边缘基础设施，大约花费是1000美元/餐厅。 我们希望硬件投资保持低成本和可扩展性。 我们目前还未找到方法让硬件系统的增加变得动态/有弹性，但也许有一天可以做到。

借助我们的架构，可以根据需求来添加其他设备以增加额外的计算容量。我们的硬件系统足够应付当前的工作量，未来我们可能会扩大硬件设备空间。 谷歌也开始在商品硬件上增加工作负载。所以我们的方向是对的。

我们希望自己的边缘计算系统可以鼓励那些受限于有限资源（物理空间，预算或其他方面）的人进行创造性思考。 简单来说每个人都有这样的需求。

其他

最后，我们有连接层和物联网的问题需要解决。 许多设备都是直接供电的（没有电池），但仍然受到芯片/处理能力的限制。 Wi-Fi是设备默认的连接方法。 我们尚未致力于使用低功耗协议，但对LoRa和WiFi Halo（802.11ah）等项目感兴趣。

对于物联网和物理设备，我们的团队还为开发人员提供了一个SDK，用于执行入职流程（基于OAuth）和访问Edge环境中的服务，如MQTT。 Brian在QConNY 2017上更广泛地讨论了这个问题（注意，我们当时使用的是Docker Swarm与Kubernetes）。

边缘系统中功能

为什么要在Edge系统中运行一些功能呢？ 出于同样的原因，您可以在云中（或其他任何地方）运行它们。

因为项目管理和测试会变得更加容易。 开发人员体验更轻松，更好。 团队可以更快，更自主地执行计划，尤其是在有合理的抽象点（例如k8s名称空间）和资源限制（CPU / RAM）时。

另一个设计的关键目标是保证关键应用的可靠性，这意味着架构中不可以出现任何单点故障。 可以通过多种方式实现此类目标，但我们认为在Edge系统上拥有多个物理主机，并且依靠基于功能的业务流程，可以让我们执行多种工作负载并且最大化发挥团队人员的技能。

我们最初称我们的策略为“餐厅冗余计算”，它真正说明了我们的方法背后的目标。 后来，我们改称为“边缘计算”。

能够有效地协调服务并快速一致地保留所需数量的数据副本，Kubernetes这些能力吸引了我们。

为什么选择Kubernetes？

起初，我们计划使用Docker Swarm进行容器编排，但是在2018年初转向Kubernetes，因为我们相信它的核心功能和周围的生态系统（迄今为止）是最强的。 我们很庆幸用Kubernetes相关的一些开发程序，如Istio和OpenFaaS。

最重要的是，我们坚信：创意本身并没有价值，代码本身没有任何价值，唯一有价值的是在生产中运行的代码。 只有这样，我们才能为用户创造价值，并有机会改善自己的业务。

因此，在Chick-fil-A，我们希望优化好的想法，将它们转换为代码，并尽可能快地在生产中部署代码。

研究表明，使用最新最好的技术（如Kubernetes）与团队或组织的成功无关。将想法转化为代码并快速将代码投入生产的能力才是最重要的。

如果您可以通过VMWare，一台计算机，一些其他集群工具或业务流程层或仅使用云来实现此目标，我们就不会试图说服你切换到Kubernetes并跟随我们的选择。 通常，最简单的解决方案才是最佳解决方案。

在Chick-fil-A，我们认为实现这些目标的最佳方式是接受集群化，并使用Kubernetes系统。 在每一天结束时，它都可以帮助顾客更多更好地“多吃鸡”（Eat More Chicken该餐厅标志为一只鸡的头像）。