Де повинна знаходитись бізнес-логіка в архітектурі мікросервісів?

Ще намагаюся обернути голову навколо архітектури мікросервісу, оскільки я звик до монолітного підходу

Припустимо, ми намагаємося побудувати надзвичайно спрощену систему бронювання Uber. Щоб спростити, скажімо , у нас є 3 послуги та API шлюзу для клієнта: Booking, Drivers, Notificationі ми маємо наступний робочий процес:

Під час створення нового бронювання:

1. Перевірте, чи наявний користувач вже має бронювання
2. Отримайте список доступних драйверів
3. Надішліть повідомлення водіям, щоб забрати бронювання
4. Водій бере за бронювання

Скажімо, все обмін повідомленнями відбувається за допомогою http-дзвінка, а не шини для обміну повідомленнями, як-от kafka, щоб все було просто.

Тому я подумав, що Bookingсервіс може перевірити наявне бронювання. Але тоді хто повинен отримувати список доступних драйверів та повідомлення? Я думаю про те, щоб зробити це на рівні шлюзу, але тоді логіка поділяється на два місця:

• Gateway - отримати список доступних драйверів + надсилати сповіщення
• Booking - перевірити наявність наявного бронювання

І я впевнений, що шлюз - це не правильне місце для цього, але я відчуваю, що якщо ми робимо це в Bookingсервісі, він стає щільно поєднаним?

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

Ще один спосіб зробити це, я думаю, що кожен проект має власну службу бронювання, яка розмовлятиме з базовою службою бронювання, але я не впевнений, який найкращий підхід тут :-)

Люди часто чують "мікро-сервіс" і думають "нано-сервіс", і це може викликати певну плутанину. Це мікросервіси , тому вам не потрібен окремий сервіс для кожної окремої організації. Все, що ви намагаєтесь зробити, повинно бути в послугах bookingта notificationпослугах. Вам не потрібна driverпослуга (для будь-якої дії, яку ви описали).

Отримання списку драйверів, доступних для бронювання, підпадає під bookingпослугу. Загальна проблема полягає в тому, щоб не групувати пов’язані дії в одну службу, це називається низькою узгодженістю, і це дуже погано. Пам'ятайте, що ви об’єднуєте речі в службу за проблемним доменом, а не за суттю.

Що стосується повторного використання, то перевагою наявності окремої мікро-служби є те, що тепер у вас можуть бути три окремі команди, які роблять програми для споживачів. Одна команда для стандартного веб-додатка html, додатка для android та iios. Усі ці різні програми можуть бути побудовані абсолютно по-різному, і виглядати відповідним для їх конкретної платформи (без повторення коду). Код bookingпослуги повторно використовуються всіма цими додатками, оскільки всі три додатки здійснюють http-дзвінки до служби, натомість мають власний код бронювання.

Типовий потік бронювання виглядатиме так:

1. Додаток Android викликає bookingслужбу, щоб отримати список доступних драйверів
2. Служба бронювання повертає список драйверів у додаток
3. Потім користувач вибирає драйвер і додаток називає метод "книги" bookingпослуги
4. bookingОбслуговування викликає notificationслужбу з деталями бронювання
5. notificationСлужба відправляє повідомлення водія, повідомивши йому про бронювання
6. Додаток для драйверів надсилає повідомлення notificationсервісу, коли вони знаходяться в межах милі від замовника
7. notificationСлужба надсилає повідомлення клієнту , що їх водій майже немає

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

Все залежить від вашої точної вимоги.

Скажімо, у вас є дві програми, які роблять бронювання:

1. Перший випадок: Один додаток може дозволити одному користувачеві бронювати кілька разів, а інший - лише один. Це означає, що обмеження на бронювання знаходиться на рівні заявки, тому що у вас є дві точки входу в систему бронювання (одна, яка дозволяє багаторазове бронювання, та, яка не робить), або ви просто перевіряєте це в мікросервісах відповідних застосування.
2. Другий випадок: частина визначення "Бронювання" є частиною того, що користувач не може мати декілька варіантів незалежно від програми, це правило справедливо для всієї системи: це означає, що ви можете поставити чек у мікросервісі бронювання.

Що стосується системи сповіщень, ви можете мати мікросервіси, які підписуються на послугу бронювання, щоб слухати будь-яке нове бронювання. Як такий мікросервіс бронювання повідомляє всіх абонентів, і вони діятимуть відповідно.

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

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

Але все-таки нам потрібно якось координувати це двоє. Існує проста відповідь: ви використовуєте браузер для отримання URI з індексної служби, а потім отримання даних із служби даних. Жодна служба "не знає" про іншу, і між ними абсолютно немає зв'язку. Я можу використовувати службу індексів з будь-якою іншою службою передачі даних і навпаки.

Це не обов'язково так, що це найкращий підхід у всіх сценаріях, але існує багато переваг для побудови речей таким чином, особливо для повторного використання в сценаріях, які наразі невідомі.