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/

创作场景

美国移动支付巨头 Square 的无服务器应用实践