4

我有一个包含区域的 SQS URL。我正在使用官方 Go SDK 对此 SQS 执行操作，这需要 AWS 区域来初始化会话。目前，我已经编写了一个实用程序函数来解析 URL 并返回 AWS 区域。

示例网址：https://sqs.us-east-1.amazonaws.com/774557911234/my_sqs_name

示例初始化代码：

sess, err := session.NewSession()
if err != nil {
    return
}

s := sqs.New(sess, aws.NewConfig().WithRegion(getRegionFromSQSURL(config.SQSURL))

从 URL 获取区域的示例函数

func getRegionFromSQSURL(url string) string {
    return strings.Split(url, ".")[1]
}

只是想知道这是否是正确的方法。

在任何情况下，SQS URL 在 URL 中的区域与 SQS 所在的区域不同吗？

我应该在服务中再添加一个环境变量吗？

4

3 回答 3

4

从这里引用：https ://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-queue-message-identifiers.html

重要的

在您的系统中，始终按照 Amazon SQS 在您创建队列时返回给您的方式存储整个队列 URL（例如， http://sqs.us-east-2.amazonaws.com/123456789012/queue2）。每次需要在请求中指定队列 URL 时，不要从其单独的组件构建队列 URL，因为 Amazon SQS 可以更改构成队列 URL 的组件。

如前所述，他们可以在将来出于任何原因更改 URL 的结构。队列区域可能仍会保留在 url 中的某个位置，但不一定在您期望的位置。

所以，考虑到所有的想法，我认为引入新的环境变量是正确的方法。

于 2018-01-23T09:39:45.730 回答
3

是的，从队列 URL 中提取区域应该是完全安全的。

其他地方引用的文档化建议并不是说将队列 URL解构为其组件是不安全的，而是建议不要从其组件部分构造队列 URL。警告是存储整个 URL。没有建议根本不解析它。

在您的系统中，始终按照 Amazon SQS 在您创建队列时返回给您的方式存储整个队列 URL

URL 的主机名部分非常确定，SQS 的区域端点非常一致sqs.${region}.amazonaws.com。

没有明显的理由不依赖主机名来确定区域。AWS很少更改端点主机名，并且在少数情况下，它是为了让它们更可预测。同时，旧的端点仍然安静地存在——例如，原始端点，例如queue.amazonaws.com和us-west-1.queue.amazonaws.com仍然处于活动状态，并且看起来功能齐全，即使它们被正式取代sqs.us-[east | west]-1.amazonaws.com。AWS 最近与端点约定更加一致和分层，但这样做，他们并没有破坏这些值是硬编码的旧客户端。

于 2018-01-23T23:42:45.450 回答
1

如果我理解正确，问题会询问是否可以从 SQS URL 中提取 AWS 区域...

一个简单的答案是肯定的。但我不推荐这个。

首先，从保存在配置文件中的固定 SQS URL 中提取 Region 只是一个附加处理。由于它已经存储在 Config 文件中，我们也可以在 Config 文件中指定 AWS-region，因为除非我们决定手动更改，否则我们工作的区域不会动态更改。如果您查看此文档，AWS 区域通常保存在配置文件中，以便更好地维护。

其次，使用拆分从字符串中提取区域是不可信的。这就像试图破解一些东西以获得你需要的东西。这不是一个好的编码习惯。

第三，您上面给出的是特定队列的 AWS SQS 端点。阅读本文档并了解 AWS 终端节点的结构。AWS 终端节点并不总是在 Sting 结构中包含其中的区域。在 AWS 区域的配置文件中维护一个单独的参数始终是最佳实践。

某些服务，例如 IAM，不支持区域；因此，它们的端点不包括区域。某些服务（例如 Amazon EC2）允许您指定不包含特定区域的终端节点，例如https://ec2.amazonaws.com。在这种情况下，AWS 将端点路由到 us-east-1。

于 2018-09-11T16:37:53.607 回答