按照正常的微服务框架，我们希望将每个微服务放在它自己的 git 存储库中，然后为 Service Fabric 项目创建一个存储库。当我们更新其中一项微服务时，Service Fabric 项目将仅重新部署该服务。
有没有像这样拆分 Service Fabric 项目的示例？我注意到在他们的所有示例中，所有内容都在一个解决方案/存储库中。
【问题讨论】：
标签： c# azure microservices azure-service-fabric
tl;dr：找出在管理代码和单个服务的发布方面最适合您的开发团队的方法。使用 diff packages 仅升级 Service Fabric 应用程序中的更改。最小的存储库大小应该是包含在一个 Visual Studio 解决方案中的一个 Service Fabric 应用程序。
加长版： 完全可以将您的 Service Fabric 应用程序拆分为多个应用程序，最小的是您拥有的每个微服务的一个 Service Fabric 应用程序。这是一个好主意还是不完全取决于您尝试构建的应用程序的类型。服务之间是否存在依赖关系？您如何对服务进行分区？如果您想以协调的方式进行分区，是否有任何情况？您打算如何监控您的服务？如果您不想以协调的方式这样做，那么在同一个应用程序中拥有更多服务可能是有意义的。
将代码拆分为比您的 Visual Studio 解决方案更小的存储库可能只会给您带来麻烦。从技术上讲，您可以在一定程度上使用 Git 子模块或子树，但 Visual Studio 在解决方案中处理项目引用的方式可能会让您很快陷入合并地狱。
在升级 Service Fabric 应用程序时，实际上有一种方法可以让您根据服务清单中的版本号仅升级应用程序中已更改的服务。这称为 diff 包，可用于将应用程序部署到至少部署了一次应用程序的集群（即，它是升级，而不是安装）。如果您只升级应用程序中的少数服务，这可能会极大地影响部署的升级时间。 The full documentation for this can be found here。还有一个SO answer 对其进行了描述。
我会说，你的选择是，在开发中，不同收益之间的权衡。
将服务拆分为包含更少服务的更细粒度的应用程序可以使升级更容易（但从技术上讲，这种效果在某种程度上也可以通过使用 diff 包来实现）。这种方法的缺点是您必须将依赖关系作为服务之间的严格接口来管理。一种方法是将您的服务/参与者接口发布到私有 NuGet-feed。这反过来又会在您的开发管道中引入一些额外的复杂性。
将所有内容保存在同一个存储库、同一个 Visual Studio 解决方案、同一个 Service Fabric 应用程序中可能适用于较小的解决方案，但如果您的解决方案在合并、版本控制和发布方面有所增长，从长远来看可能很难使用。
【讨论】：
在我们的项目中，我们遵循与此类似的模式，但不是那么精细。每个 SF 应用程序都包含在它自己的存储库中，但我们将在一个应用程序中拥有多个特定的微服务。我们将我们的应用程序分成与最终应用程序相关的特定功能块（数据层、中间层、演示、分析等）。当我们升级时，我们将一次升级特定的应用程序，不一定是特定的服务。升级特定服务是一个巨大的 pita ops 明智之举。我们仍然有一个共享接口项目，我们使用 SF remoting 在不同的应用程序之间进行通信，我们之所以能够做到这一点，是因为我们在自己的 repo 中管理容器和接口，然后我们通过私有 nuget 服务器进行分发。这使得工作流程变得困难，但最终它很好，因为它让我们保持了解应用程序之间的接口兼容性。我们还有一些核心微服务，每个应用程序都将使用SF Nuget 分发这些微服务。它还很年轻，有一些锋利的边缘，但它很棒。
【讨论】：
阅读您的问题，听起来您的存储库拆分主要是为了部署问题，所以我将专注于这方面。
我们为每个 Service Fabric 应用程序（包含多个服务）使用一个 Git 存储库，这有助于简化持续集成和持续部署的完成方式：如果存储库（代码或配置）发生变化，SF 应用程序需要构建和部署。
如果您在线使用 VSTS 的生成和发布功能，则可以轻松利用可用于 Service Fabric 的生成任务来支持差异升级。使用“更新 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 应用程序的差异化升级。
【讨论】：
您不必将 Service Fabric 服务视为微服务。
代码/服务/应用程序等的 Service Fabric 分类为您提供了高度灵活的组合方式来满足您的需求（如前所述）。考虑一个事实，您可以在一个服务中运行更多代码包并尝试将其转换为微服务定义，这只会让事情变得更难处理。
由于 SF 应用程序是您的部署单元（是否包含一个或多个更新的服务），您应该努力以某种方式构建您的 repo/解决方案/SF 应用程序设置，以便您可以包含对一个 SF 应用程序的大多数更改（ = 一个解决方案和一个 repo）。
如果您遇到需要不断部署多个 SF 应用程序以进行更改的情况，您将无法高效工作。
【讨论】：