有关Azure Service Fabric应用程序设计的问题

Question

我对微服务架构设计有以下要求。 我的项目是Dot Net Core中的Azure Service Fabric无状态服务和有状态服务类型。

该项目中总共3个无状态服务和3个有状态服务。

对于每个有状态服务，我们都创建了一个无状态服务作为该服务的网关。

我们将在有状态服务中存储数据，而通过无状态我们将发送数据并检索数据。

出于通信目的，我们将使用服务代理（即IService实现的接口）。

我可以轻松地从stateless1调用stateful1的方法，  但是我有这样的要求，例如我需要来自有状态1和有状态3的数据。

在每个有状态服务之间，我都有一些业务逻辑，

当前我正在statful1上创建Service Proxy，并收集有状态2和3的所有数据，并且在对所有数据进行计算后将其发送到无状态。

我的问题将是，是否最好再有一层称为存储库（无状态使用的类库项目）的层，它将联系每个有状态的服务并组成业务逻辑？

或者如果在状态中使用反商业逻辑会影响性能，而不是在无状态中使用商业逻辑。

我以3个无状态和3个有状态的简单示例为例，但是实际上我的项目包含50多个服务，每个服务都具有网关和有状态服务。 在每个有状态服务之间，我需要编写更多的业务。

请建议我采用更好的方法来满足此要求。

Answer 1

您的问题似乎有很多上下文，并不是所有这些问题对于读者来说都是显而易见的。

在我看来，微服务架构就像拉出工具箱的“大锤”，除非您试图通过创建的系统解决的问题无法通过任何其他方式适当解决。

当我听到您谈论50多种服务时，每个服务都有对应的服务，因此实际上有100多种服务，我的第一个怀疑是您的这种架构是否设计过度？但是话又说回来，正如我已经指出的，缺少很多背景信息，因此我很难真正进行评估。

也许您应该考虑合并有状态服务1、2和3调用它们是否对您有好处？

您所处的状况可能是这些服务紧密相关的征兆，并且可能会被合并在一起而受益。

最近我处于类似的情况，其中有2个微服务（我认为应该是1个）处理了密切相关的数据，一个是案例服务，另一个是客户背景检查服务，该企业要求出口数据到csv文件，其中所需输出csv文件中的每一行都包含案例和客户背景检查数据的组合。实现此目的的唯一方法是遍历所有案例，并针对每种情况致电客户后台检查微服务，这当然是可怕的。 1000例意味着1000次http调用。但是，如果在一个SQL数据库中只有2个表，那么您可以轻松地想象到用单个联接查询可以简单地解决这个问题。

有时候少就是多。