Микросервисный дизайн хранилища файлов

Обзор проблемы:
Я создаю весеннее приложение только для учебных целей. Я хотел бы создать микросервис только для файлов, которые:

  • в начале будет иметь только две основные конечные точки upload /download файл (используемый другими микросервисами, а не пользователем напрямую)
  • создайте базу данных только для этого микросервиса с таблицей file. По крайней мере, в начале.
  • хранить файлы в облаке (например, Amazon S3)
  • хранит мета-информацию о файле в таблице file. Под мета я имею в виду:
    • Url для хранения в облаке
    • Имя
    • Размер
    • Тип (каталог или файл)
    • Extension

Пример . flow:

  • микросервис A отправляет изображение: user_attachment.jpg к файлам микросервиса upload конечная точка.
  • сервер выполняет проверку, проверку безопасности и т. д.
  • отправляет файл в облачное хранилище, например Amazon S3
  • сохраняет мета-информацию об этом файле в локальной таблице с именем file. F.E. добавляет: INSERT INTO file (url, name, size, type, extension) VALUES ("http://aws.amazon.com/testapp/pictures/2018-09/picutre.jpg", "picture", 34233, "FILE", "JPG")
  • отправьте метаинформацию обратно в микросервис A, который инициализировал операцию загрузки.

Загрузка в облако будет происходить в другом потоке, асинхронно и, возможно, даже с помощью брокера сообщений.


Вопросы:

  1. Является ли это подходом, соответствующим принципам чистого /хорошего дизайна?
  2. Что хорошего /плохого в этом подходе?
  3. Как я могу сделать это лучше? (не хотите хранить файлы (контент) на компьютере, на котором запущено приложение [локально])

Разное:
Этот пример прост. Я считаю, что в коммерческих /больших проектах дизайн может иметь схожие предположения /основы. Итак, давайте предположим, что в микросервисе file есть несколько таблиц, и их структура и логика микросервиса усовершенствованы.

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

1 голос | спросил user3529850 9 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 09 Sep 2018 21:07:19 +0300 2018, 21:07:19

1 ответ


2

Целью сервиса в SOA является выполнение некоторой логики, которая в противном случае должна была бы дублироваться среди других сервисов. Эта логика, в свою очередь, является причиной существования сервиса.

В вашем случае вы не добавляете ценность через сервис. Любой другой сервис может легко получить доступ к S3 напрямую, учитывая, что S3 сам по себе является сервисом (это не ваш сервис, но здесь это не имеет значения).

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

Таким образом, вы собираетесь потратить две или три недели на разработку и, возможно, одну неделю на отладку (YMMV; я не знаю вашего опыта работы с HTTP, SOA и технологиями, которые вы хотите использовать для создания своего сервиса, но даже если у вас большой опыт, не стоит тратить на это менее двух недель, что много ).

  

Я просто хотел узнать, как это делается в коммерческих /крупных проектах.

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

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

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

  • Должен быть исправлен, а исправление требует изменения интерфейса,
  • Должен быть перемещен в другое место с изменением его URL,
  • Не работает, требуется автоматический выключатель, чтобы гарантировать, что клиентский сервис не отключается по очереди,
  • устарело, требует переноса клиента на что-то другое,

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

Наконец, многие разработчики имеют опыт работы с Amazon AWS (и, возможно, S3). Это означает, что когда вы нанимаете нового парня, он может легко понять, как служба хранит файлы, если она использует S3 напрямую. Если вы добавите уровень косвенности, это преимущество будет потеряно. И, что более важно, каждый раз, когда у кого-то возникает проблема с хранилищем, ему нужно будет спросить себя, возникает ли проблема в клиентской службе, у вашего посредника или у S3. Это увеличивает время отладки.

Итак:

  

Является ли это чистым подходом, соответствующим шаблонам дизайна?

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

  

Что хорошего /плохого в этом подходе?

Что хорошо: тот факт, что вы предоставляете интерфейс, который намного проще по сравнению с S3. Для разработчиков, незнакомых с AWS, S3 может быть довольно сложным.

Что плохого: уже говорилось выше.

  

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

Позвонив напрямую в S3.

ответил Arseni Mourzenko 10 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 10 Sep 2018 20:18:56 +0300 2018, 20:18:56

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132