使用来自 AWS Serverless Application Repository 的组件构建无服务器应用程序

许多人都有过多次从零开始构建用户登录或授权服务的经历。而且，您可能还构建过许多其他用于处理付款或导出 PDF 等类似的服务。其实，我们都曾不止一次地这样做过。现在，使用 AWS Serverless Application Repository，您可以投入更多的时间和精力开发业务逻辑，更快的向客户交付重要的功能。

什么是 AWS Serverless Application Repository？

借助 AWS Serverless Application Repository，开发人员可以开发、发布常用的无服务器组件并在其团队和组织之间进行共享。AWS Serverless Application Repository 的公有库包含社区构建的开源无服务器组件，这些组件可以即刻使用自定义的参数和预定义的许可进行搜索和部署。这些组件使用 AWS 无服务器应用程序模型 (AWS SAM) 构建和发布，AWS SAM 是一种基础设施即代码服务，支持 YAML 语言，用于开发 AWS 资源的模板。

如何在生产中使用 AWS Serverless Application Repository

我想构建一款可让客户选择产品并付款的应用程序。乍听上去，这会颇费周章，对不对？实际上，由于使用了 AWS Serverless Application Repository，这并未花费我多少时间。

大致而言，我构建了以下项目：

一个具有 Buy 按钮的产品页面，它自动链接到 Stripe Checkout 开发工具包。当客户选择 Buy 时，该页面会显示 Stripe Checkout 付款表单。
一项具有 API 终端节点的 Stripe 支付服务，它接受来自 Stripe 的回调，向客户收款，并发送交易成功的通知。

在本文中，我创建了一个预先构建的示例静态页面，该页面不仅会显示产品详细信息，而且具有 Stripe Checkout JavaScript 代码。

尽管使用了预先构建的页面，仍然可以集成支付服务。既然许多其他开发人员已经至少构建过一次支付应用程序，我为何还要花费时间构建相同的功能呢？这正是 AWS Serverless Application Repository 的用武之地。

查找和部署组件

首先，我在 AWS Serverless Application Repository 公有库中搜索现有组件。然后，我键入“stripe”，选择查看已创建自定义 IAM 角色或资源策略的应用程序。我看到了以下结果：

我选择名为 api-lambda-stripe-charge 的应用程序，然后在组件的详细信息页面中选择 Deploy。

在部署任何组件之前，我都对其进行了检查，以确保它的安全性和生产就绪性。

评估组件

评估 AWS Serverless Application Repository 组件的建议方法分为四个步骤：

检查组件的权限。
检查组件的实施。
在受限环境中部署和运行组件。
监控组件的行为和成本，然后再用于生产。

这可能看似与 AWS Serverless Application Repository 的快速交付优势相悖，但实际上，您只需对每个组件验证一次。然后，您可以轻松在整个公司重复使用和共享组件。

下文介绍了如何在添加 Stripe 组件时运用此方法。

1.检查组件的权限

组件分为两类：公有组件和私有组件。公有组件是开源的，但私有组件不一定如此。在本例中，Stripe 组件是公有组件。我检查了代码，以确保它不会提供可能会损害安全性的不必要权限。

在本例中，Stripe 组件位于 GitHub 上。在组件页面中，我打开了 template.yaml 文件。该文件中只有一个 AWS Lambda 函数，因此我找到了 Policies 属性并查看了它使用的策略。

  CreateStripeCharge:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs8.10
      Timeout: 10
      Policies:
        - SNSCrudPolicy:
          TopicName: !GetAtt SNSTopic.TopicName
        - Statement:
          Effect: Allow
          Action:
            - ssm:GetParameters
          Resource: !Sub
