在最近的Service Fabric社区问答第24版上，围绕在ApplicationManifest.xml中使用DefaultService构造进行了很多讨论，它的缺点是。微软建议完全从ApplicationManifest中忽略这一点，而应该修改Deploy-FabricApplication.ps1来构造应用程序的默认实现，以便开发人员仍然具有不错的F5体验。
因此，我已将Deploy-FabricApplication.ps1修改为以下内容(此摘录是脚本的底部):
if ($IsUpgrade)
{
$Action = "RegisterAndUpgrade"
if ($DeployOnly)
{
$Action = "Register"
}
$UpgradeParameters = $publishProfile.UpgradeDeployment.Parameters
if ($OverrideUpgradeBehavior -eq 'ForceUpgrade')
{
# Warning: Do not alter these upgrade parameters. It will create an inconsistency with Visual Studio's behavior.
$UpgradeParameters = @{ UnmonitoredAuto = $true; Force = $true }
}
$PublishParameters['Action'] = $Action
$PublishParameters['UpgradeParameters'] = $UpgradeParameters
$PublishParameters['UnregisterUnusedVersions'] = $UnregisterUnusedApplicationVersionsAfterUpgrade
Publish-UpgradedServiceFabricApplication @PublishParameters
}
else
{
$Action = "RegisterAndCreate"
if ($DeployOnly)
{
$Action = "Register"
}
$PublishParameters['Action'] = $Action
$PublishParameters['OverwriteBehavior'] = $OverwriteBehavior
$PublishParameters['SkipPackageValidation'] = $SkipPackageValidation
Publish-NewServiceFabricApplication @PublishParameters
#Get-ServiceFabricApplication
New-ServiceFabricService -Stateless -ApplicationName "fabric:/Acme.Hierarchy" -ServiceTypeName "Acme.Hierarchy.HierarchyServiceType" -ServiceName "fabric:/Acme.Hierarchy/Acme.Hierarchy.HierarchyService"-InstanceCount 1 -PartitionSchemeSingleton
}
上面的错误失败
FabricElementNotFoundException
但是，如果取消注释
#Get-ServiceFabricApplication行，您会发现它确实返回了ApplicationName : fabric:/Acme.Hierarchy
ApplicationTypeName : Acme.HierarchyType
ApplicationTypeVersion : 1.0.0
ApplicationParameters : { "_WFDebugParams_" = "[{"CodePackageName":"Code","Cod
ePackageLinkFolder":null,"ConfigPackageName":null,"Con
figPackageLinkFolder":null,"DataPackageName":null,"Dat
aPackageLinkFolder":null,"LockFile":null,"WorkingFolde
r":null,"ServiceManifestName":"Quantium.RetailToolkit.
Fabric.Hierarchy.HierarchyServicePkg","EntryPointType"
:"Main","DebugExePath":"C:\\Program Files
(x86)\\Microsoft Visual Studio\\2017\\Professional\\Co
mmon7\\Packages\\Debugger\\VsDebugLaunchNotify.exe","D
ebugArguments":"
{6286e1ef-907b-4371-961c-d833ab9509dd} -p [ProcessId]
-tid [ThreadId]","DebugParametersFile":null}]";
"Acme.Hierarchy.HierarchyServ
ice_InstanceCount" = "1" }
Create application succeeded.
并在发布脚本完成后运行失败的命令非常正常。
是否有人通过不使用DefaultServices而是使用Powershell脚本来获得良好的开发人员体验的解决方案？
提前致谢
最佳答案
我已经更新了答案，以添加更多详细信息为什么不应该使用默认服务(仅在生产中)。
在服务结构上，有两种创建服务的选项:
声明方式为您提供了定义应用程序预期结构的便利，因此Service Fabric可以根据ApplicationManifest中的声明来创建和启动服务实例。它给您带来的便利对于开发目的非常有用，请想象一下，如果每次必须调试应用程序时，它都必须:Build> Package> Deployed to Service Fabric>您必须手动启动定义应用程序的许多服务。这太不方便了，因此这就是默认服务变得方便的原因。
另一种情况是，当您的应用程序定义不可变时，这意味着相同数量的服务和实例将保持不变，并且在整个生产环境中都不会发生变化。
但是我们知道，这些定义在多年甚至一天之内保持不变的可能性很小，因为微服务的想法是它们应该具有可伸缩性和灵活性，以便我们可以独立于微服务来调整各个服务的配置。彼此。
通过使用默认服务，业务流程逻辑将很难确定与原始部署中指定的默认服务相比，您的服务已进行了哪些更改，并且在冲突的情况下，应该优先使用哪种配置，例如:
这些是可能发生的许多问题中的一些。这就是为什么您应该离开默认服务并动态(强制)创建它们的原因，有了动态服务，服务结构将收到一个升级命令，将发生以下情况:
“这是我的具有新服务类型的新应用程序类型包
定义，无论您在那里部署什么版本，都可以替换
版本并保持相同的配置”。
如果需要新配置，您将提供参数作为部署参数，以覆盖旧值或在单独的命令上对其进行更改。这将使事情变得更加简单，因为SF不必担心不同的配置，只需将软件包更改应用于已部署的服务即可。
您还可以在以下链接中找到有关这些问题的详细信息:
关于您的主要问题:
有谁对我如何获得优秀开发人员有解决方案
不使用DefaultServices而是使用Powershell体验
脚本？
如果您希望获得良好的体验，则应使用默认服务，这是为此目的而设计的，可为开发人员提供良好的体验，而不必担心启动时需要运行的服务。
诀窍在于，在CI流程中，应在打包应用程序之前从应用程序清单中删除默认服务，以免日后面临弊端。
在CI(如VSTS Build)期间删除defaultServices，您可以在开发环境中使用defaultServices的好处，不必维护powershell脚本版本(如果有新版本)，并且删除默认服务非常简单添加了powershell脚本作为构建步骤。除此之外，一切都保持不变。
附言:我现在没有真正的脚本，但是会很简单，例如:
$appManifest = "C:\Temp\ApplicationManifest.xml" #you pass as parameter
[xml]$xml = Get-Content $appManifest
$xml.ApplicationManifest.DefaultServices.RemoveAll()
$xml.save($appManifest)
关于azure-service-fabric - 在开发人员计算机上自动创建没有DefaultServices的服务，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50441340/