如何在微服务分布式环境中创建一个简短易读的 UUID
How to create a short readable UUID in a microservices distributed environment
我正在使用 CQRS 和事件溯源将一个超级单体 Web 服务分解为一个微服务方法。有了这个，并考虑到以前的体系结构，每个 table 依赖于 SQL 服务器增量标识号，分布式系统依赖数据库是不可接受的 table，因为我们现在将有各种预测系统中的事件。
但我们仍然必须保持关系并传输 id 以供分析、API 调用等。显而易见的选项是 GUID，在您到达 GET 请求之前它看起来不错，http://awesomedomain.com/users/98e3b2ab-3c69-4077-aea1-38d22e79b007，嗯，不是那么漂亮，也有点笨重，但它会起作用。众所周知，将 GUID 作为数据库中的索引键可能会影响性能。
在这里查看了一些尝试基于 EPOCH UNIX timestamp ticks, shorten the GUID, or this interesting approach 生成 id 的答案（但发现不是全局解决方案），每个解决方案都不能真正保证全局唯一性，除了短 GUId 一个，但仍然不清楚.
另一种选择是使用带有分布式锁 (Redis) 的 Guid 服务来生成 EPOCH UNIX tick id，但如果您有数千个并发 "create" 请求，这可能会给我们带来性能损失。
我们真的应该费心去缩短 GUID 还是寻找另一个更 "human readable" 的解决方案？
我们可以实施任何其他全球唯一标识符解决方案吗？
你有的就是好的。
它可能不是人类可读的，但这正是它应该是的。顺序 ID 很容易被猜到并且不利于安全。 GUID 很好地填补了这个空白。
根据您的系统结构，您实际上可以将 int ID 作为主键，同时也保留您的 GUID，它们不必是主键。然而，这并不总是可能的。
您可以从以下几个选项中进行选择：
不关心
为什么要为 GUID 操心。没有人会看到它。它仅用于服务间通信或技术 api 呼叫。
缺点：可能看起来很丑。
使用自然键
事物可以有 ISO 标准，例如国家或货币。在大多数情况下，它们是人类可读的。其他一些东西可以有另一个自然标识符，比如船。
有些事情不会。这很烦人。没有缺点（除了数据库调用的速度），但并不总是可用。
在本地重新格式化 ID
某些 UI Web 部件可能会在其自己的搜索优化数据库中存储一些超快速的可搜索条目。在这里你可以有一个本地ID。但是，这与其他服务的通信很糟糕。
缺点：集成复杂。
更短的 guids
我们可以生成一个随机数吗？更好的人类可读性。更好的网址。酷
缺点：不多，只是；与实际实体无关。但是，因为你在哪里使用 GUIDs 你没有它开始。
当然，我排除了一些选项。基本上;一切都取决于您的要求。速度、安全性、复制可能性等:-)
尽情享受吧！
首先测量和研究这个需求是非常重要的。您肯定不希望为对象创建实现复杂的、难以维护的逻辑，只是为了能够处理比您的系统以往更多的请求。
我个人认为数据库自增键和微服务并不互斥。您可以拥有许多轻量级服务实例，所有实例都在其背后使用单个特定于微服务的数据库。尽管它会使数据库连接成为瓶颈或单点故障，但它仍然可行，Internet 中的许多服务都可以通过这种方式正常工作。如果您正确设计数据库并保留它 "micro"，那么它应该可以正常工作，至少对于 "thousands of create requests"。
这实际上也取决于您使用的数据。
如果您创建用户，那么我认为使用 ID 或用户指定的用户名比使用 GUID 更自然。
如果你创建了一个人们上传彼此不相关的内容的平台，那么你可能想看看 YouTube 如何为其视频实现 ID 生成 - 只是随机 ID 编码为 base-something，比 GUID 更短并且更易读人类的眼睛。
我正在使用 CQRS 和事件溯源将一个超级单体 Web 服务分解为一个微服务方法。有了这个，并考虑到以前的体系结构，每个 table 依赖于 SQL 服务器增量标识号，分布式系统依赖数据库是不可接受的 table，因为我们现在将有各种预测系统中的事件。
但我们仍然必须保持关系并传输 id 以供分析、API 调用等。显而易见的选项是 GUID，在您到达 GET 请求之前它看起来不错，http://awesomedomain.com/users/98e3b2ab-3c69-4077-aea1-38d22e79b007，嗯，不是那么漂亮，也有点笨重，但它会起作用。众所周知，将 GUID 作为数据库中的索引键可能会影响性能。
在这里查看了一些尝试基于 EPOCH UNIX timestamp ticks, shorten the GUID, or this interesting approach 生成 id 的答案（但发现不是全局解决方案），每个解决方案都不能真正保证全局唯一性，除了短 GUId 一个，但仍然不清楚.
另一种选择是使用带有分布式锁 (Redis) 的 Guid 服务来生成 EPOCH UNIX tick id，但如果您有数千个并发 "create" 请求，这可能会给我们带来性能损失。
我们真的应该费心去缩短 GUID 还是寻找另一个更 "human readable" 的解决方案？ 我们可以实施任何其他全球唯一标识符解决方案吗？
你有的就是好的。
它可能不是人类可读的，但这正是它应该是的。顺序 ID 很容易被猜到并且不利于安全。 GUID 很好地填补了这个空白。
根据您的系统结构，您实际上可以将 int ID 作为主键，同时也保留您的 GUID，它们不必是主键。然而，这并不总是可能的。
您可以从以下几个选项中进行选择：
不关心
为什么要为 GUID 操心。没有人会看到它。它仅用于服务间通信或技术 api 呼叫。
缺点：可能看起来很丑。
使用自然键
事物可以有 ISO 标准，例如国家或货币。在大多数情况下，它们是人类可读的。其他一些东西可以有另一个自然标识符，比如船。
有些事情不会。这很烦人。没有缺点（除了数据库调用的速度），但并不总是可用。
在本地重新格式化 ID
某些 UI Web 部件可能会在其自己的搜索优化数据库中存储一些超快速的可搜索条目。在这里你可以有一个本地ID。但是，这与其他服务的通信很糟糕。
缺点：集成复杂。
更短的 guids
我们可以生成一个随机数吗？更好的人类可读性。更好的网址。酷
缺点：不多，只是；与实际实体无关。但是，因为你在哪里使用 GUIDs 你没有它开始。
当然，我排除了一些选项。基本上;一切都取决于您的要求。速度、安全性、复制可能性等:-)
尽情享受吧！
首先测量和研究这个需求是非常重要的。您肯定不希望为对象创建实现复杂的、难以维护的逻辑，只是为了能够处理比您的系统以往更多的请求。
我个人认为数据库自增键和微服务并不互斥。您可以拥有许多轻量级服务实例，所有实例都在其背后使用单个特定于微服务的数据库。尽管它会使数据库连接成为瓶颈或单点故障，但它仍然可行，Internet 中的许多服务都可以通过这种方式正常工作。如果您正确设计数据库并保留它 "micro"，那么它应该可以正常工作，至少对于 "thousands of create requests"。
这实际上也取决于您使用的数据。
如果您创建用户，那么我认为使用 ID 或用户指定的用户名比使用 GUID 更自然。
如果你创建了一个人们上传彼此不相关的内容的平台，那么你可能想看看 YouTube 如何为其视频实现 ID 生成 - 只是随机 ID 编码为 base-something，比 GUID 更短并且更易读人类的眼睛。