我正在使用 Service Fabric 有状态服务来存储有关系统中用户的状态。我的分区策略是使用标准化的国际字符串格式电话号码来寻址命名服务实例，并使用电话号码的哈希来解析该服务的分区。例如：fabric:/myapp/users/1/718（国际电话号码是 +1718xxxxxxx）这使我可以根据他们的国家（以及美国/加拿大市场的区号）对服务进行地理定位。
我的问题是理论上的，但在本质上也是实用的。 谁拥有服务解析的逻辑？ 一个简单的方法是只要求任何依赖此服务的人都知道它是如何分区的，但这对我来说感觉像是一个泄漏的抽象。此外，我想为用户分配一个与电话号码概念分离的 ID。
- 我最初的方法是使 Id 成为一个字节 []，其中包括用户的服务名称、分区 id 和本地 id。我放弃了这个想法，因为 ID 的大小非常大，并且会随着时间的推移而增加。（这是有问题的，因为 Reliable Dictionary 中的所有键都需要放入内存中，我不想在 id 上杀死大量内存）此外，它仍然带有每个使用 id 知道如何解释 id 的包袱并相应地使用它。
- 我的下一个想法是为使用该服务的任何人提供客户端库。这也有消费服务的二进制依赖的缺点。如果我想在未来改变策略，我必须跳过一堆箍来处理失败以正确解决实体。
- 我能想到的最后一个选择是在有状态服务之前有一个无状态代理来处理所有服务的解析。从设计的角度来看，这是最吸引人的，但也涉及管理、构建另一个服务，只是为了解决问题。不反对它，但它是一个额外的考虑。如果我走这条路，我应该将此服务作为一个单独的服务结构应用程序，还是建议将所有内容都保留为一个应用程序。
我也愿意接受以这种方式划分用户是一个坏主意的想法。但是，出于多种原因，建议使用手机。