aws api 网关 &lambda:多个端点/函数 vs 单个端点 [英] aws api gateway & lambda: multiple endpoint/functions vs single endpoint

问题描述

我有一个代理 Lamba 函数的 AWS api.我目前使用不同的端点和单独的 lambda 函数:

api.com/getData -->获取数据api.com/addData -->添加数据api.com/signUp -->报名

管理所有端点和功能的过程变得繁琐.当我使用单个端点到一个基于查询字符串决定做什么的 lambda 函数时，有什么缺点吗?

api.com/exec&func=getData -->执行 -->if(params.func === 'getData') { ... }

解决方案

将多个方法映射到单个 lambda 函数是完全有效的，如今很多人都在使用这种方法，而不是为每个方法创建 api 网关资源和 lambda 函数离散方法.

您可以考虑将所有请求代理到单个函数.请查看以下有关创建 API 网关 => Lambda 代理集成的文档:http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-set-up-simple-proxy.html >

他们的例子在这里很棒.类似以下的请求:

POST/testStage/hello/world?name=me HTTP/1.1主机:gy415nuibc.execute-api.us-east-1.amazonaws.com内容类型:应用程序/json标头名称:标头值{一个":1}

最终将向您的 AWS Lambda 函数发送以下事件数据:

<代码>{"message": "你好！",输入": {"资源": "/{proxy+}","path": "/hello/world","httpMethod": "POST",标题":{接受": "*/*"，"Accept-Encoding": "gzip, deflate","缓存控制": "无缓存","CloudFront-Forwarded-Proto": "https","CloudFront-Is-Desktop-Viewer": "true","CloudFront-Is-Mobile-Viewer": "false","CloudFront-Is-SmartTV-Viewer": "false","CloudFront-Is-Tablet-Viewer": "false","CloudFront-Viewer-Country": "美国","内容类型": "应用程序/json","headerName": "headerValue","Host": "gy415nuibc.execute-api.us-east-1.amazonaws.com","邮递员令牌": "9f583ef0-ed83-4a38-aef3-eb9ce3f7a57f","用户代理": "PostmanRuntime/2.4.5","通过": "1.1 d98420743a69852491bbdea73f7680bd.cloudfront.net (CloudFront)","X-Amz-Cf-Id": "pn-PWIJc6thYnZm5P0NMgOUglL1DYtl0gdeJky8tqsg8iS_sgsKD1A==","X-Forwarded-For": "54.240.196.186, 54.182.214.83","X-转发端口": "443",X 转发协议":https"},查询字符串参数":{姓名":我"},路径参数":{代理":你好/世界"},舞台变量":{"stageVariableName": "stageVariableValue"},请求上下文":{"accountId": "12345678912","resourceId": "roq9wj","stage": "testStage","requestId": "deef4878-7910-11e6-8f14-25afc3e9ae33",身份": {cognitoIdentityPoolId":空，accountId":空，cognitoIdentityId":空，来电者":空，apiKey":空，"sourceIp": "192.168.196.186","cognitoAuthenticationType": null,cognitoAuthenticationProvider":空，userArn":空，"userAgent": "PostmanRuntime/2.4.5",用户":空},"resourcePath": "/{proxy+}","httpMethod": "POST","apiId": "gy415nuibc"},"body": "{\r\n\t\"a\": 1\r\n}",isBase64Encoded":假}}

现在您可以访问所有标头、url 参数、正文等，并且您可以使用它在单个 Lambda 函数中以不同方式处理请求(基本上是实现您自己的路由).

我认为这种方法有一些优点和缺点.其中许多取决于您的特定用例:

• 部署:如果每个 lambda 函数都是离散的，那么您可以独立部署它们，这可能会降低代码更改带来的风险(微服务策略).相反，您可能会发现需要单独部署功能会增加复杂性和负担.
• 自我描述:API Gateway 的界面让您可以非常直观地查看 RESTful 端点的布局——名词和动词都一目了然.实施您自己的路由可能会牺牲这种可见性.
• Lambda 大小和限制:如果您代理所有 -- 那么您最终需要选择一个实例大小、超时等，以适应您的所有 RESTful 端点.如果您创建离散函数，那么您可以更仔细地选择最能满足特定调用需求的内存占用、超时、死信行为等.

I have an AWS api that proxies lamba functions. I currently use different endpoints with separate lambda functions:

api.com/getData --> getData
api.com/addData --> addData
api.com/signUp --> signUp

The process to manage all the endpoints and functions becomes cumbersome. Is there any disadvantage when I use a single endpoint to one lambda function which decides what to do based on the query string?

api.com/exec&func=getData --> exec --> if(params.func === 'getData') { ... }

解决方案

It's perfectly valid to map multiple methods to a single lambda function and many people are using this methodology today as opposed to creating an api gateway resource and lambda function for each discrete method.

You might consider proxying all requests to a single function. Take a look at the following documentation on creating an API Gateway => Lambda proxy integration: http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-set-up-simple-proxy.html

Their example is great here. A request like the following:

POST /testStage/hello/world?name=me HTTP/1.1
Host: gy415nuibc.execute-api.us-east-1.amazonaws.com
Content-Type: application/json
headerName: headerValue

{
    "a": 1
}

Will wind up sending the following event data to your AWS Lambda function:

{
  "message": "Hello me!",
  "input": {
    "resource": "/{proxy+}",
    "path": "/hello/world",
    "httpMethod": "POST",
    "headers": {
      "Accept": "*/*",
      "Accept-Encoding": "gzip, deflate",
      "cache-control": "no-cache",
      "CloudFront-Forwarded-Proto": "https",
      "CloudFront-Is-Desktop-Viewer": "true",
      "CloudFront-Is-Mobile-Viewer": "false",
      "CloudFront-Is-SmartTV-Viewer": "false",
      "CloudFront-Is-Tablet-Viewer": "false",
      "CloudFront-Viewer-Country": "US",
      "Content-Type": "application/json",
      "headerName": "headerValue",
      "Host": "gy415nuibc.execute-api.us-east-1.amazonaws.com",
      "Postman-Token": "9f583ef0-ed83-4a38-aef3-eb9ce3f7a57f",
      "User-Agent": "PostmanRuntime/2.4.5",
      "Via": "1.1 d98420743a69852491bbdea73f7680bd.cloudfront.net (CloudFront)",
      "X-Amz-Cf-Id": "pn-PWIJc6thYnZm5P0NMgOUglL1DYtl0gdeJky8tqsg8iS_sgsKD1A==",
      "X-Forwarded-For": "54.240.196.186, 54.182.214.83",
      "X-Forwarded-Port": "443",
      "X-Forwarded-Proto": "https"
    },
    "queryStringParameters": {
      "name": "me"
    },
    "pathParameters": {
      "proxy": "hello/world"
    },
    "stageVariables": {
      "stageVariableName": "stageVariableValue"
    },
    "requestContext": {
      "accountId": "12345678912",
      "resourceId": "roq9wj",
      "stage": "testStage",
      "requestId": "deef4878-7910-11e6-8f14-25afc3e9ae33",
      "identity": {
        "cognitoIdentityPoolId": null,
        "accountId": null,
        "cognitoIdentityId": null,
        "caller": null,
        "apiKey": null,
        "sourceIp": "192.168.196.186",
        "cognitoAuthenticationType": null,
        "cognitoAuthenticationProvider": null,
        "userArn": null,
        "userAgent": "PostmanRuntime/2.4.5",
        "user": null
      },
      "resourcePath": "/{proxy+}",
      "httpMethod": "POST",
      "apiId": "gy415nuibc"
    },
    "body": "{\r\n\t\"a\": 1\r\n}",
    "isBase64Encoded": false
  }
}

Now you have access to all headers, url params, body etc. and you could use that to handle requests differently in a single Lambda function (basically implementing your own routing).

As an opinion I see some advantages and disadvantages to this approach. Many of them depend on your specific use case:

• Deployment: if each lambda function is discrete then you can deploy them independently, which might reduce the risk from code changes (microservices strategy). Conversely you may find that needing to deploy functions separately adds complexity and is burdensome.
• Self Description: API Gateway's interface makes it extremely intuitive to see the layout of your RESTful endpoints -- the nouns and verbs are all visible at a glance. Implementing your own routing could come at the expense of this visibility.
• Lambda sizing and limits: If you proxy all -- then you'll wind up needing to choose an instance size, timeout etc. that will accommodate all of your RESTful endpoints. If you create discrete functions then you can more carefully choose the memory footprint, timeout, deadletter behavior etc. that best meets the needs of the specific invocation.

这篇关于aws api 网关 &lambda:多个端点/函数 vs 单个端点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！