Передача великих файлів / даних в архітектурі мікросервісу

В даний час моя компанія працює над розробкою архітектури мікросервісу, але ми на цьому шляху стикаємося з певними зростаючими болями (шоком!). Одним із ключових моментів, з якими ми стикаємося, є передача великої кількості даних між нашими службами.

Як невеликий фон, у нас є магазин документів, який служить сховищем для будь-якого документа, з яким нам може знадобитися обробка у всій компанії. Взаємодія зі згаданим магазином здійснюється через сервіс, який надає клієнту унікальний ідентифікатор та місце для передачі документа. Пізніше можна знайти доступ до документа через пошук з наданим ідентифікатором.

Проблема в цьому - чи має сенс всі наші мікросервіси приймати цей унікальний ідентифікатор як частину свого API для взаємодії з документами чи ні? Для мене це суттєво неправильно - служби вже не є незалежними і покладаються на послуги магазину документів. Хоча я визнаю, це може спростити дизайн API і, можливо, навіть мати деякий приріст продуктивності, що призведе до з’єднання, більше, ніж противагу переваг.

Хтось знає, як єдинороги веселки (Netflix, Amazon, Google тощо) обробляють великі файли / обмін даними між своїми службами?

Хтось знає, як єдинороги веселки (Netflix, Amazon, Google тощо) обробляють великі файли / обмін даними між своїми службами?

На жаль, я не знаю, як вони вирішують подібні проблеми.

Проблема в цьому - чи має сенс всі наші мікросервіси приймати цей унікальний ідентифікатор як частину свого API для взаємодії з документами чи ні?

Він порушує Принцип єдиної відповідальності, який повинен бути притаманний архітектурі вашої мікросервісу. Одна мікросервіс - логічно один, фізично багато випадків, що представляють один - має стосуватися однієї теми .

У випадку з вашим зберіганням документів у вас є одна точка, куди надходять усі запити щодо документів (звичайно, ви могли розділити цю логічну одиницю на кілька сховищ документів для декількох видів документів).

• Якщо ваша "програма" потребує роботи над документом, вона запитує відповідну мікросервіс і обробляє її результати.

• Якщо іншій службі потрібен фактичний документ або його частини, він повинен запитати службу документування.

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

Це архітектурна проблема:

1. Зменшення потреби в передачі великих обсягів даних

   В ідеалі кожна служба має всі свої дані та не потребує передачі, щоб просто обслуговувати запити. Як розширення цієї ідеї - якщо у вас є потреба в передачі даних, подумайте про надмірність (* позитивним способом_): чи є сенс мати дані надлишковими в багатьох місцях (там, де вони потрібні)? Подумайте, як можливі невідповідності можуть завдати шкоди вашим процесам. Передачі немає швидше, як насправді немає .

2. Зменшіть розмір самих даних

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

Якщо ідентифікатор, повернутий у вашому магазині документів, є спосіб довідкових документів в рамках всієї системи, то це має сенс для всіх послуг , щоб визнати , що «ідентифікатор документа» на їх API , коли потреба обслуговування , щоб дізнатися , який документ вона повинна працювати.

Це не обов'язково створює тісніший зв'язок між послугами, ніж це потрібно. Служби, яким потрібно отримати доступ до документів, у будь-якому випадку мають доступ до служби зберігання документів, і їм потрібен цей ідентифікатор, щоб вказати магазину, до якого документа отримати доступ.
Сервісам, які не мають доступу до документів, можливо, потрібно буде передавати ідентифікатор документа разом, але для цих служб це буде лише довільна рядок, яка не створює залежності.

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

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

Хтось знає, як єдинороги веселки (Netflix, Amazon, Google тощо) обробляють великі файли / обмін даними між своїми службами?

Оформити API Amazon S3 REST API, схоже, вони повертають повний об'єкт у байтах. Здається, не так багато варіантів, якщо ви розробляєте мікросервіс. Посилання формату відповіді Amazon S3