arn:${AWS::Partition}:ssm:${AWS::Region}:${AWS::AccountId}:parameter/${SSMParameterPrefix}/*

该组件使用了一个预先定义的 AWS SAM 策略模板和一个自定义模板。这些预先定义的策略模板是经过 AWS 安全团队验证和推荐的 AWS 权限集。使用这些策略来指定资源权限，是使用 AWS Serverless Application Repository 上的无服务器组件的一个推荐做法。另一个自定义的 IAM 策略允许该函数检索 AWS System Manager 参数，这是存储 Stripe 加密密钥等安全值的最佳实践。

2.检查组件的实施

我希望确保该组件的主要业务逻辑只做它应该做的事情，也就是创建 Stripe 收款。此外，识别不明的第三方 HTTP 调用以防止信息泄露也非常重要。然后，我检查了此项目的依赖项。在此次检查过程中，我使用了 PureSec，当然也可以选择其他工具，例如 Protego 提供的工具。

主要业务逻辑位于 charge-customer.js 文件中。从该文件中可以看出，直接的逻辑是简单调用 Stripe 创建收款，然后用创建的收款发布一条通知。我看到这点在以下代码中有所体现：

return paymentProcessor.createCharge(token, amount, currency, description)
    .then(chargeResponse => {
      createdCharge = chargeResponse;
      return pubsub.publish(createdCharge, TOPIC_ARN);
    })
    .then(() => createdCharge)
    .catch((err) => {
      console.log(err);
      throw err;
    });

paymentProcessor 和 pubsub 的值分别是与 Stripe 和 Amazon SNS 进行通信的适配器。我对了解它们的工作机制乐此不疲。

3.在受限环境中部署和运行组件

无服务器开发的一项最佳实践是，维护一个单独的、受限的 AWS 账户来测试无服务器应用程序。我总是会确保我的测试账户设置了严格的 AWS 账单和 Amazon CloudWatch 警报。

我登录到此独立账户，打开“Stripe component”页面，然后对其进行手动部署。部署之后，我需要验证它的运行情况。由于该组件只有一个 Lambda 函数，因此我在 Lambda 控制台中寻找该函数，并打开其详细信息页面，以便可以验证代码。

4.监控组件的行为和成本，然后再用于生产

如果我的测试账户中一切都正常运作，我通常会给组件添加监控和性能功能，以帮助诊断所有事件，并评估组件的性能。为此，我经常使用 Epsagon 和 Lumigo，但添加这些步骤会使本文的篇幅过长。

我还想跟踪组件的成本。为此，我添加了严格的账单警报，该警报会跟踪组件的成本以及该组件中各项 AWS 资源的成本。

在组件通过这四项测试后，我就可以对其进行部署，将其添加到我现有的产品选择应用程序中。

将组件部署到现有应用程序

为了将我的 Stripe 组件添加到现有的应用程序中，我重新打开了组件的 Review, Configure, and Deploy 页面，然后选择“Copy as SAM Resource”。这将必要的模板代码复制到了我的剪贴板。然后，我将其粘贴到现有的 AWS SAM 模板中的“Resources”下，从而将其添加到现有的无服务器应用程序中。这些代码如下：

Resources:
  ShowProduct:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs8.10
      Timeout: 10
      Events:
        Api:
          Type: Api
          Properties:
            Path: /product/:productId
            Method: GET

  apilambdastripecharge:
    Type: AWS::Serverless::Application
    Properties:
      Location:
        ApplicationId: arn:aws:serverlessrepo:us-east-1:375983427419:applications/api-lambda-stripe-charge
        SemanticVersion: 3.0.0
      Parameters:
        # (Optional) Cross-origin resource sharing (CORS) Origin.You can specify a single origin, all origins with "*", or leave it empty and no CORS is applied.
        CorsOrigin: YOUR_VALUE
        # This component assumes that the Stripe secret key needed to use the Stripe Charge API is stored as SecureStrings in Parameter Store under the prefix defined by this parameter.See the component README.

       # SSMParameterPrefix: lambda-stripe-charge # Uncomment to override the default value

Outputs:
  ApiUrl:
    Value: !Sub https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Stage/product/123
    Description: The URL of the sample API Gateway

我复制并粘贴了 AWS::Serverless::Application AWS SAM 资源，它根据 ApplicationId 及其 SemanticVersion 指向该组件。然后我定义了该组件的参数。

出于演示目的，我将 CorsOrigin 设置为“*”。
我无需设置 SSMParameterPrefix 值，因为它会选择一个默认值。但我通过在 Systems Manager Parameter Store 中运行如下命令设置了我的 Stripe 密钥：

aws ssm put-parameter --name lambda-stripe-charge/stripe-secret-key --value --type SecureString --overwrite

除参数之外，组件还包含输出。输出是您可以用于其他应用程序或组件的外部化组件资源或值。例如，api-lambda-stripe-charge 组件的输出为 SNSTopic，这是一个 Amazon SNS 主题。这让我可以挂载其他组件或业务逻辑，从而在付款成功时收到通知。例如，也可以挂载 lambda-send-email-ses 组件，它会在付款成功时发送一封电子邮件。

最后，我运行了以下两个命令：

aws cloudformation package --template-file template.yaml --output-template-file output.yaml --s3-bucket YOUR_BUCKET_NAME

aws cloudformation deploy --template-file output.yaml --stack-name product-show-n-pay --capabilities CAPABILITY_IAM

对于第二个命令，您可以根据需要添加参数覆盖。

我的产品选择和付款应用程序已成功部署！

小结

AWS Serverless Application Repository 让我可以分享和重复使用常用的组件、服务和应用程序，从而真正专注于创造核心业务价值。

我只用简单几步就构建了一种可让客户选择产品并付款的应用程序。整个过程花费了几分钟，而不是几小时或几天！您可以看到，无需很长时间即可对组件进行仔细的分析和检查。现在，我可将该组件与公司的其他团队共享，这样他们也能消除重复劳动。

现在，您可以立即使用 AWS Serverless Application Repository 来加快您的团队开发产品、交付功能以及构建和共享生产就绪型应用程序的方式。

亚马逊AWS官方博客