CLUTCH，Lyft的开源基础设施工具平台

今天，我们很兴奋地宣布，Lyft用于基础设施工具的可扩展UI和API平台CLUTCH已经开放源码。CLUTCH使工程团队能够构建、运行和维护用户友好的工作流程，这些工作流程还包含特定于领域的安全机制和访问控制。CLUTCH附带了几个用于管理平台(如AWS、特使和Kubernetes)的功能，并强调了可扩展性，因此它可以托管堆栈中任何组件的功能。

云计算的动态性显著降低了新基础设施的采用成本。CNCF Landscape目前跟踪300多个开源项目和1000多个商业产品。虽然组织可以快速采用这些项目和供应商，但每种新技术都有自己的一组配置、工具、日志和指标。要让开发人员在整个堆栈中快速安全地进行更改，需要对工具进行大量的前期投资和持续投资，而大多数组织都没有考虑到这一点。因此，虽然新的基础设施越来越容易采用，但很难扩展新组件的管理，特别是在整个平台的复杂性和工程团队规模增长的情况下。CLUTCH通过使基础设施团队能够为其整个工程组织提供直观、安全的基础设施管理界面，解决了这一问题。

CLUTCH是长达一年的开发周期的结果，目的是解决Lyft开发经验和工具方面的不足。离合器的核心由两个主要部件组成。GO后端被设计为一个可扩展的基础架构控制平面，将拼凑在单个协议驱动的API后面的系统集合在一起，具有共同的授权、可观察性和审核日志记录。后台API定义通过protocol buf工具自动生成前端客户端。React前端是一个可插拔的、面向工作流的UI，允许用户和开发人员在单一控制台中创建新功能，只需更少的代码、更少的JavaScript知识和更少的维护。

在开发人员工具领域，CLUTCH与其他解决方案有什么不同之处？在项目开始时，在构建我们自己的工具之前，我们对现有工具进行了彻底的分析。

缩短响应警报时的平均修复时间(MTTR)基础架构。工程师在随叫随到的情况下响应页面时，花费了太长时间通读Runbook和导航复杂的工具。

在执行维护任务时消除意外停机。由于用户遗漏了Runbook中的警告，甚至完全修改或删除了错误的资源(例如，他们认为未使用但有大量通信量和使用量的资源)，因此发生了严重的停机。

实施粒度权限，并以通用格式审核所有活动。某些权限过于宽泛，因为供应商访问控制不支持细粒度控制。此外，当我们出于安全目的从各种工具收集审计日志时，很难将这些数据提炼成关于如何改进我们的工具的可操作的见解。

提供一个平台，极大地简化未来工具的开发。按照Lyft的规模，如果不考虑直接团队之外的贡献，规模较大的项目很少会成功。我们没有足够的资源来构建Lyft需要的所有功能，更不用说支持它了。

我们从查看可用的供应商UI的缺点开始。由于缺乏专门化，供应商的工具速度很慢(在某些情况下还很危险)。它们需要不必要的步骤来执行常见任务，并提供必要信息的超集。除了简单的访问控制外，通常很少有护栏。其结果是，操作员可能会执行看似无害的操作，但实际上会降低系统性能。另一方面，他们可能不熟悉该工具，从而导致延迟补救。理想情况下，工程师每4到6周才随叫随到。很容易忘记如何使用工具，特别是考虑到无需与特定系统交互就可以进行多个待命周期的可能性。

依赖供应商工具的最终结果是由于碎片化和信息蔓延而导致的高认知负荷。

依赖供应商工具的最终结果是由于碎片化和信息蔓延而导致的高认知负荷。相比之下，与供应商无关的工具(如CLUTCH)可以使用清晰一致的用户界面来统一不同的系统，并提供专门的功能，只需尽可能少的点击和培训即可执行常见任务。

接下来，我们转向开源社区。我们发现，开源基础设施管理工具的范围通常仍然局限于单个系统，并不是针对广泛的定制而设计的。这并没有解决认知负荷和支离破碎的问题。此外，尽管有其他用于构建控制台的前端框架，但它们都没有集成具有身份验证、授权、审计、可观察性、API架构和丰富插件模型的后端框架。有一个流行的持续交付平台，它解决了许多与离合器相同的首要问题(例如，降低MTTR、用户友好的UI)。然而，它需要大量投资来运行许多微服务，并将应用程序迁移到不同于我们自己的结构。CLUTCH的后端通过在每个API端点上免费集成上面列出的核心功能，简化了功能开发。它还部署为单个二进制文件，只需要很少的运营投资。

