美國移動支付巨頭 Square 的無服務器應用實踐

Square 和雲

Square 正處於向雲遷移的早期階段。現在，我們的大多數應用程序都運行在自己的數據中心。

我們的平台和基礎架構工程（PIE）團隊一直負責提供在數據中心構建和運營應用的基礎架構和工具。不過，由於 PIE 是 Square 一個較小的部門，因此它的產出存在很多局限。PIE 認為雲計算可以為 Square 工程師創造機遇，幫助他們選擇更適合自身需求的工具和架構模式。

我們的策略分為兩個層面：

首先，讓團隊以最小的代價將現有應用程序遷移至雲端；

其次，為團隊提供工具和基礎架構，幫助他們使用雲原生模式來構建應用程序。

我們的雲原生開發一開始關注的是無服務器應用程序。Square 有 160 多個工程團隊，關注的問題領域多種多樣，包括外部 API、內部 Web 應用程序、支付處理、語音系統等等。在數據中心內

Square 數據中心中的應用程序通過 Envoy 通信，使用相互傳輸層安全性（也稱為 mTLS）進行身份驗證。證書是在物理主機上自動生成和輪換的。服務到服務（s2s）的通信通過 Envoy 控制，其負責同步來自稱為注冊表（Registry）的內部應用程序提供的應用依賴項信息。

我們很早就決定將 DC 中的 Lambda 函數和部署視為同一應用程序的邏輯組件。團隊可以選擇將它們進一步分離成單獨的應用程序。

數據中心中的 S2s 調用主要依賴自動化和配置。為了讓 Lambda 能調用數據中心的應用程序，我們需要弄清楚哪些工具可以重用，哪些內容需要構建。

結果，我們發現要構建的東西有很多。我們選擇了自動化優先的思路來實現目標，這樣就用不著創建人工流程，之後還得廢棄它們了。開始轉向 AWS

團隊轉向雲中構建時，遇到的第一個障礙是帳戶、網絡和基礎架構設置。

我們原本用來在數據中心創建新應用程序的工具在雲端無法使用，於是 PIE 中的 Cloud Foundations 團隊構建了一個應用程序，團隊只需輕點按鈕或提交一個簡單的表格就能用它為已有的應用程序創建開發和暫存帳戶——可以將其看作是一個 AWS 賬戶自動售貨機。生產和第三方開發人員沙箱帳戶在創建之前需要獲得一些內部批准，我們也在努力簡化相關流程。

這意味著團隊的每個應用程序將擁有 3 或 4 個 AWS 賬戶。我們發現這種多帳戶模型帶來的收益超過了它的開銷。

請求新的 AWS 賬戶和新應用程序的簡單表格

默認情況下，所有新帳戶均使用共享 VPC 中的子網和連接到 CI/CD 管道的 Terraform 存儲庫設置。完整的帳戶創建過程用時不足 30 分鐘，無需任何人工干預，並且帳戶准備就緒時會通過 slack 和電子郵件通知開發人員。

提醒新帳戶可用的 Slack 通知，其中包括一個立即訪問賬戶的鏈接

Square 的開發人員不習慣在數據中心中創建或管理自己的基礎架構。Cloud Foundations 團隊采訪了內部客戶，了解他們想要使用哪些工具來管理雲中的基礎架構。AWS 控制台用戶界面確實很有用，但依靠它來管理基礎架構的路徑是無法擴展的。我們將 Terraform 用作基礎架構即代碼解決方案，該方案已被 Square 的一些團隊使用。

我們構建了幾個 Terraform 模塊，來幫助安全地配置 AWS 賬戶和 Lambda 函數。這些模塊負責處理常見需求，例如設置 IAM 以供我們的 CI 系統使用，以及用 s2 正常工作所需的正確權限和約定來銷毀 Lambda 函數。團隊使用中心化管理的 Terraform CICD 管道，其中基礎架構的更改也會像我們部署的其他內容一樣提交代碼審查。Lambda 和 mTLS

我們希望確保 Lambda 可以進入 Envoy 服務網格，並像 Square 上的其他應用程序一樣參與工作。具體來說，我們不希望從 Lambda 調用的應用程序需要任何更改——它運作起來應該和其他服務調用一樣。

這涉及許多運動部件，因為所有服務到服務的調用都使用 Envoy 和 mTLS。Lambdas 接入 Envoy 需要證書和路徑。無法讓 Envoy 作為 Lambda 的 sidecar 運行，因此我們需要弄清楚請求是如何到達 Envoy 實例的。證書

每個 Lambda 需要 TLS 憑據（證書和私鑰對）和一組根 CA 證書才能執行 mTLS。根 CA 證書已添加到可供我們 AWS 組織使用的，內部可訪問的 s3 存儲桶中。

與 Square 的其他應用程序一樣，Lambda 函數使用其 TLS 憑據對其他應用程序進行身份驗證。Envoy 和服務器應用程序均基於客戶端 TLS 證書中的身份驗證，檢查調用方是否有權進行 API 調用。這意味著憑據是高度敏感的，並且有必要以最小特權的方式訪問。

