首页 > 后端开发 > Golang > 使用 AWS SAM 和 Go 构建 API

使用 AWS SAM 和 Go 构建 API

Patricia Arquette
发布: 2025-01-20 12:05:09
原创
468 人浏览过

Building an API with AWS SAM and Go

AWS SAM是通过基础设施即代码(IAC)部署Web应用程序的绝佳方式。我最近尝试在我的工作项目中使用它,却遇到了一个严峻的现实……

Go是AWS的丑小鸭 ?

AWS SAM文档中专门介绍Go的部分非常简短且含糊不清,建议大量重复我们的源代码!每个lambda函数都有一个go.mod、go.sum和实用函数?!

我写这篇文章是为了像我一样迷茫的你?‍?。让我们一起解决这个问题!

这将是一个两部分的系列:

  1. 文件结构(本文)
  2. SAM配置

Go运行时的上下文

目前,lambda的Go运行时不受支持。这意味着AWS lambda没有特定选项来指定您的代码是用Go编写的。相反,AWS提供2个通用运行时?:

  • al2(Amazon Linux 2)
  • al2023(Amazon Linux 2023)

这指的是lambda将运行的操作系统。建议使用al2023,因为它更新,并且与AWS Graviton处理器兼容,后者可以以更低的价格提供更好的性能。

无论如何,这些运行时要求我们提供一个可执行文件(通常命名为bootstrap),该文件将在每个lambda函数中执行。因此,我们不是向lambda交付代码,而是交付我们之前用Go编译的可执行文件。很简单,对吧?

这也消除了像JS这样的语言需要使用lambda层的必要性,因为所有常见的依赖项都将打包在已编译的可执行文件中?。

问题

那么,我们如何构建该可执行文件呢?AWS建议我们每个lambda都应该存储在一个文件夹中,以及它的go.mod和go.sum,他们提供的模板如下所示:

<code>.
├── hello-world/
│   ├── go.mod
│   ├── go.sum
│   └── main.go
├── events/
│   └── ...
├── samconfig.toml
└── template.yaml</code>
登录后复制
登录后复制

这是template.yaml中的函数定义

<code>  HelloWorldFunction:
    Type: AWS::Serverless::Function 
    Metadata:
      BuildMethod: go1.x
    Properties:
      CodeUri: hello-world/
      Handler: bootstrap
      Runtime: provided.al2023
      Architectures:
        - x86_64
      Events:
        CatchAll:
          Type: Api
          Properties:
            Path: /hello
            Method: GET</code>
登录后复制
登录后复制

如果我们查看Lambda定义,我们会了解到:

  1. BuildMethod: go1.x 我们使用AWS内置的Go构建器来为我们构建可执行文件
  2. CodeUri: hello-world/ lambda代码将专门存储在这个目录中。
  3. Handler: bootstrap 可执行文件的名称将是bootstrap
  4. Runtime: provided.al2023 这将是运行时。

你看到问题了吗?目前我们需要第二个lambda,我们必须创建一个带有自己go.mod、go.sum和依赖项的新目录,如果我们想在两个lambda之间共享一个实用函数怎么办?太糟糕了?!你必须将相同的文件复制到新的lambda文件夹中。留下一个看起来像这样的文件结构:

<code>.
├── function1/
│   ├── go.mod
│   ├── go.sum
│   ├── main.go
│   └── SHAREDFUNC.go
├── function2/
│   ├── go.mod
│   ├── go.sum
│   ├── main.go
│   └── SHAREDFUNC.go
├── events/
│   └── ...
├── samconfig.toml
└── template.yaml</code>
登录后复制

这太糟糕了?!有很多重复的代码!并且随着我们添加的lambda越多,它会变得更糟。一定有更好的方法!

解决方案

由于我想通过所有lambda共享go.mod、go.sum和实用程序代码,我想出了这个结构:

<code>.
├── hello-world/
│   ├── go.mod
│   ├── go.sum
│   └── main.go
├── events/
│   └── ...
├── samconfig.toml
└── template.yaml</code>
登录后复制
登录后复制
  1. 我将所有公共代码分解到internal/文件夹中,
  2. 将go.mod和go.sum文件放在根目录中
  3. 将所有lambda入口点移动到/cmd(在Go中存在这种约定,每当项目产生多个可执行文件时,入口点都放在cmd目录中)

现在我只需要通知AWS SAM这个新的结构?!我只是通过调整CodeUri和Handler的值找到了解决方案。

秘密?

似乎如果你

  • 将go.mod和go.sum移动到根文件夹
  • 将CodeUri设置为函数入口点所在的任何文件夹。

SAM将自动检测它并使用根依赖项和internal/代码进行构建? ? ?

<code>  HelloWorldFunction:
    Type: AWS::Serverless::Function 
    Metadata:
      BuildMethod: go1.x
    Properties:
      CodeUri: hello-world/
      Handler: bootstrap
      Runtime: provided.al2023
      Architectures:
        - x86_64
      Events:
        CatchAll:
          Type: Api
          Properties:
            Path: /hello
            Method: GET</code>
登录后复制
登录后复制

可以更好吗?

是的✨,我们将在下一篇文章中讨论更多自定义Go编译的方法!

以上是使用 AWS SAM 和 Go 构建 API的详细内容。更多信息请关注PHP中文网其他相关文章!

来源:php.cn
本站声明
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn
作者最新文章
热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板