Большая передача файлов / данных в микросервисной архитектуре

Моя компания в настоящее время работает над принятием микросервисной архитектуры, но мы сталкиваемся с некоторыми проблемами роста (шок!) На этом пути. Одна из ключевых проблем, с которыми мы сталкиваемся, заключается в том, как передавать большие объемы данных между нашими различными службами.

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

Проблема в следующем: имеет ли смысл для всех наших микросервисов принимать этот уникальный идентификатор как часть своего API для взаимодействия с документами или нет? Мне это кажется по своей сути неправильным - сервисы больше не являются независимыми и зависят от сервиса хранилища документов. Хотя я и признаю, что это может упростить разработку API и, возможно, даже получить некоторый выигрыш в производительности, результирующая связь больше, чем уравновешивает преимущества.

Кто-нибудь знает, как радужные единороги (Netflix, Amazon, Google и т. Д.) Справляются с большими файлами / обменом данными между их сервисами?

Кто-нибудь знает, как радужные единороги (Netflix, Amazon, Google и т. Д.) Справляются с большими файлами / обменом данными между их сервисами?

К сожалению, я не знаю, как они справляются с такими проблемами.

Проблема в следующем: имеет ли смысл для всех наших микросервисов принимать этот уникальный идентификатор как часть своего API для взаимодействия с документами или нет?

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

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

• Если вашему «приложению» нужно работать с документом, оно запрашивает соответствующий микросервис и обрабатывает его результаты.

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

Одна из ключевых проблем, с которыми мы сталкиваемся, заключается в том, как передавать большие объемы данных между нашими различными службами.

Это архитектурная проблема:

1. Уменьшите необходимость передавать большие объемы данных

   В идеале каждый сервис имеет все свои данные и не нуждается в передаче для простого обслуживания запросов. Как продолжение этой идеи - если у вас есть необходимость передавать данные, подумайте об избыточности (* в позитивном ключе_): имеет ли смысл иметь избыточность данных во многих местах (где они необходимы)? Подумайте, как возможные несоответствия могут повредить ваши процессы. Там нет передачи быстрее, как на самом деле нет .

2. Уменьшить размер самих данных

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

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

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

Лично я предпочел бы не использовать отдельную службу хранилища документов и идентификатор документа, а URL для доступа к документам (с надлежащей аутентификацией заголовка). При таком подходе вам не понадобятся другие службы, чтобы полагаться на службу документов, скорее, он мог бы просто использовать полный URL-адрес для доступа к документу. И также имеет смысл, когда речь идет о масштабировании, вы можете использовать несколько хранилищ документов как и когда хранилище растет и укажите URL.

Однако вам может потребоваться услуга (ы) для загрузки документа и получения его URL.

Кто-нибудь знает, как радужные единороги (Netflix, Amazon, Google и т. Д.) Справляются с большими файлами / обменом данными между их сервисами?

Ознакомьтесь со спецификациями REST API Amazon S3, похоже, они возвращают полный объект в байтах. Кажется, не так много вариантов, если вы разрабатываете микросервис. Ссылка формата ответа Amazon S3