在开发人员计算机上自动创建没有DefaultServices的服务

Question

在最近的Service Fabric社区问答第24版上，围绕在使用DefaultService构造ApplicationManifest.xml及其缺点方面进行了大量讨论。微软建议完全从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脚本来获得良好的开发人员体验的解决方案？

提前致谢

Answer 1

我已经更新了答案，以添加更多详细信息为什么不应该使用默认服务（仅在生产中）。

在服务结构上，您有两个创建服务的选项：

• 通过默认服务功能完成的声明式方式，您在其中描述应使用ApplicationManifest作为应用程序的一部分运行的服务。
• 和动态使用（势在必行）的方式PowerShell命令，一旦应用程序部署到创建这些服务。

该声明的方式带给你定义应用程序的预期结构的便利性，使服务织物做创建和启动根据在ApplicationManifest声明你的服务实例的工作。它给您带来的便利对于开发目的非常有用，请想象一下，如果每次必须调试应用程序时，它都必须：Build> Package> Deployed to Service Fabric>您必须手动启动定义应用程序的许多服务。这太不方便了，因此这就是默认服务变得方便的原因。

另一种情况是您的应用程序定义不可变时，这意味着相同数量的服务和实例将保持不变，并且在整个生产环境中都不会发生变化。

但是我们知道，这些定义在多年甚至一天之内保持不变的可能性很小，因为微服务的想法是它们应该具有可伸缩性和灵活性，以便我们可以独立于微服务来调整各个服务的配置。彼此。

通过使用默认服务，业务流程逻辑将很难确定与原始部署中指定的默认服务相比，您的服务已进行了哪些更改，并且在发生冲突的情况下，应优先使用哪种配置，例如：

• 部署的默认服务定义了一个包含5个实例的服务，部署后，您将执行powershell脚本更新为10个实例，然后新的应用程序升级即默认服务具有5个实例或新值为8，该怎么办？ ？哪一个是正确的？
• 您向默认服务中未定义的现有部署中添加了一个额外的命名服务（与其他名称相同类型的服务），当新的部署进入时会发生什么，并说不应使用此服务？删除它？和数据？如何从生产中删除此服务？如果我在开发过程中误删除了？
• 新版本将删除现有服务，部署失败，应如何重新创建旧服务？如果有任何数据要作为部署的一部分进行迁移？
• 服务已重命名。如何跟踪它已被重命名，而不是删除旧文件并添加新文件？

这些是可能发生的许多问题中的一些。这就是为什么您应该离开默认服务并动态（强制）创建它们的原因，有了动态服务，服务结构将收到一个升级命令，将发生以下情况：

“这是我的新应用程序类型包，带有新的服务类型定义，无论您在那里部署了什么版本，都可以替换该版本并保持相同的配置”。

如果需要新配置，则将提供参数作为部署参数，以覆盖旧值或在单独的命令上对其进行更改。这将使事情变得更加简单，因为SF不必担心不同的配置，只需将软件包更改应用于已部署的服务即可。

您还可以在以下链接中找到有关这些问题的详细信息：

• 如何不使用服务结构默认服务
• 服务架构问答10
• 服务架构问答11

关于您的主要问题：

是否有人通过不使用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)