最后，我们想要一个可以作为一个组织进行投资的平台，因此要求其他内部团队易于理解和构建。CLUTCH提供了一个集成的、有指导的开发模型，使功能开发成为一个简单的过程。除了一流的后端功能之外，Ccluch的前端还为状态管理和多步骤表单提供了独特的抽象，这使得没有大量JavaScript经验的基础设施团队可以更轻松地进行前端开发。

有关其他工具如何达到离合器的详细分析，请参阅与其他工具的比较。

特使委托书是在Lyft创建的。今天，它是最受欢迎的代理之一，部署在许多大型互联网公司，并不断推进云网络的标准。我们的团队从与更大的社区一起维护特使中学到了很多。特使用户讨论的最热门话题之一是控制平面的发展状态，特别是如何系统地集成各种不同的组件，使特使能够有效地路由和报告网络流量。这直接类似于CLUTCH，它在统一的API下集成了不同的基础设施系统。

CLUTCH采用了特使代理的许多核心模式，这些模式是在网络控制平面多年的工作中出现的。

CLUTCH采用了特使代理的许多核心模式，这些模式是在网络控制平面多年的工作中出现的。与特使一样，CLUTCH也是配置驱动、模式驱动的，并且利用模块化的基于扩展的体系结构来使其在不影响可维护性的情况下适用于各种用例。扩展CLUTCH不需要分叉或重写，并且可以很容易地将自定义代码从自定义公共或私有外部存储库编译到应用程序中。这些相同的模式使拥有独特技术堆栈的大大小小的组织能够融合到单个代理解决方案上，有望使同样独特的组织能够将离合器融合为基础设施控制平面。

此外，CLUTCH附带身份验证和授权组件。用于单点登录的OpenID Connect(OIDC)身份验证流、通过静态映射实现的资源级基于角色的访问控制(RBAC)，以及所有操作的自动审核，并能够运行额外的接收器进行输出，例如Slackbot。

离合器还具有减少事故可能性的功能。Runbook中通常记录的护栏和启发式方法可以通过编程实现。例如，我们从不允许用户一次将群集缩减超过50%，因为这种行为历来会导致正常维护期间的意外停机。将来，我们计划获取CPU和其他使用情况数据，以便与群集信息一起显示，如果我们确定这可能会导致停机，甚至会限制缩减的下限。通过在工具中直接实施护栏和启发式方法，我们避免了仅依靠培训和Runbook来防止事故的需要。

CLUTCH作为包含前端和后端的单一二进制文件发布，这使得它的部署变得微不足道。许多更改可以通过配置来实现，而不是重新编译新的二进制文件。

其他提供基础设施生命周期工具的系统需要一组复杂的微服务，或者需要迁移到一种固执己见的管理和部署应用程序的方式。离合器是用来补充现有系统的，而不是取代它们。

离合器是由GO后端和反应前端提供动力的。它为后端和前端开发提供了功能齐全的框架。CLUTCH中的所有组件都是可组合的，允许部分使用框架产品或完全自定义功能。

这种组件和工作流体系结构允许前端经验有限的开发人员在不到一小时的开发时间内将笨重的工具或命令行脚本替换为清晰易用的分步UI。

CLUTCH的前端软件包提供组件，可轻松构建分步工作流，提供一致、无缝的用户体验，包括：

DataLayout，处理用户输入和来自API调用的数据的工作流本地状态管理组件。

自定义材质UI组件，用于跨工作流以一致的方式用最少的代码显示丰富的信息。

CLUTCH的后端在很大程度上依赖于从Protobuf API定义生成的代码。Protobuf工具还生成前端客户端，使后端和前端随着API的发展保持同步。后端组件包括：

解析器，基于自由格式文本搜索或结构化查询定位资源的通用界面。

