3

我有很多 dotnet lambda 微服务使用 SSM 参数存储进行配置。由于我在不同的微服务之间共享大量配置，因此它对环境变量非常冒险。虽然最近我开始挑战它的极限。它现在影响了我的吞吐量，并且开始花费比我想要的更多的成本。

我考虑过为 dotnet 配置管理器使用亚马逊扩展，但它不能满足我的要求。我需要配置进行热交换，以保持微服务在正常运行时间较长时运行良好。当前的实现不会发生这种情况。仅仅为了配置更改而部署所有微服务也不是一种选择。

这使我研究了一种缓存解决方案，该解决方案至少能够从外部使缓存无效，但我无法遇到任何与 SSM 参数存储一起使用的东西。

在最坏的情况下，我需要提供另一个微服务，它有自己的数据库来处理配置，但我不想走这条路。

在这种情况下使用的一般方法是什么？

4

3 回答 3

2

您可以在环境变量中使用 SSM，例如

environment:
    VariableName: ${ssm:/serverless-VariableName}

并从环境中引用您的代码。我们正在使用这种方法。

这将在您部署应用程序时存储 SSM，并在不为每个请求调用 SSM 存储的情况下重复使用它

于 2020-02-23T12:31:51.623 回答
2

  • 为了减少对 SSM 参数存储的网络调用次数，您可以在 应用程序启动时
    将配置值从 SSM 分配给静态属性。
    并将这些静态属性用于
    应用程序中的配置值，而不是在该特定 lambda 实例的整个生命周期内再次调用 SSM 参数存储。对 SSM 参数的更改将仅反映在 lambda 的新实例中。

  • 如果您在 lambda 上使用预配置并发，那么上述解决方案将无济于事，因为 SSM 存储参数中的更改不会反映到预配置 lambda，因为它始终保持在初始化状态。要使更改反映您需要重新部署或删除配置并发并将其添加回来。

  • 如果您有一个参数值经常更改的用例，并且它应该立即反映在您的 lambda 代码中，那么您可以使用密钥管理器来存储这些值，并使用 aws 为密钥https://aws.amazon 提供的客户端缓存支持。 com/blogs/security/how-to-use-aws-secrets-manager-client-side-caching-in-dotnet/。

于 2020-12-10T10:13:00.560 回答
0

我认为我们需要深入研究您问题的架构。

由于您使用的是 lambda，而与您的配置无关，如果您不使用配置的并发，您的容器生命周期将是 5-10 分钟（共享 lambda 容器的常见生命周期）。

也就是说，如果我们使用另一种类型的基础架构，例如 K8s（例如 EKS），您可以：

  1. 将此 SSM 参数缓存在分布式缓存 (Elasticache) 中。
  2. 在 cloudwatch events 中创建 SSM 参数更改事件。
  3. 将 SNS 作为目标。
  4. 订阅 http 端点或 lambda 函数以清除此缓存条目。

现在，在缓存失效的情况下，第一个需要此参数的应用程序将从 SSM 参数中获取值并放入缓存中，您可以在此处放置一个 TTL 以按计划失效。

但是，因为您正在使用无服务器方法运行，所以为每个 lambda 容器创建一个 TCP 连接（您可以在多个调用中与 elasticache 共享 tcp 连接）可能会降低您的性能，因此，您需要进行权衡：验证与elasticache 对您的用例来说是个问题。如果是，您可以使用简单的 SSM 参数缓存客户端并放置一个小的 TTL（例如 5 分钟），以防止您的 lambda 达到 SSM 参数限制。

于 2022-01-17T01:23:24.140 回答