c# - 单独 git 存储库中的服务结构项目

Question

按照正常的微服务框架，我们希望将每个微服务放入其自己的 git 存储库中，然后为 Service Fabric 项目创建一个存储库。当我们更新其中一个微服务时，Service Fabric 项目将仅重新部署该服务。

是否有像这样拆分 Service Fabric 项目的示例？我注意到在他们的所有示例中，所有内容都在一个解决方案/存储库中。

Answer 1

tl;dr:找出在管理代码和单个服务发布方面最适合您的开发团队的方法。使用diff packages仅升级 Service Fabric 应用程序中的更改。最小的存储库大小应该是一个 Visual Studio 解决方案中包含的一个 Service Fabric 应用程序。

更长的版本:完全可以将 Service Fabric 应用程序拆分为多个应用程序，最小的应用程序是为您拥有的每个微服务分配一个 Service Fabric 应用程序。这是否是一个好主意，完全取决于您尝试构建的应用程序的类型。服务之间是否存在依赖关系？您如何划分服务？当您想要以协调的方式进行划分时，是否存在任何场景？您打算如何监控您的服务？如果您不想以协调的方式做到这一点，那么在同一应用程序中提供更多服务可能是有意义的。

将代码拆分为小于 Visual Studio 解决方案的存储库可能只会给您带来麻烦。从技术上讲，您可以使用 Git 子模块或子树来达到某种效果，但 Visual Studio 处理解决方案内的项目引用的方式可能会让您很快陷入合并 hell 。

在升级 Service Fabric 应用程序时，实际上有一种方法可以根据服务 list 中的版本号仅升级应用程序中已更改的服务。这称为差异包，可用于将应用程序部署到该应用程序至少部署过一次的集群(即，它是升级，而不是安装)。如果您只升级应用程序中的少数服务，这可能会极大地影响部署的升级时间。 The full documentation for this can be found here 。还有一个SO answer描述它。

我想说，您的选择与开发一样，是不同 yield 之间的权衡。

将服务拆分为包含更少服务的更细粒度的应用程序可以使升级更容易(但这种效果在某种程度上在技术上也可以通过使用 diff 包来实现)。这种方法的缺点是您必须将依赖关系作为服务之间的严格接口(interface)进行管理。一种方法是将您的服务/参与者接口(interface)发布到私有(private) NuGet-feed。这反过来又会给您的开发流程带来一些额外的复杂性。

将所有内容保留在同一个存储库、相同的 Visual Studio 解决方案、相同的 Service Fabric 应用程序中可以适用于较小的解决方案，但从长远来看，如果您的解决方案在合并、版本控制和发布方面不断增长，则可能很难使用。