为什么AWS有自己的UUID版本？

Question

我一直在开发托管在 AWS 云上的应用程序，该应用程序是数据管道的一部分。应用程序处理来自 EventBridge 的事件，进行一些数据映射，然后将结果放入 Kinesis 流中。

传入事件有效负载看起来像这样（为了便于阅读而被截断）：

{
  "version": "0",
  "id": "9a0f9e20-c518-a968-7fa6-1d8038a5bcfc",
  "detail-type": "Some sort of event",
  ....
}

放入 Kinesis 流的事件类似于：

{
    "eventId": "9a0f9e20-c518-a968-7fa6-1d8038a5bcfc",
    "eventTime": "2021-04-08T06:19:47.683Z",
    "eventType": "created",
    ...
}

我查看了传入事件的“id”属性，乍一看它看起来像一个 UUID。我将一些示例放入在线验证器中，它作为有效的 UUID 返回。由于它是一个 UUID 并且应该是“普遍唯一”，所以我想我可能会重用该 ID 作为传出有效负载的“eventId”属性。我认为这甚至可以更容易地追踪事件的源头。

但是，当我开始集成测试时，我开始注意到不相关服务发出警报。到处都发生验证错误。原来下游服务不喜欢“eventId”的格式。

下游服务使用“uuid”NPM 模块来验证事件信封中的 UUID，但它似乎不喜欢来自 AWS 的 UUID。为了确保我正确诊断了问题，我启动了节点 REPL 并尝试验证通过的 UUID 之一，果然它返回为无效！

> const uuid = require('uuid');
> u.validate("9a0f9e20-c518-a968-7fa6-1d8038a5bcfc")
false

然后我检查了“uuid”模块使用的

正则表达式进行验证，我注意到它正在检查 UUID 第三组的第一个字符中的数字 1-5。

很困惑，我查看了

Wikipedia 页面上的 UUID ，发现来自 AWS 的 UUID 的 UUID 版本是 A

，而不是预期的版本号 (1-5)

我有几个相关问题：

为什么 AWS 有自己的 UUID 版本？
它还是一个UUID吗？
为什么 AWS 会违反
3. 最小原则 惊讶 这样，使用常规 UUID 肯定更容易吗？

我希望有人有一个有趣的故事，讲述 AWS 如何发明自己的 UUID 版本来处理一些只在其规模上发生的史诗级工程问题，但我想我会接受一个更简单的答案。

Answer 1

事实证明，有一个 UUIDv8，只要符合规范，就允许自定义版本。这允许亚马逊指定他们自己的“A”UUID 版本。

似乎某些 UUID 验证器缺少此版本，因为它是最近添加的。

它没有回答我关于 AWS 为何这样做以及他们获得什么好处的部分问题。希望有一天我们能收到一篇关于它的博客文章。

来自

https://planetscale.com/blog/the-problem-with-using-a-uuid-primary-key-in-mysql

UUIDv8 版本 8 是最新版本，允许特定于供应商的实现，同时遵守 RFC 标准。 UUIDv8 的唯一要求是与所有其他版本一样在第三段的第一个位置指定版本。