我們通過兩種方式做到了這一點。

首先，我們將元數據添加到注冊表的應用程序中，以指示應用程序在 AWS 中具有資源，並添加了默認標志來控制證書的生成。團隊必須選擇在 AWS 中生成證書，這樣可以避免生成潛在的高權限憑據，除非雲中的應用程序組件需要它們。

該 UI 允許為一組 AWS 賬戶打開或關閉 Lambda s2s 功能。

其次，在 AWS 內部，安全基礎架構團隊構建了一個系統，檢查注冊表中的元數據，然後僅為需要它們的應用程序生成短期證書。這將在後台使用 AWS Private Certificate Authority（PCA）。每個證書都通過資源策略保存到中央 AWS Secrets Manager，其資源策略決定哪些 AWS 帳戶和角色可以讀取它。Lambda 在其短壽命容器的生命周期內對其進行緩存。證書每 12 個小時生成一次，並且僅生效 24 小時，這樣即便證書被盜或無意泄漏，也能限制攻擊窗口。

以上就是我們構建證書生成系統的簡要概述。關於更詳細的內容，我們將在以後的博客文章中介紹它。進入服務網格

Envoy 還用於服務發現和負載平衡。由於 Lambda 沒有 sidecar，並且服務之間的所有通信都是通過 Envoy 進行的，因此我們需要另外一塊工具來將通信路由到服務網格。

我們最初嘗試構建一個 L7 代理，它將重新簽名來自 Lambda 的請求，但這將創建一個能模仿其他任何應用程序身份的強大應用程序。我們認為這種安全風險是無法接受的。我們還研究了在每個需要調用數據中心的 AWS 賬戶中部署 Envoy 的方法，但意識到這將給應用程序團隊和 PIE 中的中央流量團隊帶來運營負擔，並增加成本。

最後，我們部署了一個“網格網關”Envoy 作為 L4 代理，駐留在我們的共享 kubernetes 集群中，前端是網絡負載均衡器。網格網關使用 SNI 標頭將請求轉發到請求的後端服務，但是 TLS 握手仍由調用的 Lambda 處理。這允許 Lambda 將請求發送到 staging.appname.meshproxy.internaldomain.com，並且網狀網關會將請求路由到正確的後端。

對我們而言，這是最佳折衷方案：一個 Envoy 無法訪問多個應用程序的私鑰，所有團隊的運營壓力都不算大，並且 Lambda 仍然可以利用 Envoy 的功能，因為 Envoy 就在請求的另一端。

架構概述，包括使用 PCA 生成證書的帳戶，從機密管理器中提取證書的 Lambda 以及通過 L4 Envoy 代理請求路由的過程。Lambda 代碼

其他基礎架構都就緒後，Lambda 就需要使用它了。這意味著下載 s2s 憑據並執行 mTLS 握手。通過與內部客戶的交流，我們得知需要支持多個 Lambda 運行時，最初是 Ruby 和 Golang。我們還了解到大家想盡可能減少需要維護的庫，尤其是在涉及 mTLS 握手的代碼時。由於 Square 具有廣闊的技術前景，因此 Lambda 需要自定義的 mTLS 邏輯，並且我們希望盡量避免重複。

我們的解決方案是一個 golang 軟件包，它可以檢索和緩存證書，並在 Lambda 函數中處理 mTLS 邏輯。使用 go 運行時的任何 Lambda 都可以直接導入這個包。對於其他語言，我們將一個二進制 Lambda 層分發給整個組織。這個層創建了一個反向 HTTP 代理，其在後台使用了與 go http 客戶端相同的代碼，這樣 mTLS 代碼只需放在一處即可。對於其他語言，我們還開發了將二進制文件作為後台進程啟動的庫，並提供了正確配置的 http 客戶端供 Lambda 使用。這些特定於語言的庫比 go 軟件包小得多，這樣維護它們和接受內部開發人員社區的貢獻也就容易多了。

我們為在 Lambda 內運行而構建的所有內容均依賴於常規庫，而不是什麼市面可用的無服務器開發框架。我們的目標是與框架無關，以便團隊可以選擇最能滿足其產品、安全性和時間要求的工具。總結

上述工具鏈和基礎架構的結合使團隊可以隨意設置自己的 AWS 賬戶。這套工具鏈（特別是來自虛擬自動售貨機和 Terraform CI/CD 管道的 AWS 賬戶）能確保團隊以一致的方式設置和管理賬戶。該基礎架構有一個單獨的 AWS 賬戶，負責生成證書和作為 kubernetes 中應用程序的 Envoy，整個架構負責創建從 Lambda 到數據中心的安全通信流。

原文鏈接：

https://developer.squareup.com/blog/enabling-serverless-applications-at-square/

關注我並轉發此篇文章，私信我“領取資料”，即可免費獲得InfoQ價值4999元迷你書！