Блог

Я новичок в использовании Service Fabric и пытаюсь определить некоторые варианты проектирования. У меня есть библиотека классов, которая выполняет разные задачи. Некоторые задачи требуют больших ресурсов и выполняются долго (обработка сообщений из очередей), а другие недолговечны и должны реагировать (обработка запросов на задания от пользователей). Существует значительный объем кэшированных данных, поэтому общие процессы имеют смысл, а приложение не имеет состояния. Я хочу убедиться, что длительные задачи не истощают ресурсы других задач, а также что уровень использования высок.

1. Возможно ли создать в моем решении один проект службы без состояния (ссылающийся на мою библиотеку классов) и развернуть несколько именованных экземпляров StatelessService, совместно использующих один и тот же процесс, используя конфигурацию для разграничения задач, выполняемых этими экземплярами? С несколькими типами сервисов или без них (хотя они кажутся по одному на проект, поэтому я предполагаю, что это должен быть один тип сервиса)?
2. Если да, можно ли применить разные правила управления ресурсами к этим экземплярам службы, чтобы некоторые ресурсы можно было зарезервировать для пользовательских задач? Пока у меня создается впечатление, что это невозможно, когда службы совместно используют процесс.

1. Модель общего процесса по умолчанию определяет это:

В предыдущем разделе описывается модель размещения по умолчанию, предоставляемая Service Fabric, называемая моделью общего процесса. В этой модели для данного приложения на узле активируется только одна копия данного пакета услуг (который запускает все пакеты кода, содержащиеся в нем). Все копии всех служб данного типа ServiceType помещаются в пакет кода, который регистрирует этот тип ServiceType. Другими словами, все реплики всех служб на узле данного типа ServiceType совместно используют один и тот же процесс.

Можно указать несколько типов служб и несколько пакетов кода.

ServiceTypes объявляет, какие типы служб поддерживаются пакетами кода в этом манифесте. Когда служба создается для одного из этих типов служб, все пакеты кода, объявленные в этом манифесте, активируются путем запуска их точек входа. Ожидается, что результирующие процессы зарегистрируют поддерживаемые типы служб во время выполнения. Типы служб объявляются на уровне манифеста, а не на уровне пакета кода. Таким образом, при наличии нескольких пакетов кода все они активируются всякий раз, когда система ищет любой из объявленных типов служб.

2. Управление ресурсами настраивается в манифесте службы, а не на уровне экземпляра.