微服务是现在的趋势，其中大多数都是在云上开发的。我遇到的情况是，我们正在将大多数单片服务分解为 域级微服务在亚马逊云中，每个单独的服务将进一步实现为多个lambda函数。因为将有100个功能，每个功能执行特定类型的活动，由单个管道作业部署。 在不久的将来，函数的数量可能会增加到1000s
这种情况与我们在早期版本spring框架中看到的xml地狱类似或复杂。
首先，如果您要在Lambda上转向微服务，您可能需要考虑Chalice这样的框架。这将有助于减少服务的蔓延，但每种情况都不同，这取决于你在哪里绘制有边界的上下文。
从与你正在从事的工作类似的经历来看，你会想在几个领域进行大量投资。首先，拥有一致的日志记录方法是关键。您希望将日志一致地发送到单个日志聚合服务，这样您就可以轻松地跨所有服务进行查询以获得度量。CloudWatch、Sumo Logic等可以帮助解决这一问题。还可以使用X射线获得更详细的见解。
您还需要考虑在CI/CD管道中添加一些自动化功能，以便在Swagger或类似的工具中生成文档。这样做的方式应该是，结果是一个可搜索的目录所有服务以及所有必要的文件。我的经验包括使用Swagger UI和一些自定义HTML来完成这项工作，这些HTML会在每个构建作业中生成并部署。
最后一个建议是投资测试。契约测试和向后兼容性测试是避免部署破坏性更改的关键。我还想添加功能切换作为另一个关键点，可以在这里携手并进。
祝你好运！
在没有要求的情况下，您不应该也不应该将应用程序分解为许多许多不同的Lambda函数。拥有不同Lambda函数的唯一原因是您需要执行不同的基础设施或安全要求。
像任何正常函数一样，Lambdas将event和context作为输入。如果您在Lambda前面使用API网关，您将拥有path、httpMethod、queryStringParameters等，如这里所示。AWS生成了许多库，这意味着您不需要重构应用程序代码，并且可以将此事件转换为应用程序能够理解的HTTP请求。
一个应用程序可以是一个Lambda函数。您还可以将库依赖关系分解为层，这也可以在优化CI/CD以获得文件大小限制时加快部署速度。
您也不需要在API网关中定义每个API方法，只需使用proxy集成即可。
国际海事组织这是唯一明智的做法。随着需求的出现，您将相应地调整基础设施和Lambda，因此，如果您需要一个API调用来延长超时时间，则可以定义此方法和一个新的Lambda函数。例如，如果reports端点应该只有读取权限，这将再次触发您生成另一个Lambda函数，该函数可能只在您使用的iam角色中有所不同。考虑使用Serverless框架或AWS SAM来减少您需要的锅炉板，这意味着您可以再次使用相同的S3 zip文件来减少维护。
我强烈建议您不要部署许多不同的Lambda功能，这将是一场噩梦，会导致单个应用程序的不一致性，以不破坏用户体验的方式进行部署几乎是不可能的。
AWS Lambda支持标记。这是理解Lambda上标签计费的最干净的方法。
您可以标记您的微服务以进行成本分配和计费。
更多信息：
https://docs.aws.amazon.com/lambda/latest/dg/tagging.html
希望能有所帮助。
另一个可能非常适合您的用例的选项是使用一个名为Serverless Framework(Serverless.com)的工具。它是开发应用程序最流行的工具，是完全开源的，但也提供了一个管理工具，如果您愿意，可以将所有服务保留在一个git repo中，并且他们的CI/CD工具可以独立部署每个服务。该管理工具还包括为各种环境管理AWS帐户的能力，如QA、暂存和生产，以及按环境参数管理。所有这些都意味着由许多Lambda函数组成的应用程序实际上变得易于处理。我知道，我自己也做过很多次。
更不用说他们最近推出了新的组件功能，这是为常见问题部署标准化解决方案的好方法。想要将静态前端部署到S3主机和CloudFront CDN？使用网站组件！想要部署一个快速的cron作业，请使用cron组件。组件的类型只会随着时间的推移而增长，您甚至可以添加自己的组件。