在单独的git仓库中服务fabric项目

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

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

将代码分割成比你的Visual Studio解决方案更小的repos可能只会给你带来麻烦。从技术上讲，你可以使用Git子模块或子树来达到某种效果，但Visual Studio在解决方案中处理项目引用的方式可能会很快让你陷入合并地狱。

当涉及到升级服务结构应用程序时，实际上有一种方法可以根据服务清单中的版本号仅升级应用程序中已更改的服务。这被称为diff包，可用于将应用程序部署到至少部署过一次应用程序的集群(即，它是升级，而不是安装)。如果您只升级应用程序中的一小部分服务，这可能会极大地影响部署的升级时间。完整的文档可以在这里找到。也有一个SO答案来描述它。

我想说，您的选择，就像在开发中一样，是不同收益之间的权衡。

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

将所有内容保持在相同的repo，相同的Visual Studio解决方案，相同的Service Fabric应用程序中可以用于较小的解决方案，但如果您的解决方案在合并，版本控制和发布方面不断增长，则可能很难长期使用。

对于我们的项目，我们遵循类似的模式，但不是那么细粒度。每个SF应用程序都包含在它自己的repo中，但是我们在一个应用程序中会有多个特定的微服务。我们根据最终应用程序(数据层、中间层、表示、分析等)将应用程序分成特定的功能块。当我们升级时，我们会一次升级特定的应用程序，而不一定是特定的服务。升级特定的服务是一个巨大的操作智慧。我们仍然有一个共享接口项目，我们使用SF远程在不同的应用程序之间进行通信，我们能够做到这一点是因为我们在自己的repo中管理容器和接口，然后通过一个私有的nuget服务器进行分发。这使得工作流程变得困难，但最终它是好的，因为它使我们保持对应用程序之间接口兼容性的意识。我们也有一些核心微服务，每个应用程序都有，我们使用SF Nuget进行分发。它还很年轻，有一些锋利的边缘，但它很棒。

阅读你的问题，听起来你的存储库分割主要是为了部署问题，所以我将重点关注这方面。

我们在每个Service Fabric应用程序(包含多个服务)中使用一个Git存储库，这有助于简化持续集成和持续部署的完成方式:如果在repo(代码或配置)中有变化，则需要构建和部署SF应用程序。

如果您在线使用VSTS的构建和发布功能，您可以轻松地利用Service Fabric可用的构建任务来支持差异升级。使用"更新服务结构应用程序版本"任务(https://www.visualstudio.com/en-us/docs/build/steps/utility/service-fabric-versioning)，使用带有"确定性编译器标志"(https://blogs.msdn.microsoft.com/dotnet/2016/04/02/whats-new-for-c-and-vb-in-visual-studio/)的"仅在更改时更新"选项，以确保如果代码相同，二进制文件总是相同的，您很容易以每个SF应用程序的差异升级告终。

您不必将服务结构服务视为微服务。

代码/服务/应用程序等的服务结构分类法为您提供了高度的灵活性，可以根据您的需求进行组合(如上所述)。考虑到这样一个事实，你可以在一个服务中运行更多的代码包，并试图将其转换为微服务定义，只会使事情变得更加难以处理。

由于SF应用程序是您的部署单元(无论它包含一个或多个更新的服务)，您应该努力构建您的repo/solution/SF应用程序设置，以便您可以将大多数更改包含在一个SF应用程序中(=一个解决方案和一个repo)。

如果你经常需要部署多个SF应用程序来进行更改，那么你的生产力将会降低。