单独的git仓库中的服务结构项目

Question

遵循一个正常的微服务框架，我们希望将每个微服务放置在它自己的git仓库中，然后为Service Fabric项目提供一个仓库。当我们更新其中一个微服务时，Service Fabric项目将重新部署该服务。

有没有像这样分裂Service Fabric项目的任何例子？我注意到在他们的所有例子中，一切都在一个解决方案/资料库中。

Answer 1

在我们的项目中，我们遵循类似于此的模式，但没有那么细致。每个SF应用程序都包含在它自己的回购中，但我们将在应用程序中有多个特定的微服务。我们将应用程序分为与最终应用程序相关的特定功能块（数据层，中间层，演示文稿，分析等）。升级时，我们将一次升级特定的应用程序，而不一定是特定的服务。升级特定服务是一个巨大的挑战。我们仍然有一个共享的接口项目，我们使用SF远程处理来在不同的应用程序之间进行通信，我们可以这样做，因为我们通过自己的回购来管理容器和接口，然后我们通过私人的nuget服务器进行分发。这使工作流程变得很困难，但最终它很好，因为它使我们保持了应用程序之间的接口兼容性。我们也有一些核心的微服务，我们使用SF Nuget分发每个应用程序。它还年轻，有一些锋利的边缘，但它很棒。

Answer 2

tl; dr：找出在管理代码和个别服务发布方面最适合您的开发团队的东西。使用diff packages仅升级Service Fabric应用程序中的更改。最小的回购大小应该是包含在一个Visual Studio解决方案中的一个服务结构应用程序。

加长版： 这是完全有可能对您的服务光纤应用分成多个应用程序，最小的是一个服务织物应用你有每个微服务。如果这是一个好主意或者不完全取决于你正在尝试构建的应用程序的类型。服务之间是否存在任何依赖关系？你如何划分服务，当你想以协调的方式做到这一点时，是否有任何情况？你打算如何监控你的服务？如果你不想以协调一致的方式做到这一点，那么再次在同一个应用程序中提供更多的服务可能是有意义的。

将代码拆分成小于您的Visual Studio解决方案的回购可能只会导致您遇到麻烦。您可以在技术上与Git子模块或子树一起工作，但Visual Studio在解决方案中处理项目引用的方式很可能会使您最终陷入合并 - 地狱。

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

我想说，您的选择与发展一样，是不同收益之间的折衷。

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

如果您的解决方案在合并，版本控制和版本方面不断增长，那么同样的Visual Studio解决方案中保留所有内容，相同的服务结构应用程序可以用于较小的解决方案，但从长远来看可能很难。

Answer 3

您不应该将Service Fabric服务视为微服务。

的代码/服务/应用程序等服务织物分类为您提供了如何撰写您需要的高弹性（如已经指出的那样）。考虑一下这样一个事实，即你可以在一个服务中运行更多的代码包，并试图将其转换为微服务定义，这使得事情变得更加难以应付。

由于SF Appation是您的部署单位（无论是否包含一个或多个更新的服务），因此您应该努力以一种方式构建您的repo/solution/SF应用程序设置，以便您可以包含对一个SF App的大部分更改（=一个解决方案和一个回购）。

如果你在一个情况下，你需要不断部署多个应用程序的SF得到一个改变了得到的，你会不会生产。

Answer 4

阅读你的问题，这听起来像你的资料库分割主要是为部署的关注，所以我将专注于这方面。

我们为每个Service Fabric应用程序（包含多个服务）使用一个Git存储库，这有助于简化Continuous Integration和Continuous部署的完成方式：如果存储库中存在更改（代码或配置）应用程序需要被构建和部署。

如果您正在使用VSTS的生成和发布功能，在线，您可以轻松地利用可用的服务架构中的构建任务，以支持差分升级。使用“更新服务织物应用版本”任务（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应用程序的差分升级很容易结束。