我正在测试 Azure Service Fabric 并开始向同一个项目添加大量参与者和服务 - 这样做可以吗？或者我会失去任何 Service Fabric 功能(如故障转移、可扩展性等)吗？
最佳答案
我的偏好显然是 1 个参与者/1 个服务 = 1 个项目。像这样的平台的最大好处是，它允许您几乎免费编写适当的面向微服务的应用程序，至少与在其他有些类似的平台上执行类似实现时的实现开销相比是这样。
我认为它违背了像这样的架构来构建跨越多个关注点的服务或参与者的意义。使用这些虚构的约束来迫使您将这些服务的责任范围尽可能小是有意义的(至少对我来说)，而是依赖/调用其他服务来提供超出服务职责范围的功能。您当前正在实现的项目。
在扩展方面，您似乎仍然能够独立扩展您的服务/参与者，即使它们是同一项目的一部分 - 至少通过查看应用程序 list 格式可以看出这一点。但是，您将无法做的是项目中服务/参与者的独立更新。举个例子;如果您的项目有两个不同的参与者，并且您对其中之一进行了更改，您仍然需要对它们都部署更新，因为它们是同一代码包的一部分并且共享版本号。
关于azure-service-fabric - 参与者/服务是否应该分成多个项目？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30755515/