谁应该拥有Service Fabric Stateful Services中服务解析的逻辑？

Question

我使用Service Fabric状态服务来存储系统中用户的状态。我的分区策略是使用规范化的国际字符串格式电话号码来寻址命名的服务实例，并使用电话号码的散列来解析该服务的分区。 EX：fabric：/ myapp / users / 1/718（其中国际电话号码是+ 1718xxxxxxx）这使我能够根据他们的国家（以及区域代码在美国/加拿大市场）进行地理定位服务。

我的问题是理论上的，但也是实际的。 谁拥有服务解析的逻辑？一个简单的方法就是要求任何依赖此服务的人知道它的分区方式，但这对我来说就像是一个漏洞的抽象。此外，我想为用户分配一个与电话号码概念脱节的ID。

1. 我最初的方法是将Id设为byte []，其中包括用户的服务名称，分区ID和本地ID。我放弃了这个想法，因为ID的大小非常大，并且随着时间的推移会增加。 （这是有问题的，因为可靠词典中的所有键都需要适合内存而我不会在ids上杀死大量内存）此外，它还带有每个人使用id知道如何解释的包袱id并相应地使用它。
2. 我的下一个想法是为使用该服务的任何人提供客户端库。这也具有消费服务的二元依赖性的缺点。如果我想在未来改变策略，我必须跳过一堆箍来处理无法正确解析实体。
3. 我能想到的最后一个选择是在状态服务前面建立一个无状态代理来处理所有服务的解析。从设计的角度来看，这是最具吸引力的，但也涉及管理，构建另一项服务以便解决问题。不反对，但这是一个额外的考虑因素。如果我走这条路线，我应该将此服务作为单独的服务结构应用程序，或者建议将所有内容保留为一个应用程序。

我也很乐意接受以这种方式划分用户的想法是一个坏主意。但是，出于多种原因，建议使用手机。

Answer 1

如果可能的话，我建议您远离服务使用者的任何分区知识。这样，您可以在不改变消费者方面的任何内容的情况下更改服务内部。

这导致选项3，与内置的反向代理服务相结合。 在该额外服务中，您可以查找经过身份验证的用户并使用其位置来确定服务分区。

如果你把它变成一个新的应用程序，它可以成为多个有界上下文的入口点（/ proxy）