我已经更新了答案，以添加更多详细信息，说明为什么不应使用默认服务(仅在生产中).

I have updated the answer to add more details why the default services should not be used (In production only).

在服务结构上，您有两个选择来创建服务:

On service fabric, you have two options to create your services:

• 声明性方法，通过默认服务功能完成，在该方法中，您描述了应使用ApplicationManifest作为应用程序的一部分运行的服务.
• 和动态(强制性)方式，一旦部署了应用程序，便使用powershell命令创建这些服务.

• The Declarative way, done via Default Services feature where you describe services that should run as part of your application using the ApplicationManifest.
• and the Dynamic(Imperative) way using powershell commands to create these services once the application is deployed.

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

The declarative way bring you the convenience of defining the expected structure of your application, so that Service Fabric does the job of creating and starting instances of your services according to the declaration in the ApplicationManifest. The convenience it gives you is very useful for development purposes, imagine if every time you had to debug an application, it had to: Build > Package > Deployed to Service Fabric > You had to manually start the many services that define your application. This would be too inconvenient, so that is why default service become handy.

另一种情况是，当您的应用程序定义不可变时，这意味着相同数量的服务和实例将在生产过程中始终保持不变.

Another scenario is when your application definition immutable, that means, the same number of services and instances will stay the same without variation throughout the time it is deployed in production.

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

But we know this is high unlikely that these definitions will keep the same throughout the years or even hours in a day, because the idea of microservices is that they should be scalable and flexible, so that we can tweak the configuration of individual services independent of each other.

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

By using default services, would be too complex for the orchestration logic identify what changes has been made on your services compared to the default specified in the original deployment, and in cases of conflict, which configuration should have priority, for example:

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

这些是可能发生的许多问题中的一些.这就是为什么您应该离开默认服务并动态地(紧急地)创建它们的原因，使用动态服务，服务结构将收到一个升级命令，并且将发生以下情况:

These is some of the many issues that can happen. This is why you should move away from default services and create them dynamically(imperatively), with dynamic services, service fabric will receive an upgrade command and what will happen is:

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

"This is my new application type package with new service type definitions, whatever version you get deployed there, replace for this version and keep the same configuration".

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

If a new configuration is required, you will provide as parameters for the deployment to override the old values or change it on a separate command. This will make things much simpler, as SF won't have to worry about different configurations and will just apply package changes to deployed services.

您还可以在以下链接上找到有关这些问题的好信息:

You can also find a nice info about these issues on these links:

• 服务结构Q& A 10
• 服务结构Q& A 11

• How not to use service fabric default services
• Service Fabric Q&A 10
• Service Fabric Q&A 11

关于您的主要问题:

有人对我如何获得优秀的开发人员有解决方案吗? 不使用DefaultServices而是使用Powershell体验 脚本?

Does anyone have a solution as to how I can get a good developer experience by not using DefaultServices and instead using Powershell scripts?

如果您想获得良好的体验，则应使用默认服务，这是为此而设计的，可以为开发人员提供良好的体验，而不必担心启动时需要运行的服务.

if you want a good experience you should use the default services, it is intended for this, give the developer a good experience without worrying about services required to run at startup.

诀窍是，在CI流程中，应在打包应用程序之前从应用程序清单中删除默认服务，以免日后面临弊端.

The trick is, during your CI process, you should remove the default services from the application manifest before you pack your application, so that you don't face the drawbacks later.

在CI(类似于VSTS Build)期间删除defaultServices，您可以在开发环境中使用defaultServices的好处，无需维护powershell脚本版本(如果有新版本)，则删除默认服务是作为构建步骤添加的非常简单的powershell脚本.除此之外，一切都保持不变.

Removing the defaultServices during CI (Like VSTS Build), you have the benefits of defaultServices on dev environment, don't have to maintain the powershell script versions(if a new version comes along) and the removal of the default services is a very simple powershell script added as a build step. Other than that, everything keeps the same.

Ps:我现在没有一个真正的脚本，但是会很简单，像这样:

Ps: I don't have a real script at hand now, but will be very simple like this:

$appManifest = "C:\Temp\ApplicationManifest.xml"     #you pass as parameter

[xml]$xml = Get-Content $appManifest

$xml.ApplicationManifest.DefaultServices.RemoveAll()

$xml.save($appManifest)