问微服务爆炸的治理方法

EN

您不应该也不应该将应用程序拆分成许多不同的Lambda函数，而不需要这样做。拥有不同的Lambda函数的唯一原因是，如果您有不同的基础架构或安全需求，则需要强制执行。

与任何普通函数一样，Lambdas也接受event和context作为输入。如果你在Lambda前面使用API Gateway，你会有path，httpMethod，queryStringParameters等，就像找到的here一样。AWS生成了许多库，这意味着您不需要重构您的应用程序代码，并且可以将此事件转换为您的应用程序能够理解的HTTP请求。

一个应用程序可以是一个Lambda函数。您还可以将库依赖项分解为多个层，这也可以在简化CI/CD以获得文件大小限制时加快部署速度。

您也不需要在API Gateway中定义每个API方法，只需使用proxy集成即可。

在我看来，这是唯一明智的方法。随着需求的出现，您可以相应地调整您的基础设施和Lambda，因此，如果您需要一个API调用来获得更长的超时，您可以定义此方法和一个新的Lambda函数。例如，如果reports端点应该只具有读取权限，这将再次触发您创建另一个Lambda函数，该函数可能只是在您使用的iam角色上有所不同。考虑使用无服务器框架或AWS SAM来削减您需要的样板文件，这将意味着您可以再次使用相同的S3压缩文件来减少维护。

我强烈建议您不要部署许多不同的Lambda函数，这将是一个难以支持的噩梦，将导致单个应用程序的不一致，并且以一种不破坏用户体验的方式编排部署几乎是不可能的。

首先，如果您要迁移到Lambda上的微服务，您可能需要考虑像Chalice这样的框架。这将有助于减少服务的无序蔓延，但每种情况都是不同的，都取决于您在哪里绘制您的有界上下文。

从你正在从事的类似经历来看，你会想要在一些领域投入大量资金。首先，拥有一致的日志记录方法是关键。您将希望一致地将日志发送到单个日志聚合服务，这样您就可以轻松地跨所有服务进行查询以获得指标。CloudWatch、相扑逻辑等可以帮助你做到这一点。也可以使用X-Ray来获得更详细的洞察。

您还需要考虑在CI/CD管道中添加一些自动化功能，以生成Swagger或类似格式的文档。这应该以这样一种方式完成，即结果是所有服务的可搜索目录以及所有必要的文档。我的经验涉及到使用Swagger UI和一些在每个构建作业上生成和部署的自定义HTML来实现这一点。

最后一个建议是投资于测试。契约测试和向后兼容性测试是避免部署破坏性更改的关键。我还会添加功能切换，作为另一个可以在这里手把手使用的键。

祝你在这项工作中好运！

AWS Lambda支持标记。这是理解Lambda上的标签计费的最干净的方法。

您可以标记您的微服务以进行成本分配和计费。

有关的更多信息：

https://docs.aws.amazon.com/lambda/latest/dg/tagging.html

希望能有所帮助。