azure-service-fabric - 引用多个外部 Web API 的单个 Service Fabric 应用程序

Question

我的问题有点类似 this question ，但答案并没有真正帮助我，除非我遗漏了什么。

如果我想将 10 多个无状态服务(基于 OWIN 的 Web API)部署到 Service Fabric 集群中，根据我对 ASF 的理解，我会:

1. 在 Visual Studio 中创建一个新的 Service Fabric 应用程序(称之为“MyBackendServices”)
2. 创建 10 多个无状态 Web API
3. 将它们添加到 Service Fabric 应用程序
4. 部署到集群。

但这不会涉及在与 Service Fabric 应用程序相同的 Visual Studio 解决方案中创建所有 Web API 吗？

我担心的是，如果我们希望团队完全自主，理想情况下他们不需要共享相同的 Visual Studio 解决方案吗？

目前每个“团队”都有自己的 GitHub 存储库和 Visual Studio 解决方案，并且每个 API 都是独立部署的。

我希望将此设置移植到 ASF，其中每个 Web API 都是它自己的解决方案，并且它们以某种方式打包到一个 Service Fabric 应用程序中。

谁能帮我解决这个问题？

谢谢

Answer 1

我将每项服务都保留在它自己的解决方案(和存储库)中，并仅在部署时将它们整合到一个应用程序中。构建和部署通过 PowerShell 进行，可以作为 CI/CD 过程的一部分触发。只有更新的服务被修改，我让它使用当前日期/时间自动更新 list 版本。

对于具有其他服务依赖项的服务，我在解决方案中引用了他们的项目，因此我可以轻松调试，但只部署了主要服务。

在答案中添加更多细节，评论 block 太小。

我创建了一个目录以将发布版本放置在正确的 SF 目录结构中。我将发布的 ApplicationManifest.xml 复制到该目录，尽管您可以将其设为存储库并只 checkin 该文件。我有一个 buildrelease.ps1，它枚举存储库并为发布配置运行 msbuild。对于该配置，除了要部署的服务之外，我没有构建任何东西(没有单元测试或其他用于调试目的的测试应用程序)。版本是根据日期和时间自动生成的，例如2017_05_31_1702。这是在服务 list 中更新并最终在应用程序 list 中更新的内容。成功构建后，服务 list 将更新回解决方案目录，如下所示:

    $serviceManifestPath = "$solutionDir\src\${ServiceName}Service\PackageRoot\ServiceManifest.xml"
Set-ItemProperty $serviceManifestPath -name IsReadOnly -value $false

$serviceManifestXml = [xml](Get-Content $serviceManifestPath)
$ns = New-Object System.Xml.XmlNamespaceManager($serviceManifestXml.NameTable)
$ns.AddNamespace("ns", $serviceManifestXml.DocumentElement.NamespaceURI)

$serviceManifestXml.ServiceManifest.Version = $NewVersion
$serviceManifestXml.ServiceManifest.CodePackage.Version = $NewVersion
$serviceManifestXml.ServiceManifest.ConfigPackage.Version = $NewVersion
$serviceManifestXml.Save($serviceManifestPath)

接下来再次调用 msbuild 来打包 SFProj。

$buildResult = & $msBuild $sfproj /p:Configuration=Release /nologo /v:M /fl /flp:LogFile="msbuild.log;Verbosity=Normal" /nr:false /target:package

今天我只构建具有修改过的服务 list 的服务，因此您必须记住在修改代码/配置时修改 list 。我想改进它，只是时间不够。

打包后，将解决方案的release{service name}Service.pkg复制到release文件夹下。脚本完成后，生成的目录将以正确的格式包含所有已更改的服务。

下一个脚本是每个集群的部署脚本。我确信可以创建一个数据驱动的。这将连接到远程集群、测试包、将包上传到图像存储并根据应用程序是否已存在进行新的或升级。我有一个可以部署到我的一体机的版本，这样我就可以使用本地配置测试/调试一起运行的所有服务。