解析器是一种离合器抽象，我们希望它能对将功能抽象到多个组织的方式产生重大影响。使用自定义资源位置代码可以轻松扩展解析器，从而允许操作员通过组织习惯的通用名称而不是简洁的规范标识符来定位资源(如K8s Pod或EC2实例)。例如，如果开发者将其应用程序命名为`myService-staging`，则很容易添加代码，将此类查询解释为结构化元素`${APPLICATION_NAME}-${Environment}`。此外，前端从后端定义自动生成用户输入表单。

在后端配置额外的搜索维度会自动在前端呈现的形式中反映出来。

在推出CLUTCH之前，Lyft的工程师依赖命令行工具、Web界面和Runbook的大杂烩来执行简单的任务。Lyft最常见的警报需要多达六个不同的信息源才能解决：警报、其他服务仪表板、Runbook、其他文档源、供应商控制台或脚本以及配置设置。当Lyft在团队、产品和堆栈方面进行扩展时，我们意识到工具没有跟上步伐。我们没有办法用现有的框架来解决这些问题。这导致了第一代离合器的开发。

在过去的一年里，无论是在使用还是开发方面，CLUTCH的内部采用率都令人难以置信。数以千计与基础设施管理相关的其他高风险操作都经历了离合器，每一项操作都代表着发生事故或延迟事件缓解的可能性，导致我们的司机和乘客失去信任。在撰写本文时，已经有7个内部工程团队计划在2020年底之前添加新功能，其中至少有一半是针对开源的。工程师(包括我们优秀的实习生)已经能够在有限的指导下开发有意义的功能。最重要的是，我们终于能够看到通过单一平台交付内部平台的前进道路，使Lyft基础设施成为满足客户需求的产品，而不是拼凑在一起的系统和工具集合。

“我很高兴它的存在，否则我现在还在等着加载到云提供商的控制台上。”

关于Lyft离合器的更多细节可以在Lyft案例研究文章中找到。

在构建CLUTCH的整个过程中，产品不断发展，我们的外部和内部路线图现在涵盖了Lyft开发人员的全部体验。我们的长期愿景包括构建一个上下文感知的开发人员门户。不仅向开发人员提供一套工具，而且在用户登录门户后立即呈现最相关的工具和信息。

特使UI，为用户提供实时仪表板来监控其分布式应用程序的网络行为和配置。

混沌测试，与特使集成，允许使用自动中止标准进行预定的故障注入和挤压测试。

其他基础架构生命周期管理功能，查看群集状态以查找异常值，执行长期维护任务。

服务运行状况仪表板，使用可配置的报告机制向开发人员提供有关其服务状态(例如，代码覆盖率、成本、活动事件)的反馈。

通用配置管理，允许用户通过有指导的UI管理复杂的配置，或者以代码声明的形式反映基础架构中的更改。

拓扑映射，将用户与他们拥有的服务相关联，并在登录页面上向他们显示相关数据和工具。

CLUTCH对Lyft的开发体验产生了重大影响，使基础设施和其他工程团队能够将工具作为精致的产品交付，而不是事后才想到的产品。团队对在内部贡献新功能感到超级兴奋，Lyft的工程师们也喜欢使用这个平台：

易用性超级棒，提高了Lyft工程师的整体生活质量。“。

加入我们！我们认为，离合器对其他大小工程团队都有同样突出的潜力。我们期待着与社区合作开发更多插件和核心功能，以构建丰富的生态系统。我们的目标是让每个团队和每个技术堆栈都能使用一流的云本地工具，并降低认知负荷。所有的贡献都是受欢迎的，从想法到实现，我们很乐意帮助您开始您的第一个功能。

如果没有Lyft许多工程师的贡献和辛勤工作，包括Sindhura Tokala，Matthew Gumport，Scarlett Perry，Ryan Cox，Shawna Monero，Bill Gallagher，Gastón Kleiman，Paul Dittamo，Mike Cutalo，Rafal Augustiniak，Alan Chiu，Kathan Shah，Ansu Kar，Tony Allen，Amy Baer，Stephan Mercatoris，Susan Li，Jose Nino，特别感谢帕特里克·桑迪，马丁·孔蒂·麦克唐奈，波利·彼得森，迈克尔·雷贝洛和皮特·莫雷利。再次感谢所有直接参与该项目的人，以及在整个过程中为我们提供指导和支持的人。

我们迫不及待地想看看开源社区将把这个项目带到哪里去。前进！