今天我們很高興地宣佈，Lyft 的基礎設施工具可擴充套件 UI 和 API 平臺clutch已開放原始碼，clutch使工程團隊能夠構建、執行和維護使用者友好的工作流，這些工作流還包含特定於域的安全機制和訪問控制。clutch相容多種管理平臺功能（如 AWS、Envoy和Kubernetes）(https://www.alauda.cn)，強調可擴充套件性，因此它可以為堆疊中任何元件提供託管功能。

雲端計算的動態屬性顯著地降低了新基礎設施的採用成本。CNCF雲原生計算基金會全景圖跟蹤了300多個以上開源專案和1000多個商業產品。儘管各組織們能快速採用這些專案和供應商，但每種新技術都有它自帶的一套配置、工具、日誌和指標。為了讓開發者快速、安全地在整個堆疊中變更，需要在工具方面進行大量前期和持續的投資，而大多陣列織都未能考慮到這一點。所以，雖然新基礎設施越來越容易採用，但日益擴大的新元件的規模難以管理，特別是隨著整個平臺的複雜性和工程團隊規模的增長。Clutch解決了這一難題，通過讓基礎設施團隊向他們整個工程組織提供直觀和安全的基礎設施管理介面。

Clutch是一年開發週期的成果，用來解決“Lyft”開發人員經驗和工具的短板。Clutch由兩個核心部件組成。go後端設計為可擴充套件的基礎設施控制平面，將單個由protobuf驅動的API拼湊成具有通用授權，可觀測性和審計日誌記錄的系統。React前端是一個可插拔並且面向工作流的UI允許使用者和開發者在單個窗格後建立新功能，這隻需要很少的程式碼和很少的JavaScript知識及更少的維護工作。

1 設計和架構

在設計和架構方面，比起其他解決方案，clutch提供了與眾不同的開發人員工具空間。在專案開始時，我們在構建自己的工具前對現有工具做了深入分析。採用工具的主要目的是：

•減少平均維修時間。基礎設施什麼時候響應告警，工程師們待命時花太多時間在閱讀runbooks和操作複雜的工具。

•消除意外中斷。當執行維護任務時，當用戶在使用runbook時漏掉警告或者刪除錯誤的資源（例如，他們認為沒有使用，但佔用了很大流量的資源），從而導致嚴重中斷。

•強化細粒度的許可權並以通用格式審計所有活動，一些許可權過於寬泛，是因為供應商的訪問控制不支援細粒度控制元件，此外，當我們出於安全目的從各種工具收集審計日誌時，很難將那些資料提煉成為如何幫助我們改善工具的可執行見解。

•提供一個極大簡化未來工具開發的平臺。以“Lyft”這樣的規模，如果不考慮團隊外的貢獻資源，專案範圍很大時很難成功，我們沒有足夠的資源來構建Lyft需要的每一個特性，更別說支援它了。

一開始我們看到現有供應商UI的不足：由於缺乏專業化，供應商工具很慢 （並且在某些情況下是危險的）。他們需要不必要的步驟來執行常見任務，並提供超出必要的資訊集。除了簡單的訪問控制外，通常很少有防護，結果導致運營人員可能會執行看似無害但實際降低系統性能的操作。另外，他們也許不太熟悉該工具從而延誤補救。理想情況下，工程師每四到六週只來一次。人們很容易忘記如何使用這個工具，特別是考慮到沒有用特定的互動系統情況下，又去多種執行任務。

由於碎片化和資訊雜亂無序，依賴供應商工具的後果是高認知負荷。

相比之下，Clutch這樣一個與供應商無關的工具能將不相關的系統一體化為清晰，一致的使用者體驗，並且提供專用功能來執行常見任務，只需很少的點選和培訓。

然後我們轉向開源社群，發現開源基礎設施管理工具通常仍然侷限於單個系統，並不是為廣泛的自定義設計的，它並不能解決認知負荷和碎片化的問題。此外，雖然有用於構建控制檯的其他前端框架，但沒有一個框架包含具有身份驗證，授權，審計，可觀察性，API模式和豐富外掛模型的整合後端框架。有一個很流行的持續交付平臺，它解決了與Clutch相同的首要問題（例如，降低MTTR，使用者友好的UI）但是，它需要大量的投入來執行微服務和遷移應用到不同於我們自己的架構上。Clutch後端功能開發簡化，是通過上面列出的集成核心功能為每個API端點免費。它還開發為單個二進位制檔案，只需要很少的操作投入。

最後，我們想要一個平臺，可以對它進行投資，對其他內部團隊來說它需要更容易理解和構建。Clutch提供一個整合的和引導式開發模型，使其功能開發成為簡明直接的過程。除了一流的後端功能外，Clutch 的前端還為狀態管理和多步表單提供了獨特的抽象，沒有大量JavaScript 經驗的基礎架構團隊更容易實現前端開發。

2 特性

"控制平面"模型

Envoy 代理是Lyft建立的。如今，它是最受歡迎的代理之一，部署在許多大型網際網路公司，並不斷推進雲網絡標準。我們的團隊從與大社群一起維護Envoy中學到了很多東西。Envoy使用者討論的最熱門主題之一是控制平面的開發進展，特別是如何系統地整合各種不同的元件，以便Envoy能夠有效地路由和報告網路流量。Envoy類似於 Clutch，它整合不同的基礎設施系統於統一的API。

Clutch採用了許多envoy代理的核心模式，這些模式是在網路控制平面多年的工作中脫穎而出的。

像Envoy 一樣，Clutch 是配置驅動、模式驅動的，並利用基於模組化擴充套件的架構，使其適用於各種用例，同時不影響可維護性。擴充套件Clutch不需要分支或重寫，自定義程式碼可以很容易地從自定義公共或私有外部儲存庫編譯到應用程式中。這些相同模式使具有獨特技術堆疊的大小組織能夠聚集在單個代理解決方案上，有望使相似的獨特組織聚焦在Clutch這樣的基礎設施控制平面上。

3 安全和保障

此外，Clutch附帶身份驗證和授權元件。OpenID Connect （OIDC） 身份驗證流用於單點登入、RBAC，以及對所有操作的自動稽核，並能夠執行附加的輸出接收器，例如Slackbot。

Clutch 還具有降低事故風險的功能。通常記錄在 Runbook 中的護欄和啟發式方法可以以程式設計方式實現。例如，我們絕不允許使用者一次將群集縮減 50% 以上，因為這種操作曾經導致過正常維護時的意外中斷。不久以後，我們計劃獲取CPU 和其他使用資料，以便與群集資訊一起顯示，甚至在確定可能導致停機的情況下，限制縮小規模的下限。通過將護欄和啟發式方法直接實施到工具中，避免了僅僅依靠於培訓和執行手冊來防止事故的發生。

4 部署和使用者引導

Clutch作為包含前端和後端的單個二進位制檔案進行傳輸，使部署工作變得很簡單。許多更改可以通過配置實現，而不是重新編譯新的二進位制檔案。

提供基礎設施生命週期工具的其他系統，則需要一組複雜的微服務或遷移到一種固有的方式管理和部署應用程式。Clutch旨在完善現有系統，而不是更換它們。

5 框架和元件

Clutch由Go後端和React前端驅動。它為後端和前端開發提供了功能齊全的框架。Clutch的所有元件都是可組合的，允許使用部分框架功能或完全自定義功能。

這樣的元件和工作流體系結構讓前端經驗有限的開發人員在不到一個小時的開發時間內，就能使用清晰且易於使用的分步 UI 替換笨重的工具或命令列指令碼。

Clutch的前端封裝提供的元件，可輕鬆構建一致且連續使用者體驗的分步工作流程，包括：

•DataLayout：是一個工作流-本地狀態管理控制元件，用於處理來自 API 呼叫的使用者輸入和資料。

•Wizard：用於向用戶顯示分步表單，自定義元素的 UI 外掛，用於在以最少的程式碼以一致的方式顯示豐富的資訊。

•Clutch的後端重度依賴從ProtobufAPI 定義生成的程式碼。

Protobuf 工具還生成前端客戶端，隨著 API 的發展，該客戶端保持後端和前端的同步。後端的元件包括：

•模組：程式碼生成的 API 存根的實現

•服務：用於與外部資料來源互動

•中介軟體：用於檢查請求和響應資料以及應用稽核、授權等。

•解析器：一種基於自由格式文字搜尋或結構化查詢查詢資源的通用介面

解析器是一個Clutch抽象，我們希望會對將功能抽象到多個組織的方式產生重大影響。解析器使用自定義資源位置程式碼可輕鬆擴充套件，允許操作員通過組織習慣的通用名稱（而不是普通的規範識別符號）定位資源（如 K8s pod 或 EC2 例項）。例如，如果開發人員稱其應用程式為"myService-staging"，則很容易新增一種將此類查詢解釋為結構化元素的程式碼"$application_name=-${environment}"。此外，前端自動從後端定義生成使用者輸入表單。

前端有一行程式碼：
1

<Resolvertype="clutch.aws.ec2.v1.Instance"/>

渲染的表單如下：

在後端配置額外的搜尋維度，將會自動對映在前端渲染表單。

6 Clutch在Lyft公司

在 Clutch 之前，Lyft 工程師依靠一系列大雜燴式命令列工具、Web 介面和 Runbook 來執行簡單的任務。Lyft 最常見的警報需要解決多達六個不同的資訊源：警報、其他服務儀表板、Runbook、其他文件源、供應商控制檯或指令碼以及配置設定。隨著 Lyft 在團隊、產品和堆疊方面進行擴張，我們意識到這些工具沒有跟上步伐。我們用現有的框架解決這些問題沒有出路，這導致了Clutch的第一個迭代開發。

在過去的一年裡，Clutch 在使用和開發方面擁有令人難以置信的內部採用率。Clutch經受住了數千個與基礎設施管理相關的風險操作，每一個操作都有帶來意外或延遲的可能，導致使用者失去對我們的信任。

在撰寫本文時，七個內部工程團隊已經計劃到 2020 年底新增新功能，其中至少一半面向開源。工程師（包括我們出色的實習生）在有限的指導下能夠開發出有意義的功能。最重要的是，我們終於能夠看到一條路線，通過單一虛擬管理平臺交付我們的內部平臺，使 Lyft 基礎設施成為滿足客戶需求的一個產品，而不是拼湊的系統和工具集合。

我們在內部收到了很多積極的反饋，例如：

"我很滿意它的存在， 否則我將仍然在等待選項卡載入到雲提供商的控制檯中。

有關 Lyft Clutch的更多細節，可以在 Lyft 案例研究文章中找到。

7 路線圖

在整個構建Clutch的過程中，產品不斷髮展，我們的內外部路線圖目前包含了 Lyft 的全體開發人員經驗。我們的長期願景是構建一個情景感知開發者門戶，不僅向開發者提供一套工具，而且在使用者登入門戶時提供最有價值的工具和資訊。

即將推出的功能包括：

Envoy UI，為使用者提供一個實時儀表盤，以監視其分散式應用程式的網路效能和配置。
混沌測試，與Envoy整合來允許預定的故障注入和擠壓測試與自動停機條件。自動修正，通過適當的Clutch操作自動響應警報。
安全增強，包括效能升級、考察模態和兩階段審批。
附加的基礎設施生命週期管理功能，檢視群集的狀態以查詢異常值，執行長時間執行的維護任務。
服務健康狀況儀表板，使用可配置的報告機制向開發者提供有關其服務狀態的反饋（例如程式碼覆蓋率、成本、活躍的突發事件）。
通用配置管理，允許使用者通過引導式 UI 管理複雜配置，或以其他方式將基礎結構中的變更反映為程式碼宣告。
拓撲圖，將使用者與其擁有的服務關聯，並在登陸頁上向他們顯示相關的資料和工具。

作者：Daniel Hochman & DerekSchaller

譯者：時間