Публикация метаданных в Service Fabric

Question

Итак, у меня есть эта идея, над которой я работаю, где сервисы на некоторых узлах должны динамически обнаруживать другие службы во время выполнения на основе метаданных, которые они могут публиковать. И я пытаюсь выяснить, как это сделать.

Некоторые из этих метаданных будут обнаружены на локальной машине во время выполнения, но затем должны быть опубликованы в Ткань, чтобы другие службы могли принимать на нее решения.

Я вижу материал расширения в ServiceManifests. Это хорошее начало. Но похоже, что вы можете изменять или добавлять расширения во время выполнения. Это было бы чудесно!

Представьте себе мой прецедент. У меня много машин на Fabric, с множеством сервисов, развернутых для них. То, что я рекламирую, - это аудиокодеки, которые может поддерживать данный компьютер. Некоторые узлы имеют DirectShow. Таким образом, они будут публиковать локальные кодеки. На некоторых машинах работают 32-битные службы и публикуются 32-битные кодеки DirectShow, которые у них есть (это действительно то, что мне нужно, поскольку у меня есть некоторые проприетарные кодеки ACM, которые работают только в 32 бит). Некоторые машины - это Linux-машины и хотят предоставить их кодеки GStreamer.

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

И тогда каждый будет хорошо сообщать о своей информации о здоровье и нагрузке, поэтому ткань может определить, как масштабироваться.

Каждая из этих служб будет поддерживать один и тот же интерфейс IService, но каждый из них будет использоваться только клиентами, которые решили использовать их на основе опубликованных метаданных.

Answer 1

В сервисе Fabric способ думать об этой проблеме - это сервисная точка зрения, а не машинная точка зрения. Другими словами, что делает каждый сервис в кластере поддержки, а не то, что каждый машина поддержка. Таким образом, вы можете использовать множество встроенных функций Service Fabric для поиска и запросов, потому что абстракция, предоставляемая платформой, действительно касается услуг больше, чем о машинах.

Один из способов сделать это - с ограничениями размещения и экземплярами службы, представляющими каждый кодек, поддерживаемый кластером в целом. Это означает, что у вас будет экземпляр службы, представляющей кодек, который работает только на машинах, поддерживающих этот кодек. Вот упрощенный пример:

Предположим, у меня есть тип сервиса, называемый «AudioProcessor», который выполняет некоторую обработку звука с использованием любого кодека.

И давайте иметь 5 узлов в кластере, где каждый узел поддерживает один из кодеков A, B, C, D и E. Я буду отмечать каждый узел свойством узла, соответствующим кодеку, который он поддерживает (узел свойство может быть просто любой строкой, которую я хочу). Обратите внимание, что предполагается, что я, владелец кластера, знаю кодеки, поддерживаемые каждой машиной.

Теперь я могу создать 5 экземпляров типа сервиса AudioProcessor, по одному для каждого кодека. Поскольку каждый экземпляр получает уникальное имя службы, находящееся в формате URI, я могу создать иерархию с именами кодеков в ней для обнаружения через встроенные службы обслуживания и инструментов запросов Fabric, например, «fabric:/AudioApp/Processor/A «для кодека A. Затем я использую ограничение места размещения для каждого экземпляра, которое соответствует заданному ярусу I, установленному на каждом узле, чтобы гарантировать, что кодек, представленный экземпляром службы, доступен на узле.

Вот что все это выглядит, когда развертывается все:

Node 1 - Кодек: Экземпляр: ткань/AudioApp/Процессор/A

Узел 2 - Кодек: B Instance: ткань/AudioApp/Процессор/B

Узел 3 - кодек: С Экземпляр: ткань/AudioApp/Процессор/C

Узел 4 - кодек: D Экземпляр: ткань/AudioApp/Процессор/D

узел 5 - Кодек: E Instance: ткань/AudioApp/Процессор/E

Так что теперь я могу делать вещи, как:

• Найти все кодеки кластера поддерживает, запрашивая список экземпляров службы AudioProcessor и изучение их имен (аналогично получению списка URI в HTTP API).
• Отправить запрос на обработку сервиса, который поддерживает кодек B с помощью разделяющей ткани:/AudioApp/AudioProcessor/B
• масштабироваться мощность переработки кодека C путем добавления новых машин, которые поддерживают кодек C - Service Fabric автоматически поместит новую Экземпляр «C» AudioProcessor на новом узле.
• Добавьте машины, поддерживающие несколько кодеков. Используя свойства нескольких узлов на нем, Service Fabric автоматически разместит на нем правильные экземпляры службы.

Путь потребитель думает об этом приложении теперь по линии «есть ли служба, которые поддерживают кодек E?» или «Мне нужно поговорить с службами A, C и D, чтобы обработать этот файл, потому что у них есть кодеки, которые мне нужны».