【问题标题】:Prevent repeat write API calls whilst traffic mirroring防止在流量镜像时重复写入 API 调用
【发布时间】:2021-03-08 01:54:07
【问题描述】:

我正在考虑将 Istio 的流量镜像用于暗测试版本。

镜像流量将意味着我不希望多次调用诸如订单和支付等编写 API,否则我将向客户收取两次费用并向他们发送重复的产品。

是否有防止这种情况发生的标准方法(存根在生产中似乎是一件奇怪的事情)或者镜像仅适用于读取 API?

【问题讨论】:

  • 正如here 提到的,当您使用镜像流量时,这些请求被镜像为“即发即弃”,这意味着响应被丢弃,来自镜像服务的回复被丢弃(由特使代理边车)并且不返回给调用者,所以如果我理解正确,镜像服务不应该给客户回电话,你提到的也不应该发生。你测试过吗?真的发生了吗?
  • 是的。镜像流量以创建订单的 API (createOrder)。因此,尽管忘记了响应,但 API 仍然创建了订单。
  • 在我看来,您应该为您的测试目的添加一些custom header 的路径,因此这只能由您/您的组织进行测试,而客户不应该参与其中。该主题由 Christian Posta here 详细描述。
  • 这是一个很好的建议,谢谢。

标签: testing istio mirroring


【解决方案1】:

问题

diagram 的流量镜像设置。

虽然这些镜像请求被镜像为“fire and forget”,并且来自镜像服务的回复只是被(由 envoy 代理 sidecar)丢弃到 /dev/null 并且没有返回给调用者,但它仍然使用这个 api。


解决方案

如cmets中所述

在我看来,您应该使用一些 custom header 添加用于测试目的的路径,因此只能由您或您的组织进行测试,而客户不应参与其中。


Christian Posta here 详细描述了该主题。

当我们部署新版本的服务并将流量镜像到测试集群时,我们需要注意对环境其余部分的影响。我们的服务通常需要与其他服务协作(查询数据、更新数据等)。如果与其他服务的协作只是读取或 GET 请求并且这些协作者能够承担额外的负载,这可能不是问题。但是,如果我们的服务改变了协作者中的数据,我们需要确保这些调用被定向到测试替身,而不是真正的生产流量。

您可以考虑几种方法,所有方法都在上面的链接中进行了描述:

  • 为某些测试配置文件取消协作服务
  • 综合交易
  • 虚拟化测试集群的数据库
  • 物化测试集群的数据库

在实践中,将生产流量镜像到我们的测试集群(无论该集群存在于生产环境中还是非生产环境中)是降低新部署风险的一种非常有效的方法。像 Twitter 和 Amazon 这样的大型 webops 公司多年来一直在这样做。这种方法会带来一些挑战,但正如上述模式中所讨论的那样,存在一些不错的解决方案。

【讨论】:

    猜你喜欢
    • 2018-05-15
    • 1970-01-01
    • 2012-08-30
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-06-29
    • 2016-05-13
    • 2017-09-25
    相关资源
    最近更新 更多