我正在使用CQRS和Event Sourcing将超大型Web服务分解为微服务方法。考虑到这一点，并考虑到以前的体系结构（取决于每个表的SQL Server增量标识号），分布式系统依赖数据库是不可接受的，因为我们现在对系统中的事件有各种预测。
但是我们仍然必须保持联系并传送ID以进行分析，API调用等。显而易见的选项是GUID，在您到达GET请求http://awesomedomain.com/users/98e3b2ab-3c69-4077-aea1-38d22e79b007之前看起来还不错，嗯既漂亮又麻烦，但是可以使用。还众所周知，在数据库中将GUID用作索引键可能会对性能造成影响。
在这里找到一些答案以尝试根据EPOCH UNIX timestamp ticks，shorten the GUID或this interesting approach生成ID（但发现不是全局解决方案）之后，每种解决方案都不能真正保证全局唯一性，但简短的GUId除外，但仍不清楚。
另一种选择是拥有一个带有分布式锁（Redis）的Guid服务来生成EPOCH UNIX刻度号，但是如果您有成千上万个并发的“创建”请求，这会给我们带来性能上的损失。
我们是否真的应该缩短GUID或寻找另一个更“易读”的解决方案？ 对于我们可以实现的全局唯一标识符，还有其他解决方案吗？
答案 0 :(得分：3)
你所拥有的很好。
它可能不是人类可读的，但这恰恰是应该的。顺序ID很容易猜到，并且对安全性不利。 GUID很好地填补了这一空白。
根据系统的结构，您实际上可以将int ID作为主键，同时也保留GUID，而不必将它们用作主键。但是，这并不总是可能的。
答案 1 :(得分：2)
首先测量和研究此要求非常重要。您绝对不想仅仅为了能够处理比系统更多的请求而实现复杂，难以维护的逻辑来创建对象。
我个人会说数据库自动增量键和微服务不是互斥的。您可以有许多轻量级服务实例，所有实例都在其背后使用单个特定于微服务的数据库。即使它可以使数据库连接成为瓶颈或单点故障，它仍然可行，并且Internet上的许多服务都可以通过这种方式正常工作。如果您正确地设计数据库并将其保持为“微型”，那么它应该可以正常工作，至少对于“数千个创建请求”而言。
这实际上还取决于您使用的数据。
如果创建用户，那么我认为使用ID或用户指定的用户名比GUID更自然。
如果您创建一个平台，让人们上传彼此不相关的内容，那么您可能需要研究YouTube如何为其视频实现ID生成-只是编码为基本内容的随机ID，比GUID短，并且对于人类的眼睛。
答案 2 :(得分：1)
您可以从以下两个选项中进行选择：
为什么要担心GUID。没有人会看到它。它仅用于服务通信或技术api调用。
缺点：看起来很丑。
事物可以具有ISO标准，例如国家或货币。在大多数情况下，它们是人类可读的。其他一些东西可以具有另一个自然标识符，例如船。
有些事情没有。真烦人没有缺点（除了数据库调用速度之外），但并非总是可用。
某些UI Web部件可能在其自己的搜索优化数据库中存储了一些可快速搜索的条目。在这里您可以拥有一个本地ID。但是，这与其他服务通信不畅。
缺点：集成的复杂性。
我们可以生成一个随机数吗？更好的人类可读性。更好的网址。很好。
缺点：不多，只是；与实际实体无关。但是，既然您在使用GUID的地方就没有开始。
享受！