我在微服务架构设计中有以下要求。我的项目是Azure Service Fabric类型无状态和Dotnet Core中的有状态服务。 qazxsw poi
该项目共有3个无状态服务和3个有状态服务。
对于每个有状态服务，我们创建了一个无状态服务作为其门户。
我们将数据存储在有状态服务中，通过无状态，我们将发送数据和检索数据。
出于通信目的，我们将使用服务代理（即IService实现的接口）。
我可以很容易地从stateless1调用stateful1的方法，但是我要求我需要来自stateful1的数据，它依赖于有状态2和有状态3。
我在每个有状态服务之间都有一些业务逻辑，
目前我正在statful1上创建服务代理并收集有状态2和3的所有数据，并在计算完整数据后将发送给无状态。
我的问题是，还有一个名为存储库的层（无状态使用的类库项目）是否会更好，它将联系每个有状态服务并使业务逻辑更新？
或者，如果有状态的反逻辑业务逻辑将影响性能，而不是无状态的业务逻辑。
我举了3个无状态和3个有状态的简单例子，但实际上我的项目包含50多个服务，每个服务都有网关和有状态服务。在每个有状态的服务之间，我有更多的业务需要写。
请建议我采取更好的方法来满足这一要求。
你的问题似乎有很多背景，并非所有这些对读者来说都是显而易见的。
微型服务体系结构在我看来像是一个“大锤子”从工具箱中拔出，除非您尝试解决的问题与您正在创建的系统无法以任何其他方式适当地解决。
当我听到你谈到50多项服务，其中每项服务实际上都有100多项服务时，我首先怀疑你的这种架构是否可能过度工程化？但是，我已经指出了很多背景，因此很难让我真正做出评估。
也许你应该考虑在你调用它们时合并有状态服务1,2和3是否有益？
您所处的情况可能是这些服务紧密相关的一种症状，可能会被合并在一起。
我最近处于类似的情况，其中2个微服务（我认为应该是1）处理密切相关的数据，一个是案例服务，另一个是客户背景检查服务，业务请求导出数据到csv -file其中所需输出csv文件中的每一行包含来自案例和客户背景检查的数据的组合。实现这一目标的唯一方法是迭代案例，并针对每个案例调用客户背景检查微服务，这当然是可怕的扩展。 1000个案件意味着1000个http电话。如果在一个SQL数据库中有2个表，那么您可以很容易地想象使用单个连接查询可以解决这个问题。
有时少即是多。