Самый быстрый способ сохранить файл для потоковой передачи из приложения Service Fabric? - PullRequest
Новая
       18

Самый быстрый способ сохранить файл для потоковой передачи из приложения Service Fabric?

0 голосов
/ 20 января 2019

Сценарий:

Я хочу приложение сервисной фабрики, которое может возвращать файл по запросу, например [GET] /{fileId}/read.

Предположим, что fileId связан с customerId, например, 

 =======================
   customerId  | fileId
 =======================
       1       |   1
 -----------------------
       1       |   2
 -----------------------
       1       |   3
 -----------------------
       2       |   4
 -----------------------
       2       |   5

Это различные комбинации (нет 2 fileId с для того же customerId).

Я хочу, чтобы customerId была единицей масштаба. Другими словами, нагрузка на customerId=326 не должна влиять на производительность customerId=913842, но нагрузка на customerId=326 может влиять на ее собственную производительность.

Я не настолько опытен в понимании государственных служб, надежных актеров, партий и т. Д.

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

     Node0        Node1       Node2     Node3    Node4
        \         /            |          \        /
         Customer1        Customer2        Customer3

                \
                 \

                  |
                  |
                  |
           [GET] /3/stream

и файл 3 может быть сохранен непосредственно на диске Node1 в E:\\files\foo.txt, поэтому его можно быстро передавать.

Это вообще возможно, или как лучше?

1 Ответ

0 голосов
/ 21 января 2019

Я бы не рекомендовал вам использовать нод-диски в качестве хранилища для ваших услуг.

Во-первых, поскольку узлы с вашими данными могут быть потеряны \ заменены, и вам потребуется обработать способ резервного копирования и восстановления этих файлов там, где работают службы. Кроме того, эфемерный диск в узле может потерять данные после перезагрузки (что-то общее случается).

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

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

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

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

  1. Использование хранилища Azure для хранения файлов
  2. Динамически распределяйте разделы узлов (Заказчик) вместо того, чтобы прикреплять их к узлам
  3. Установить ограничения ресурсов для служб (память и ЦП)
  4. Использовать пользовательские метрики
  5. Добавить ограничения скорости, чтобы ограничить использование для каждого клиента

С этими направлениями:

  1. вам не нужно беспокоиться об управлении файлами, поскольку хранилище Azure будет управлять репликацией для вас в соответствии с выбранной конфигурацией;
  2. Динамически распределенные сервисы будут эффективно использовать ресурсы, поэтому вы не выделяете полный узел для сервиса, и узел теряет ресурсы, тратя ресурсы (деньги).
  3. Ограничение лимитов памяти и ЦП, которые может использовать служба, не позволит службе использовать слишком много ресурсов, влияющих на другие службы.
  4. Используя пользовательские метрики, вы можете позволить сервисам сообщать о загрузке в Service Fabric; Service Fabric будет балансировать службы, чтобы избежать простоя узлов, когда другие заняты. Также можно использовать для автоматического масштабирования экземпляров служб, если они заняты.
  5. Добавление ограничения скорости к услугам предотвратит злоупотребление пользователями и более плавное использование, предотвращая внезапный всплеск использования одним клиентом, влияющий на других.
...