委托资源标识符：微服务中持久引用的一种模式

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

也有英文版本

如果你曾经将统一资源定位符存入数据库，随后又后悔莫及，那么这篇文章就是为你准备的。

这是一个常见的场景：一个服务需要维护对另一个服务中资源的引用。最显而易见的解决方案是保存统一资源定位符。这在主机变更、应用程序接口升级或团队决定重构路径之前一直有效。突然间，所有保存的引用都失效了，追踪其影响变成了一个比预期更严重的问题。

根本问题在于，统一资源定位符混淆了两个不同的概念：资源是什么以及资源在哪里。当你保存一个统一资源定位符时，你是在赌这个位置不会改变。在不断演进的系统中，这种赌注通常会输掉。

核心思想

如果不保存资源的位置，而是保存一个网关知道如何解析的唯一标识符，会发生什么？

commerce:orders/order:id=ARG-2024-00091872
finance:accounts/customer:status:id=109234
health:coverage/credential:patient-id=12345678

保存引用的一方无需知道资源位于何处或如何访问。这一责任由网关承担。如果应用程序接口发生变化、服务迁移或出现新系统，只需更改解析器即可。已保存的引用仍然有效。

我将此方案称为委托资源标识符（DRI）。

此模式不是什么

• 它不是标准
• 它需要网关作为中介：当客户端需要直接访问资源而无需经过任何中介时，此模式不适用
• 它不强制规定上下文的分类体系：每个团队定义自己的分类体系

当你需要在受控生态系统中对资源进行持久引用，并希望集中解析逻辑时，这是一种有用的约定。

构建方式

标识符由两部分组成，以 / 分隔：

<上下文>/<资源>

• 上下文（左侧）：标识知道如何解析此类资源的域。网关使用它进行路由。
• 资源（右侧）：标识具体资源。其结构由实现解析器的一方定义。

commerce:orders/order:id=ARG-2024-00091872
└─── 路由 ──────┘└─── 具体资源 ──┘

: 用于分隔层级。= 用于赋值。每一侧定义自己的内部约定。

标识符由保存引用的一方根据已有数据和已知上下文构建。不需要任何外部调用。例如，接收订单标识符的计费服务知道该订单属于 commerce:orders，并在持久化引用时构建委托资源标识符。

如果网关有默认解析器，则可以省略上下文：

/order:id=ARG-2024-00091872

一些用例

电子商务：检索订单

客户服务服务保存对订单的引用，这些订单可能来自不同渠道：自有商店、市场平台、应用程序