【发布时间】：2017-12-25 19:53:03
【问题描述】：
我正在构建一个 API，它将充当 n 个底层 API 的代理，它们都做同样的事情。它将使用circuit breaker 模式来确定底层API 之一何时不可用，因此代理API 将具有状态。一种解决方案是在 AWS lambda 上运行 API 并将断路器状态存储在 AWS ElastiCache 中。
是否还有另一种更具成本效益的解决方案，不需要我运行像 ElasticCache 这样的“永远在线”服务？
【问题讨论】：
-
"n APIs that all do the same thing"听起来好像您正在尝试重新发明负载均衡器......所以您可能想澄清一下您是什么总体而言，试图完成。这些 n 是谁的 API？它们是可替代的吗？当断路器跳闸时，您的行动方案是什么？通过在无状态环境中跟踪状态，您可能会在您的平台中设计一些具有讽刺意味的不可靠性。
-
API 做同样的事情（发送电子邮件）但有不同的合同，所以负载均衡器不是一个选项。是的，理想情况下我会保持解决方案无状态，但我想要断路器提供的行为，以便我可以检测服务何时上升和下降并相应地路由流量。
-
好的，发送电子邮件实际上是来自不同供应商的不同但可替代的 API 的一个很好的（相对罕见的）示例。不过，这个问题确实需要一些思考，因为（除其他事项外）您还需要将唯一的事务标识符交还给调用者，以识别每个交互，以便以后跟踪和故障排除哪个目标处理了消息。似乎最好使用存储转发而不是直通来处理邮件。
-
我开始研究 AWS 的类似模式/架构（不一定仅限代理），并且想知道您是否/如何设法在 AWS API 管理中实现断路器模式。你最后用了 lambda 吗？由 DynamoDB 支持？还是别的什么？
-
不确定我是否得到了完整的问题，但如果您只是在寻找不是“始终开启”的存储，那么使用 AWS Systems Manager Parameter Store (docs.aws.amazon.com/systems-manager/latest/userguide/…) 并从 Lambda 使用它怎么样.
标签： amazon-web-services aws-lambda amazon-elasticache circuit-breaker