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

Question

我正在使用Service Fabric状态服务在系统中存储有关用户的状态。 我的分区策略是使用规范化的国际字符串格式电话号码来寻址已命名的服务实例，并使用电话号码的哈希值来解析该服务的分区。 例如：fabric：/ myapp / users / 1/718（国际电话号码为+ 1718xxxxxxx），这使我可以根据服务所在的国家/地区（以及地区号在美国/加拿大市场）对服务进行地理位置定位。

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

1. 我最初的方法是使Id成为byte []，其中包括用户的服务名称，分区ID和本地ID。 我放弃了这个想法，因为ID的大小很大，并且随着时间的推移会增加。 （这是有问题的，因为“可靠字典”中的所有键都需要容纳到内存中，而我宁愿不杀死id上的大量内存。）此外，它仍然携带着每个使用id的人的行李，他们知道如何解释id并据此使用。
2. 我的下一个想法是为使用该服务的任何人提供一个客户端库。 这也具有消费服务的二进制依赖性的缺点。 如果我想在将来更改策略，则必须跳过一堆箍来处理故障以正确解析实体。
3. 我能想到的最后一个选择是在有状态服务之前有一个无状态代理，该代理处理所有服务的解析。 从设计角度来看，这是最有吸引力的方法，但同时也涉及管理，构建另一个仅用于解决问题的服务。 不反对它，但这是一个额外的考虑。 如果我走这条路，我应该将此服务作为单独的服务结构应用程序使用，还是建议将所有内容都保留为一个应用程序。

我也乐于接受这样的想法：以这种方式对用户进行分区是个坏主意。 但是，出于多种原因，建议使用电话。

Answer 1

如果可能的话，我建议远离您的服务使用者，保持对分区的任何了解。 这样，您可以更改服务内部，而无需在用户端进行任何更改。

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

如果将其设为新应用程序，则它可以成为多个有界上下文的入口点（/ proxy）