Я обновил ответ, чтобы добавить более подробную информацию о том, почему не следует использовать службы по умолчанию (только в производстве).
В сервисной фабрике у вас есть два варианта создания служб:
- Способ Декларативный , выполняемый с помощью функции служб по умолчанию, где вы описываете службы, которые должны работать как часть вашего приложения, с помощью ApplicationManifest.
- и Dynamic (Обязательный) способ использования команд powershell для создания этих служб после развертывания приложения.
Декларативный способ обеспечивает удобство определения ожидаемой структуры вашего приложения, так чтоService Fabric выполняет работу по созданию и запуску экземпляров ваших служб в соответствии с объявлением в ApplicationManifest.Это удобство очень полезно для целей разработки, представьте, что каждый раз, когда вам приходилось отлаживать приложение, ему приходилось: Build> Package> Deployed to Service Fabric> Вам приходилось вручную запускать множество сервисов, которые определяют ваше приложение.Это было бы слишком неудобно, поэтому служба по умолчанию стала удобной.
Другой сценарий - это когда определение вашего приложения неизменное, то есть одно и то же количество сервисов и экземпляров останется неизменным в течение всего времени его развертывания в производстве.
Но мы знаем, что маловероятно, что эти определения будут оставаться неизменными на протяжении лет или даже часов в день, потому что идея микросервисов заключается в том, что они должны быть масштабируемыми и гибкими, чтобы мы могли настроитьконфигурация отдельных служб, независимых друг от друга.
Использование служб по умолчанию будет слишком сложным для логики оркестровки, чтобы определить, какие изменения были внесены в ваши службы по сравнению со значением по умолчанию, указанным в исходном развертывании, и в случаяхконфликта, какая конфигурация должна иметь приоритет, например:
- Развернутые службы по умолчанию определяют службу с 5 экземплярами, после ее развертывания вы выполняете сценарий powershell для обновления до 10 экземпляров, затем новыйЧто должно произойти при обновлении приложения со службами по умолчанию, имеющими 5 экземпляров или новое значение 8?какой из них правильный?
- Вы добавляете дополнительные именованные службы (службы того же типа с другим именем) к существующему развертыванию, которое не определено в службах по умолчанию, что происходит, когда приходит новое развертывание, и говорят, что эта служба не должна бытьожидается?Удали это?А данные?Как этот сервис должен быть снят с производства?Если я удалил по ошибке во время разработки?
- Новая версия удаляет существующую службу, развертывание завершается неудачно, как следует восстановить старую службу?А если были какие-либо данные, которые нужно было перенести в рамках развертывания?
- Служба была переименована.Как отследить, что оно было переименовано вместо удаления старого и добавления нового?
Это некоторые из многих проблем, которые могут возникнуть.Вот почему вы должны отойти от сервисов по умолчанию и создать их динамически (обязательно) , с динамическими сервисами сервисная структура получит команду обновления и произойдет следующее:
«Это мой новый пакет типов приложений с новыми определениями типов служб, какую бы версию вы там не развернули, замените эту версию и сохраните ту же конфигурацию».
Если требуется новая конфигурация, вы будетепредоставьте в качестве параметров для развертывания переопределение старых значений или измените его отдельной командой.Это значительно упростит задачу, так как SF не придется беспокоиться о различных конфигурациях и будет просто применять изменения пакетов к развернутым службам.
Вы также можете найти хорошую информацию об этих проблемах по этим ссылкам:
Относительно вашего основного вопроса:
У кого-нибудь есть решение относительно того, какЯ могу получить хороший опыт разработчика, не используя DefaultServices и вместо этого используя скрипты Powershell?
Если вы хотите получить хороший опыт, вы должны использовать сервисы по умолчанию, это предназначено для этого, дайте разработчику хорошийопыт, не беспокоясь о службах, необходимых для запуска при запуске.
Хитрость заключается в том, что во время процесса CI вы должны удалить службы по умолчанию из манифеста приложения перед упаковкой приложения, чтобы вы не столкнулись сНедостатки позже.
Удаляя defaultServices во время CI (например, VSTS Build), вы получаете преимущества defaultServices в среде разработки, не нужно поддерживать версии сценариев powershell (если появляется новая версия) иУдаление сервисов по умолчанию - очень простой скрипт powershell, добавленный в качестве шага сборки.Кроме этого, все остается прежним.
Ps: у меня нет настоящего сценария под рукой, но он будет очень простым, как этот:
$appManifest = "C:\Temp\ApplicationManifest.xml" #you pass as parameter
[xml]$xml = Get-Content $appManifest
$xml.ApplicationManifest.DefaultServices.RemoveAll()
$xml.save($appManifest)