amazon-web-services - 微服务爆炸的治理方法

微服务是现在的趋势，其中大部分是在云上开发的。我有一种情况，我们将大部分单体服务分解为域级微服务。每个问题域只有少数服务。

在亚马逊云中，每个单独的服务都将进一步实现为多个 lambda 函数。因为有100 多个函数，每个函数都执行特定类型的活动，每个函数都由单独的管道作业部署。

在不久的将来，函数的数量可能会增加到1000 个数量级。这与我们今天拥有的 40 个单体应用程序相比。有没有办法对账户使用指标、成本等进行分组、可视化？

这种情况与我们在早期版本的 spring 框架中看到的 xml 地狱相似或复杂。

标签： amazon-web-servicesarchitectureaws-lambdamicroservices

首先，如果您要迁移到 Lambda 上的微服务，您可能需要考虑使用诸如 Chalice 之类的框架。这将有助于减少一些服务的蔓延，但每种情况都是不同的，并且完全取决于您在哪里绘制有界上下文。

从与您正在着手的类似经历说起，您将希望在几个领域进行大量投资。首先，拥有一致的日志记录方法是关键。您需要将日志一致地发送到单个日志聚合服务，以便您可以轻松地查询所有服务以获取指标。CloudWatch、Sumo Logic 等可以帮助解决这个问题。还可以使用 X 射线获得更详细的见解。

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

最后一个建议是投资于测试。合同测试和向后兼容性测试是避免部署重大更改的关键。我还将添加功能切换作为另一个可以在这里手拉手的键。

祝你好运！