AWS无服务器框架Mono-Repo结构最佳实践

时间:2019-12-10 21:54:10

标签: amazon-web-services aws-lambda serverless-framework serverless aws-serverless

我正在从事一个相当大的AWS无服务器项目,并且我对该过程并不十分熟悉,因此我对如何正确构建应用程序有一个更基本的问题。

正在使用的主要AWS服务是Lambda,Dynamo,S3,Cognito和IoT。 有本机iOS和Android应用程序以及Angular仪表板和Google Home + Alexa。他们都使用本机SDK通过Cognito进行身份验证,但将Lambda端点用于所有其他云通信。

有些Lambda端点是移动应用独有的。 有些Lambda终结点是语音助手专用的。 有一些Lambda终结点专用于角度仪表板。 有些Lambda终结点仅供内部使用。

我将项目分为个模块。我专门有一个模块(例如)Locations。 我还有一个专门用于Users的模块。

每个模块都包含其专有的所有资源(或多或少)。 (有一些跨模块依赖性)。这是我的工作区示例:

|- app/
|--- auth/
|----- package.json
|----- serverless.yml
|--- device/
|----- package.json
|----- serverless.yml
|--- user/
|----- package.json
|----- serverless.yml
|--- voice/
|----- package.json
|----- serverless.yml
|- lib/
|- package.json

此处有两点需要注意:

  • 根目录下的app/目录由以下内容组成: 服务。服务包含单个serverless.yml文件。
  • 每项服务都处理相对较小且自成体系的 功能。这些可能会进一步细分,具体取决于 CloudFormation堆栈大小。 (最初是个大问题!)
  • lib/目录包含可用于 所有服务。
  • 在这种情况下,您分别部署每个模块

好的,这很好,但是现在我们开始考虑环境了。 需要在所有不同的服务之间协调环境(或阶段)。根据我的阅读,您只需使用名称中定义的stage为每个环境创建重复的资源(lambda函数,s3存储桶,发电机表等)。

示例:{service}-{module}-{stage}-{endpoint},其中service是您的应用程序名称,module是您正在使用的核心服务,stage是您的环境(开发人员,stage,prod)和endpoint就是lambda函数的名称。

这是正确的假设吗?如果是这样,在他们的工作空间中如何构造它?我还想将每个Lambda函数划分为各自的角色(应用程序,仪表板,语音等)。这也将使设置策略更加容易。这是我正在寻找建议/最佳实践的地方。对于这种类型的应用程序,什么是好的工作区/文件夹结构?

谢谢!

1 个答案:

答案 0 :(得分:0)

这对我来说是一个非常漂亮的monorepo!

您对处理不同的环境完全正确。由于无服务器应用程序通常是按使用付费的,因此启动多个环境以进行测试,QA,Dev等非常容易且负担得起。

除了您带来的环境差异外,许多人还将应用程序环境划分到不同的AWS账户中。无服务器框架将处理跨阶段命名函数,存储桶和表的过程。它也可以按阶段轻松地部署到多个不同的帐户。您根本不需要调整目录结构!

您可以使用sls deploy --stage {{stage name}}部署到新阶段。

我经常收到的一个问题是如何在微服务之间共享业务逻辑的某些方面。为此,我更喜欢创建另一个名为shared的目录,并使用必要的共享逻辑在该目录中构建一个新的npm包。然后在每个微服务中,我使用NPM通过引用路径来安装软件包。这样,无服务器框架便可以在部署或本地调用功能时查找并安装本地程序包。

  "dependencies": {
    "shared": "file:../shared",
    ....
  }

在我看来,monorepos的最终弊端是所使用的任何CI / CD解决方案的复杂性。大多数(travisci,circleci)通常不了解无服务器功能的monorepos,并且您会发现自己编写了非常复杂的脚本来处理未更改的跳过服务,协调测试等。

为此,我建议尝试使用新的Serverless CI/CD工具。

希望我有所帮助!