引用多个外部Web API的单个Service Fabric应用程序 [英] Single Service Fabric application referencing multiple external Web API's

问题描述

我的问题与 有点相似 ，但是除非我丢失了某些内容，否则答案并不能真正帮助我.

My question is somewhat similar to this question, but the answer doesn't really help me, unless i'm missing something.

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

If i want to deploy 10+ stateless services (OWIN-based Web API's) into a Service Fabric cluster, well from my understanding of ASF, i would:

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

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

But wouldn't this involve creating all the Web API's in the same Visual Studio solution as the Service Fabric application?

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

My concern is if we want teams to be fully autonomous, they ideally shouldn't need to share the same Visual Studio solution?

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

Currently each "team" has their own GitHub repository and Visual Studio solution, and each API gets deployed independently.

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

I was hoping to port this setup to ASF, where each Web API is it's own solution, and they somehow get packaged into the one Service Fabric application.

有人可以帮我吗?

谢谢

推荐答案

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

I keep each service in it's own solution (and repo) and bring things together into a single application only at deployment time. Build and deployment occurs via PowerShell which can be triggered as part of a CI/CD process. Only the updated services are modified and I have it updating the manifest versions automatically using the current date/time.

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

For service that have other service dependencies, I've references their project within the solution so I can easily debug, but only the primary service is deployed.

要在答案中添加更多详细信息，注释框太小.

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

I created a directory to place the release versions in the correct SF directory structure. I copy the ApplicationManifest.xml for the release to that directory, though you could make this a repo and check just that file in. I have a buildrelease.ps1 that enumerates the repos and runs msbuild for the release configuration. For that configuration, I'm not building anything but the service to be deployed (no unit tests or other test apps for debugging purposes). The version is generated automatically based on the date and time, e.g. 2017_05_31_1702. This is what is updated in the service manifest and eventually in the application manifest. After a successful build, the service manifest is updated back in solution directory like this:

    $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.

Next msbuild is called again to package the SFProj.

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

今天，我仅构建具有已修改服务清单的服务，因此您必须记住在修改代码/配置时要修改清单.我想改善这一点，只是没有足够的时间.

Today I'm only building services that have a modified service manifest, so you have to remember to modify the manifest when you modify code/config. I'd like to improve that, just not enough time.

打包后，解决方案的发行版{service name} Service.pkg被复制到发行文件夹.脚本完成后，结果目录将包含正确格式的所有更改的服务.

After packaging, the solution's release{service name}Service.pkg is copied to the release folder. When the script is done, the resulting directory contains any changed services in the correct format.

下一个脚本是每个群集的部署脚本.我敢肯定可以创建一个数据驱动的.这将连接到远程群集，测试程序包，将程序包上传到映像存储，然后根据应用程序是否已存在进行新的或升级.我有一个可以部署到我的一体机的版本，因此我可以使用本地配置测试/调试一起运行的所有服务.

Next script is a deployment script per cluster. I'm sure one could be created that is data driven. This connects to the remote cluster, tests the package, uploads the package to the image store and does a new or upgrade depending on if the application already exists. I have a version of this that can deploy to my one-box so I can test/debug all of the services running together all using local configuration.

这篇关于引用多个外部Web API的单个Service Fabric应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！